Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 50

Thread: R600/700 Mesa Driver Picks Up Blit Support

  1. #11
    Join Date
    Dec 2008
    Posts
    983

    Default

    Yeah that could make sense.

  2. #12
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    620

    Default

    Quote 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)

  3. #13
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,381

    Default

    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.

  4. #14
    Join Date
    Dec 2007
    Posts
    2,315

    Default

    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; 01-16-2010 at 11:43 AM.

  5. #15
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,381

    Default

    Great, another stinkin' GL command I have to go and understand

  6. #16
    Join Date
    May 2008
    Posts
    598

    Default

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

  7. #17
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    904

    Default

    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; 01-16-2010 at 12:57 PM.

  8. #18
    Join Date
    Dec 2007
    Posts
    2,315

    Default

    Quote 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.

  9. #19
    Join Date
    Jul 2009
    Posts
    416

    Default

    Huge speedup on Quake Live. It's playable again.

  10. #20
    Join Date
    Jan 2007
    Location
    Germany
    Posts
    2,114

    Default

    Quote 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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •