Jump to content

  • Log In with Google      Sign In   
  • Create Account


DrawPrimitive() Dilemma


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 Endemoniada   Members   -  Reputation: 283

Like
0Likes
Like

Posted 13 September 2011 - 08:05 PM

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.

Sponsor:

#2 Hodgman   Moderators   -  Reputation: 27005

Like
0Likes
Like

Posted 13 September 2011 - 08:33 PM

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".

#3 rouncer   Members   -  Reputation: 355

Like
0Likes
Like

Posted 14 September 2011 - 05:23 AM

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.

#4 Krypt0n   Crossbones+   -  Reputation: 2272

Like
1Likes
Like

Posted 14 September 2011 - 07:59 AM

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.



#5 mhagain   Crossbones+   -  Reputation: 7338

Like
0Likes
Like

Posted 14 September 2011 - 11:28 AM

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.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#6 Endemoniada   Members   -  Reputation: 283

Like
0Likes
Like

Posted 16 September 2011 - 12:24 AM

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.

#7 pcmaster   Members   -  Reputation: 643

Like
0Likes
Like

Posted 20 September 2011 - 02:11 AM

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 :-)

#8 Numsgil   Members   -  Reputation: 501

Like
1Likes
Like

Posted 20 September 2011 - 06:49 PM

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.
Darwinbots - Artificial life simulation

#9 Numsgil   Members   -  Reputation: 501

Like
1Likes
Like

Posted 21 September 2011 - 10:45 AM

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.
Darwinbots - Artificial life simulation




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS