Thoughts about a WebGL-Next (2016) | Hacker News Reader

Thoughts about a WebGL-Next (2016)

floooh.github.io

67 pointspanic21 comments

Here's a followup blogpost I wrote a few months later where I did a little experimental Typescript WebGL-wrapper (it was just one weekend, so not complete):

http://floooh.github.io/2016/10/24/altai.html

I think something like this could be used as a minimal wrapper for WebGPU, with WebGL2 and WebGL as fallback paths (shaders will be a problem though).

You could use your oryol shader generator?

That's neat, and I agree there's a lot of potential to learn and experiment with that approach.

I've done something similar with Go, it was a library [0] that exposed identical API in 3 situations: desktops, mobile, and browsers. It uses OpenGL 2.1 backend on desktop, OpenGL ES 2.0 on mobile, and WebGL 1.0 in browsers.

It worked really well and results in an extremely cross-platform graphics library. It was also a great way to learn about the few subtle differences between OpenGL ES and WebGL, and understand the kind of challenges they faced when designing the WebGL API.

[0] https://github.com/goxjs/gl

In the older post you mentioned one of the performance issues being that JS couldn't write directly to the GPU for security reasons and so a copy to the GPU would have to be done after the browser vetted things.

To my _very_ naive thinking, and if video RAM was plentiful, couldn't things be set up such that the JS runtime _could_ write to the GPU, but to a reserved section of video memory that wasn't directly executable? After being checked by the JS runtime, bytecode could be copied over to another area in video memory to be run. Would something like this work? If so, has this approach been tried by anyone?

Security issues aside, why wouldn't we want "WebVulkan"? I suspect there would be some interest from various parties in making a WebAssembly compatible cross platform 3D library. Being able to create something with Unreal Engine, for example, while targeting both web, mobile and desktop seems like it would be incredibly powerful.

Vulkan is a more like a driver-level API, an API to write other 3D-APIs with. You need over a thousand lines of code to render a triangle. It doesn't abstract the underlying GPU enough that you can have a single code path that gives you best performance across GPU vendors (at least that was the state a couple of months ago, I don't know if this has changed).

I think this is the wrong approach for a 3D API that should be usable by more people than a very small group of highly specialised rendering engineers. Metal is an API that fills that gap very well, it is easy to use and is a modern low-overhead API.

A proper modern 3D web API should be agnostic to the underlying native API (a bit similar to how WebGL runs on top of D3D on Windows, but with much less 'conversion overhead' since most state is compiled into immutable objects).

I am going to respectfully disagree with you here. Yes, Vulkan is a difficult API to work with and it's not at all beginner friendly.

But simplicity and ease of use should not be guiding the decisions, the emphasis should be on providing a way to run Unity, Unreal, and other engines (new and old) on the Web.

Even if Vulkan is a difficult API to work with, a low level 3d API should be available in a browser. It could be used as a building block to create frameworks and engines that are easy to use.

Even WebGL is "too low level" for most application developers, which is why three.js and other frameworks are popular.

Yes there are also valid points for having an really low level 3D-API like a WebVulkan in the browser, and the 'big-engine-makers' seem to be fond of this idea. But I see this more in the realm of a 'compilation target', more for WebAssembly then JS. Translating Vulkan 1:1 to D3D12 or even Metal would be challenging though, I think most of the advantages of having a real bare-metal API would be lost in this translation-layer I guess.

The Altai example is great but they can already be implemented in JavaScript with very low overhead. If the performance is a concern then we should be moving more towards lower level APIs such as Vulkan, and let JS libraries implement their own API on top of that when that extra performance is needed. There is also the possibility that performance improvements to WebGL could always be made (i.e. supporting command queues or SPIR-V).

I think that Metal / WebGPU is just at the right abstraction level for a modern 3D API. It's like a successor to D3D11 (which is a mighty fine 3D-API). Vulkan and D3D12 are really not a lot of fun to work with. I'd rather maintain an thin API wrapper on top of 3 different 3D-APIs at the complexity level of D3D11 or Metal, instead of having to maintain a single wrapper for D3D12 or Vulkan (and you need to support multiple 3D APIs anyway, since none of them exists on all relevant platforms). But that is strictly IMHO, I guess there's also people who enjoy working in D3D12 or Vulkan ;)

The problem with the WebGpu proposal is that it is difficult to implement with Vulkan efficiently as the spec is now.

I'm sure the spec can still be changed to be a better fit, though.

It's not about being too low-level for developers, it's about it being too low-level for implementation. Vulkan is lower level than DX12 or Metal; you can't implement it on top of those platform APIs, like ANGLE runs OpenGL ES on top of a compatibility shim over DirectX or desktop OpenGL. A cross-platform graphics API in the browser needs to be high-enough level to abstract over all of Vulkan/DX12/Metal and provide a consistent interface so that developers don't have to know which one their application is running on.

Either that, or in addition to WebVulkan you need WebDX12 and WebMetal.

> you can't implement [Vulkan] on top of [DX12 or Metal]

http://lmgtfy.com/?q=vulkan+metal

First result: "MoltenVK is an implementation of Vulkan that runs on Apple's Metal graphics framework on iOS and macOS."

You can already do that, that is the whole point of a game engine, to abstract way the underlying platforms, while providing higher level tooling.

Also a reason, why outside communities like HN, most game developers don't really care about API wars.

>Security issues aside

I don't think you can really put those aside - that's the whole point of web as a platform - that visiting a link won't let you take over my PC (and that's hard enough as is in practice).

Just use native apps if you want native access.

I can't wait to read flohofwoe's thoughts on WebGPU.

I think it's great, hopefully SPIR-V will be used for shaders. I guess the current use of MetalSL is a compromise to get the prototype up and running fast. I think that MetalSL is pretty much the perfect shader language, but its compiler shouldn't have to live in the browser.

Not too familiar with either - is MetalSL's compiler much more complicated than SPIR-V's, such that it being in the browser would be onerous?

MetalSL is basically a slightly stripped-down C++ with vector math datatypes and some new annotation keywords, but I think it basically requires a complete C++ compiler (Apple's MetalSL compiler is based on LLVM I think). SPIR-V is a bytecode format with the idea that several shader languages could be compiled into SPIR-V (hopefully also MetalSL).

Are there any plans to improve debugging ? It seems to be the elephant in the room with this kind of tech

Whatever it would be, I hope drawing a triangle is a one liner.

Reply on news.ycombinator.com