Vertex Buffers
Author
How many polygons are ideal for each Vertex Buffer to maintain good speed in my program? 10,000 each maybe? Thanks in advance.
We need more information!!!!
Are we talking immutable static VB's, or ones that you might want to update at some point?
For the former case, ISTR that a 4mb buffer was good, but for dynamic buffers it was around 1mb. From an ATI presentation I read years ago!
It also depends on the type of geometry - There was an Nvidia produced excel spreadsheet some time ago (not sure if it's still available) graphing the performance hit for not correctly aligning data to the hardware buffers. iirc, a standard 32byte alignment performed best [smile]
Then, thats not even considering batch size and pipeline utilization...
Batch size is probably more crucial than overall VB size - rendering a larger subset is often better than rendering smaller subsets. However many small subsets from one buffer is likely to be as good as several larger subsets from many VB's. It's difficult to tell without profiling!
Pipeline utilization might well reveal that it, quite simply, does not matter! If your application is heavily fill-rate bound (lots of pixel shaders and associated blending and post-processing operations) then chances are the VS units are twiddling their thumbs waiting for some work. If the stall is occuring further down the pipeline then it doesn't matter how much data the VS's pump out because it's just gonna get added to the queue [wink]
So, two things:
1. As I originally said: More data!! Not just specific implementation details, but context information - what are you trying to achieve.
2. Profile. Profile. Profile. Profile. Until you've isolated the problem not only can you only guess but we can only guess as to what or where the performance is getting sucked up [smile]
hth
Jack
Are we talking immutable static VB's, or ones that you might want to update at some point?
For the former case, ISTR that a 4mb buffer was good, but for dynamic buffers it was around 1mb. From an ATI presentation I read years ago!
It also depends on the type of geometry - There was an Nvidia produced excel spreadsheet some time ago (not sure if it's still available) graphing the performance hit for not correctly aligning data to the hardware buffers. iirc, a standard 32byte alignment performed best [smile]
Then, thats not even considering batch size and pipeline utilization...
Batch size is probably more crucial than overall VB size - rendering a larger subset is often better than rendering smaller subsets. However many small subsets from one buffer is likely to be as good as several larger subsets from many VB's. It's difficult to tell without profiling!
Pipeline utilization might well reveal that it, quite simply, does not matter! If your application is heavily fill-rate bound (lots of pixel shaders and associated blending and post-processing operations) then chances are the VS units are twiddling their thumbs waiting for some work. If the stall is occuring further down the pipeline then it doesn't matter how much data the VS's pump out because it's just gonna get added to the queue [wink]
So, two things:
1. As I originally said: More data!! Not just specific implementation details, but context information - what are you trying to achieve.
2. Profile. Profile. Profile. Profile. Until you've isolated the problem not only can you only guess but we can only guess as to what or where the performance is getting sucked up [smile]
hth
Jack
Author
Well I have one dynamic vertex buffer with 27 teapot meshes loaded from file,
that's got 3784 polygons each, with a total of 102,168 polygons on the screen at once, not including the skybox, which is on a separate static vertex buffer. It looks like this:
And as you can see, I'm not getting any faster than 30 frames per second. So I was gonna use more vertex buffers.
that's got 3784 polygons each, with a total of 102,168 polygons on the screen at once, not including the skybox, which is on a separate static vertex buffer. It looks like this:
And as you can see, I'm not getting any faster than 30 frames per second. So I was gonna use more vertex buffers.
Why are you using a dynamic buffer for the teapots? On an average machine you should be throughputting about 80million triangles per second at around 80hz. So you are operating at 1 tenth your capacity. Have you check the the run-time debug info?
ace
ace
As I mentioned. MORE DETAILS. I don't wish to be rude, but I fail to see how you expect us to automagically come to a conclusion for you [smile]
I think you need to delve into the performance analysis side of things to get much further - blind guessing doesn't help anyone. Without performance details (look into PIX for Windows) and information on the characteristics of the application we can only guess as to what the performance problem might be [smile]
hth
Jack
I think you need to delve into the performance analysis side of things to get much further - blind guessing doesn't help anyone. Without performance details (look into PIX for Windows) and information on the characteristics of the application we can only guess as to what the performance problem might be [smile]
hth
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
