Announcement

Collapse
No announcement yet.

Radeon R600 Tiling Patches Are Ready

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

  • #11
    Originally posted by ChrisXY View Post
    Is there a recommended kernel branch that contains radeon work but maybe not potentially new unstable kernel features, radeon-drm-testing perhaps? Or should we just use master?

    Latest git of mesa, xf86-video-ati and libdrm isn't much of a problem, but the kernel...

    Also, why a xorg.conf setting? Would that be different from R600_TILING=1?
    For this, all you need is the 3.3 series kernel (currently on rc2) which isn't all that bleeding edge, especially now that all the worst bugs of the -rc1 have been fixed (rc1 is always pretty hairy, but rc2 is like 99.9% identical to the final release).

    You then have to apply a patch to the kernel, a patch to mesa master, regular old libdrm master (without any patches now that they're merged), and a patch to the DDX. DDX shouldn't need a patch before long, and it'll probably hit mesa master eventually too. Once it does, the only patch you'll need is the kernel until 3.4-rc is out.



    0001-drm-* = for kernel, will be in mainline by linux 3.4-rc1

    0001-r600-* = for DDX (xf86-video-ati), will be applied to master soon (?)

    0001-r600g-* = for mesa gallium3d, will be applied to master no later than when they branch for mesa 8.1

    0001-radeon-* = for libdrm, but currently all of these are merged to master so don't download or apply them

    To "apply" them, just use

    git apply 0001-whatever.patch

    in the top directory of the sources. Then build like you normally would build from source, out of the scope of this mini-howto.

    Comment


    • #12
      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.

      Comment


      • #13
        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.
        Uh, what? The kernel patches do apply to 3.3-rc2. You need to first apply http://people.freedesktop.org/~gliss...amout-v7.patch and then http://people.freedesktop.org/~gliss...ng-infor.patch (in that order). Actually if git can't understand the streamout patch's formatting, go to http://article.gmane.org/gmane.comp....h=streamout+v7 and grab it from the text.

        I've tested it myself with 3.3-rc2, so don't tell me it doesn't apply there would be a problem on your end if it doesn't apply.

        Comment


        • #14
          Originally posted by bongmaster2
          can you provide performance numbers with swapbufferswait off and pcie_gen2 on?
          Maybe at some point, but performance "numbers" aren't going to mean much because the biggest improvement for me is not in raw FPS, but in FPS stability (i.e. less stalls).

          For example, with 1D tiling, panning the camera around your ship in sector space in Star Trek Online would yield constant framerate hiccups / pipeline stalls and it was so bad that you'd hear the sound crackle because wine couldn't feed data fast enough to pulseaudio while also managing the 3d stuff.

          With 2d, that very rarely happens (e.g. if you are looking at a *ton* of ships, maybe it'll happen, but not in the typical case of seeing some ships here and there). So basically it went from "always choppy" to "rarely choppy", and the raw framerate when not panning the camera went from (air numbers, guessed based on visual perception) ~20 to ~50.

          Also, there's one particular object in STO that, for some reason or another, causes FPS to absolutely tank when it's within your viewport. This is the case both with, and without 2D tiling. But what I noticed is that the performance drop suffered when viewing this object with 2D tiling is much less dramatic. So if before my FPS was 0.5 when that object is in my view, now I get about 5 fps instead, which is somewhat usable. Keep in mind that whatever the reason for this object's slowness, it's probably something specific to STO, so don't consider this "the norm" for r600g. Indeed, there are many areas of the game where this object doesn't appear at all, and the performance is very playable with 2D tiling, usually running in the 40s to 50s fps. And this is with swapbufferswait on, and pcie_gen2 on.

          Comment


          • #15
            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.
            Your ddx is properly patched but your compositor is not using the proper patched mesa driver. As i can't go back in time (my delorean is at the shop right now ...) i can't fix already release mesa, that's why there is a ddx option to only enable 2D tiling if you know for sure that you have proper mesa. If you are on x64-64 make sure you used ./autogen.sh --prefix=/usr --libdir=/usr/lib64 ... the libdir argument is important.

            Comment


            • #16
              wanted to try this but no luck
              had to compile mesa without egl and NWN2 whitch works without 2Dtiling didnt work
              no picture just some white garbage on screen

              Comment


              • #17
                Originally posted by pixo View Post
                wanted to try this but no luck
                had to compile mesa without egl and NWN2 whitch works without 2Dtiling didnt work
                no picture just some white garbage on screen
                Install apitrace, run a trace, compress it with xz, and upload it somewhere. I'll try to reproduce it locally, and you might be able to pull Glisse's ear to get him to look at it too.

                Also, when it worked without 2d tiling, were you using *old* drivers, or a very recent git master without 2d tiling? If you were using old drivers, the issue you're hitting might be a regression unrelated to tiling. Try it first with git master but with 2d tiling disabled (for example, boot up a non-tiling 3.2 kernel).

                Also, what radeon hardware do you have?

                Comment


                • #18
                  Originally posted by pixo View Post
                  wanted to try this but no luck
                  had to compile mesa without egl
                  With egl I get this linking-error:

                  gmake[3]: Entering directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/gallium/targets/egl-static'
                  /bin/sh ../../../../bin/mklib -o egl_gallium.so -noprefix -linker 'x86_64-pc-linux-gnu-g++' \
                  -ldflags '-L../../../../lib64 -Wl,--no-undefined -Wl,-O1 -Wl,--as-needed -L/usr/lib64/llvm -ludis86 -lpthread -lffi -ldl -lm ' \
                  -cplusplus -install ../../../../lib64/egl \
                  egl.o egl_pipe.o egl_st.o -Wl,--start-group ../../../../src/gallium/auxiliary/libgallium.a ../../../../src/gallium/drivers/identity/libidentity.a ../../../../src/gallium/drivers/llvmpipe/libllvmpipe.a ../../../../src/gallium/drivers/r600/libr600.a ../../../../src/gallium/drivers/rbug/librbug.a ../../../../src/gallium/drivers/softpipe/libsoftpipe.a ../../../../src/gallium/drivers/trace/libtrace.a ../../../../src/gallium/state_trackers/egl/libegl.a ../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a ../../../../src/gallium/winsys/sw/xlib/libws_xlib.a ../../../../src/mesa/libmesagallium.a -Wl,--end-group \
                  -lEGL -lX11 -lXext -lXfixes -ldl -ldrm -lglapi -lm -lpthread -lrt -ludev -lLLVMBitWriter -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMX86Info -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport
                  mklib: Making Linux shared library: egl_gallium.so
                  ../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a(radeon_drm_winsys.o): In function `radeon_winsys_destroy':
                  radeon_drm_winsys.c.text+0xdc): 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+0x409): undefined reference to `radeon_surface_manager_free'
                  radeon_drm_winsys.c.text+0x5a1): 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+0x88): undefined reference to `radeon_surface_init'
                  collect2: ld returned 1 exit status
                  mklib: Installing egl_gallium.so in ../../../../lib64/egl
                  mv: cannot stat `egl_gallium.so': No such file or directory
                  /usr/bin/install -c -d /var/tmp/portage/media-libs/mesa-9999/image//usr/lib64/egl
                  for out in ../../../../lib64/egl/egl_gallium.so; do \
                  /bin/sh ../../../../bin/minstall -m 755 "$out" /var/tmp/portage/media-libs/mesa-9999/image//usr/lib64/egl; \
                  done
                  Unknown type of argument: ../../../../lib64/egl/egl_gallium.so
                  gmake[3]: *** [install] Error 1
                  gmake[3]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/gallium/targets/egl-static'
                  gmake[2]: *** [install] Error 1
                  gmake[2]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/gallium/targets'
                  make[1]: *** [install] Error 1
                  make[1]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src'
                  make: *** [install] Error 1

                  edit:

                  Hm, even with egl disabled it doesn't work. After kdm came up, I got a garbled screen and dmesg said:

                  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 !

                  I had to disable ColorTiling and ColorTiling2D in xorg.conf to get X working again.

                  This happend with patched kernel, drm (from upstream git), mesa and xf86-video-ati driver.
                  Last edited by PuckPoltergeist; 05 February 2012, 07:15 PM.

                  Comment


                  • #19
                    The following patch should fix it:

                    Code:
                    From d9286b87bebfc9d79b2037d9b1cb199679419837 Mon Sep 17 00:00:00 2001
                    From: Tobias Droste <[email protected]>
                    Date: Mon, 6 Feb 2012 01:51:28 +0100
                    Subject: [PATCH] build: Add libdrm_radeon when linking egl and gbm
                    
                    this fixes undefined references when creating egl_gallium and r600g
                    
                    Signed-off-by: Tobias Droste <[email protected]>
                    ---
                     src/gallium/targets/egl-static/Makefile |    2 ++
                     src/gallium/targets/gbm/Makefile        |    2 ++                                                     
                     2 files changed, 4 insertions(+), 0 deletions(-)                                                      
                                                                                                                           
                    diff --git a/src/gallium/targets/egl-static/Makefile b/src/gallium/targets/egl-static/Makefile                                                              
                    index 70e4362..02a55ee 100644                                                                                                                               
                    --- a/src/gallium/targets/egl-static/Makefile
                    +++ b/src/gallium/targets/egl-static/Makefile
                    @@ -115,6 +115,7 @@ egl_CPPFLAGS += -D_EGL_PIPE_R300=1
                     egl_LIBS += \
                            $(TOP)/src/gallium/winsys/radeon/drm/libradeonwinsys.a \
                            $(TOP)/src/gallium/drivers/r300/libr300.a
                    +egl_SYS += -ldrm_radeon
                     endif
                     endif
                     
                    @@ -125,6 +126,7 @@ egl_CPPFLAGS += -D_EGL_PIPE_R600=1
                     egl_LIBS += \
                            $(TOP)/src/gallium/winsys/radeon/drm/libradeonwinsys.a \
                            $(TOP)/src/gallium/drivers/r600/libr600.a
                    +egl_SYS += -ldrm_radeon
                     endif
                     endif
                     
                    diff --git a/src/gallium/targets/gbm/Makefile b/src/gallium/targets/gbm/Makefile
                    index ce56f93..ca58a97 100644
                    --- a/src/gallium/targets/gbm/Makefile
                    +++ b/src/gallium/targets/gbm/Makefile
                    @@ -114,6 +114,7 @@ ifneq ($(findstring radeon/drm,$(GALLIUM_WINSYS_DIRS)),)
                     ifneq ($(findstring r300,$(GALLIUM_DRIVERS_DIRS)),)
                     _pipe_TARGETS_CC += $(PIPE_PREFIX)r300.so
                     pipe_SOURCES += pipe_r300.c
                    +pipe_LDFLAGS += -ldrm_radeon
                     endif
                     endif
                     
                    @@ -121,6 +122,7 @@ ifneq ($(findstring radeon/drm,$(GALLIUM_WINSYS_DIRS)),)
                     ifneq ($(findstring r600,$(GALLIUM_DRIVERS_DIRS)),)
                     _pipe_TARGETS_CC += $(PIPE_PREFIX)r600.so
                     pipe_SOURCES += pipe_r600.c
                    +pipe_LDFLAGS += -ldrm_radeon
                     endif
                     endif
                     
                    -- 
                    1.7.7

                    Comment


                    • #20
                      Originally posted by pali View Post
                      > The ColorTiling2D option though still needs to be enabled within the xorg.conf for proper support.

                      How to enable it? Which option must be added to xorg.conf?
                      same question

                      Comment

                      Working...
                      X