Avoiding "round-trip" API calls and performance

Originally posted by Korval:
Why is it that nobody (besides Mesa3D) has a nice, GL-compliant, open-source (MIT or BSD license) matrix stack implementation out there?
You can use mine korval, I’ll make a special license for you.

Originally posted by knackered:
[quote]Originally posted by V-man:
Calling glFinish is not necessary for the driver. The driver could just keep track of the matrices in a large array on the CPU side.
Yes it could run through the display list at compile time and store the resultant matrix state.
But I can’t see it being optimized enough to do that to avoid the special case of someone calling glGetFloatv. It is more likely it would call glFinish for every get.
[/QUOTE]Getting matrices is different than getting the framebuffer.
If you call glReadPixels, then the driver has to wait for the GPU to finish.
If you call glGetFloat then the driver will just compute or just retrieve the matrix from RAM and memcpy to your memory.

For example :


Even if the GPU hasn’t completed to render the model, the glGetFloat will be able to return the matrix to you immediatly.

Well, not really. Imagine you have the command buffer, where different matrix operations are located together with rendering operations. If you call glGet, the driver has to return the result of the last matrix operation. Basically this means, that the buffer has to be processed to the point where no matrix operations are pending. So it means waiting for the remaining (rendering) operations. Of course, you can optimize this, but I don’t think the driver developers would bother. BTW, this is another reason we need LP soon :slight_smile: