Jump to content
  • Advertisement
Sign in to follow this  
Raeldor

Performance Hit On Multiple Vertex Streams?

This topic is 4837 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

Advertisement
Quote:
Original post by Raeldor
Is the performance hit on multiple vertex streams a big one?


Yes it is. Minimize vertex buffer switches for better performance. Recomended is to use one large static vertex buffer per flexible vertex format for static objects, rather than one per object. If it is possible, use static vertex buffers, and index buffer usage is good way too.

Petr

Share this post


Link to post
Share on other sites
Quote:
Original post by PetrCBR
Quote:
Original post by Raeldor
Is the performance hit on multiple vertex streams a big one?


Yes it is. Minimize vertex buffer switches for better performance. Recomended is to use one large static vertex buffer per flexible vertex format for static objects, rather than one per object. If it is possible, use static vertex buffers, and index buffer usage is good way too.

Petr


Is it still considered a switch if I have multiple concurrent streams and the buffers are residing on the video hardware? Ie, I have my vertex and normals in one stream, and my UV's and vertex colors in another?

Share this post


Link to post
Share on other sites
He doesn't mean vertex buffers; he means vertex streams. As in SetStreamSource.

Anyway, the best answer is to set up a profiling situation and see. Load the same data using one stream and two streams and see what the difference is. I'm guessing it won't be much, but I haven't tried it myself.

Share this post


Link to post
Share on other sites
Petr, I think he meant multiple streams (ie: more than 1 VB bound at once) rather than just using lots and lots of buffers.

I think the hit is fairly low, but I don't have hard data to back that up. The only real measure though is whether the hit incurred is less than the hit incurred by trying to stuff all your data into one stream and selectively choosing which data to use. Unless you're having a performance problem, don't worry about it. If there is too much data for 1 stream, or if it's hard to make a selection algorithm in your shader, or if it just plain makes your design a nightmare to use one stream then you've really got little choice.

Share this post


Link to post
Share on other sites
Separating normals, texture etc is not what streams are meant for, streams (one use) is to make e.g. animated models less demanding, as, everything except x,y,z (or whatever more you like) is static, that is all textures, colors and so on... why change it? you don't, add another stream that only has x,y,z... in that way you minimze the bandwidth usage.

However, streams are not meant for separating data that could as well has been in one stream, unless for reusing that is.

(This is one use)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I use multiple streams, I basically have one type of data per stream. One stream has positions, one has normals, one has tangents, ect.

I did some testing on a 9800 and found no noticible difference from packing all of the data into one stream. It may just be that it balances out when I do multipass rendering and don't need all of the data for certain passes. More overhead but less data is being sent for example on the ambient pass i only send the position and uv stream, since i don't need normals or tangent vectors.

Share this post


Link to post
Share on other sites
When we benchmarked on one title I was working on we found no difference for our particular case. It all depends where your bottleneck is though - if you're vertex fetch limited it will slow you down a bit but if your bottleneck is elsewhere then you won't notice any difference. Even if you are vertex fetch limited however it's not a huge hit.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!