Bug 199142 – [WHLSL] Compiles should be asynchronous

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebGPU

[Myles C. Maxfield]

Eventually, all of WebGPU should be asynchronous, but until we can get there, we can make shader compiles asynchronous. This involves two pieces: making the WHLSL compiler execute on another thread, and making the Metal shader compiler execute on another thread.

Because the MSL shader compiler involves the MTLDevice, and I don't think MTLDevices are thread safe, we probably have to start that compilation from the main thread. We can't wrap all accesses to the MTLDevice in a mutex because we can't wrap CAMetalLayer's internal uses of the MTLDevice.

Therefore, the flow probably has to work like this:
1. Kick off an asynchronous task to run the WHLSL compiler
2. When the WHLSL compiler is done, kick off a task back to the main loop to start the Metal shader compiler
3. From the main thread, use the asynchronous flavor of the Metal shader compiler.
4. In the completion callback, kick off another task back to the main thread to mark the compile as completed.

setPipeline() requires knowing the results of this compilation. However, it can't simply block on the results of the asynchronous operation, because that would cause a deadlock if it occurs during step 2 above. (The main thread can't start the MSL compiler because it's being blocked by setPipeline() waiting on the results of the MSL compiler.) Instead, the internals of setPipeline() will probably have to see whether we're in step 2 or step 4, and if we're in step 2, block until the WHLSL compiler is complete, and then synchronously invoke the Metal compiler. Then, when step 3 executes, it should detect that the MSL compiler has already been invoked, and return early. We can do something similar for step 4.

[Myles C. Maxfield]

Created attachment 372730 [details]
Use the asynchronous flavor of the MSL compiler

[Myles C. Maxfield]

Created attachment 372731 [details]
Wrap each use of MTLDevice in a mutex

[Myles C. Maxfield]

Making the WHLSL compiler asynchronous is important if we want to move the standard library to a standalone file in WebCore's bundle. We don't want to do synchronous IO on the main thread, so doing it on another thread is important.

Because we can block the main thread on the results of this asynchronous IO, this isn't a full solution, but having an asynchronous compile makes it at least possible to not block.

Eventually, a better solution would be to move the entire WebGPU implementation to another thread (sort of like a GPU process architecture, except executing in a thread instead of a process).

[Myles C. Maxfield]

WHLSL is no longer relevant.