what's all about this GL_EXT_compiled_vertex_array stuff ?

Graphics and GPU Programming Programming

Started by DJSnow January 24, 2004 02:09 PM

15 comments, last by DJSnow 20 years, 2 months ago

13,404

January 24, 2004 07:58 PM

quote:Original post by DJSnow
@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)

It''s fine to keep it locked over frames, just remember that
1) You can''t modify it while it''s locked (undefined behavior)
2) Not unlocking before you exit will be similar to a memory leak, so unlock it eventually!

SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.

Myopic Rhino

2,378

January 24, 2004 10:52 PM

quote:Original post by DJSnow
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%.

Reread what I said earlier. CVAs aren't guaranteed to cache your entire transformed vertex arrays in video memory. The driver may ignore CVAs completely, or only cache some vertices. You can probably think of it as hint. You're basically saying "Until I tell you otherwise, I'm not going to change this data, so do whatever you can to optimize it."

quote:Original post by DJSnow
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 ?!

I think Promit probably helped with some of your confusion, but let me respond to this anyway. In that demo, I'm only using one set of vertex arrays. Since I'm never changing them, I can lock them immediately after enabling them and passing them to gl*Pointer(). If you're using multiple sets of arrays, then using CVAs isn't going to buy you anything, unless you're using multipass techniques. The driver may cache them, but you'll be unlocking and replacing the arrays before it has a chance to use the cached data.

Btw, the parameters passed to glLockArraysEXT() are similar to the start and count parameters in glDrawArrays(). The first param is the first vertex to lock, and the second is how many vertices to lock.

Trienco

2,555

January 25, 2004 03:02 AM

hm, before i rewrite everything to try that: are cva as picky about the kind of data you use? situation:
i have a kind of large terrain (2049² just to beat far cry''s 1024) and storing the vertices as 3 floats is far too much. in fact, 3 bytes would already suffice and its working well with vertex arrays. vbo however just seems to hate everything except floats and so performance is totally killed if i dont use them. trying to pass it as color and doing some stuff in the vertex program failed (obviously without any pointer to position or attrib[0] it wont do a thing).

if cva are a little less restrictive they might be an alternative, so i already have a hard time seeing why the data type would make any difference between va and vbo.

f@dzhttp://festini.device-zero.de

DJSnow

100

Author

January 25, 2004 04:35 AM

@trienco:
>>in fact, 3 bytes would
it''s impossible to pass GL_BYTE to glVertexPointer says my MSDN ??!?

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

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

Trienco

2,555

January 25, 2004 04:51 AM

quote:Original post by DJSnow
@trienco:
>>in fact, 3 bytes would
it''s impossible to pass GL_BYTE to glVertexPointer says my MSDN ??!?

DJSnow

it is, but passing data as glAttribPointer doesnt care about the type. sending 3 bytes from a normal va is working well, but vbo is kicking in my face the moment i use anything else but float (just tried it for color and even that will work with 1200fps as float but drop to 48 as byte). slighty frustrating if youre forced to waste 34mb when 12mb would be enough.

maybe cva isnt that annoying *g*

f@dzhttp://festini.device-zero.de

DJSnow

100

Author

January 25, 2004 05:31 PM

ok,
i tried it; with an easy mesh, 32k tri's, there is a nice gain of 7 - 10fps; rising the fps from ~63 to ~71.
but: it seems that there is a bug, if i want to use more than one vertex arrays - each time i'm using it with a complex scene, i got an invalid operation; is there any limitation on this extension that i can only use/have locked one array at the same time ?!

but, apart from that for beeing as easy to implement as this, it's not bad

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

[edited by - DJSnow on January 25, 2004 6:32:16 PM]

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

Promit

13,404

January 25, 2004 05:43 PM

Well, yes, you can only have one locked array at a time, because to changing which array you''re using is essentially the same as changing the array. You have to unlock before calling any of the gl*Pointer functions.

The primary use of CVAs is probably when you have a single array of vertices and you have to draw many index buffers using those vertices.

SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.

what's all about this GL_EXT_compiled_vertex_array stuff ?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

what's all about this GL_EXT_compiled_vertex_array stuff ?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines