5 ms·

Thoughts about a WebGL-Next (2016)

67 points by panic 10y ago

bobajeff 10y ago
I can't wait to read flohofwoe's thoughts on WebGPU.
- flohofwoe 10y ago
  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.
  - glhaynes 10y ago
    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?
    - flohofwoe 10y ago
      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).
chj 10y ago
Whatever it would be, I hope drawing a triangle is a one liner.
flohofwoe 10y ago
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 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).
- pjako 10y ago
  You could use your oryol shader generator?
- shurcooL 10y ago
  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 https://github.com/goxjs/gl
- thinline 10y ago
  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?
iLoch 10y ago
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.
- flohofwoe 10y ago
  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).
  - exDM69 10y ago
    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.
    - flohofwoe 10y ago
      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.
HugoDaniel 10y ago
Are there any plans to improve debugging ? It seems to be the elephant in the room with this kind of tech

67 points by panic 10y ago

bobajeff 10y ago

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

flohofwoe 10y ago
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.
- glhaynes 10y ago
  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?
  - flohofwoe 10y ago
    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).

chj 10y ago

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

flohofwoe 10y ago

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 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).

pjako 10y ago
You could use your oryol shader generator?
shurcooL 10y ago
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 https://github.com/goxjs/gl
thinline 10y ago
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?

iLoch 10y ago

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.

flohofwoe 10y ago
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).
- exDM69 10y ago
  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.
  - flohofwoe 10y ago
    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.

HugoDaniel 10y ago

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