Announcement

Collapse
No announcement yet.

R600/700 Mesa Driver Picks Up Blit Support

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

  • #11
    Yeah that could make sense.

    Comment


    • #12
      Originally posted by bridgman View Post
      Maybe 2D with a compositor running (where the compositor uses 3D) ?
      yeah, especially compiz and kwin with compositing

      all the newer chips don't have "native" 2D support or acceleration support anymore if I remember right - so bit blitting which is mainly targeted at the 3D engine / helping it to operate autonomously should improve both 2D and 3D (both are "run" or accelerated by the 3D engine)

      Comment


      • #13
        I guess the point others were trying to make is that the X driver has had 2D blit code (using the 3D *hardware*) for a long time - what's new is making more use of blit code in the 3D *driver* (which would not affect 2D operations done by the X driver).

        There was a blit routine in drm for a while, but it was only used for GLSwapBuffers AFAIK; now presumably other functions are being accelerated as well.
        Test signature

        Comment


        • #14
          The blit code in mesa accelerates glCopyTex(Sub)Image and could also be used to accelerate glReadPixels. It's pretty much the same code as used by EXA for copies and the drm for buffer moves and textures uploads.
          Last edited by agd5f; 16 January 2010, 12:43 PM.

          Comment


          • #15
            Great, another stinkin' GL command I have to go and understand
            Test signature

            Comment


            • #16
              What a shame. I was just getting used to the Frames Per Days metric

              Comment


              • #17
                Well, in my case (RHD4850, Phenom II, Kwin) 2D now "feels" slightly degraded performance-wise.
                Is it possible that the relatively fast CPU did a better job (for now) than the new blitter implementation?
                Last edited by entropy; 16 January 2010, 01:57 PM.

                Comment


                • #18
                  Originally posted by entropy View Post
                  Well, in my case (RHD4850, Phenom II, Kwin) 2D now "feels" slightly degraded performance-wise.
                  Does that mean the relatively fast CPU does a better job (for now) than the current blitter implementation?
                  This isn't some magical general speed up for 3D as the article might have you believe. The new code accelerates glCopyTex(Sub)Image, which is fairly specific. Most 3D apps don't use that (reading back from textures) which is why they already run pretty well. If an app makes use of glCopyTex(Sub)Image it would likely have been REALLY slow before blit support. I doubt the new code is used in your case. Other than perhaps tiny copies (where the setup overhead is more than the data copied), using the 3d engine will be faster. Compare gearbox before and after blit support or openarena with bloom enabled. Also, note that the new code is only available with KMS, so it is not used at all with UMS.

                  Comment


                  • #19
                    Huge speedup on Quake Live. It's playable again.

                    Comment


                    • #20
                      Originally posted by pvtcupcakes View Post
                      Huge speedup on Quake Live. It's playable again.
                      Great, I was wondering why it has been that slow until now

                      Comment

                      Working...
                      X