WebGLNext-Proposals

> They can be defined in an IDL kind of way, like e.g. WebIDL, abstractly e.g. Internet RFCs, or define mappings to all major languages in the GPGPU field, namely C, C++ and Fortran. That's already done. Mozilla's Obsidian is an object-oriented WebIDL interface to Vulkan: https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas... Again, Khronos is just a standards group. It does what its members tell it to. Khronos is far more lightweight of an organization than, say, ISO's C++ committee. Instead of blaming Khronos, you could perhaps encourage them to focus on initiatives like Obsidian.

Obsidian didn't manage to materialize a Khronos working group, so it's not moving forward. Apple instead went with the W3C to form the GPUWeb group, based on their work on WebGPU. The Obsidian folks at Mozilla have decided to follow this path instead, see here: https://github.com/KhronosGroup/WebGLNext-Proposals/pull/11#... However, there's no real writeup of what the API will end up remotely looking like right now, so it's too early to speculate. WebGPU's original prototype used Metal's shading language for instance (since the prototype came from WebKit), but any real standard probably will probably change things up. I believe the webgpu-servo folks have, in the mean time, begun working on lower level components/libraries to target Vulkan/DX12/Metal, for use by systems like WebGPU. Sort of like ANGLE by the Chrome team, but for newer GFX

WebGPU would gain traction if it was based on Vulkan. But it's not. However, Mozilla's Obsidian API is: https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas... Apple has so little to gain over Vulkan by developing its own API but so much to lose by not adopting Vulkan (gaming companies may actually prefer developing games on the cross-platform Vulkan to target macOS/iOS devices, too, at the same time, instead of using DirectX).

Obsidian ultimately became WebGPU in servo (the op's link) –https://github.com/KhronosGroup/WebGLNext-Proposals/pull/11#...

No, Mozilla's is Obsidian: https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...

Thanks for the link! WebGPU looks like it could be quite powerful for ad-hoc grid compute ;) https://www.w3.org/community/gpu/ https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas... https://github.com/google/nxt-standalone

For folks curious about WebGL in a Vulkan world, there's https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas... .

I hope soon we'll have a shot at rethinking the browser's rendering stack. Not necessarily ala WebRender [0] since it needs to be backwards-compatible, but something with a clean slate. I imagine programmable layout, GPU contour rasterization, motion-blur, programmable shaders, layer blending, LOD and infinite zooming, and render-to-texture (for putting 2D surfaces in a 3D scene). None of this is unnecessary if you bring AR/VR to the mix. Soon people will want to put on their AR/VR glasses and read books, select pieces of text, open links, etc. There are no APIs that allows them to do that in a web browser. Ergo => flock to native. Quite a bit of work remains for that to happen. A whole bunch of APIs need to be exposed in the browser, such as native text rendering APIs, a better-than-WebGL2 API for graphics [1][2], a way to make the webpa

Yes, Obsidian, Mozilla's proposal, is based on Vulkan, https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...

Other browser vendors should adopt WebGPU only when Apple adopts Vulkan. Apple's stubbornness is the only reason why Khronos is even considering this "portable" low-level API with fewer features in the first place (even though Vulkan was supposed to be that portable API - again, thanks Apple!): https://www.khronos.org/3dportability In the meantime, Mozilla has proposed its own low-level web graphics API that the other browser vendors can back: https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...