What do draw calls do?

[Vadi]

Is the number of draw calls important for the videocard's bandwith only?

 

[Reverend]

Somewhere in your question/sentence, I think the word "only" is debatably (and confusingly) placed. I can think of a few places where "only" can be inserted appropriately!!

 

[BRiT]

Somewhere in your question/sentence, I think the word "only" is debatably (and confusingly) placed. I can think of a few places where "only" can be inserted appropriately!!

Inconceivable.

 

[Hyp-X]

Is the number of draw calls important for the videocard's bandwith only?

No.
The number of draw calls are important because of the CPU time required to process them.
This is API dependent though - the CPU overhead of the draw calls are much bigger in Direct3D than in OpenGL.
Bandwidth plays a role only when you pass dynamic vertex/index data. (Or maybe when you frequently change lot of shader constants.)

 

[Karoshi]

IIRC I read somewhere glVertex3f on an old SGI machine was 10 asm instructions. I dont know the D3D architecture, but from the kind of shit that programs like fraps are able to do I suppose even complete user/kernel switches may happen for some primitive calls.

 

[Reverend]

I dont know the D3D architecture, but from the kind of shit that programs like fraps are able to do I suppose even complete user/kernel switches may happen for some primitive calls.

Hey, FRAPS ain't shitty.

Wait, that's not what you said, is it? You're talking about shitty stuff allowed by an API.

 

[Hyp-X]

IIRC I read somewhere glVertex3f on an old SGI machine was 10 asm instructions. I dont know the D3D architecture, but from the kind of shit that programs like fraps are able to do I suppose even complete user/kernel switches may happen for some primitive calls.

Well first the program calls the D3D runtime which encodes most of the calls into a command buffer in a device independent format.
When the command buffer gets full the runtime calls into the kernel mode part of D3D which calls the kernel mode driver.
The driver then unpacks the commands and re-packs them into the GPU command buffer.

So while not every call does a complete user/kernel switch it happens every few calls. Actually changed shader constants are stored into this buffer - which means that more constants change will cause the switch to happen more often.

You might think that this architecture sux - and you are not the only one.

 

[Vadi]

Thanks people!

I asked because in Söldner there is important grass (gameplay) which is displayed old fashioned using many objects. My idea is to change this or make an option for shader based grass.

 

[Hyp-X]

Use instancing for grass if possible

 

[db]

The new Windows Vista driver model writes device-dependent streams and avoids the translation step. Buffer flushes do not happen that often, typically a few times per frame unless the application does things to force explicit synchronization (e.g., locking a surface).

 

[Demirug]

Well first the program calls the D3D runtime which encodes most of the calls into a command buffer in a device independent format.
When the command buffer gets full the runtime calls into the kernel mode part of D3D which calls the kernel mode driver.
The driver then unpacks the commands and re-packs them into the GPU command buffer.

So while not every call does a complete user/kernel switch it happens every few calls. Actually changed shader constants are stored into this buffer - which means that more constants change will cause the switch to happen more often.

You might think that this architecture sux - and you are not the only one.

Nothing keeps longer than an interim solution. I still remember the time were you have to fill this command buffers by your own.

 

[DemoCoder]

Aren't convoluted C-macros wonderful.

 

[Vadi]

Somewhere in your question/sentence, I think the word "only" is debatably (and confusingly) placed. I can think of a few places where "only" can be inserted appropriately!!

Is only the number of draw calls important for the videocard's bandwith?