Live data from Hacker News

Porting WebGL Shaders to WebGPU

construct.net

51–60 of 64 posts

Re: Porting WebGL Shaders to WebGPU

#51

Our team is working to build out support for Unreal Engine 4 and Unreal Engine 5 to support WebGPU, so game developers and real-time 3D developers can export their creations to the web at near native performance and access features like computer shaders. Long term goal is to disrupt Steam and the App Stores. We're also working on WebXR support to enable UE VR apps on the web. If anyone is interested and wants to lear…

As a gamer though, why would I want to play any of these developers' games through the browser instead of Steam?

Aside from what others have mentioned, the browser's sandboxing makes it a lot more appealing to try out small indie/hobbyist casual games on a whim. Like the Flash game aggregators of old, or maybe itch.io today.

Re: Porting WebGL Shaders to WebGPU

#52
post #37
post #26

As a non-web-developer, I'm kinda excited about WebGPU. Specifically WebGPU native, that has potential to be a portable modern 3D graphics API without the difficulty of using Vulkan or DX12.

It can only expose a subset of their capabilities. Don't expect using mesh shaders on WebGPU for example.

I'll say I am definitely biased in favor of WebGPU up front[2].

WebGPU is focused on landing 1.0 currently, so yes, more features are not on the immediate roadmap.

But they've been considering/investigating adding support for this before mesh shaders in DX12 were even finalized[0] so it's not like there is some "we cannot / will not expose that functionality" mandate going on here. Despite its name, WebGPU is actually pretty much a 1:1 mapping of what is commonly available across APIs.

Separately, AMD doesn't support mesh shaders in Vulkan either, in fact Vulkan doesn't at all outside of a Nvidia extension from what I understand - and it sounds like there are some concerns from Khronos about whether they even map to all GPU architectures in a reasonable way at all.[1]

If you want to argue "but by dropping to the level of DX12, Vulkan, Metal, etc. I can use some very specific new features" that's totally true, but you can do that with WebGPU native too: after all, Dawn and other WebGPU implementations are just abstractions over those 3 APIs. One can just as easily hop into their code and add your own extension to make use of Mesh shaders in DX12, I can say that at least Dawn's codebase is set up to allow for such extensions from what I've seen.

[0] https://github.com/gpuweb/gpuweb/issues/445

[1] https://github.com/KhronosGroup/Vulkan-Docs/issues/1423#issu...

[2] https://devlog.hexops.com/2021/mach-engine-the-future-of-gra...

Re: Porting WebGL Shaders to WebGPU

#53
post #46

Earlier quoted context omitted.

What Safari is shipping behind a flag is not anything like the current version of WebGPU. I don't think it supports WGSL, for example. It's going to be a long time before all three browsers have shipped implementations that are interoperable and not behind flags. I don't think WebGPU is the biggest thing that's going to let mobile game devs start shipping on the web. WebGL 2 can do graphics well enough today. Other t…

I play a lot of web games without any of that stuff now

There's definitely a niche market out there, I think https://poki.com exemplifies it. Which ones do you play?

Re: Porting WebGL Shaders to WebGPU

#54
post #37
post #26

As a non-web-developer, I'm kinda excited about WebGPU. Specifically WebGPU native, that has potential to be a portable modern 3D graphics API without the difficulty of using Vulkan or DX12.

It can only expose a subset of their capabilities. Don't expect using mesh shaders on WebGPU for example.

If you're writing a game engine for an AAA game, surely you have the budget and manpower to use those lower level API's and push the GPU to its limit.

If the rest of the world can get 90% of the way with an easier to use and more portable API, that would be very nice.

Re: Porting WebGL Shaders to WebGPU

#55
post #26

As a non-web-developer, I'm kinda excited about WebGPU. Specifically WebGPU native, that has potential to be a portable modern 3D graphics API without the difficulty of using Vulkan or DX12.

What game engine do you use? UE4 or Unity?

I'm not a game developer, so neither.

Re: Porting WebGL Shaders to WebGPU

#56

As someone who's never used this API: is there some kind of permission prompt for this before websites start trying to use my GPU for crypto mining? Most CPU crypto miners were basically worthless, but GPU power is a whole lot more powerful.

No permission prompt, just as there is no permission prompt for WebGL (which already enables crypto mining on your GPU). https://arxiv.org/pdf/1904.13071&ved=2ahUKEwipqPGblenzAhWDbs...

I see. That is somewhat worrying. However, the authors of the paper do state that there are significant drawbacks to the WebGL API that I believe WebGPU would solve, notably by its direct access to compute resources.

I suppose I'll just be disabling these APIs until I can find a personal use for them, then.

Re: Porting WebGL Shaders to WebGPU

#57
post #54
post #37

Earlier quoted context omitted.

It can only expose a subset of their capabilities. Don't expect using mesh shaders on WebGPU for example.

If you're writing a game engine for an AAA game, surely you have the budget and manpower to use those lower level API's and push the GPU to its limit. If the rest of the world can get 90% of the way with an easier to use and more portable API, that would be very nice.

With WebGL 2.0 we have an API designed for 2011 hardware finally fully available in 2021, without any game relevant to compete with something like Infinity Blade, released for GL ES 3.0 on the iPhone.

That is hardly 90% of the way.

WebGPU won't be any different.

Re: Porting WebGL Shaders to WebGPU

#58
post #52
post #37

Earlier quoted context omitted.

It can only expose a subset of their capabilities. Don't expect using mesh shaders on WebGPU for example.

I'll say I am definitely biased in favor of WebGPU up front[2]. WebGPU is focused on landing 1.0 currently, so yes, more features are not on the immediate roadmap. But they've been considering/investigating adding support for this before mesh shaders in DX12 were even finalized[0] so it's not like there is some "we cannot / will not expose that functionality" mandate going on here. Despite its name, WebGPU is actuall…

When WebGPU runs on the browser you cannot definitely do it, after all that is the whole point being discussed about working around stores.

Given the distance between WebGL 2.0 and GL ES 3.2, with the 10 years that took to made it available everywhere, good luck waiting for WebGPU to become mature for adoption.

Mesh shaders was the easiest example to refer to, there are plenty of 2021 native features that won't make it into version 1.0.

Then to top that, we get a shading language that seems like C++, Rust and HLSL had a child.

Re: Porting WebGL Shaders to WebGPU

#59
post #58
post #52

Earlier quoted context omitted.

I'll say I am definitely biased in favor of WebGPU up front[2]. WebGPU is focused on landing 1.0 currently, so yes, more features are not on the immediate roadmap. But they've been considering/investigating adding support for this before mesh shaders in DX12 were even finalized[0] so it's not like there is some "we cannot / will not expose that functionality" mandate going on here. Despite its name, WebGPU is actuall…

When WebGPU runs on the browser you cannot definitely do it, after all that is the whole point being discussed about working around stores. Given the distance between WebGL 2.0 and GL ES 3.2, with the 10 years that took to made it available everywhere, good luck waiting for WebGPU to become mature for adoption. Mesh shaders was the easiest example to refer to, there are plenty of 2021 native features that won't make…

> Given the distance between WebGL 2.0 and GL ES 3.2, with the 10 years that took to made it available everywhere, good luck waiting for WebGPU to become mature for adoption.

WebGL2 took 4 and a half year to complete (with OpenGL ES 3.0: published in August 2012, and implementations of WebGL2 final version shipped in browsers in early 2017). Why did Apple refused to implement it for four more years? I don't know, but at least it isn't happening with WebGPU.

> Then to top that, we get a shading language that seems like C++, Rust and HLSL had a child.

Is that supposed to be a bad thing?

Re: Porting WebGL Shaders to WebGPU

#60
post #58

Earlier quoted context omitted.

When WebGPU runs on the browser you cannot definitely do it, after all that is the whole point being discussed about working around stores. Given the distance between WebGL 2.0 and GL ES 3.2, with the 10 years that took to made it available everywhere, good luck waiting for WebGPU to become mature for adoption. Mesh shaders was the easiest example to refer to, there are plenty of 2021 native features that won't make…

> Given the distance between WebGL 2.0 and GL ES 3.2, with the 10 years that took to made it available everywhere, good luck waiting for WebGPU to become mature for adoption. WebGL2 took 4 and a half year to complete (with OpenGL ES 3.0: published in August 2012, and implementations of WebGL2 final version shipped in browsers in early 2017). Why did Apple refused to implement it for four more years? I don't know, but…

What guarantees do you have it won't happen again?

Even if Apple had done it on time, it was a 2012 hardware API for 2017 hardware, and never exposed a complete ES 3.0 API surface, nor anything beyond it up to ES 3.2.

Intel had two failed attempts to bring compute into the browser.

Yes it is a very bad thing, when Vulkan can keep using GLSL and HLSL, while DX12 happily will use any HLSL from the API history, and Metal can use proper C++14 shaders.

WGSL is web politics as usual.

Post reply on HN