Inertia's picture

OpenGL Commands and the GC

Hello again,

This is not really OpenTK related, but since you are the Guru behind the OpenGL bindings and the Tao forum won't let me create new topics i figured i might aswell ask here. This puzzles me for quite a while now, but it seems beyond my understanding.

The way i understand OpenGL, it doesn't immediately process the Instructions you call. Instead it queues all received Instructions and schedules their execution on it's own. Assuming this is correct, and let's assume we pin and pass a float[] as parameter to glVertexPointer() then release the pin, how can one be sure the GC didn't move the array already by the point of time OpenGL actually executes the Instruction? The way i understand it, once you call .Free() or end a fixed-block the object is immediately allowed to be moved again? I've tried to prove this by passing excessive amounts of glVertexPointers and immediately trash the array after passing it, but either my GPU can process the Instructions much faster than the CPU can supply data, or OpenGL really executes Instructions immediately rather than queueing them? Clarification would be appreciated :)

I'm not having any problems with pinning, just curious how this works under the hood.

-Inertia


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler.'s picture

I had written a lengthy reply but the browser crashed...

Anyway, the gist was that commands that operate on video/system memory are safe (for example glTexImage or the VBO version of glVertexPointer), while commands that operate on client memory are not (e.g. the VA version of glVertexPointer). I've done some tests that seem to confirm this, and it definitely is a real problem when it happens (for example the Vertex Arrays example in OpenTK 0.3.12 suffers from this), but it is safe if you take care to manually pin volatile memory (or avoid using functions that operate on client memory).

Inertia's picture

Hate when that happens, but nevertheless Thanks for your answer :)

I believe to have encountered this problem once when using glTexImage2D with a byte[], but could never replicate the error again so I'm not sure what actually caused the problem (was expecting the crash to have something to do with my parameters for teximage and didn't really debug). To my understanding it should be sufficient to use glFinish(), before releasing the pin, for all OpenGl Instructions while the program is loading, to prevent any GC-related problems from happening. Obviously this is no solution for the interactive part tho.

Thanks again for clarifying this, i haven't run into any problem like this lately (probably because I do use VBOs ;) ) but it's always good to know such pitfalls and strive for preemptive software design.

Hope your exam went well,

-Inertia