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

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. How we collect and use information is described in our Privacy Policy.