Re: Emscripten and Vulkan

[juj j]

Unfortunately there is no way to support Vulkan unless some kind of "WebVulkan" specification was created first so that Emscripten could back on to it. The initial thoughts have been that Vulkan would be a bit too low level to be able to enforce web security/sandboxing, and hence such a WebVulkan API might not be feasible. I don't know if anyone has since made any work with researching how to create a web safe version of Vulkan, and what that would exactly mean, but if someone does have proposals about it that can construct the proper security model on top of Vulkan, I'd be all ears at least! :)

2016-02-19 13:22 GMT+02:00 Joshua Biggs <fili...@gmail.com>:

With the official release of Vulkan, will Emscripten be looking to support it in the future like they support OpenGL?

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Floh]

I've been thinking a little about how a modern alternative to WebGL could look like which would still be safe and easy to use but gets rid of some annoyances, inefficiencies and complexity.

The 'new' 3D-APIs like D3D12 or Vulkan are low-level only in one aspect: the explicit resource management and direct resource access. IMHO this is also the least desirable area for a web-API which should be simple and easy to get into, and I think this explicit resource management is the only security-related feature which would be complicated to 'harden'. The idea is simply to drop explicit resource management and keep the old 'managed' style.

All other aspects of the modern 3D APIs *are* desirable for a web-API, they would even result in a simpler, faster and more robust API than WebGL (IMHO):

- pipeline-state-objects instead of granular GL state, this would reduce the required number of calls into the API dramatically

- the concept of render passes, this is especially useful for tiled mobile renderers

- shaders as precompiled (SPIR-V) byte-code instead of having to compile from source

- command buffers/lists: this would allow to efficiently assemble command lists on WebWorkers and enqueue them on the main thread (much less complex as making WebGL run in workers)

All resource management would be traditional D3D11/GL style: buffer and textures objects, with usage hints, and under-the-hood buffer-renaming for dynamic resources.

Metal on OSX/iOS demonstrates how such a 'simple and modern' 3D-API could look like. If one ignores the ugly Objective-C on the surface, Metal is a very elegant and simple API, much simpler then OpenGLES2/WebGL, and much easier to get into than Vulkan or D3D12.

It would even be possible to create such an API in Javascript on top of WebGL as a shim, similar to how WebAssembly is currently developed (I guess it would even be possible to translate SPIR-V back to GLSL).

Cheerio,

-Floh.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.