[WebGPU] Limit the number of MTLCommandQueue objects created
Created attachment 455300 [details] Patch
I don't know enough about the api.. Is this a standard technique? I cannot immediately see anything else than limiting the number of devices, which probably is not an option if the test suite creates thousands of devices? Can there be ordering problems if flush on other device induces a flush on the commands of the other device? // device A tasks command1 command2 signalSemaphore(s1) // device B tasks waitForSemaphore(s1) commandZZ // A non-linear programmer writes them as a.command1 a.command2 b.waitForSemaphore(s1) b.commandZZ b.flush a.signalSemaphore(s1) a.flush // The shared command buffer implementation would contain command1 command2 waitForSemaphore(s1) // deadlock commandZZ signalSemaphore(s1) // where individual command buffers implementation would contain // command buffer 1 command1 command2 signalSemaphore(s1) // command buffer 2 waitForSemaphore(s1) // No deadlock? commandZZ
You’re right that deadlocks would naturally be a problem. However, we have 2 mitigating factors: 1. We don’t have fences / semaphores / barriers in the API yet. In fact, we don’t even have multiple queues yet (for a single device) with which to use semaphores. See https://github.com/gpuweb/gpuweb/pull/1217 2. Even when we did, we solved this deadlock problem by validating that: A) Signal values only ever increased over time B) A command to signal the value being waited on has already been submitted (This is only possible because we don’t have multi-threading yet, so a single thread sees every signal/wait command produced by the app.)
Comment on attachment 455300 [details] Patch I should see if the test suite calls GPUDevice.destroy().
(In reply to Myles C. Maxfield from comment #4) > Comment on attachment 455300 [details] > Patch > > I should see if the test suite calls GPUDevice.destroy(). It totally does.