Jump to content
  • Advertisement
Sign in to follow this  
Tispe

Concatenation of vertex buffers and performance

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

Hello

 

How far can I stretch vertex buffer merging for performance gains?

 

Are there any rules of thumb of how many vertices that should be in the same buffer?

 

cheers!

Share this post


Link to post
Share on other sites
Advertisement

than more polygons in single vertex buffer than better

it means if you have oportunity to sed two 400 poly models in one 800 poly vertex buffer and draw or

darw it witch two draw calls, than select first case (if it is possible)

 

i were been created buffers with 500000 polys and it sems to be working well so i see not limit on how many polygons to yse in one vertex buffer

Share this post


Link to post
Share on other sites

If I use 16bit indices then I could no longer use more then 65535 vertices right? Which is what SM3.0 hardware must support. With a 32byte large vertex that totals a 2MB large buffer on SM3.0.

 

 

Say I have an Area mesh that fits inside such a buffer, is it better to partition that buffer up with several DrawCalls for Culling polys outside of the frustrum, or should the whole Area be drawn using a single DrawCall and let the GPU decide what to cull? What if the Area is 50MB big and I use 32bit indices?

Share this post


Link to post
Share on other sites

This is just linear optimization problem. Single batch cost constant x amount. Using bigger(in world size) batch cause culling to be less effective y% amount. You try to solve this problem using data from your scene.

Share this post


Link to post
Share on other sites

If I use 16bit indices then I could no longer use more then 65535 vertices right?

It means that each single batch can consume up to 64*1024 vertices since there's no way to address more. I suggest to stay away from index 0xFFFF however: on some hardware I tested, it had odd performance behavior (likely because interactive with primitive-restart functionality). Those implementations are old, and the issue is probably gone right now. You can still put a million indices in each VB and use batch offsets to select the correct sub-region.

 

 

 


How far can I stretch vertex buffer merging for performance gains?

Switching vertex buffer is not even nearly half expensive as it used to be. Doing a new buffer for each resource is often doable. Personally, I merge my buffers according to "resource load rounds" and vertex format so I don't have to write complex code and the inspected buffer looks good in debugger.


Are there any rules of thumb of how many vertices that should be in the same buffer?
Dynamic buffers should be below 4MiB for best performance (according to AMD, referring to GCN drivers). Static buffers can likely be a gazillion vertices with no problem. Edited by Krohm

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!