synchronousQueueSubmits can not be set to true without rebuilding MoltenVK

[zeux]

While it's possible to set the device configuration after device is created, the value of synchronousQueueSubmits is assigned in MVKDevice ctor and immediately read in MVKQueue ctor since device creates all the queues. This value is then "cached" (by initializing _execQueue) and is impossible to set later.

Profiling MoltenVK would be easier if synchronousQueueSubmits was possible to set after device is created.

[kvark]

@zeux frankly, I don't understand why you'd ever want to profile with synchronousQueueSubmits == false. It's not like it parallelizes any work. It's just moving it to a different thread that's hidden from you.

[zeux]

@kvark synchronousQueueSubmits == false is the default. It can make your code more parallel by moving the work to another thread that can run concurrently with subsequent command submission - this is similar to the driver threading that AMD/NV do for DX11.

Of course, this isn't really how Vulkan/Metal are supposed to be driven - if you have several command recording threads, with default value of synchronousQueueSubmits my understanding is that you'll be CPU bound on the thread that processes submits.

[kvark]

@zeux

synchronousQueueSubmits == false is the default.

That puzzles me no less :)

It can make your code more parallel by moving the work to another thread that can run concurrently with subsequent command submission

Isn't it using the very same libdispatch queue anyway? So a subsequent submission would still not be able to be done in parallel with the last one, no matter what thread it's trying to execute on.

this is similar to the driver threading that AMD/NV do for DX11.

That's an interesting fact, however I don't think the analogy holds here given the separate recording from submission in Vulkan.

[zeux]

This doesn’t provide parallelism between submissions but it provides parallelism between recording and submission. The latter has very significant cost in MVK. There are non-trivial details wrt linearizing the command flow - I don’t know OTOH how possible it is to do immediate recording that is done when the recording ends - not when submission is performed...

The driver threading I mentioned is the same, really. DX11 deferred contexts have a separation between recording and submission, but recording typically just buffers commands and submission flushes them to the driver thread which is exactly what MVK is doing.

[billhollings]

@zeux Ah! Good catch! Will fix.

[billhollings]

BTW...another purpose of the dispatch queue is to support the Vulkan concept of assigning a queue submission priority.

[billhollings]

Fixed in PR #219. Please retest and close.

[billhollings]

@zeux

An upgraded and more permanent fix for this has been made in PR #226.

The config has now been moved to VkInstance...to allow configuration changes to be made before each VkDevice is created.

Please update your use of MoltenVK config settings, retest, and close.