Bug 19484

Created attachment 21840 [details]
Xorg.0.log

Does disabling the DRI (Option "DRI" "false") or disabling render accel (Option "RenderAccel" "false") fix it?

Created attachment 21841 [details]
Small corruption with "RenderAccel" "false"

I tried Option          "RenderAccel" "false"
And the corruption is almost gone: there's still a minor corruption on the icon that is selected.

Disabling RenderAccel makes X use lots of cpu for simple operations such as scrolling, so this shouldn't be a real solution.

Should I still try disabling DRI?

the remaining corruption is probably DFS related.  try Option "AccelDFS" "off"
See bug 18397

(In reply to comment #3)
> Created an attachment (id=21841) [details]
> Small corruption with "RenderAccel" "false"
> 
> I tried Option          "RenderAccel" "false"
> And the corruption is almost gone: there's still a minor corruption on the icon
> that is selected.

Can you try with renderaccel enabled and DFS disabled?

> 
> Disabling RenderAccel makes X use lots of cpu for simple operations such as
> scrolling, so this shouldn't be a real solution.
> 

Right.  the trick is to find out what the app is doing that's broken.

> Should I still try disabling DRI?
> 

No, it looks like it's render and/or dfs related.

Created attachment 21844 [details]
Corruption with "AccelDFS" "off" and "RenderAccel" "true"

With "AccelDFS" "off" and "RenderAccel" "true" the corruption is different but much much more easier to reproduce than with "RenderAccel" "false".

This is still very noticeable with:

Xorg server 1.6.0
Mesa from git
xf86-video-ati from git
drm from git
kde 4.3 from svn

All packages updated today.

Can you try:
Option "DRI" "FALSE"
just to cover all the bases.

I can confirm that disabling DRI solves this issue completely.

The AccelDFS issue is tracked in another report.

With DRI and RenderAccel enabled, does either of

    Option "ExaNoUploadToScreen"

or

    Option "ExaOptimizeMigration" "off"

work around the bigger problem?

Option "ExaNoUploadToScreen" does not solve the issue.
Instead, Option "ExaOptimizeMigration" "off" does solve it.
What's the drawback in disabling this?

Oh by the way, I just noticed that the exact same bug happens with my brother's PC:

01:05.0 VGA compatible controller: ATI Technologies Inc RS690 [Radeon X1200 Series]

But he's using RadeonHD. So it must be some common code between radeon and radeonhd.

(In reply to comment #11)
> Instead, Option "ExaOptimizeMigration" "off" does solve it.
> What's the drawback in disabling this?

Potentially lower performance due to more pixmap migration overhead in some cases.

(In reply to comment #12)
> But he's using RadeonHD. So it must be some common code between radeon and
> radeonhd.

The acceleration code in both drivers is related, but this bug could even be in the EXA core. It could be related to bug 19940 and bug 16416.

So I'm guessing there's no real solution yet? Beside disabling that option.
Should I close this bug?

(In reply to comment #14)
> Should I close this bug?

Not until the bug has been found and fixed.

I'm having a hard time reproducing this with EXA from current upstream xserver Git. Can you try that?

I can still reproduce this very easily with xorg-server 1.6.1
I'll try with git master, hopefully it won't break anything else :)

Created attachment 25674 [details]
corruption with xorg-server git master

Still present with xorg-server master :(
The corruption is slightly different though:

- in the first case it should show only directories, but instead it shows some files from my home
- in the second case it shows gray rectangles (instead of black ones)

I will attach Xorg.0.log

Created attachment 25675 [details]
Xorg.0.log with git master

Mass version move, cvs -> git

Actually, the Git master log file shows the Composite extension being enabled, so this might be bug 22566.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/268.