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

Re: [Public WebGL] WebVulkan

To get a bit more specific on top of Justin's comments: Vulkan exclusively uses memory mapping as it's mechanism for updating allocated buffers. Because of the security restrictions that Justin mentioned you will never see a _javascript_ TypedArray that is actually mapped onto memory not owned by the _javascript_ VM. Therefore if we exposed something that looked like a memory mapped buffer it would be a total lie with severe performance implications. We'd have to do all sorts of nasty tricks to copy the bits of it that we thought had changed whenever you were "done" updating the buffer. (Which there's no clear signal for. You don't always unmap at the end of an update.) Thus we can't support Vulkan's memory model, and if we pretended that we could it would have enough overhead to destroy the perceived performance benefits of said memory model. Nobody "decided" this, it's just the nature of the language. 

(Okay, maybe technically Brendan Eich decided this? The be fair I doubt he was thinking of high performance GPU interfaces at the time.)

We CAN replace Vulkan's memory mapping with a BufferSubData-like interface, and probably simplify a few things in the process. (At that point you could hide copies to GPU memory if you wanted to.) But then we've lost the 1:1 mapping, so it seems silly to me to not take advantage of that fact to try and make the rest of the interface more web friendly.

On Mon, Aug 8, 2016 at 2:22 PM Justin Novosad <junov@google.com> wrote:
On Mon, Aug 8, 2016 at 4:33 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Mon, Aug 8, 2016 at 9:27 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
I'm confident we can expose something like Vulkan on top of Metal without too much friction.
It's the "like" bit that worries me, a bit. I'm sure Epic and Unity3D would find it rather convenient if they could plug their Vulkan backends more or less straight into the web (via web-assembly no doubt). It's also the case that all the documentation, books, references, tooling, middlewares, etc. that do start to exist for Vulkan, would help.

If you can par down on Vulkan but keep it vulkan compatible (insofar as that doesn't conflict with the webby-ness of the web), fine, call it Vulkan ES or something. The trouble starts when Vulkan ES doesn't conform to the principles, signatures and behaviors that Vulkan establishes, just as that's everytime incredibly troublesome when that happens in GL land (floating point textures anybody?).

To clarify the constraints of "webby-ness", the main thing that really ties our hands is security.  We cannot allow scripts or web assembly (or any other form of executable code downloaded from the web) to have a means of accessing memory that lies outside of its execution context. For example, _javascript_ code can only access memory belonging to objects that are on the JS heap.  Therefore, the Vulkan memory model simply cannot be exposed to the web.  Without proper execution context isolation, it becomes a lot easier for attackers to find exploits for writing web pages that do things like take over your machine.