Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome ships WebGPU

developer.chrome.com

Post reply on HN
Print view View original

111–120 of 405 posts

Re: Chrome ships WebGPU

#111

Post by tormeh »

mike_hearn wrote: post #97
tormeh wrote: post #6

This is HUGE news. Webgpu solves the incentives problem where all actors tries to lock you in to their graphics/compute ecosystem by abstracting over them. It's already the best way to code cross-platform graphics outside the browser. This release in Chrome ought to bring lots more developer mindshare to it, which is an awesome thing.

"Webgpu solves the incentives problem where all actors tries to lock you in" Or flipped around, it creates an incentive problem where none of the vendors see much benefit in doing R&D anymore, because browsers aren't content to merely abstract irrelevant differences, they also refuse to support vendor extensions except for their own. No point in adding a cool new feature to the GPU if Chrome/Safari insists on blockin…

Good and valid point. Effort will naturally focus on the lowest common denominator. Any new features would have to be implemented in software in the WebGPU layer for targets without API support. That's probably going to slow development of new extensions.

However, I think what GPU programming needs at the moment is better ergonomics, and code portability is a step in the right direction, at least. Currently it's quite a bit more annoying than CPU programming.

Re: Chrome ships WebGPU

#112

Post by pjmlp »

flohofwoe wrote: post #107
pjmlp wrote: post #99

Earlier quoted context omitted.

Not at all. First of all, if one depends on SPIR being present, then a SPIR to WGSL compiler needs to be present when deploying to the Web part of WebGPU. Secondly, it will be yet another extension spaghetti that plagues any API that Khronos has some relation to.

It already made sense to have a SPIRV- and SPIRVCross-based shader pipeline in cross-platform engines with WebGL support though (because you'd want to author shaders in one shading language only, and then translate them to various target languages, like some desktop GLSL version, then separate versions for GLES2/WebGL and GLES3/WebGL2, and finally HLSL and MSL, WGSL is just another output option in such an asset pipe…

And we all know how well it works when features don't map across languages, WebGPU meeting minutes is full of such examples, hence why threejs is adopting a graphical node editor for easing the transition between GLSL and WGSL.

Re: Chrome ships WebGPU

#113

Post by yread »

0xDEF wrote: post #87

Chrome and Firefox have supported WebGL since 2011 and WebAssembly since 2017. What is the reason we don't have at early-2010s quality AAA game experiences running in the browser?

There is Doom 3

https://wasm.continuation-labs.com/d3demo/

Released in 2004, but still quite impressive

Re: Chrome ships WebGPU

#114

Post by mike_hearn »

tormeh wrote: post #111
mike_hearn wrote: post #97

Earlier quoted context omitted.

"Webgpu solves the incentives problem where all actors tries to lock you in" Or flipped around, it creates an incentive problem where none of the vendors see much benefit in doing R&D anymore, because browsers aren't content to merely abstract irrelevant differences, they also refuse to support vendor extensions except for their own. No point in adding a cool new feature to the GPU if Chrome/Safari insists on blockin…

Good and valid point. Effort will naturally focus on the lowest common denominator. Any new features would have to be implemented in software in the WebGPU layer for targets without API support. That's probably going to slow development of new extensions. However, I think what GPU programming needs at the moment is better ergonomics, and code portability is a step in the right direction, at least. Currently it's quit…

Yeah, but that's because performance always takes priority. The Vulkan/DX12/Metal APIs are lower level and much more tedious than OpenGL and shader based OpenGL was itself a step backwards in usability from the fixed function pipeline (when doing equivalent tasks). So the trend has been towards more generality and performance at the cost of usability for a long time in graphics APIs. Prefixing it with "Web" won't change that. I'm not saying that's a bad trend - the vendors take the perspective that people who need usability are using game engines anyway so "easy but low level" like classic GL is a need whose time has passed. There's probably a lot of truth to that view.

Re: Chrome ships WebGPU

#115

Post by illiarian »

iamsanteri wrote: post #81

Wow, this could be huge for enabling more efficient rendering of also more basic animations and effects on the web making it a smooth experience.

If your entire site/app is in WebGPU then yes I guess?

Otherwise it does nothing for "smooth animations on the web"

Re: Chrome ships WebGPU

#116

Post by littlestymaar »

Timja wrote: post #90
littlestymaar wrote: post #71

Earlier quoted context omitted.

You only get fingerprinting from your method if the variation of the “fingerprint“ between two different runs by the same user is lower than the difference you get between two different users. This is far from obvious since it depends a lot on the workload running on the machine at the time. I'm not aware of a single fingerprinting tool that primarily use this king of timing attack rather than more traditional finger…

Not sure if the workload makes a difference. We would have to make examples of what Computation1 is and what Computation2 is to make a prediction if certain types of workloads will impact the ratio of their performance. Example: s=performance.now(); r=0; for (i=0; i For me, the ratio is consistently larger in Chrome than in Firefox. Which workload would reverse that?

Fingerprinting in the usual sense the term isn't about distinguishing Chrome from Firefox, it's about distinguishing user A from user B, … user X reliably in order to be able to track the user across website and navigation sessions.

Your example is unlikely to get you far.

Edit: in a quick test, I got a range between 8 and 49 in Chrome, and between 1.27 and 51 (!) on Firefox, on the same computer, the results are very noisy.

Re: Chrome ships WebGPU

#117

Post by foldr »

fulafel wrote: post #103
foldr wrote: post #65

Earlier quoted context omitted.

Could you explain what techniques would make this possible? I can see how it's possible in principle, if you, say, compile JS down to bytecode and then have the interpreter time the execution of every instruction. I don't immediately see a way to do it that's compatible with any kind of efficient execution model.

The rest would be optimization while keeping the timing sidechannel constraint in mind, hard to say what the performance possibilities are. For example not all computations have externally observable side effects, so those parts could be executed conventionally if the runtime could guarantee it. Or the program-visible clock APIs might be keeping virtual time that makes it seem from timing POV that operations are slow…

>not all computations have externally observable side effects

You can time any computation. So they all have that side effect.

Also, from Javascript you can execute tons of C++ code (e.g. via DOM manipulation). There's no way all of that native code can be guaranteed to run with consistent timing across platforms.

Re: Chrome ships WebGPU

#118

Post by foldr »

illiarian wrote: post #110
foldr wrote: post #56

Earlier quoted context omitted.

Even supposing that Google do benefit from it in that manner, there would be far simpler ways for them to make fingerprinting easier. It's extremely unlikely that this is a significant motivation for adding WebGPU. Not to mention that a lot of the fingerprinting you can potentially do with WebGPU can already be done with WebGL.

Google has many hands in many pots. It's not that they are necessarily looking for easier ways to do fingerprinting. But they sure as hell wouldn't put up a fight to make it harder.

Then why does Chrome contain loads of features to make fingerprinting harder?

Re: Chrome ships WebGPU

#119

Post by flohofwoe »

0xDEF wrote: post #87

Chrome and Firefox have supported WebGL since 2011 and WebAssembly since 2017. What is the reason we don't have at early-2010s quality AAA game experiences running in the browser?

One technical reason is that AAA games would require a complete rethinking of their asset loading strategy, since they'd basically have to use the internet as a very slow and very unreliable hard disc to stream their assets from (which basically means you can't stream the kind of high resolution assets expected of AAA games at all, so you'll have to find a simplified graphics style that looks explicitely 'non-AAA').

You don't want to wait minutes or even hours to download all assets before the game can start (and then again next time because the browser can't cache so much data).

TL;DR: the web platform is different enough from native platforms that ports of bleeding edge games (even from 10 years ago) are not feasible. You'd have to design the entire game around the web platform limitations, which are mainly asset streaming limitations.

But that doesn't happen because there's no working monetisation strategy for 'high profile games' on the web platform, the whole business side is just way too risky (outside some niches which mainly focus on casual F2P games).

The 3D API is only a very small part of the entire problem space (and by far not the most important).

In the end it's mostly about the missing 'business opportunity'. If there would be money in (non-trivial) web games, the games would come.

Re: Chrome ships WebGPU

#120

Post by Ciantic »

This is a comment from Aras Pranckevičius [1]:

> WebGL was getting really old by now. I do wonder whether WebGPU is a bit late too though (e.g. right now Vulkan decides that PSOs maybe are not a great idea lol)

> As in, WebGPU is very much a "modern graphics API design" as it was 8 years ago by now. Better late than never, but... What's "modern" now seems to be moving towards like: bindless everything (like 3rd iteration of what "bindless" means), mesh shaders, raytracing, flexible pipeline state. All of which are not in WebGPU.

I'm not that versed on details, but would interesting to hear what are the advantages of this modern bindless way of doing things.

[1]: https://mastodon.gamedev.place/@aras/110151390138920647

Post reply on HN