vbo, multidraw, ati

so i just got an ati 9800 pro and i’m trying to get my little geometry app to speed up a bit.

my data is generalized polygons, normally drawn by iterating thu each one and calling a drawelement command.

i’m switching over the vbo’s to get a speed up (i hope). but i’m a little unclear on how vbo’s interact with glmultidrawelements.

there are two buffers passed to glmultidrawelements. in the vbo spec, it’s pretty clear that the second buffer is a normal memory pointer that points to what would under normal circumstances be a list of pointers, but with vbo’s enabled, it should be a list of offsets into the vbo. fine. i understand that. but what about the first buffer? is that client side or server side? it’s the buffer that specifies vertex counts of the second buffer. it doesn’t mention it in the vbo spec.

clearly there’s only one vbo bound, so i can’t imagine both buffers are expected to be on the card… but my app freezes my machine the way it is now (assuming the first buffer is truly a memory pointer and not an offset for a vbo). it would be much easier to debug if i didn’t have to spend a few minutes between attempts waiting for a my computer to reboot. bleah.

any help would be appreciated!

The way multi-draw elements works is like this.

The pointer you pass in is an array (client-side) of, not pointers, but offsets into a VBO index buffer (server-side).

Think of it like this.

It takes a void , which is a pointer/array to/of void’s. However, when VBO’s are bound to the index system, void’s become offsets. Therefore, the void** becomes an int*. A flat array of ints/offsets. Though, for 64-bit compatibility, you should still allocate it as an array of pointers, and then set them as integer values.

that makes sense, but i was wondering about the pointer i’m passing with the vertex counts. i wasn’t sure if that was client side memory or vbo offsets.

turns out, it’s client side memory, tho i think it would be nice to get it on the card with the actual vertex lists. for that matter, it would be nice to get the offset list on there, too. if i have a load of general polygons, it’ll end up passing 2 int’s per poly, when really all it needs is a single buffer pointer. but i guess that’s a whole new extension…

my problems with this revolved around data sizes and counts. i didn’t multiply out some offsets by their data size and it was actually crashing my whole system. i guess that’s the price you pay for optimizing.

It’s actually never an array of pointers, it’s always an array of integers, used as the first index into the vertex array (doesn’t matter whether it’s client memory or VBO). “count” vertices are pulled from there in a linear fashion to form the primitive. Repeat “primcount” times.

This is equivalent replacement code:

void APIENTRY
replacement_glMultiDrawArrays(GLenum mode,GLint* first,GLsizei* count,GLsizei primcount)
{
	for (int i=0;i<primcount;++i)
	{
		glDrawArrays(mode,first[i],count[i]);
	}
}

What glDrawArrays is equivalent to is already laid out in the spec. Sorry, I’m feeling lazy right now

edit: Whoops. You were talking about glMultiDrawElements, I was explaining glMultiDrawArrays. Shame on me.

okay, it seems to be working now. there’s not much difference between multidrawelements and drawelements, either. or maybe there’s other stuff in my app that’s slowing stuff down elsewhere… totally possible.

anyway, now i’m running into an issue with glIsBufferARB and glDeleteBuffersARB not being supported. i get NULL’s for the wglProcAddresses for them. with or without the ARB.

which is strange because the other parts of the vbo arb that i’m using are fine. namely the buffer generation, binding, data transmission, and drawing functions. what gives?

this is the latest ati driver on a 9800 pro. i don’t think i can just NOT delete the buffers, can i?

Are you sure you’re using the right strings? Try copying them directly out of the spec. Or, even better, check an extension loading library.

i’m using the intel glsdk extension library… thing… (got it from sgi’s opengl site) it works fine for other things… i’ll check the strings, tho, just to make sure.