If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
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.
Would (or could) this be useful for games/apps that want to "manually" draw on top of a rendered scene (notwithstanding whether this is a good idea in general on modern graphics hardware)? I recall a Wine bug report that turned out to be a game doing something like this (to draw a crosshair, of all things) and cratering its FPS as a result.
If so, I think the issue was that SS2 running under Wine made heavy use of GLReadPixels and GLDrawPixels to push the entire screen back and forth between system and video memory every frame. I don't think those calls have been accelerated with blit - I think I remember someone mentioning that it might be possible but I don't remember where I saw that.
I'm not sufficiently familiar with the Wine code to know if the GL calls which *have* been accelerated by blit could be used here instead of the GLReadPixels and GLDrawPixels calls.
Is this with a compositor ? My dim understanding was that the blit code currently accelerated a couple of texture functions which glxgears didn't use, so presumably the speedup must be happening somewhere else in the stack (eg compositor or something).