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

Re: [Public WebGL] WebVulkan



I've bundled my current thoughts on the topic into a blog post, this
is all from an API user's perspective who's been working both with
WebGL (although mostly via emscripten), as well as native 3D-APIs
across nearly all currently existing platforms (except the current
generation of game console). I'm also more focused on lower-end GPUs
(mobile and integrated) than high-end stuff. Maybe this provides some
useful feedback to the discussion:

http://floooh.github.io/2016/08/13/webgl-next.html

Cheers,
-Floh.

On Tue, Aug 9, 2016 at 3:31 PM, Vladimir Vukicevic <vladimir@mozilla.com> wrote:
>
>
> 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:
>>
>> Make Vulkan multi-processable, this should really have been done from the
>> start.
>> Make Vulkan share its context across processes
>> 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)
>> 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.

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------