DavidGraham
Veteran
Why are the Draw Calls on the PC more expensive than the Xbox360 (for example) , Developers can do more of them on the Xbox than on PC which sounds pretty strange considering that PCs have way more GPU and CPU horsepower .
Modern GPU hardware is already a pretty close copy of the API.
Translating isn't really the issue.
The predominant problem is having to deal with multiple processes sharing the GPU. This will not change, short of adding hardware to the GPU to enable fast context switches which at some point may be justifiable.
This is not going to happen. 1. HW from different vendors is to dissimilar for a common ISA. Not to mention that instructions are not everything GPUs process: there's some state involved, which is entirely HW-specific. 2. Part of what goes to the buffer is so tied to hardware it may be covered by patents (not that I would know anything about patents, just assuming this may very well be the case). 3. Even for the actual code there's a huge variation in what and how you want encoded in the command buffer which depends on the HW you're feeding.If the GPU becomes more mature then it may be possible to have a somewhat fixed hardware "instruction set" for GPUs, and it'd be possible to have a much leaner driver stack on PC.
This is not going to happen. 1. HW from different vendors is to dissimilar for a common ISA. Not to mention that instructions are not everything GPUs process: there's some state involved, which is entirely HW-specific. 2. Part of what goes to the buffer is so tied to hardware it may be covered by patents (not that I would know anything about patents, just assuming this may very well be the case). 3. Even for the actual code there's a huge variation in what and how you want encoded in the command buffer which depends on the HW you're feeding.
While I agree with most of the points you bring up, I'm not sure the (in)efficiency of today's draw call on the desktop is that much related to the GPU ISA per se. State models, buffer sync/lock mechanisms and such are much more relevant to the subject than what the compiler outputs. With the advent of binary-program APIs you could even consider the compiler's stage as (near) zero-cost these days, and that would not change that much the cost of the draw call. I mean, draw calls were a factor to reckon with much before GPU ISAs were a topic for conversations.If the GPU becomes more mature then it may be possible to have a somewhat fixed hardware "instruction set" for GPUs, and it'd be possible to have a much leaner driver stack on PC.
There are, of course, some problems. The obvious one is, who gets to design this "instruction set." Most hardware 'standard' developed from a single product by a single company, which becomes very popular and then be used as a "de facto" standard (and may become a real industrial standard). It's really hard to make a new standard out of nothing. And design by a committee doesn't work. Microsoft is another possible candidate, but they probably don't understand enough about the underlying hardware architecture to make a good design.
Another way is to design an "intermediate code" which is translated by a software into hardware commands. But then this is not very different from a command buffer, and probably not going to bring much performance advantage.
There are other problems too. For example, since the driver would not be able to do safe keeping works, the hardware will have to. Basically you'll want the GPU to be like a CPU, with all the security modes and controls. Personally I think this is a good thing, as with GPU getting more flexible and GPGPU there will be more related problems with security, so it's probably better done with hardware anyway.
On a second read, I think that must be the case. My bad.I assumed pcchen wasn't referring to the shader ISA, rather a theoretical command buffer "ISA".
So what can be done to reduce the cost of draw calls on PC?
CPUs are not standard either ; ) Moreover, a proper level of abstraction beats standardized hw most of the time (e.g. HL programming languages vs assembly, etc)Make GPU standard just like CPU thank you.
I can't speak of D3D, but I have observations from GLES - the driver there has two (or two-and-a-half) major functions:Not investigated the cost of a draw call in a while, a lot happens behind the hood for sure, but we are used to minimizing them since D3D9...
A draw call basically gets all the states and check their validity/consistency before filling the command stream.
Anyone working on drivers can explain how that works in D3D10/11 ?
(I know the runtime does a lot because of NV , but I'd be curious to see how much is left to the driver. Could "just" be transcoding the D3D command stream into a GPU specific one.)
Make GPU standard just like CPU thank you.
AMD hardware supports triangle fans though I would like to see future APIs drop support for any primitive type that isn't a list.Draw call cost depends on the HW. Some things have to be translated for a given card and this imposes extra CPU cost per call. One could imagine that modern hardware may not support certain topologies (triangle fans would be something I guess most cards don't support directly; perhaps some support just plain TRIs or just lists). But it's not really a draw call that kills you, it's the (unnecessary) state changes between draw calls and stuff that has to be translated. Pretty much every modern HW out there simulates fixed pipeline in the driver, so that's extra CPU cost for you. Weird texture formats may require some processing. There's a lot happening beyond draw calls. And there are lots of things you can do to minimize CPU usage.