Radeon R600 Tiling Patches Are Ready

[droste]

Yay, it's in mesa master:

../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a(radeon_drm_winsys.o): In function `radeon_winsys_destroy':
radeon_drm_winsys.c:(.text+0xbc): undefined reference to `radeon_surface_manager_free'
../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a(radeon_drm_winsys.o): In function `radeon_drm_winsys_create':
radeon_drm_winsys.c:(.text+0x3e9): undefined reference to `radeon_surface_manager_free'
radeon_drm_winsys.c:(.text+0x572): undefined reference to `radeon_surface_manager_new'
../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a(radeon_drm_winsys.o): In function `radeon_drm_winsys_surface_best':
radeon_drm_winsys.c:(.text+0x68): undefined reference to `radeon_surface_best'
../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a(radeon_drm_winsys.o): In function `radeon_drm_winsys_surface_init':
radeon_drm_winsys.c:(.text+0x78): undefined reference to `radeon_surface_init'

new patch:

From 99054a12175583ab4ef2f14e5a1fe6146e830479 Mon Sep 17 00:00:00 2001
From: Tobias Droste <tdroste@gmx.de>
Date: Tue, 7 Feb 2012 16:20:21 +0100
Subject: [PATCH] gallium/gbm: r300 and r600 now depend on libdrm

fixes undefined references in libradeonwinsys.a when linking

Signed-off-by: Tobias Droste <tdroste@gmx.de>
---
 src/gallium/targets/gbm/Makefile |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/gallium/targets/gbm/Makefile b/src/gallium/targets/gbm/Makefile
index ce56f93..2737b79 100644
--- a/src/gallium/targets/gbm/Makefile
+++ b/src/gallium/targets/gbm/Makefile
@@ -72,11 +72,13 @@ nouveau_SYS = -ldrm_nouveau
 r300_LIBS = \
        $(TOP)/src/gallium/winsys/radeon/drm/libradeonwinsys.a \
        $(TOP)/src/gallium/drivers/r300/libr300.a
+r300_SYS += -ldrm_radeon
 
 # r600 pipe driver
 r600_LIBS = \
        $(TOP)/src/gallium/winsys/radeon/drm/libradeonwinsys.a \
        $(TOP)/src/gallium/drivers/r600/libr600.a
+r600_SYS += -ldrm_radeon
 
 # vmwgfx pipe driver
 vmwgfx_LIBS = \
-- 
1.7.7

[PuckPoltergeist]

native resolution: 1366x768 60.0

other possible resolutions are:

1280x720 59.9
1152x768 59.8
1024x768 59.9
800x600 59.9
848x480 59.7
720x480 59.7
640x480 59.4

Will test, if any other works. At the moment I'm rebuilding drm, mesa and ddx from git.

Ok, the xserver crash when playing video is related to the ddx-patch. And the screen corruptions with invalid command stream errors are related to the resolution. 1024x768 works fine, with and without ColorTiling2D enabled.

[PuckPoltergeist]

Ok, the xserver crash when playing video is related to the ddx-patch. And the screen corruptions with invalid command stream errors are related to the resolution. 1024x768 works fine, with and without ColorTiling2D enabled.

So, even 1366x768 works when activating afterwards. I can start with 1280x720, 1152x768 or 1024x768, no problem. Only starting with native resolution 1366x768 results in garbled screen. When switching afterwards to 1366x768 (KDE tools oder xrandr), it seems to work.
But video playback with xv doesn't work, regardless of the resolution. Playback with vdpau seems to work.

[glisse]

So, even 1366x768 works when activating afterwards. I can start with 1280x720, 1152x768 or 1024x768, no problem. Only starting with native resolution 1366x768 results in garbled screen. When switching afterwards to 1366x768 (KDE tools oder xrandr), it seems to work.
But video playback with xv doesn't work, regardless of the resolution. Playback with vdpau seems to work.

I pushed a fix to ddx upstream it should be ok now.

[ChrisXY]

new patch:

Thank you very much.

[PuckPoltergeist]

I pushed a fix to ddx upstream it should be ok now.

Partly ok. I get a short flickering with garbled screen with one message in dmesg:

radeon 0000:01:00.0: evergreen_surface_value_conv_check:329 invalid array mode 5
radeon 0000:01:00.0: evergreen_packet3_check:1918 invalid cmd stream 454
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

After this it works.


Video playback with xv still leads to a xserver crash.

[Zephiris]

I pushed a fix to ddx upstream it should be ok now.

I'm able to log in with startx now, but with ColorTiling2D just starting X or loading any compressed textures (with ColorTiling2D disabled), I get a kernel crash with a BUG on the memcpy in radeon_cs_update_pages on 3.3-rc2 with my 6950.

[ChrisXY]

I have applied the two 0001-drm* patches (can you please provide the second patch in less comfortable way than in a mail to a mailinglist complete with headers with the patch attached encoded in base64?)
Is it normal that git apply doesn't have any output whatsoever?

But it seems good:

[    13.302] (**) RADEON(0): Option "ColorTiling2D" "on"

I have only tested xonotic on "high" so far. Looks ok, only some minor problems with reflections in the water.

HD 6550M, 3.3rc2

edit:
No, it doesn't:

xrandr --output HDMI-0 --rotate right --mode 1600x1200 --right-of LVDS --output LVDS --mode 1600x900

Result=

Right screen looks good, left screen is very broken. When I move windows on the right screen the broken graphics on the left screen move as well. Screenshot with scrot looks normal for both screens.
Happens also with no 2d color tiling enabled. Happens only when the right screen is rotated left OR right. With rotate normal it looks ok.
It also looks good with xrandr --output HDMI-0 --rotate right --mode 1280x1024 --right-of LVDS --output LVDS --mode 1024x768.
Maybe both need to be the same aspect ratio for rotation?
The problem are not the kernel patches. Just installed mainline 3.3rc2 and it still happens. My uneducated guess would be the ddx.

[Wilfred]

Hey, if stuff is in git master, couldn't I just install xorg-edgers on ubuntu and recompile the ubuntu kernel with patch?
If I want to test this that is.

[PuckPoltergeist]

Video playback with xv still leads to a xserver crash.

Seems to be fixed by commit f63262e2f112a348c45f0dcecd891c8b6d9c5ee8 from Michel Dänzer.