Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

what's all about this GL_EXT_compiled_vertex_array stuff ?

This topic is 5231 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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. *-

Share this post


Link to post
Share on other sites
@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]

Share this post


Link to post
Share on other sites
CVAs simply allow you to tell the OpenGL driver that you won''t be modifying your VA data until you unlock the arrays, which may allow it to cache vertex data in video memory. In my experience, the performance improvement is rather small (5-10%) but it''s easy to use them, so I think it''s worth adding support for them if VBOs aren''t available.

Share this post


Link to post
Share on other sites
@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

Share this post


Link to post
Share on other sites
quote:
Original post by DJSnow
>>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 ?!

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. CVAs were kind of an intermediate step between regular vertex arrays and VBOs. You're still creating your vertex arrays in client memory; locking the arrays simply gives to the driver the option (it's not a guarantee; it may only place part of the arrays, or ignore the lock completely) of placing them in video memory.

So in your VBO path, you shouldn't be using CVAs. In your non-VBO path, you might as well use CVAs if they are supported.

Share this post


Link to post
Share on other sites
@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

Share this post


Link to post
Share on other sites
@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 arrays
if (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]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
@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]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!