[Public WebGL] WebVulkan and multithreaded command queue assembly

Steve Baker [email protected]
Wed Mar 4 09:01:43 PST 2015

It's pretty clear how it's heading though - a byte-code style
psuedo-machinecode for shaders - and everything else being sent as a
stream of command buffers and some minimal API for queueing buffers up and
shipping them off to the GPU.

It seems like it's going to be just like working on PlayStation 3(ish).

Lessons learned with WebGL (things like being able to abort a slow-running
shader to avoid DOS attacks) need to be in Vulkan from the get-go.

  -- Steve

Brandon Jones wrote:
> I'm not in a position to dive into the details of the APIs, but I think
> it's pretty safe to say that exposing APIs like Vulkan/DX12/Metal to the
> Web with little to no modification will be a non-starter, mostly for the
> same reasons we're not exposing mapBuffer in WebGL2. The memory models
> just
> aren't Web friendly.
> That's not to say that we shouldn't look to this new wave of APIs for
> inspiration. I think there's several concepts present across all of the
> new
> APIs that would play well on the Web, and may even work nicely with web
> workers in some form. I just don't don't believe we'll get a ~1:1 mapping
> like we saw with WebGL and OpenGL ES.
> This is all a little premature, though. We don't have public specs for
> anything but Metal and the working group has a clear direction forward
> with
> WebGL2. Once that's in users hands and the new API specs are publicly
> available I look forward to some great discussion about the next step.
> --Brandon
> On Wed, Mar 4, 2015 at 4:08 AM Floh <[email protected]> wrote:
>> Do we already know how exactly multithreaded command buffer building
>> works in Vulkan? My guess is that Vulkan itself doesn't care/know
>> about threads but instead the application maps a pointer to resource
>> memory (e.g. a command buffer) on the main thread, and a thread
>> directly writes to the mapped memory area, signals back to the main
>> thread when it's done, and the main thread enqueues the command buffer
>> (as far as I know, the application is completely responsible for
>> resource management in those new low-level 3D APIs, like making sure
>> that the CPU doesn't write to memory that the GPU is currently using).
>> This is the most efficient way to setup a resource since it doesn't
>> involve extra data copying, and is also recommended for other types of
>> resources in modern GL (e.g., have a single GL context on the main
>> thread, create a few, big, persistently mapped buffers there, and
>> write to them from other threads, while making sure that no areas in
>> the buffer are written that are pending for rendering).
>> While this is the most efficient way to setup resources, I don't see
>> how this would work in browser (e.g. with renderers living in another
>> process etc...). Maybe SharedArrayBuffers would at least help to
>> eliminate some memory copies:
>> https://blog.mozilla.org/javascript/2015/02/26/the-
>> path-to-parallel-javascript/
>> (I think this will become the preferred solution for emscripten's
>> pthreads-like threading implementation).
>> Cheers,
>> -Floh.
>> On Wed, Mar 4, 2015 at 7:38 AM, Florian Bösch <[email protected]> wrote:
>> > TL;DR
>> >
>> > 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.
>> >
>> > Preamble
>> >
>> > 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
>> engine)
>> >
>> > 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).
>> >
>> > Conclusion
>> >
>> > 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.
>> >
>> > Proposal
>> >
>> > 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.
>> -----------------------------------------------------------
>> You are currently subscribed to [email protected]
>> To unsubscribe, send an email to [email protected] with
>> the following command in the body of your email:
>> unsubscribe public_webgl
>> -----------------------------------------------------------

 -- Steve

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list