Anonymous's picture

Vertex Array example

The Vertex array example (T02_Vertex_Arrays.cs) is missing the "Main" method in the example class file. I added it based one of the other examples, but the example does not display things.

Is this example in flux due to 0.9.1 development?

The reason I was looking at the Vertex array example is that while researching the share context issues I came accross several message boards indicating that OpenGL 3 will drop display lists from the spec and further indicated thet VA and VBO were both described as mechanisms to use in place of display lists.



Comment viewing options

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

@Inertia: I hear "random crashes" and get the impression, I might have missed some mistake you have found? I dont think, it runs as smoothly as it does, just because of LOH (Is that, what you mean?) So if you see any potential danger, I would love to hear from it ! :)

the Fiddler's picture

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.

haymo's picture

Ah, I see your point. I didn't know, the GL does process the vertices asynchronously. Are there any specs handling this topic? In the official OpenGL2.1 spec I found the following paragraph (chapter "Display Lists"):
When such a command is accumulated into the display list (that is, when
issued, not when executed), the client state in effect at that time applies to the command.
Only server state is affected when the command is executed. As always,
pointers which are passed as arguments to commands are dereferenced when the
command is issued. (Vertex array pointers are dereferenced when the commands
ArrayElement, DrawArrays, DrawElements, or DrawRangeElements are accumulated
into a display list.)

Thinking even a little longer about it, I wonder, if not all the other OpenTK delegates registering GCHandles (f.e. BufferData()) in order to send pointers to OpenGL also suffer from this issue? If the driver does not read the data immediately, the Handle will be disposed and the buffer might have moved away already?

the Fiddler's picture

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. :)

haymo's picture

Thanks for that excellent explanation :) !

docflabby's picture

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.InterleavedArrays(InterleavedArrayFormat.C3fV3f, 0, handle.AddrOfPinnedObject());
            GL.DrawArrays(BeginMode.Triangles, 0, vertexArray.Length / 6); 
void unload()
the Fiddler's picture

Yes, this works as long as you keep the pin intact.

Doing so, however, can be quite detrimental to performance and memory consumption (i.e. an object pinned at heap location 1000000 will ensure that 1000000 bytes will be always consumed - even if the object itself is smaller).

Also, pinning this way moves memory management back to you (taking care of resource allocation/deallocations, potential memory leaks, exception handling etc) - it hurts productivity.

Last, every call to GCHandle.Alloc, allocates memory and is quite slow in itself (about 200ns).

I'd really suggest avoiding this idiom whenever possible - but to each his own :-)

(OpenTK itself uses this quite extensively for OpenGL functions that take object parameters).

docflabby's picture

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.

the Fiddler's picture

Yep, this is the way to go if you want Vertex Arrays. Just wanted to discourage potential users from using this model on managed code (there are way too many tutorials on vertex arrays out there, and the potential pitfalls aren't readily visible).

coder123's picture

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?