Bug 27186

Summary:

Visual corruption with new r6xx/r7xx accel code

Product:

xorg

Reporter:

Damien Mir <dm>

Component:

Driver/Radeon

Assignee:

xf86-video-ati maintainers <xorg-driver-ati>

Status:

RESOLVED FIXED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

medium

CC:

devh

Version:

7.5 (2009.10)

Hardware:

All

OS:

All

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Taskbar corrupted	none
possible fix	none
use consistent write domain	none

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.