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

Re: [Public WebGL] WebVulkan




On Aug 5, 2016, at 11:27 AM, Kearwood Kip Gilbert <kgilbert@mozilla.com> wrote:

Hello,

I’d just like to add my 2c, as Vulkan has much to offer to WebVR content.

If we could implement something as close as possible to Vulkan, with the minimal changes needed to secure the memory model, there is still a lot of benefit over WebGL.

In particular, tessellation, multi-threaded command buffer generation, and GPGPU for physics calculation.  Perhaps this would fit well in a world with WebWorkers.

Tessellation and GPGPU don’t need Vulkan. They’ve been in OpenGL for some time. Multi-threaded command buffer generation though is an attractive feature provided only by Vulkan.


IIRC, the SPIRV header explicitly declares the memory model used for the shader and there are several memory models to choose from.  Perhaps we could only support a subset and validate the byte code to ensure it is in fact constrained to the stated behavior described by the header.

The memory model choice at present is only between GLSL and OpenCL, basically whether pointers are supported or not. So it is not relevant to WebVulkan).


Perhaps implementing the Vulkan-Like API on top of Metal is an option?  Perhaps libraries like three.js could simply detect WebVulkan and use it when available and fall back to lower quality and less performant WebGL when needed until wrappers around other API’s such as Metal are implemented?

Vulkan on Metal exists already - MoltenVK. Not open source unfortunately.

Mark Kilgard gave a short presentation Migrating from OpenGL to Vulkan on the NVIDIA booth at Siggraph. In it he describes what kinds of applications can and can't benefit from Vulkan. Interesting reading.

I agree with what Floh described upthread as his ideal next gen API.

Regards

    -Mark

--

Mark Callow
President
www.edgewise-consulting.com

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail