[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebVulkan

On Tue, Aug 9, 2016 at 6:05 AM Florian Bösch <pyalot@gmail.com> wrote:
The problem seems to be that Vulkan is multi-threadable, but not multi-processable, and that it can't share contexts across processes. This is compounded by the fact that UAs have decided that JS won't get threads and that rendering happens in a dedicated process.

JS will get threads and shared memory via SharedArrayBuffer (see https://developer.mozilla.org/en-US/docs/Web/_javascript_/Reference/Global_Objects/SharedArrayBuffer and https://kripken.github.io/emscripten-site/docs/porting/pthreads.html).

 As for rendering in a separate process, that's certainly been a common pattern (and one that Firefox is moving to, though not necessarily for WebGL content).  But there are ways to mitigate this; for example, we're planning on adding WebGL access from worker threads, and I can see a place for a dedicated special worker thread that's a WebGL worker (or really a generic GPU worker -- as you suggest below) which the implementation can then put in its own separate process for proper isolation.  That thread can then spawn its own GPU worker threads that could possibly share the same Vulkan context, with the whole thing just exporting a set of surfaces for the UA's compositor to put on the screen.

There are advantages to that pattern even for WebGL -- having all GPU access in a single process is good for stability, but not great; the browser can control what it renders for regular web page content, but not for WebGL.  Having WebGL run in its own process would provide wins not just for WebGL, but also for general responsiveness and stability.

    - Vlad

There are several ways this can be addressed:
  1. Make Vulkan multi-processable, this should really have been done from the start.
  2. Make Vulkan share its context across processes
  3. For each Vulkan context, create a "Vulkan Worker", which hosts a JS interpreter, and the Vulkan context (and give JS in that worker process the ability to multithread)
  4. Move the Vulkan context into the main JS process/tab
These are solvable problems, and memory-mapping shouldn't be avoided in JS because it's scary. It isn't. You just make sure the memory is properly initialized to 0 prior to handing it to JS, just the same as you do with ordinary array buffers. GPUs do implement memory region isolation as well, and if Vulkan does not (which I highly doubt), that's something to fix as well.