#### Archived

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

# Correct Vertex buffer usage?

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

## Recommended Posts

From what I gathered.. Using vertex buffers (DrawPrimitiveVB) over our own buffer (DrawPrimitive) may be faster as the video driver may put the data in a DMA area (rather than our own buffer which is always system memory).. So even if video card runs out of memory, it will only be as slow as using our own buffer.. so use it often However the speed increase comes in place when it saves on re transforming the vertices (for non TnLHAL cards - basically all except GeForce and a few minority) In the following situation  "Normal" method ---------------- 1. Allocate and fill own object buffer (one time setup) 2. Change the render state 3. Call DrawPrimitive (send it for transforming) 4. Change render state 5. Call DrawPrimitive (redundant transformation)  Vs  Vertex Buffer (If non TnLHAL) ------------------------------ 1. Create System-only VB (source) and fill it (one time setup) 2. Create VB (Write only, dest) (one time setup) 3. Call dest->ProcessVertices (Do 1 transformation only) 4. Change render state 5. Call DrawPrimitiveVB (use dest) 6. Change render state 7. Call DrawPrimitiveVB( use dest. Not re - transformed)  And  Vertex Buffer (If TnLHAL) -------------------------- 1. Create VB and fill it (one time setup) 2. Change render state 3. Call DrawPrimitiveVB ( use hw to do the transformation) 4. Change render state 5. Call DrawPrimitiveVB ( let the card do the redundant transformation)  The above assume using the D3D TnL.. The VB can be furthur optimised with the Optimise function if the vertex data does not change. Even if it does change often, the Lock/Unlock does not take much time, so it''s always better to use VB over our own buffer.. Sorry for the long post..Am I on the right track? Is there any other usage for VB?? ..

##### Share on other sites
I would say that you have it pretty much nailed down

- WitchLord

##### Share on other sites
Just to add to the discussion, last week I did
a series of time tests concerning VBs and DrawPrim.
The test dealt with drawing combinations of 100 to 10000
polygons over a series of 100 to 1600 screen flips.
The three tests were
1) DrawPrim
2) A VB that is filled in every frame ( not constructed )
3) A VB that is constructed once and not touched again
between flips.

At low polygon counts, the times were about the same.
Case 2 was a little slower, but not big deal. And
as probly guessed, at the higher counts the VB behaved faster.
The interesting thing was 2 & 3had the same speeds, and I only
got about 2 to 3 fps over 1.

I haven''t done speed tests on proceesed VBs, because I new they would be faster, but I plan on doing those tonight to see how much faster. FYI, I have a nVidia TNT Ultra, P3-450

My guess is that processed VBs will HOPEFULLLY be far faster. If not, then I will be curious what conditions they are.
I will write back tomorrow on what happens.

##### Share on other sites
I would think the improvement using VB is highly dependant on the video card driver (where it wants to store the VB is video mem or system mem) and whether the video card has TnL hardware..

If the VB (source and destination) is stored in system memory and there is no TnL, it should be roughly the same speed when compared to using our own buffer (the first method) unless the redundant transformation is done many times (during multipass rendering)

Thanks there..