[Webkit-unassigned] [Bug 199142] New: [WHLSL] Compiles should be asynchronous

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=199142

            Bug ID: 199142
           Summary: [WHLSL] Compiles should be asynchronous
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebGPU
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mmaxfield at apple.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190624/3ff92b83/attachment-0001.html>