Bug 27186 - Visual corruption with new r6xx/r7xx accel code
Summary: Visual corruption with new r6xx/r7xx accel code
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.5 (2009.10)
Hardware: All All
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-18 15:35 UTC by Damien Mir
Modified: 2010-03-23 15:32 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Taskbar corrupted (16.67 KB, image/png)
2010-03-18 15:35 UTC, Damien Mir
no flags Details
possible fix (606 bytes, patch)
2010-03-22 09:05 UTC, Alex Deucher
no flags Details | Splinter Review
use consistent write domain (499 bytes, patch)
2010-03-22 09:47 UTC, K.S.
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Damien Mir 2010-03-18 15:35:34 UTC
Created attachment 34221 [details]
Taskbar corrupted

Starting with commit :
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=488c9fd8300505cc6c0c2f8f0f00849f27cc5d63

I am experiencing some visual corruption, mostly in KDE taskbar and on rare occasions on other KDE desktop plasmoids.
At some point, items/icons are randomly disappearing and re-appearing again when hovering the mouse on them.
It often starts to occur when switching desktop (I run Kwin with GL compositing).

Each time a "corruption" occurs, I get the following msg in Xorg.log :
reloc emit failure -22 (set_render_target 262)
reloc emit failure -22 (set_render_target 279)
reloc emit failure -22 (set_render_target 283)
Needless to say it is filled with such msgs after some time in the X session.

I first suspected a bug in Mesa, but it wasn't. Reverting previous to the above commit solves the problem.

My setup :
Xorg 1.7.6
Mesa libdrm xf86-video-ati from git
2.6.33 or next + glisse/drm
Comment 1 K.S. 2010-03-22 05:36:08 UTC
same here on an RV770 with Xorg 1.6.5 + drm-radeon-testing (commit 7fc3c459022ec0b1d08bbd4fe05615f0d0a13dd0) + xf86-video-ati head
but additionally on dmesg i get:
[drm:r600_cs_packet_next_reloc_mm] *ERROR* No packet3 for relocation for packet at 5402.
radeon 0000:01:00.0: bad SET_CONTEXT_REG 0x28040
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
Comment 2 Alex Deucher 2010-03-22 09:05:18 UTC
Created attachment 34323 [details] [review]
possible fix

Does this patch help?
Comment 3 K.S. 2010-03-22 09:47:01 UTC
Created attachment 34326 [details] [review]
use consistent write domain

patch fixes the problem for me but probably has performance implications. The problem seems to be that in R600PrepareCopy() a bo is created from a pixmap with a write domain = VRAM and later on in R600DoPrepareCopy() , set_render_target is called and tries to BATCH_RELOC that bo to wd = VRAM | GTT which results in the check in cs_gem_write_reloc() that checks for old_wd == reloc_wd to fail. As i do not know if the dest bo is allowed to be in GTT i didn't change the initial placement but adapted the reloc.
Comment 4 Damien Mir 2010-03-22 13:26:04 UTC
Patch no. 34323 didn't help.
Same corruptions and dmesg :
[  548.332504] [drm:r600_cs_packet_next_reloc_mm] *ERROR* No packet3 for relocation for packet at 725.
[  548.332528] [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28040
[  548.332546] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

Patch no. 34326 indeed worked. Cannot tell about performance however.
Comment 5 Alex Deucher 2010-03-22 14:02:02 UTC
(In reply to comment #4)

> Patch no. 34326 indeed worked. Cannot tell about performance however.
> 

It's basically akin to reverting the initial commit.  The domain is always forced to vram so GetImage will be slow.
Comment 6 Alex Deucher 2010-03-23 10:37:27 UTC
I've just pushed some changes to xf86-video-ati that may help.
Comment 7 Damien Mir 2010-03-23 15:32:22 UTC
(In reply to comment #6)
> I've just pushed some changes to xf86-video-ati that may help.
> 

Yes they do ! I guess this bug can be closed.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.