Announcement

Collapse
No announcement yet.

A Big Comparison Of The AMD Catalyst, Mesa & Gallium3D Drive

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

  • I upgrade to latest git once every few days, and I seem to remember that adding the color tiling option in xorg boosted OpenArena framerate by about 60%, and other people here reported similar things.

    I might have been related to a number of other optimisations which landed at the same time, I'm not sure. Bridgman should know better than I do, in any case.

    I can imagine that it is more important at higher resolutions, due to the additional bandwith needed, so maybe the gain is much smaller at lower resolutions.

    EDIT: you're right, I wasn't talking about averages.

    Comment


    • Yeah, I think we are saying the same thing. I'm going from memory so you may actually know better than me here

      Either way, all of the improvements add up over time and good things are happening.
      Test signature

      Comment


      • With the current 1D tiling code, we only implement 1D tiling for the back buffer. Ideally we'd 2D tile all buffers and textures. r600g has preliminary support for this but it requires 2.6.37 and some ddx and r600g patches. These patches against the kms-pflip branch of the ddx:
        http://people.freedesktop.org/~agd5f/all_2D_tiling.diff
        and mesa:
        http://people.freedesktop.org/~agd5f...ling_mesa.diff
        add preliminary support.

        Comment


        • Originally posted by bongmaster2
          arent they rdy for primetime like your pageflipping patches?
          id love to enable pageflipping without building from git and patching the source manualls. just an xorg.conf option like color tiling
          The drm pageflipping patches are scheduled to go upstream in 2.6.38, so for now you'll need to use development versions. As for the 2D tiling patches, they require 2.6.37 and probably some more stability testing before I commit them. Hopefully after I pull the ddx pflip stuff into master I'll have some time to get them integrated.

          Comment


          • Woah, exciting things ahead! Thanks.

            Comment


            • Originally posted by agd5f View Post
              The drm pageflipping patches are scheduled to go upstream in 2.6.38, so for now you'll need to use development versions. As for the 2D tiling patches, they require 2.6.37 and probably some more stability testing before I commit them. Hopefully after I pull the ddx pflip stuff into master I'll have some time to get them integrated.
              I asked this many, many times, but never got an answer: Can I use the development DRM drivers on the current stable kernel? If so, how?

              Comment


              • Originally posted by RealNC View Post
                I asked this many, many times, but never got an answer: Can I use the development DRM drivers on the current stable kernel? If so, how?
                You can either use the drm development tree as is, or merge the changes in drm-next into your current kernel tree (2.6.37) using git.

                Comment


                • I unpacked the 2.6.37 tarball. Not sure what to do next in order to update its DRM drivers :-P

                  Comment


                  • Originally posted by RealNC View Post
                    I unpacked the 2.6.37 tarball. Not sure what to do next in order to update its DRM drivers :-P
                    You can't use a tarball to do a git merge. You need to clone either Linus' tree (http://git.kernel.org/?p=linux/kerne....git;a=summary) or Dave's (http://git.kernel.org/?p=linux/kerne...ed/drm-2.6.git) and then add the other one as a remote, fetch the branch you want, do the merge and resolve any conflicts. It's probably easiest to just check out Dave's drm-next branch (2.6.37-rc8 based) and use that directly:
                    git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
                    cd drm-2.6
                    git checkout -b drm-next origin/drm-next

                    Comment


                    • Wouldn't that leave me with an rc8 kernel instead of .37 final?

                      Comment

                      Working...
                      X