[HN Gopher] Capturing the WebGPU Ecosystem
___________________________________________________________________
Capturing the WebGPU Ecosystem
Author : mariuz
Score : 48 points
Date : 2023-11-11 17:09 UTC (5 hours ago)
(HTM) web link (developer.chrome.com)
(TXT) w3m dump (developer.chrome.com)
| andrewstuart wrote:
| WEbGPU still not available in Chrome Linux.
| vivaldidev wrote:
| Looks like WebGPU for Android is coming first, shipping stable
| in January:
|
| https://twitter.com/Tojiro/status/1720592878056112158
| astlouis44 wrote:
| Anyone else excited for what WebGPU will enable for next
| generation browser games and real-time 3D web applications?
| janosdebugs wrote:
| There was a discussion on the BabylonJS forums back in August
| about this. [1] TL;DR the GPU may now be available, but having
| to download several gigabytes of assets to download and sit in
| your browser cache may be a bit problematic. Also, the
| expectations towards a web-based thing are different than a
| dedicated download.
|
| [1] https://forum.babylonjs.com/t/why-havent-3d-web-games-
| reache...
| SeanAnderson wrote:
| I definitely am :D to the point that I started trying to build
| a WASM game just to start troubleshooting pain points.
| pjmlp wrote:
| Nah, it is an API for 2015 hardware, after a decade of WebGL we
| still haven't got anything better than SpectorJS, and on top of
| it we have to either use yet another shading language, or
| abstract it via code generation tooling.
|
| The only thing good about it, is moving the Web 3D beyond GL ES
| 3.0 subset.
|
| Don't expect nanite or Fortnite on the browser anytime soon.
| lyu07282 wrote:
| Why? It's pretty close to the Vulcan API why is Web GPU stuck
| in 2015 as you claim? Also Web GPU isn't just the browser
| didn't you read the article?
| flohofwoe wrote:
| Vulkan is moving away from the extreme "everything is baked
| into immutable objects" philosophy of Vulkan 1.0 (see: http
| s://registry.khronos.org/vulkan/specs/1.3-extensions/man...
| ), while WebGPU will be stuck with this model for quite a
| while and even adds more restrictions on (for instance
| baking shader resource bindings into immutable BindGroup
| objects).
|
| WebGPU still has a nice balance between convenience and a
| somewhat modern feature set, but going down to the native
| platform 3D APIs (Metal, D3D12 and Vulkan) will always
| offer a much bigger feature set and less CPU overhead
| (mainly because WebGPU also needs to support mobile GPUs,
| and some of those are indeed 10 years behind the curve).
| rezmason wrote:
| In many ways, you're right.
|
| In my opinion, the main strength of WebGPU is it removes the
| cost of re-implementing something when targeting a different
| platform. If that was present in 2015, maybe we'd have more
| games, more interesting applications, and less pressure on
| people who feel locked into one vendor's ecosystem.
| beebeepka wrote:
| More scared than excited but yeah, definitely excited.
|
| As a non game developer, though, I am wondering if migrating
| existing renderers would allow me to create UIs, or parts of
| them, using graphics that is not just html+CSS without the
| massive overhead that we currently have. I mean, I can draw the
| frames just fine but these extra cycles suck power and produce
| heat
| neftaly wrote:
| https://github.com/coconut-xr/apfel-kruemel works today, I
| only know about battery-optimized software in the context of
| games and IoT though.
|
| https://felt.com/blog/svg-to-canvas-part-2-building-
| interact... and https://github.com/servo/pathfinder/ might be
| of interest.
| gmiller123456 wrote:
| I'm not expecting too much, as it's going to be hard to
| monetize something people get the source code to. So I think
| it's going to be limited to small projects, or sub projects
| that don't cost a lot to develop.
| vore wrote:
| If you're so worried about people getting the source code to
| it, you can just compile to WebAssembly.
| connicpu wrote:
| I imagine any serious project won't be written in JavaScript,
| and WASM code with symbols stripped out is about as opaque as
| x86 or ARM assembly, especially when you start getting into
| the code sizes you expect for a full game engine or
| productivity suite.
| Waterluvian wrote:
| When you minify js don't you end up with the same kind of
| thing? You can "decompile" both and neither give you any
| symbols. Just a bunch of random letters calling other
| random letters, etc. Maybe I need an example to understand.
| Drakim wrote:
| Not quite, minify JS can be "beautified" to get pretty
| reasonable JS back, sans variables and functions having
| letters for names as you noted. But this is because
| obfuscated JS is still valid JS, it's just made ugly.
|
| Obfuscated assembly is often changed in such a way that
| there are no corresponding language constructs to
| "reverse" back to, if it originally came from a language
| like C++. Sure you can see the actual assembly code, but
| you can't recreate the higher level C++ constructs in a
| sane way, because the obfuscation technique scrambles
| things too much.
| flohofwoe wrote:
| That problem has been solved by F2P client/server games a
| long time ago. The important stuff happens on the server, and
| the client is "only" a dumb renderer. You'll need to assume
| that the client is compromised anyway, whether that also
| means that the client source code "leaks" is irrelevant for
| monetization (via in-app-purchases, which again in controlled
| by the server while the client only renders the "shop UI").
| flohofwoe wrote:
| Don't get yourself too hyped up, in the end WebGPU is running
| on the same GPU as WebGL2, and unless your code is CPU bound
| you won't see performance improvements if your WebGL2 code is
| already well optimized.
|
| And currently some high-frequency WebGPU calls have an even
| higher CPU overhead than similar WebGL2 calls (I wrote about
| that here a bit: https://floooh.github.io/2023/10/16/sokol-
| webgpu.html).
|
| WebGPU allows more flexibility of course, compute shaders and
| storage buffers are more flexible and cleaner than trying to
| shoehorn the same stuff into vertex/fragment shaders and using
| textures as "poor man's storage buffer", but that doesn't mean
| that one approach is slower or faster than the other.
| nottorp wrote:
| I wonder why "capturing". This being Google, it makes me think
| "abuse of dominant market position". Or embrace and extend.
|
| Was the title a freudian slip or something?
| vore wrote:
| Is there anything in the article that makes you think "abuse of
| dominant market position", or simply a weird turn of phrase in
| the title?
|
| As much as we all distrust Google, this kind of tangential
| comment is pretty tiresome when it has no relevance to what's
| being posted.
| Waterluvian wrote:
| Yeah I did a double take when I realised it was from the Chrome
| team. I clicked expecting to read about the next way they're
| going to leverage it to squeeze profit.
| jacobgorm wrote:
| What I don't like is having to rewrite all my compute shaders and
| being forced to give away the sources.
| potwinkle wrote:
| I'd rather know the sources than have every website be an
| opaque WASM blob.
| DaiPlusPlus wrote:
| Shaders haven't been precompiled for PC in years due to GPU
| heterogeneity - it's only games consoles where binary shaders
| are usable. OpenGL's wiki is full of dire warnings about
| relying on binary shader representations:
| https://www.khronos.org/opengl/wiki/Shader_Compilation
|
| I'm surprised there isn't much support for even a bytecode
| representation...
| animatethrow wrote:
| Are Windows prebuilt Dawn WebGPU libs available anywhere so I can
| try to draw a triangle using C/C++? Many Google projects are
| extremely time consuming to build on a Windows machine and need
| like 30+ GB of space for all tools and dependencies. Windows is
| still over 95% of the paid non-console gaming market so those who
| want to pay bills making games can't ignore it. BGFX is easy to
| clone and build from GitHub; examples are up and running in only
| a few steps. Any way to do the same with Dawn WebGPU?
| vore wrote:
| https://eliemichel.github.io/LearnWebGPU/getting-started/hel...
| has a good getting started guide on it but, ironically, wgpu
| with wgpu-native might be easier to get started with, even with
| C/C++. https://github.com/gfx-rs/wgpu-native/releases/latest
| has ZIPs with Windows DLLs and headers.
| flohofwoe wrote:
| The Mach engine project maintains prebuilt Dawn libraries and
| also a simplified build-from-source workflow using the Zig
| build system, see:
|
| https://machengine.org/pkg/mach-gpu-dawn/
|
| It's also possible to use wgpu-native in C/C++ projects as
| prebuilt library, see:
|
| https://github.com/gfx-rs/wgpu-native
| solardev wrote:
| I wonder if games are gonna move more in this direction or just
| render on the server altogether, like GeForce Now and Luna and
| PSNow and XCloud. Even if they could harness 100% of my phone GPU
| or M2, that's nothing compared to a proper gaming setup.
|
| I feel like this would only really get used for simple mobile
| games and not for actual titles with gameplay... even if the API
| is there, most people don't have powerful enough devices to drive
| modern console or PC quality games. And if they did, they'd be
| looking on Steam or an app store, not the Web.
|
| What's the use case?
| janosdebugs wrote:
| There's a whole bunch of 3D stuff you can do on the web, from
| product demos and configurators to interactive navigation.
| Simple casual games will work fine too if optimized properly.
| Heck, my wife and I built a 3D content website with BabylonJS
| for no other reason than we could.
| astlouis44 wrote:
| My startup is building a platform exactly for this - to enable
| developers to make their native games to be browser-compatible
| utilizing WebAssembly and WebGPU.
|
| It also gets more interesting when you consider that the world
| is increasingly moving to ARM. Take Qualcomm's new ARM chips
| for example; they're competitive with Apple Silicon already.
| WASM/WebGPU represents a straightforward way to convert x86
| games to run on these new chips.
|
| Below is a blog post about our platform-as-a-service and tools,
| and our current development focus to support Unreal Engine 5 in
| WebGPU/WASM:
|
| https://theimmersiveweb.com/blog
| opergamer404 wrote:
| Interesting to see if more compute intensive applications will
| move towards the web. Big implications for games, as well as real
| "desktop software" like CAD, video editors, DAW software, etc.
| Narishma wrote:
| > The Chrome team is also considering using Dawn as the default
| rendering backend for all browser UI elements, including menus,
| toolbars, developer tools, and web content.
|
| Wouldn't that make Chrome unusable if you don't have a recent
| GPU?
| flohofwoe wrote:
| There's a proposal for a "WebGPU compatibility mode" which also
| works on older devices:
|
| https://github.com/gpuweb/gpuweb/issues/4266
|
| Also I guess Chrome could just fall back to a "legacy rendering
| backend" if WebGPU isn't supported.
| tormeh wrote:
| What's your definition of recent? Anything with Vulkan, DX12,
| or Metal support should work. wgpu also has best-effort support
| for OpenGL 3.3. The situation seems similar with Dawn.
| tormeh wrote:
| > This can be used to target Dawn, wgpu, and others, easing the
| creation of bindings for languages using C FFI
|
| I wish we could agree on something slightly more ergonomic than a
| C FFI. The largest common denominator has to be slightly more
| advanced than C (if we decide to not accommodate C).
| flohofwoe wrote:
| The "ergonomic" API is the Javascript API. Of course that is
| only usable from Javascript (ok, and Typescript).
|
| If you want to use WebGPU from as many languages as possible, a
| C API is pretty much the only option.
|
| There's also a C++ API, but just as with the JS API, this is
| limited to a single language.
|
| For usage from Rust you can also use gfx-rs/wgpu, which has a
| Rust-idiomatic API (e.g. see: https://github.com/gfx-
| rs/wgpu/blob/trunk/examples/hello-tri... - which to be honest
| doesn't look more "ergonomic" than the C API to me).
|
| Also, it's not like the C API is "unergonomic", it works with
| C99 designated initialization which makes it quite nice to use.
| The only downside is COM-style manual lifetime management via
| ref/release calls, but if you are used to Direct3D that's a no-
| brainer (it works exactly the same), and the C++ API has RAII
| wrappers for this stuff.
| bobajeff wrote:
| Yes but until we have this "more better thing" please continue
| to expose your libraries to the c FFI. Also, please make sure
| it's actually better before telling everyone to use it.
|
| Thanks.
___________________________________________________________________
(page generated 2023-11-11 23:00 UTC)