Draw calls obviously use up a lot of CPU, but with a lot of them I noticed only one of my cores gets fully loaded while the other one is nearly doing nothing.
This obviously limits my performance, much more than the polygon count does and I will probably have to resort to some way of combining multiple meshes into one.
But I’m wondering, would it be hard to add multi-core support(myself, or by unity staff in next versions), at least just for the draw calls?
drawcalls are graphic card related.
Independent of the amount of cores, they have the same impact.
Even with genius programming, you will only have very little possibility to change that as well as you can not use a distinct thread to mess with Unity’s behalf, you can only work on things that are not controlled by unity within distinct threads.
Draw calls are mostly a CPU issue. At least that’s what I’ve been taught. (And what Nvidia claims: developer.nvidia.com/docs/IO/8230/BatchBatchBatch.ppt)
I didn’t hope to be able to change unitys systems, but it didn’t hurt to ask
My question stands
Yeah, draw calls are hard to solve via multicore means using existing technology. DX11 will probably help with that a bit, once it’s released (and once Unity will have DX11 renderer). The problem is that the graphics device can only be safely accessed from one thread. Hence all rendering should happen on one thread.
We have bits of Unity engine on other threads (like mesh skinning, audio decompression etc.), and with time we’ll multithread more things. But draw calls themselves are not a low hanging fruit.
Exactly what I wanted to know! Thank you