Jump to content
  • Advertisement
Sign in to follow this  
Basiror

vertexarrays vs interleaved arrays vs VBOs

This topic is 5408 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 you probably already know interleaved arrays are faster than standard vertex arrays because this reduce the memory look ups to get vertex,normal and uv data some questions 1. are they generally faster or does it depent on the system 2. can i stored interleaved arrays in VBOs? 3. if i can store them in VBOs can i dereference the like indexed vertex arrays? i want to use indexed vertex arrays because i have read somewhere that the hardware transforms vertices which are used for multiple triangles only once my geometry is brush base polygonal data triangulated to render it with vertex arrays thus i have several triangles using the same vertices it the statement that vertices are transform only once true? if so i guess it stored them in the cards vertex cache after transformation and reuses it if you haven t overwritten the slot in the cache with another vertex (FIFO) thx for your answers

Share this post


Link to post
Share on other sites
Advertisement
1. they should be faster all the time, due to the lack of memory hopping you mentioned earlier. Keeping them around 32bytes per vertex is best as thats a single AGP transfer size (although dont worry about being too strick with it,most cards have a pre-transform cache as well apprently to help)

2. Yes. While I've not seen it done with teh glInterleavedArray() function you probably could. The normal method is the use the gl*pointer() functions and use the stride and offset parameters to line up your data being passed to the GPU. The speed difference is the VBO is in VRAM might not be so great but if its in AGP ram it could help a great deal.

3. you can use index arrays with VBOs, yes.

VBOs are just VAs which are controled by the driver and could be in video ram, all the normal VA rules apply.

and yes, gfx cards have had a post-T&L cache for years (GF1 I think was the first), the number of slots varies per card but iirc you are pretty much sure of gettting 16 slots.

Share this post


Link to post
Share on other sites
ok thx

i will stick with 32 bytes per vertex everywhere that are 3 floats for vertex 3 for normal 2 for uv coordinates

enough for brush base geometry maybe i can use integers since the brush based polygons are grid aligned so i could use shorts to represent the coordinates but i guess retransforming this data when saving in vbos would slow it down since the cards uses floating point data internally


the vbos are fine too, but what makes me curious is why didn t they use interleaved arrays in q3 engines? yes they have implemented a renderpath for interleaved arrays but they disabled them


search for /cvarlist r_vbo_interleave

there should be a cvar called r_vbo_interleavethat is set to 0 by default

Share this post


Link to post
Share on other sites
just wondering about the 32 bytes, will pcie cards underly the same limitation or could we use more bytes per vertex?

Share this post


Link to post
Share on other sites
the recent ATI/NV OpenGL optermisation video (see sig) indicate thats PCI-Express will also have a min. transaction size of 32bytes.

Just to be clear, i'm not saying your vertex data HAS to fit inside of 32bytes, just making it 32byte aligned if its logical todo so will help with AGP transfers.
So if you are just below a multiple of 32bytes you might get some performance increase by padding it out, however dont go overboard on this as cards apprently have a pre-T&L buffer where data is stored to try and deal with data which stradles AGP transactions.

Really, you'd be better off watching the video/reading the pdf in my sig as its explained slightly better.

Share this post


Link to post
Share on other sites
I think some gl drivers will convert your bytes into floats but it still helps to have them as bytes/shorts on client side to save memory.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!