Vertex Array example

Both Inertia and me have observed random crashes with unpinned arrays. The code sample above will work correctly as long as any of the following is true (ordered according to danger, with 1 being the least dangerous):

1. All GL.DrawElements calls finish within the fixed section.
2. GL.DrawElements spill outside the fixed section, but the GC does not touch m_vertices because it is placed in the LOH.
3. GL.DrawElements spill outside the fixed section, m_vertices are not in the LOH, but no GC happens while GL.DrawElements are executing.

You can ensure that (1) will always happen, by placing a call to GL.Finish just before leaving the fixed statement, which will block until all GL.DrawElements calls are complete. Without this, your graphics drivers will determine whether the calls will finish on the spot, or they will be queued up and executed later on. This is not something to be relied on - it may work ok on your system, but it may cause problems elsewhere.

Now, if the m_vertices array is big enough, you may be able to get away with (2), without pinning and without calling GL.Finish. Obviously "big enough" is not something to be relied on either - it may change in future versions of .Net.

If neither (1) or (2) apply, you start to tread into the dangerous waters of probabilistic programming and random crashes (i.e. "what are the chances it will work today?") :) Both Inertia and me fell into this trap on our first approach to VAs from .Net, and this is why we recommend taking care.

Just add a GL.Finish to the code above and it will be 100% solid. There is a performance hit associated with this, but if the vertex arrays are very large (as they seem to be in this case), the hit won't be noticeable.

This has been thoroughly discussed and tested in the past for both Tao.OpenGl and OpenTK. We haven't been able to reproduce a case where commands dealing with server-side may execute asynchronously and fail.

Makes sense, too. Imagine the following code in C:

void LoadBuffer(...)
{
    float vertices[3 * number_of_vertices];
    // Populate the array somehow - the details are not interesting.
    glBufferData(..., (void*)vertices);
}

This is a fairly typical sample. The "vertices" array is allocated on the stack and will be deleted as soon as the function returns. Were glBufferData to execute asynchronously, this code would fail. But in practice this doesn't happen: BufferData copies the array internally and the driver handles the rest.

Vertex Arrays behave differently however, as the user is responsible for the buffer (client-side storage). Since you are expected to keep the pointer intact, VAs are free to execute asynchronously if the driver so chooses, and this certainly happens in display lists. :)

Something thats works for me, that I thought I would share. Basically you can pin memory without going "unsafe" (.net 2.0)

float[] vertexArray = new float{
            1.0f, 0.0f, 0.0f,
            -1.0f, -0.5f, -4.0f,
 
            0.0f, 1.0f, 0.0f,
            1.0f, -0.5f, -4.0f,
 
            0.0f, 0.0f, 1.0f,
            0.0f, 0.5f, -4.0f}
 
void load()
{
handle = GCHandle.Alloc(vertexArray, GCHandleType.Pinned);
}
 
void render()
{
 GL.EnableClientState(EnableCap.VertexArray);
            GL.InterleavedArrays(InterleavedArrayFormat.C3fV3f, 0, handle.AddrOfPinnedObject());
            GL.DrawArrays(BeginMode.Triangles, 0, vertexArray.Length / 6); 
            GL.DisableClientState(EnableCap.VertexArray);
}
 
void unload()
{
handle.Free();
}

I agree, its going to be a performance killer. I'm planning on doing the sensible thing and using VBOs :) I just noticed no one had posted up a stable managed solution to get vertex arrays to work. I couldn't get the unsafe/fixed code posted earlier to work, so thought I would post this.

Hi, Fiddler.
Please look at my question here.
datenwolf's answer says that glDrawArrays copies the data, so it can be safely deallocated immediately after that. Do you know if that's true?