Hi guys,
I'm rendering 128 objects made up of 124 triangles each. Should I be calling DrawPrimitive() for each object ? The only alternative I can come up with is to call LockBuffer() and fill it up, doing all the transformations (position and normal) on the CPU, followed by a single call to DrawPrimitive().
I'm locking and filling the buffer at about 800HZ which isn't bad, but I have an I7 860 and I plan on doing more processing, like sound and particles, so it might be slow on a not-so-fast computer.
Maybe there is another way ?
Thanks.
DrawPrimitive() Dilemma
128 draw-calls per frame is fine for a PC. If it was 1000+ draw-calls, I'd look into ways of reducing it, such as "instancing".
As the pci express bus expands you get more draw calls, more memory throughput, more write than read, like ten thousand, Id have to try it out but it might be able to handle it.
you can stuff all objects into one buffer, with 15872 triangles. Adding per vertex an index that identifies the object (like an ID, maybe into the alpha channel of the color, if you provide this in your vertex-stream).
then you set your 128 transformations as constants and draw all if it in one go, by indexing in the vertex shader into the constants area, using the per-vertex ID.
- I think that shall be the fastest way
- make sure you can fit enough constants in your Vertexshader/vertexprogram version, otherwise you'd need to split it.
then you set your 128 transformations as constants and draw all if it in one go, by indexing in the vertex shader into the constants area, using the per-vertex ID.
- I think that shall be the fastest way
- make sure you can fit enough constants in your Vertexshader/vertexprogram version, otherwise you'd need to split it.
you can stuff all objects into one buffer, with 15872 triangles. Adding per vertex an index that identifies the object (like an ID, maybe into the alpha channel of the color, if you provide this in your vertex-stream).
then you set your 128 transformations as constants and draw all if it in one go, by indexing in the vertex shader into the constants area, using the per-vertex ID.
- I think that shall be the fastest way
- make sure you can fit enough constants in your Vertexshader/vertexprogram version, otherwise you'd need to split it.
I use this approach for particles and I've found it faster than both instancing and drawing directly. It also works on a wider range of hardware than instancing, which is a nice bonus. Like you said though, limited constants space is something to be dealt with.
Don't even attempt to index constants this way in a pixel shader, by the way.
Author
That's a really nice technique but I can only see it working with a fixed number of objects that doesn't change.
How do you deal with objects that no longer exist (say they got blown up by the player) ?
Thanks again.
How do you deal with objects that no longer exist (say they got blown up by the player) ?
Thanks again.
That's a really nice technique but I can only see it working with a fixed number of objects that doesn't change.
How do you deal with objects that no longer exist (say they got blown up by the player) ?
Thanks again.
You can always discard any geometry in geometry shader, simply by not appending anything to the output stream(s). However and obviously, it's always better to avoid this at the CPU level :-)
An interesting rule of thumb, the source of which I forget:
25000 * CPU Speed in Ghz * percentage of frame time to spend on drawl calls * time per frame = draw calls per frame
So on a 2 Ghz machine running at 60 FPS and aiming at 40% time spent on graphics, you're looking at about 320 draw calls per frame. Useful way to theorycraft how much simplification you'll need to be doing to meet your target framerate.
Not sure where the magic number 25000 comes from. I'm sure it's batches per second for a given card, but I can never seem to find numbers on that anywhere.
25000 * CPU Speed in Ghz * percentage of frame time to spend on drawl calls * time per frame = draw calls per frame
So on a 2 Ghz machine running at 60 FPS and aiming at 40% time spent on graphics, you're looking at about 320 draw calls per frame. Useful way to theorycraft how much simplification you'll need to be doing to meet your target framerate.
Not sure where the magic number 25000 comes from. I'm sure it's batches per second for a given card, but I can never seem to find numbers on that anywhere.
Found the answer: http://origin-develo...hBatchBatch.pdf.
Basically: batch calls per frame is CPU limited (all done in the driver), and so is independent of the graphics card or its speed. From some empirical testing, 25K is a mid to low estimate of how many draw calls a 1 Ghz processor can do per second. This exact number is dependent on drivers and other factors.
Basically: batch calls per frame is CPU limited (all done in the driver), and so is independent of the graphics card or its speed. From some empirical testing, 25K is a mid to low estimate of how many draw calls a 1 Ghz processor can do per second. This exact number is dependent on drivers and other factors.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
