Announcement

Collapse
No announcement yet.

Radeon R600 Tiling Patches Are Ready

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

  • Radeon R600 Tiling Patches Are Ready

    Phoronix: Radeon R600 Tiling Patches Are Ready

    Jerome Glisse, the Red Hat developer commonly working on the open-source Radeon graphics driver, has announced that he believes the R600 Gallium3D tiling support is complete...

    http://www.phoronix.com/vr.php?view=MTA1MjY

  • #2
    Awesome!

    I can't wait to see benchmarks about this interesting feature Thank you Jerome Glisse!

    Comment


    • #3
      This is just fantastic! All Linux Radeon users thank you, Jerome
      Have a nice break, and please do HiZ if it is your domain. Thanks.

      Comment


      • #4
        > 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?

        Comment


        • #5
          Originally posted by Drago View Post
          Have a nice break, and please do HiZ if it is your domain. Thanks.
          That would be great! For those who don't know what HiZ stands for, it means Hierarchical Z-Buffer. There is some code to support this feature, but it's stuck since August as you can see here and according to freedesktop's bug report it doesn't work.

          Comment


          • #6
            https://bugs.freedesktop.org/show_bug.cgi?id=36602

            Hi-Z seems stalled unfortunately
            ## VGA ##
            AMD: X1950XTX, HD3870, HD5870
            Intel: GMA45, HD3000 (Core i5 2500K)

            Comment


            • #7
              3.4 is a long wait.

              Comment


              • #8
                Originally posted by ormaaj View Post
                3.4 is a long wait.
                This is a large patch, and 3.3 merge windows is closed. I wish it could be faster

                Comment


                • #9
                  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?

                  Comment


                  • #10
                    The patches are easy to apply, and they work so well that I can use them with Star Trek Online running under wine with an evergreen card. It improves performance a great deal and actually reduces stalling significantly (one of the previous issues I was having is that it was "choppy", but not with 2d tiling).

                    Great work, Jerome! Truly one of the better things to hit r600g in a LONG time.

                    Comment


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

                      http://people.freedesktop.org/~glisse/tiling/

                      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

                              Working...
                              X