Recently, while browsing Nvidia’s presentations from this year’s GDC I found some information on NVX_instanced_arrays extension. As nobody has mentioned it yet, I would like to express my very strong interest in such an instancing extension for the GL. And I would also want to ask, when we can expect it to ship in public drivers? Just please don’t kill this extension before its release (as it’s in experimental stage), I know that for some of GL developers it might seam like an abomination, but for some of us this is of utmost importance to have such a feature in the GL. 
not supported by newest Detonator 87.56 
I guess that we will have to wait for some 90-series driver. I just hope that this extension is not some kind of pre-april fools joke 
.
i will love this extension. it will help me a lot.
I would really like to know how the usual glDrawElements usw should behave when called on arrays with enabled divisors. Ignore them?
So is this extension aimed at SLI setups? If not what would I benefit from using it for? an example would be nice. Thanks
Basically, it is usefully when you draw a lot of similar objects that only differ in a slight manner. For example, space ships with common geometry but different color. Usually, you would render teh array n times seting different color for each ship, but using this extension you can let the GPU handle it for you. It will basically draw the array n times adjusting the specified array pointers after each repetition instead of after each vertex. It can be used to reduce the setup overhead.
It has nothing to do with SLI. You can also look into DirectX 9 instancing
Hmm so this would be nice if you say had a RTS game and you had 4 players or more and each side had some similar units but different textures and there was 100’s of units this would reduce the cost of setup for rendering a lot of polygons… Now this sounds interesting…
Is there even a spec for it yet?
If there is, it’s not public, or they’re hiding it from me in particular.
Nvidia’s got a bunch of cool toys in works. This, the conditional render thing, geometry shaders, … I’m getting a bit flustered.
It would be interesting to have a possibility to create more advanced vertex arrays then we have currently. Basically, current arrays can be only indexed like START + index*(STRIDE + SIZE), where index can be a vertex index(or an instance number as in this extension). So we only have one adressing possibility and two indexing variables. Plus, we can specify one index variable indirect, by using an arbitrary index buffer. To make the example of Mars_9999 possible(that with different texture coordinates) we would need addressing mode like START + (index1+index2)*(STRIDE + SIZE). Actually, this remind me of the shader beginnings and the nvidia’s texture shaders. What if we had similar flexibility with vertex arrays? Like more indexing variables, indirections and nested vertex generation loops. For example(api comes just in my mind):
// indexing variables
// position per-vertex
VertexArrayIterator(0, INDEX1)
// transformation per-instance
VertexArrayIterator(1, INDEX2)
// texture per-vertex-per-instance
VertexArrayIterator(2, INDEX3)
// indices
IndexArrayIterator(INDEX4)
// INDEX3 = INDEX1 + INDEX2
IteratorSource2(INDEX3, ADD, INDEX1, INDEX2)
// INDEX1 = index lookup
IteratorSource1(INDEX1, LOOKUP, INDEX4)
// render the geometry
DrawIteratedArraysDoubleLoop(TRIANGLES, INDEX4, 0, indexcount, INDEX2, 0, inctancecount)
This way, we can render ‘inctancecount’ number of objects using an indexed vertex array, where first attribute depends on current vertex(but not current instance), second attribute depends on curretn instance(but not current vertex) and thir attribute depends on both.
I hope I didn’t went too offtopic :-), this is just something that bothers my mind for several days now, as I think of a nice geometry generation API
Hmm so this would be nice if you say had a RTS game and you had 4 players or more and each side had some similar units but different textures and there was 100’s of units this would reduce the cost of setup for rendering a lot of polygons… Now this sounds interesting…
If that’s what this extension is for. There are a couple of things that can be considered “instancing”.
But, in general, to see a performance gain, you need the objects to be small (< ~100 polys), lots of them, and for them to not be too different from one another. You could do something like pass a quaternion for each instance, or perhaps two or three 4-vector vertex attributes.
I would really like to know how the usual glDrawElements usw should behave when called on arrays with enabled divisors. Ignore them?
From the pseudo-code for DrawArraysInstancedNVX I assume that the devisor will have no impact on standard drawing routines (DrawElements, DrawRangeElements, DrawArrays) as the instance index is always equal to 0 for them. But I maybe missing some important issue here.
It would be interesting to have a possibility to create more advanced vertex arrays then we have currently…
Index shaders anyone . But honestly I think that future hardware will more likely try to optimize vertex texture fetches and probably geometry shading rather then extending specialized instancing capabilities. Just look how long it took them to have this simple instancing extension. It seems that IHVs are treating it as a temporary fix for the D3D batching issues. But than again on one of the slides Simon Green mentions that benefits of using instancing should improve on future hardware, so maybe they are going to develop it further.