[Mesa-dev] Performance glxSwapBuffers 32 bit vs. 64 bit

Mathias Fröhlich Mathias.Froehlich at gmx.net
Thu Nov 10 22:35:24 PST 2011


On Thursday, November 10, 2011 18:42:13 Michel Dänzer wrote:
> On Don, 2011-11-10 at 11:01 +0100, Theiss, Ingo wrote:
> > The function calls of mesa/state_tracker/st_cb_readpixels.c:382 ->
> > st_readpixels and mesa/main/pack.c:552 -> _mesa_pack_rgba_span_float
> > clearly stands out when comparing the 32 bit and 64 bit profile.
> I'm afraid that's a red herring, as I don't think glXSwapBuffers calls
> glReadPixels under any circumstances. I suspect the time inside
> glXSwapBuffers isn't spent on CPU cycles but rather waiting for some
> kind of event(s). Offhand I don't know any better way to debug that than
> attaching gdb, interrupting execution every now and then and hoping to
> catch it somewhere inside glXSwapBuffers. Maybe others have better
> ideas.

Well he is using VirtualGL which intercepts glXSwapBuffers by LD_PRELOAD'ing a 
shared library containing this and several other functions.
The aim of VirtualGL is to render on the applicatoin side even for a remote 
display. To make this work they create an application local accelerated gl 
context render into this one and on glXSwapBuffers read the back buffer and send 
it the same way over the X connection like the software renderer does.

So It makes sense to find a glReadPixels in VirtualGL's glxSwapBuffers.

What VirtualGL provides is application side *accelerated* rendering which 
makes highly sense for example if your vizualization application runs in a 
computation center far from the display and close to the actual simulation 
producing really *huge* amount of data.



More information about the mesa-dev mailing list