[Public WebGL] WebVulkan and multithreaded command queue assembly

Florian Bösch [email protected]
Tue Mar 3 22:38:38 PST 2015


Modify JS engines to be thread safe (at least when run in a WebWorker) and
add multithreading to WebWorkers. Give WebWorkers direct Vulkan access.
Problem solved.


With Vulkan, Khronos is introducing its first API that supports command
queue assembly and sensibly made it fit for multi-threaded command queue
assembly (note that it says multi-threaded and not multi-processed, this
will prove important in just a few paragraphs).

To understand why this matters it's important to realize two things:

1) Todays CPUs usually have multiple cores (anything from 2 to 8 usually)
and they can allocate execution time on several cores for several threads
in the same process. So modern threads truly can be physically threaded.

2) Games and graphics heavy applications often have CPU intensive tasks
that can run in parallel (such as say running a physics engine and a LOD

Today on the web we cannot do threads. On a personal note, I don't like
threads much, I prefer multiprocessing. The reason we cannot use threads
mainly has to do with the fact that neither the DOM nor the JS
interpreter/compiler are thread safe. In the case of JS, it's quite a
common theme among scripting languages to suffer the GIL effect (global
interpreter lock), where the interpreter uses some resources and logic that
aren't thread safe and hence imposes a lock on operations by the scripting
language (this leads to synchronization among would-be threads and hence
renders them largely inefficient).

The alternative for the Web today to deal with this problem is web-workers.
But this isn't a good way to go about it because this would require a
fairly complex (and also globally locked) mechanism to transport
commands/data to and from workers so that they can be emitted against a
Vulkan context. Additionally such mechanisms (usually implemented over
shared memory of some kind) also tend to be somewhat less efficient
(because they rely on IPC) than threads which can share a memory space
(although threads have their own drawback).


As long as there's APIs/drivers that assume threads as their primary way to
facilitate parallelization, the best fit to serve these is to actually have
OS-level threads. You can make other forms of paralellization work, but
those will always be suboptimal solutions.


Of course this leaves the web in somewhat of a pickle, because you cannot
introduce threads on the JS main thread. It's largely futile to try to make
the DOM and various JS APIs thread safe, and even if you could, you'd
mostly just end up synchronizing the threads again.

So a relatively "simple" (in quotes here because it still requires a major
overhaul to the JS engine) solution to this would be to introduce a JS
realtime context of a sort. In this context, JS is executed in its own
process, and it only has access to a limited set of APIs (XHRs, WebSockets,
Vulkan Contexts, WebRTC and some other minor APIs) but crucially not the
DOM and its ilk.

This is largely what WebWorkers are today. The proposed change would be to
overhaul to the JS engine to be able to effectively multithread (this might
be more or less difficult depending on which one it is), and add the
capability to spawn threads from JS to JS if it runs in such a performance
context (or a WebWorker).

I believe this to be a far more attainable goal than the various complex
workarounds attempted to make multi-processed rendering work (canvas
proxies, what have you). It's more attainable because it can ignore most of
the complexities of dealing with the rest of the browser and concentrate on
providing a clean context to run non DOM related code against an API
(Vulkan) that's designed to work well in that environment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150304/2376f0b4/attachment.html>

More information about the public_webgl mailing list