Vertex Array example

Posted Friday, 25 January, 2008 - 15:14 by Anonymous in

Programming Support

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.

djk

Comments

This example was disabled on purpose because it suffers from a serious flaw: the vertex arrays are stored in managed memory and may be moved by the Garbage Collector. While this can be worked around (either by allocating unmanaged memory, or by pinning the objects in question), doing this will cause a performance hit.

Vertex Buffer Objects do not suffer from this problem, as they are stored in server memory. OpenGL 3 will not use client memory anyway, so VBO's are a safer bet.

The vertex array shows up in the example launcher under debug. I have been looking at the VBO example this morning.

Just a small note that the examples have grown a little stale (some major restructuring is underway for 0.9.2). Better check the VBO functionality in the GLSL example, as this is a little more up-to-date.

Is it better to avoid arrays in sake of speed? I think that opengl superbible talks about this issue.

Speedwise, from slowest to fastest:

Immediate mode
Vertex Arrays
Vertex Buffer Objects
Display Lists

While Display Lists can be faster than VBO's, they are only suitable for static geometry, which means VBO's are the best all-around solution. Both are (or can be) stored in video memory, so they are *very* fast to draw.

VA's on the other hand are stored in client memory, and have to travel through the AGP/PCI-E bus every time before rendering. Not only does this make them quite slow, but it also places the burden of memory management to the user (hence the problem with Garbage Collectors).

For general usage VBO's are the best solution.

Since I am rendering large mathematical objects and do not want to rely on large enough video memory, I'm still using vertex arrays. I came across the problem with index lists, which produce problems while switching to unmanaged context. However, by carefully designing the vertex array in stripes, one can most the time get around this issue. The way I figured out by now, does actually seems to be relatively ok. Thats why I'd like to share it here.

 fixed (VertexC4N3V3* pVertices = m_vertices) {
             // populate vertex array to GL
             GL.InterleavedArrays(OpenTK.OpenGL.Enums.InterleavedArrayFormat.C4fN3fV3f
                                  ,0,(IntPtr)pVertices); 
             // do some other stuff here, than
             // DrawElements will be called in a loop.
             // We give a pointer to the only index array existing, 
             // what will prevent from using index list array. 
             fixed (UInt32* pGridIndWalk = m_indices)
             for ([number of stripes]) {
                  GL.DrawElements(OpenTK.OpenGL.Enums.BeginMode.Lines,
                                  m_gridStripsLen,
                                  OpenTK.OpenGL.Enums.DrawElementsType.UnsignedInt,
                                  (IntPtr)(pGridIndWalk));
                  // increase the pointer to the next stripe
                  pGridIndWalk += m_gridStripsLen; 
             }
}

This will still be slower then using VBO, but may be useful for people needing to use indexed vertex arrays anyway.

Thanks, this should solve the problem (unless the driver decides to read the VA contents asynchronously).

One more thing to keep in mind is that the .Net GC will not move objects which are bigger than 80-90KB. Obviously this is not something to be relied on, as different versions of the runtime may have different limits, but it can affect behavior.

.Net GC will not move objects which are bigger than 80-90KB.
Good to know! I couldn't find a variable to access this limit, is there any?

This is called the "large object heap".

I would be surprised if such a variable existed. This is an implementation detail (the specs don't dictate how to implement the GC), and I guess they want to be free to change it in the future. If they did provide this information, some programs would start depending on the exact limit and such a compatibility nightmare is the last they want :)

From the link: ...implementation detail that could be changed in the future.
You are right, it would be nice though if this could be controlled. The ~83kb limit could also explain the VA related problems I had with PQ Torusknots in it's early stages (the Vertex[] had far less then 80kb back then), and why haymo's application does not require GL.Finish to run without random crashes at GL.Draw*

@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 ! :)

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

All GL.DrawElements calls finish within the fixed section.
GL.DrawElements spill outside the fixed section, but the GC does not touch m_vertices because it is placed in the LOH.
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.

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?

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

Thanks for that excellent explanation :) !

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();
}

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

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.

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

Home of the Open Toolkit library

Vertex Array example

Comments

This example was disabled on

The vertex array shows up in

Just a small note that the

Is it better to avoid arrays

Speedwise, from slowest to

Re: Vertex Array example

Re: Vertex Array example

Re: Vertex Array example

Re: Vertex Array example

Re: Vertex Array example

Re: Vertex Array example

Re: Vertex Array example

Re: Vertex Array example

Re: Vertex Array example

Re: Vertex Array example

Re: Vertex Array example

Re: Vertex Array example

Re: Vertex Array example

Re: Vertex Array example

Recent activity

Who's online