Announcement

Collapse
No announcement yet.

Radeon R600 Tiling Patches Are Ready

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • glisse
    replied
    Originally posted by PuckPoltergeist View Post
    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.

    Leave a comment:


  • PuckPoltergeist
    replied
    Originally posted by PuckPoltergeist View Post
    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.

    Leave a comment:


  • PuckPoltergeist
    replied
    Originally posted by PuckPoltergeist View Post
    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.

    Leave a comment:


  • droste
    replied
    Originally posted by ChrisXY View Post
    Yay, it's in mesa master:
    Code:
    ../../../../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:

    Code:
    From 99054a12175583ab4ef2f14e5a1fe6146e830479 Mon Sep 17 00:00:00 2001
    From: Tobias Droste <[email protected]>
    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 <[email protected]>
    ---
     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
    Last edited by droste; 07 February 2012, 11:21 AM.

    Leave a comment:


  • xming
    replied
    Rebooted and everything still works as before, I don't see any difference (no performance difference, no obvious regression). How can I tell 2D tiling is working?

    Code:
    grep -i tili Xorg.0.log
    [    17.568] (**) RADEON(0): Option "ColorTiling" "1"
    [    17.568] (**) RADEON(0): Option "ColorTiling2D" "on"
    [    17.581] (II) RADEON(0): KMS Color Tiling: enabled
    I also "(II) RADEON(0): KMS Color Tiling: enabled" before 2D tiling, it seems to me that "ColorTiling2D" "on" is accepted so it's in use, I don't have any error/warnings in dmesg/X.log.

    Leave a comment:


  • xming
    replied
    Everything except the kernel bits are merged into master, successfully built libdrm (230ec7d7bbf1e8a7e263d471b21afb08c28eba0c), mesa (938671397f6e88b68e77c93d6b440f9602950fbe) and xf86-video-ati (615033f2b5e3817e335e9d022fc9fdcf8ac8b11a), built a 3.2.5 kernel with latest drm and 0001-drm-radeon-*.patch, going to reboot.

    Leave a comment:


  • ChrisXY
    replied
    Yay, it's in mesa master:
    Code:
    ../../../../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'

    Leave a comment:


  • PuckPoltergeist
    replied
    Originally posted by glisse View Post
    What's your screen resolution ?
    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.

    Leave a comment:


  • RavFX
    replied
    Originally posted by siride View Post
    My experience with the patches was not good. When no compositing manager was running, I got a blank screen, but with a working mouse cursor and keyboard (I was able to log in to KDE this way). Once the compositing manager was loaded, it was very slow, but this appears to be because dmesg was being spammed with command stream errors (which were themselves likely the reason for the slowness). I'm sure I may have misapplied a patch (none of the kernel patches applied cleanly to 3.3-rc2) or messed something else up. I'll just wait until these things are at least in git master.
    I got about the same problem. Black screen with working mouse in gdm or E17.

    Solution :
    1 - Unplug the second monitor.
    2 - Launch X, login
    3 - Plug second monitor
    4 - xrandr the second monitor
    5 - ???
    6 - Profit!

    My second monitor is VGA with a DVI adaptor, I don't know if it's related.

    Note : I get plenty of
    Code:
    [   95.902752] radeon 0000:01:00.0: r600_cs_track_validate_cb invalid tiling 5 for 0 (0x08110568)
    [   95.902754] radeon 0000:01:00.0: r600_packet3_check:1604 invalid cmd stream 856
    [   95.902755] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
    when I try to launch X with the two monitor. With the unpluging trick, I don't get any cs error.

    Leave a comment:


  • Zephiris
    replied
    I'm getting similar errors as PuckPoltergeist with a 6950 2GB with 1440x900 screen resolution.
    All of the relevant software are git master versions with the patches applied where applicable (now that mesa and xf86-video-ati are updated, that leaves kernel).

    These kinds of errors are with ColorTiling+ColorTiling2D set to off in xorg.conf:
    Code:
    [   14.397349] radeon 0000:01:00.0: evergreen_cs_track_validate_texture:728 texture bo too small (layer size 5529600, offset 0, max layer 1, depth 1, bo size 5324800) (1536 900)
    [   14.397351] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
    [   14.905432] radeon 0000:01:00.0: evergreen_cs_track_validate_cb:443 cb[0] bo too small (layer size 5554176, offset 0, max layer 1, bo size 5529600, slice 21695)
    [   14.905434] radeon 0000:01:00.0: evergreen_cs_track_validate_cb:447 problematic surf: (1536 904) (1 4 1 0 0 4 0)
    [   14.905435] radeon 0000:01:00.0: evergreen_packet3_check:1918 invalid cmd stream 462
    These are with either on:
    Code:
    [  142.928652] radeon 0000:01:00.0: evergreen_cs_track_validate_texture:728 texture bo too small (layer size 5529600, offset 0, max layer 1, depth 1, bo size 5324800) (1536 900)
    [  142.928654] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
    [  143.169816] radeon 0000:01:00.0: evergreen_surface_value_conv_check:329 invalid array mode 5
    [  143.169818] radeon 0000:01:00.0: evergreen_packet3_check:1918 invalid cmd stream 462
    [  143.169819] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
    [  143.235577] radeon 0000:01:00.0: evergreen_surface_value_conv_check:329 invalid array mode 5
    [  143.235578] radeon 0000:01:00.0: evergreen_packet3_check:1918 invalid cmd stream 819
    [  143.235580] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
    It's impossible to get a working screen (for me) unless the DDX is reverted to a non-patched version.

    Leave a comment:

Working...
X