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

Re: [Public WebGL] WebVulkan

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.