hi. as the topic let''s assume: i''m interested in opinions about using this extension; i haven''t used it until today; perhaps i may understand this wrong: it''s nearly the same as display lists; but without the state changes - it''s also "compiled". is there a speed improvement when using this extension with normal VA''s ? DJSnow --- this post is manually created and therefore legally valid without a signature

disclaimer: I didn''t read the msg just the topic.

Nothing we use ARB_vertex_buffer_object instead anyway.


-* So many things to do, so little time to spend. *-

@ingenu:

>>Nothing we use ARB_vertex_buffer_object instead anyway.

hehe, yes; but we have massive problems with VBO on main target platform, which is GF2MX (there is also a thread on gl.org of me, relating this problem) - and, as you can guess: standard VA's could need a little speed up in our application, and this "compiled vertex array thingy" seems to be a very cheap performance tweak ?!?! i'm not sure about it's usefulness ?!

we have a codepath for VBO's, but it won't work on all our GF2MX's correctly; so i'm heading for a small improvement, if it's possible (and cheap).

DJSnow
---
this post is manually created and therefore legally valid without a signature

[edited by - DJSnow on January 24, 2004 3:15:23 PM]

@Myophic...:

>>may allow it to cache vertex data in video memory
mmmh....but: VBO''s also in video memory; so there should me more improvement, or not ?!
(aren''t display lists doing the same thing, too?)

>>so I think it''s worth adding support for them if VBOs aren''t
>>available.
apart from that, VBO implementations seems not very consistent above all cards from TNT to GF4

DJSnow
---
this post is manually created and therefore legally valid without a signature

@myophic...:

>>CVAs aren''t intended to be used with VBOs because, as you
>>pointed out, VBOs are already in video memory, so it would be
>>pointless
no, you understand me wrong - i meant "there should be more gain than 5 - 10%, if CVa''s are also located in video memory"; because VBO gains widely more than 5 - 10%.

ok, i think i will give it a try...

DJSnow
---
this post is manually created and therefore legally valid without a signature

@myophic...:
to harass you one more time (~post) - i have looked at the source of the GLbook; in the terrain example you are using this extension.
but the code confuses me a little bit, in the initialization function it looks like:

...// if the compiled arrays extension is available, lock the arraysif (glLockArraysEXT) glLockArraysEXT(0, MAP_X * MAP_Z);..  

i'm not sure about the behvaiour of this extension - i mean, why do you call it while the initializatin function ?! what would the call look like if i have multiple vertex arrays... ?
specifies the "0" as parameter of glLockArraysExt() in your code the number of the vertexarray or something like this ?!

or means this call of glLockArrays only the trying of the driver "to figure out on his own, which array (bound to an arbitrary point of time) to place on the card's videomem." ?


DJSnow
---
this post is manually created and therefore legally valid without a signature

[edited by - DJSnow on January 24, 2004 7:46:05 PM]

[edited by - DJSnow on January 24, 2004 8:00:58 PM]

This is actually set to be reformatted somewhat and published officially on GDNet (re: new column) but what the hell.
----------------------------------------------------------------
Extension Information:
Name: GL_EXT_compiled_vertex_array
Not part of the OpenGL Standard, as of version 1.5
Availability: Almost every graphics card in existence today, along with most software OpenGL implementations.

Associated Functions:
void glLockArraysEXT( GLint first, GLsizei count );
void glUnlockArraysEXT( void );

Description:
A call to glLockArraysEXT indicates to OpenGL that the arrays specified by glVertexPointer and related functions are not going to change until glUnlockArraysEXT is called. This allows the driver to perform vertex calculations and cache the results.

glLockArraysEXT: Locks the arrays specified starting from first up to the number of elements specified by count.
glUnlockArraysEXT: Unlock the arrays specified by the previous call to glLockArraysEXT.

Explanation:
Before version 1.5, OpenGL contained no built in functionality for vertex buffers or vertex caching. GL_EXT_compiled_vertex_arrays was one of the earliest extensions added for this purpose. Basically, when glLockArraysEXT is called, the driver assumes that you will not be editing any of the arrays you have set for use with glDrawArrays and glDrawElements. This allows it to transform these vertices ahead of time and cache the results in video memory, thus saving bus traffic. It also allows your program to perform other calculations while the GPU does its work, thereby resulting in more efficiency, since you don’t have to wait for the AGP bus or the GPU. Lastly, it allows multiple calls to glDrawElements to use the same set of pre-transformed vertices, instead of reprocessing those vertices on every glDrawElements call. The behavior is undefined if you actually modify the arrays after a glLockArraysEXT call but before a glUnlockArraysEXT call.

Sample Usage:

void Render(){    glEnableClientState( GL_VERTEX_ARRAY );    //buffer is an array of floats containing vertex data    glVertexPointer( 3, GL_FLOAT, sizeof(float) * 3, Buffer );        //NumVerts is an integer containing the number of    //vertices in Buffer    glLockArraysEXT( 0, NumVerts );    glDrawArrays( GL_TRIANGLES, 0, NumVerts );    //more calls to glDrawArrays/glDrawElements ?    glUnlockArraysEXT();}

[edited by - Promit on January 24, 2004 8:23:19 PM]

@promit:

and is it valid to lock and keep locked for the whole runtime of the application ? i mean, if lock-unlock-lock-unlock-lock... the whole time, i think that it won't give anything - because the driver has not the chance to cache it/upload it to videoram, because it must assume that you modify the data; so, i would keep the data locked the whole time ?! (for static data, of course)



DJSnow
---
this post is manually created and therefore legally valid without a signature

[edited by - DJSnow on January 24, 2004 8:39:12 PM]