[HN Gopher] Porting WebGL Shaders to WebGPU
___________________________________________________________________
Porting WebGL Shaders to WebGPU
Author : AshleysBrain
Score : 73 points
Date : 2021-10-26 15:03 UTC (7 hours ago)
(HTM) web link (www.construct.net)
(TXT) w3m dump (www.construct.net)
| lainga wrote:
| The confusion with `let` and `var` does seem confusing from a JS
| perspective, but it seems to be so that you can have the same
| mental model between WGSL and SPIR-V:
|
| https://github.com/gpuweb/gpuweb/issues/2207
| devit wrote:
| It seems to be a syntax mismash between Rust, which uses `let`
| and `let mut`, and JavaScript, which uses `const` and `var`,
| giving WGSL's `let` and `var`, probably chosen because they are
| the shortest.
| djxfade wrote:
| Javascript also has `let`. It's basically like var, but
| doesn't get hoisted. And can't be unassigned once assigned.
| paulgb wrote:
| Good article, I was looking for a resource like this when I was
| experimenting with WGSL. I ended up writing a short cheat sheet
| that might be useful to others here:
| https://github.com/paulgb/wgsl-cheat-sheet
| Jasper_ wrote:
| I took a very different approach for porting my WebGPU shaders
| over: I have far too many shaders to port (sometimes pretty
| massive ones! [0]), so I used Naga [1] at to runtime-translate my
| GLSL shaders to WGSL. I had to get involved a bit upstream to fix
| quite a few different bugs in the implementation, but once I got
| it working I was really happy with the result. It's quite fast,
| it compiles to a pretty light-weight WebAssembly module, and it
| works surprisingly well.
|
| [0]
| https://github.com/magcius/noclip.website/blob/e15f8045cf262...
| [1] https://github.com/gfx-rs/naga/
| wrnr wrote:
| Cool project, there is also someone working on making wgsl and
| glsl together: https://github.com/scoopr/naga-include-poc
| saurik wrote:
| Why do you do this translation at runtime--causing every user
| to have to re-execute it--instead of at compile-time? Is there
| some kind of per-user optimization this makes possible?
| AshleysBrain wrote:
| Sorry about the formatting at the top. An unexpected problem with
| the blog system on our website! The rest of it looks OK though.
| slx26 wrote:
| My main worry with WebGPU is the dependence with Javascript. If I
| understand it correctly, you can't use web APIs nor stuff like
| WebGPU directly through web assembly anyway, so there's always a
| javascript glue layer involved.
|
| Now, I know some languages like Rust have decent bindings that
| hide all that, but I wonder about the performance cost of that
| glue. Has someone measured it, or estimated how better we could
| go without it? Or am I completely wrong about this? Or are there
| clear plans to make this better/disappear? (Though in my brief
| research I didn't find anything like it).
| modeless wrote:
| WebGPU is a less chatty API than WebGL. You can kick off a huge
| amount of GPU computation with just a couple of function calls.
| The overhead of the function calls themselves is usually not a
| big issue. That said, I know there has been work in Chrome to
| make these calls more efficient for WebGL and I think the
| overhead is actually small.
| hunterb123 wrote:
| https://github.com/WebAssembly/WASI/issues/53
| wrnr wrote:
| The same WebGPU API can be used as a cross platform layer to do
| graphics, no js needed. For example rust's wgpu can just be
| used without a browser.
| astlouis44 wrote:
| 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 learn more, you can
| join our Discord here: https://discord.gg/zUSZ3T8
| ianlevesque wrote:
| As a gamer though, why would I want to play any of these
| developers' games through the browser instead of Steam?
| zamalek wrote:
| A single player title? Yeah, no thanks.
|
| However, think of the convenience of joining your friends on
| a web-based Minecraft-like game. And then hyperlinking to
| another server with some in-game mechanic.
|
| This is something I'm really interested in doing open source,
| once WebUDP is more mature.
| hunterb123 wrote:
| To try it out? Also to play or check in on a friend's
| computer or a public computer.
|
| The ease of visiting a game like a website is sometimes
| preferred, depends on the game.
|
| There's a game where the web client is mainly used to view
| streams of other players (instead of streaming video they
| mirrored the same packets they received/sent to your web
| client)
| astlouis44 wrote:
| It's a bigger deal for developers, as they don't have to give
| up 30% to Steam, and they can directly distribute to their
| end users on their own site by embedding.
|
| Not to mention instant cross-platform availability across
| PC/Mac/Android and iOS. Even Xbox supports WebGL2 via the new
| Chromium Edge they shipped on there recently.
| pjmlp wrote:
| To detriment of players experience, because neither Web 3D
| APIs are a match to native hardware capabilities.
| warvstar wrote:
| No downloads and the ability to easily and quickly jump into
| the action, especially useful for multiplayer or social
| games.
| sheepdestroyer wrote:
| You're maybe not saving the game to disk, but you still
| have to download it. At least the assets you're going to
| interact with. And if you want to play again, then you keep
| the game/assets in a browser cache somewhere and there's
| not much difference with downloading and installing the
| game, in terms of bandwidth/diskspace
| JoeyJoJoJr wrote:
| Of course, but from the user's perspective this is all
| transparent. Parent comment is talking from the UX
| perspective.
| kaetemi wrote:
| Yep. I don't see this game-in-the-browser thing taking off
| anytime soon for anything serious. Player retention, and
| immersion, are terrible. Casual 'adware' games, maybe.
| Impossible wrote:
| It seems like you aren't associated with Epic? What's the long
| term outcome here? Have Epic take your PRs? Get
| hired\acquihired (it's unclear if you are a company or a group
| of hobbyists)? It seems like when WebGPU is production ready
| Epic will support it as well as WebXR...
|
| Epic's goal is very obviously to disrupt Steam and app stores
| as well... Ignore all of this if you actually are an Epic
| employee of course :)
| astlouis44 wrote:
| Just to clarify, we're a funded startup and we've already had
| calls with them showcasing our platform. The goal is to get
| our SDK and tools in the hand of every UE developer out
| there.
| skinner_ wrote:
| > GLSL supports the ternary ?: operator. WGSL does not support
| this, but provides the built-in function select(falseValue,
| trueValue, condition) which does much the same thing (although
| mind that parameter order!).
|
| I'd really like to hear a justification for that parameter order.
| To me it seems like the 4th best option out of 6.
| jamienicol wrote:
| It could be because it matches the order of glsl's `mix()`. Not
| sure why glsl chose that order, though perhaps you might find
| it less unintuitive for an interpolation than a select. (Mix
| acts as a select rather than interpolation when the third
| argument is a boolean)
| skinner_ wrote:
| That makes much sense, thanks! But then why didn't they call
| it mix() or lerp() or interpolate()? I would have immediately
| spotted the logic behind it.
|
| EDIT: I think I get it, there also a mix() with a different
| type signature but same parameter order.
| kevingadd wrote:
| lerp(zero, one, t) -> select(falseValue, trueValue, condition ?
| 1.0 : 0.0)
| RantyDave wrote:
| Semi-related: does anyone have WebGPU running on an M1 Mac?
| Pretty sure it "can be done" but the appropriate experimental
| options are not even there on either Safari or Chrome...
| jak6jak wrote:
| Really glad you made this article. Do you guys use rust for
| webGPU?
| jeroenhd wrote:
| 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.
| ferdowsi wrote:
| 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...
| jabl wrote:
| 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.
| pjmlp wrote:
| It can only expose a subset of their capabilities.
|
| Don't expect using mesh shaders on WebGPU for example.
| astlouis44 wrote:
| What game engine do you use? UE4 or Unity?
| yissp wrote:
| Agree, it gives you pretty low-level access if you need it, but
| you can still draw a triangle in under 100 lines, e.g.
| https://github.com/morzel85/webgpu-wgsl-hello-triangle
| NiekvdMaas wrote:
| Is there any advantage at this point in time to port a game to
| WebGPU? Is it going to run faster, or have broader browser
| support in the future?
| gnarbarian wrote:
| assuming you are comparing it to webgl. WebGPU has better
| compute support. in practice this means you can more
| effectively use shaders to perform things like physics, math
| heavy computation, or algorithms that benefit from massive
| concurrency. this puts the advantages way beyond just games.
| pjmlp wrote:
| Not at all, it took 10 years for WebGL 2.0 to be generally
| available, and WebGPU is with luck reaching MVP 1.0 in 2022 on
| Chrome, let alone anywhere else.
| fulafel wrote:
| No to first question, unless you count learning, as it's mot
| enabled in browsers yet. Maybe to second (depending on your
| game).
| modeless wrote:
| At this time I would recommend WebGL 2. WebGL 2 is finally
| supported in all major browsers now that Safari 15 shipped.
| WebGL 2 has some of the benefits mentioned in the article for
| WebGPU, such as a reasonable minimum texture size (2048 vs 64
| in WebGL 1) and the built-in ability to get the size of a
| texture in a shader.
|
| WebGPU will not ship in all browsers for some time, and when it
| does it will not have have wider hardware support than WebGL 2.
| It has the potential to be faster in some cases, but the
| difference is unlikely to matter for most. The big draw of
| WebGPU should be compute shader support, though it is
| definitely possible to do compute work in WebGL 2 either with
| transform feedback or just regular shaders.
| hajile wrote:
| It is currently shipping behind a flag in desktop versions of
| Chrome (and all its derivatives), Safari, and Firefox. It is
| also shipping behind a flag in Firefox for Android. I don't
| think it's too far out from finally shipping.
|
| The biggest boon would be for mobile devs to help avoid the
| 30% store tax, but this is also the reason why mobile Chrome
| and mobile Safari (especially Safari) tend to lag behind in
| major ways.
| modeless wrote:
| 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 things hold the web
| back.
|
| Monetization is the big thing that people always talk
| about. The lucrative interstitial app install ads that
| mobile games have aren't on web, and in-app purchases have
| a lot more friction. Handling large binary assets is also a
| place where the web is lacking and WebGPU won't fix that.
| Finally, there's a lot of ecosystem and tools stuff that
| needs to happen too. The engines need to add web platform
| support which goes more than skin deep. Shipping a game as
| one giant binary is not good enough for web, you need to
| split your code into dynamically loadable modules and
| stream your assets. You need Basis Universal compressed
| textures. Etc.
|
| Fix all of the above and then web games can shine, with or
| without WebGPU. Realistically, fix monetization and the
| rest will follow. Big caveat though: I think many see the
| monetization techniques currently used by mobile games as
| exploitative. It's not clear that you could do web game
| monetization competitively without the same level of
| exploitation.
| snuser wrote:
| I play a lot of web games without any of that stuff now
| pjmlp wrote:
| Web 3D APIs are castrated, they will never be able to match
| native APIs.
|
| Going for GL ES 3.0 subset, when devices do GL ES 3.2?
|
| Going for a MVP 1.0 with minimum overlap across Metal,
| Vulkan and DX12 instead of using their full blown
| capabilities?
|
| In both cases, having to use native GPU debugging tools
| anyway.
|
| Rather give the 30%.
| klodolph wrote:
| It's like a web version of Vulkan / Metal / DX12, in that it's
| designed to more directly represent how modern GPUs work. If
| you are happy with your WebGL performance, by all means,
| continue using it. However, it can sometimes be a bit hard to
| understand what is going wrong (performance-wise) in an OpenGL
| or WebGL application... the underlying implementation will
| sometimes paper over its limitations. You can accidentally
| stray from the high-performance paths.
|
| There are some feature differences, like how WebGPU has compute
| shaders.
___________________________________________________________________
(page generated 2021-10-26 23:01 UTC)