Bug 48310 - Slow 2D rendering on r300 with xf86-video-ati-6.14.x
Summary: Slow 2D rendering on r300 with xf86-video-ati-6.14.x
Status: RESOLVED DUPLICATE of bug 34486
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.4 (2008.09)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-04 12:59 UTC by Homer
Modified: 2012-04-04 13:18 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Homer 2012-04-04 12:59:49 UTC
2D rendering is very slow, especially noticeable with text in terminal windows. I've been affected by this problem since xf86-video-ati-6.14.0 (currently on xf86-video-ati-6.14.3 and xorg-server-1.11.2). Manually setting Option "ColorTiling" "off" solves the problem.

I did a git bisect and traced the cause to this:

kms/pre-6xx: fix pageflipping with tiling
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=ef9bfb262db7004bef3704e5d914687e50d3fca4

Which apparently also caused bug #33738. However, that was resolved with this:

KMS Color Tiling requires xserver which supports EXA_MIXED_PIXMAPS.
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=fcf0cca9c0ab0f692b222f619aee8f1cdad3b519

So AFAICT that commit should have made it into 6.14.3, which is what I have, but for some reason "ColorTiling" is not being set to "off" by default (with no predefined xorg.conf), when apparently it needs to be, and that's what that commit claims to do.

I also note a commit after 6.14.3 which enables tiling by default for xserver 1.9.4.901, however 6.14.4 hasn't yet been pushed downstream (Gentoo).

check for xserver 1.9.4.901 to enable tiling by default
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=bcdb54fe16ebf2e239b84eebf20e8adfe5094bff

So my questions are:

Is ColorTiling supposed to be on or off for r300 on xorg-server 1.11.2 (i.e. does it work in theory), and if it's supposed to work then why doesn't it in my case (i.e. do I have a new bug, or is this an ongoing issue with EXA)?

Is xf86-video-ati-6.14.3 supposed to turn off ColorTiling by default, and if so then why isn't it doing so in my case (was the commit reversed, or do I have some weirdness happing)?

Just to be clear, I have a working solution (Option "ColorTiling" "off"), but I have to create an xorg.conf and specify this manually, and IMO this should be handled automatically by the xserver instead (e.g. LiveCD scenario), or fixed if it's an EXA bug.

Please ask if you need further info.

Thanks.
Comment 1 Alex Deucher 2012-04-04 13:18:39 UTC
(In reply to comment #0)
> So my questions are:
> 
> Is ColorTiling supposed to be on or off for r300 on xorg-server 1.11.2 (i.e.
> does it work in theory), and if it's supposed to work then why doesn't it in my
> case (i.e. do I have a new bug, or is this an ongoing issue with EXA)?
> 

It depends whether the xserver you are using suports EXA_MIXED_PIXMAPS or not.  If tiling is enabled, then presumably your xserver does support EXA_MIXED_PIXMAPS.

Your issue is a duplicate of bug 34486.

> Is xf86-video-ati-6.14.3 supposed to turn off ColorTiling by default, and if so
> then why isn't it doing so in my case (was the commit reversed, or do I have
> some weirdness happing)?

Tiling is enabled by default assuming your xserver supports EXA_MIXED_PIXMAPS.

> 
> Just to be clear, I have a working solution (Option "ColorTiling" "off"), but I
> have to create an xorg.conf and specify this manually, and IMO this should be
> handled automatically by the xserver instead (e.g. LiveCD scenario), or fixed
> if it's an EXA bug.

The bug is that the applications you are using are choosing software rendering paths rather than hardware rendering paths.  Tilint improves performance for hw accelerated paths at the cost of software rendering performance.

*** This bug has been marked as a duplicate of bug 34486 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.