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

Re: [Public WebGL] WebVulkan



On Mon, Aug 31, 2015 at 2:44 AM, Brandon Jones <bajones@google.com> wrote:

The WebGL working group has given input to Vulkan pretty early on in the process, but aside from a couple of broad requests the general message was "Don't dumb anything down on our account."

If Vulkan can be sandboxed (which is a dire need on any platform) then it shouldn't be much of a pain to make it Web safe. I'd be against dumbing it down of course. I'd be much more worried if it couldn't be sandboxed.

We're too deep into WebGL 2 to be distracted much with what WebGL Next looks like, but certainly the idea of basing it on next gen APIs has been discussed.

I appreciate that there's a lack of resources to plot out the future of hardware accelerated rendering and computation on the Web. However that doesn't mean it doesn't have to get done too. We can't afford to keep just one ball at the time in the air.

Here's the thing: it will probably be impractical to try and expose a ~1:1 mapping for Vulkan and friends on the web like we did with WebGL and GLES2/3. I'm expecting that anything we do build will require some pretty heavy shimming if you wanted to do WebAssembly builds targeting it with Vulkan/DX12 C++ code.

I'd very much like to have a discussion on that topic, but I can't. I can't because there's no Vulkan specification. Which means that you can draw your conclusions from information not available to me. Any discussion on that basis is not productive.

As such my gut feeling is that instead of trying to mimic any particular next gen API on the web we should probably build something that feels web-native (Vulkan definitely does not!) while still retaining the best ideas from the current crop of APIs. Of course that puts a tremendous amount of spec effort on the WebGL working group, and I'm not sure we're currently equipped to handle that.

You could argue that WebGL doesn't feel "web-native". But since there's no Vulkan specification, that point can also not effectively be discussed. However if you're looking for web-native APIs, there's VRML... . Of course there's also the mutually incompatible "runs faster than JS" variants like (p)nacl, whatever mozilla does, and the never implemented not as plugin WebCL.

But as I said, the current focus is WebGL 2. It's a near-term, very realistic goal that will open up significant new GPU capabilities for developers.

WebGL 2 does not open up much that you can't have with extensions in WebGL 1. It's a welcome change and the new stuff not available in extensions is good to have. But it's not a dramatic change. ES 3.1 is a dramatic change because of compute shaders. Much in the way that Vulkan is dramatic change, because it lets you run a much more powerful form of GPGPU comptuation than bolted on compute shaders.

Avoiding that work in favor of focusing on a next gen API would be doing the WebGL community a huge disservice.

Pushing hardware accelerated rendering/computation in browsers along can't be a single task process. You can't (obviously) drop the ball on WebGL2. But you also can't drop the ball on Extensions, WebGL3 and WebGL-Next/Vulkan/whatever. If the present and future of hardware accelerated rendering/comptuation on the Web can't be serviced by the current structure/commitment to it, it's time to talk how to fix that.