2
$\begingroup$

This is in reference and contrast to the discipline (or more or less requirement) of opengl to group draws that use the same materials together, to minimize making many draw calls or many switch shader calls.

So is it safe to say, that since vulkan is not state/context based, you can throw any mixture of draw commands with multiple seperate shaders/materials in the command queue, with no slowdown or overhead impact, and that even if you did the grouping optimization, you wouldn't see a speedup as well?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

Vulkan will not have the CPU-time performance costs associated with state changes (validation overhead, etc). But Vulkan command buffers do have state. They have two very major pieces of state: descriptor sets and the pipeline object.

Both of these objects are monolithic, dealing with potentially lots of pieces of information. The (potentially) huge quantity of stuff these objects control should strongly suggest to you that binding new objects is not cheap. And that's in terms of GPU execution speed, not CPU validation or whatever else.

Vulkan in general tries to make slow things in the API look slow and fast things look fast. Render passes are big, huge and complicated, so clearly you shouldn't just be starting and stopping them whenever you feel like it. Pipeline objects control a huge amount of information, so binding new ones feels like a heavyweight operation.

By contrast, changing what buffers get used for vertex input feels like a short, quick, focused operation. So it's probably cheaper than changing the pipeline that uses those buffers.

So yes, you should avoid state changes in Vulkan, just as much if not moreso than in OpenGL (since many state changes in Vulkan require entirely new pipelines).

Improve this answer
$\endgroup$
5
  • $\begingroup$ I would imagine that state changes in the GPU are at least an order of magnitude faster compared to the old OpenGL way, correct me if I'm wrong. I make this question in reference to how easily you can attach materials and shaders to your models in the modern versions of unity and unreal engine - almost like the cost to manage those is nil. Regardless, your reply is pointing to further study on vulkan on my part. $\endgroup$
    – GnoSiS
    Commented Jun 4, 2020 at 18:13
  • 1
    $\begingroup$ @GnoSiS just because the software (API, game engine...) changed, does not mean your hardware (GPU, CPU... ) necessarily changed the same way. Asking processors to do less things, will always be faster than asking them to do more of the same things. $\endgroup$
    – wip
    Commented Jun 12, 2020 at 15:51
  • 1
    $\begingroup$ @wip true, but the design "distance" in years between vulkan and opengl is huge, so this implies a radically different aproach. I have no reference point on how faster is managing state changes in the GPU vs the CPU. I see people "preaching" vulkan alll around, but need to get the actual details right, before making decisions. $\endgroup$
    – GnoSiS
    Commented Jun 17, 2020 at 9:16
  • $\begingroup$ Vulkan is a standardized API, how fast it is in practice depends on how well GPU vendors implemented it in their drivers (and how well it matches their hardware design). A few years ago it was not rare to have OpenGL faster than Vulkan on some mobile phones. Hopefully the situation has improved now (the hardware also changed since then). $\endgroup$
    – wip
    Commented Jun 17, 2020 at 22:12
  • $\begingroup$ @GnoSiS: "so this implies a radically different aproach" It shouldn't. The API tells you (more or less) what is fast and slow. Slow things look slow, and fast things look fast. And no matter how "radically different" something might get, basic advice like "don't repeat stuff you don't have to" should be standard. $\endgroup$
    – Nicol Bolas
    Commented Jun 17, 2020 at 22:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.