Vulkan-docs: develop webvulkan , adopt webgpu or continue with webgl ?

[GunpowderGuy]

A new low level api has recently been proposed by Apple , It is now time to reconsider webvulkan and discuss if developing it would be the best or if there is no chance of making a vulkan version ( subset ?) safe enough for untrusted applications ( i am hearing that some upcoming features may help to achieve this , could webvulkan be a subset of vulkannext , or vulkan + extensions ?) and thus making a new api would be more sensible ( i am worried that i would add yet another abstraction layer , which goes against the idea of low level apis )

Another posibility is not to go forward with neither of this apis and use webgl ( which will be continued to be developed anywhays ) with azdo , this would decrease the number of standards
https://github.com/gpuweb/gpuweb/issues/2

[bhack]

What about https://github.com/KhronosGroup/WebGLNext-Proposals?

[GunpowderGuy]

@bhack they closed my issue without comenting on it

[bhack]

But I see a comment.

[GunpowderGuy]

Its only to say that they wont hear any suggestions or answer my questionsuntil they have discussed webgl next with web browser vendors , they will also only accept proposals for them

[GunpowderGuy]

I have heard some people say that webvulkan is not practical , but is that really the case ? , i want the questions i asked in this issue answered

Ps : Another one is that if vulkan is hard to install on windows or users just need to use up to date drivers to have it ( a google chorme dev said it is a mess to install in the political langauge issue )

[krOoze]

I see two concerns with next web GL:

• It has to run on any and all APIs efficiently (especially if specific companies encourage API lock-in war) so it covers all browsers in all platforms.
  
  
  
  • Khronos seems to begin to address it: https://www.khronos.org/3dportability
  
  
• It has to run safe and securely no matter the code (e.g. no "undefined behavior"s allowed, and shredding memory before use by another process, and especially no crashing your GPU). It would probably need Vulkan SC as an intermediate step. I am not sure what would be left of Vulkan API, which relies on validation layers instead of runtime checks.

-> I think WebGL Next would be quite different from both OpenGL (except perhaps future versions) and from Vulkan. Which sucks from learning perspective, but is probably necessary split.

[cg199082]

readed this link:https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla
I found the WebAssembly maybe the key to solve the problem of bringing vulkan into web
but I follow the WebAssembly FutureFeatures https://github.com/WebAssembly/design/blob/master/FutureFeatures.md
i found some import functions are still in development status. such as Threads , GC
so i think it`s too early to talk about webvulkan before the WebAssembly spec is finished

[GunpowderGuy]

Webassembly core spec has already been finished and shipped to users , it isnt too early , the sooner we can experimenting the better ( as i think the devs have expressed ) .

[GunpowderGuy]

A garbage collector isnt necesary at all to start experimenting with obsidan , because the langs that wasm gives the most focus dont use one

[TomOlson]

Trying to wind up this old thread - the Vulkan WG's charter stops at the native API level, so we haven't felt like we could speak on behalf of more web-oriented Khronos WGs. We are committed to making Vulkan a great back end for web APIs, no matter who designs them or what they look like, and we are always interested in hearing from browser and web API developers about what they need from us.

I'll try to get someone from the appropriate group to comment on Khronos's stance on web-developer-facing APIs, and then maybe we can close this.

[kenrussell]

Currently, all of the browser vendors are participating in the "GPU for the Web" community group: https://www.w3.org/community/gpu/ . This is the appropriate place for discussion of future web graphics APIs. They welcome public discussion and comment on their mailing list or GitHub issue tracker: https://github.com/gpuweb/gpuweb/issues .

[kvark]

We are committed to making Vulkan a great back end for web APIs

Also note that Vulkan Portability Initiative can turn this from "a great backend" to "the only (required) backend", if successful.