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

191–200 of 405 posts

Re: Chrome ships WebGPU

#191

Post by MuffinFlavored »

FL33TW00D wrote: post #135

This is very exciting! (I had suspected it would slip to 114) WebGPU implementations are still pretty immature, but certainly enough to get started with. I've been implementing a Rust + WebGPU ML runtime for the past few months and have enjoyed writing WGSL. I recently got a 250M parameter LLM running in the browser without much optimisation and it performs pretty well! ( https://twitter.com/fleetwood___/status/16384…

what would it take to python -> wasm -> webgpu for the entire existing webgpu ecosystem (all of the libraries around neural networks, torch, yada yada)

Re: Chrome ships WebGPU

#192

Post by pmontra »

codedokode wrote: post #158
merlish wrote: post #153

Earlier quoted context omitted.

For a user to correctly answer a permissions dialog, they need to learn programming and read all the source code of the application. To say nothing of the negative effects of permission dialog fatigue. In practice, no-one who answers a web permissions dialog truly knows if they have made the correct answer. Asking the user a question they realistically can't answer correctly is not a solution. It's giving up on the p…

They don't need to learn programming. Just write that this technology can be used for displaying 3D graphics and fingerprinting and let user decide whether they take the risk.

Most of them will say, "I need to see this site, who cares about fingerprints." Some will notice that they're on their screen anyway, a few will know what it's all about.

Maybe "it can be used to display 3D graphics and to track you", but I expect that most people will shrug and go on.

Re: Chrome ships WebGPU

#193

Post by kevingadd »

codedokode wrote: post #158
merlish wrote: post #153

Earlier quoted context omitted.

For a user to correctly answer a permissions dialog, they need to learn programming and read all the source code of the application. To say nothing of the negative effects of permission dialog fatigue. In practice, no-one who answers a web permissions dialog truly knows if they have made the correct answer. Asking the user a question they realistically can't answer correctly is not a solution. It's giving up on the p…

They don't need to learn programming. Just write that this technology can be used for displaying 3D graphics and fingerprinting and let user decide whether they take the risk.

They're going to be confused if you say "display 3D graphics", because canvas and WebGL will still work. The website will just be laggier and burn their battery faster. That's not going to make sense to them.

"Fingerprinting" is a better approach to the messaging, but is also going to be confusing since if you take that approach, almost all modern permissions are fingerprinting permissions, so now you have the problem of "okay, this website requires fingerprinting class A but not fingerprinting class B" and we expect an ordinary user to understand that somehow?

Re: Chrome ships WebGPU

#194

Post by kevingadd »

fulafel wrote: post #62
Timja wrote: post #30

Earlier quoted context omitted.

There is no way to escape fingerprinting. Just one example: A script which runs many different types of computations. Each computation will take a certain amount of time depending on your hardware and software. So you will get a fingerprint like this: computation 1: ** computation 2: **** computation 3: ********** computation 4: ** computation 5: ************** computation 6: ************ computation 7: ********* etc…

It's possible to have the runtime execute the computations in fixed time across platforms.

No video driver is actually going to implement fixed-time rendering. So you'd have to implement it in user-space, and it would be even slower than WebGL. Nobody wants that. You're basically just saying the feature shouldn't ship in an indirect way (which is a valid opinion you should just express directly.)

Re: Chrome ships WebGPU

#195

Post by pjmlp »

bschwindHN wrote: post #142
pjmlp wrote: post #68

Get ready to rewrite all your shaders in WGSL.

You're in almost every thread about WGPU, with negative opinions about it. What would your ideal graphics API be, and why isn't it coming to fruition, do you think?

> What would your ideal graphics API be

Same capabilities as native APIs.

> , and why isn't it coming to fruition, do you think?

Politics and lack of tooling.

Why the negativity?

Consider that after 10 years, there is no Web game that can match AAA releases for Android and iOS written in OpenGL ES 2.0 (already lowering the bar here to WebGL 1.0).

And SpectorJS is the best GPU debugger we ever got.

Meanwhile in 2010,

https://www.youtube.com/watch?v=UQiUP2Hd60Y

Re: Chrome ships WebGPU

#196

Post by kevingadd »

fsloth wrote: post #177
mike_hock wrote: post #9

Earlier quoted context omitted.

And to prevent device fingerprinting, all the operations are specified to deterministically produce the same bit-exact results on all hardware, and the feature set is fixed without any support for extensions, right? Or is this yet another information leak anti-feature that we need to disable?

"..all the operations are specified to deterministically produce the same bit-exact results on all hardware..." You have to block floating point calculations as well if that is your intent.

The animals already fled the barn on that one, WebAssembly floating point is not specified to be bit-exact, so you can use WASM FP as a fingerprinting measure (theoretically - I don't know under which configurations it would actually vary.)

Re: Chrome ships WebGPU

#197

Post by kevingadd »

sebzim4500 wrote: post #27
echelon wrote: post #7

Earlier quoted context omitted.

I doubt there's as much effort being put into crypto these days. The folks hustling on crypto are now in the AI space.

Crypto prices are still quite high, I don't see why the incentives to steal gpu cycles to mine crypto are any less now than they were during the blockchain summer.

The prices don't matter if the quantity of coins you can mine is a tiny fraction, which is the problem

Re: Chrome ships WebGPU

#198

Post by kevingadd »

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.

Not really. If you want smooth and efficient rendering of basic animations/effects, you should be using CSS, because then the browser will natively rasterize, scroll and composite everything in parallel using hardware acceleration. It's far more efficient than rendering basic elements with WebGL and will probably be better than WebGPU in most cases.

Re: Chrome ships WebGPU

#199

Post by dilawar »

illiarian wrote: post #34
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.

> 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. Instead we have a third graphics standard (after canvas and WebGL) fully incompatible with the previous two that does exactly that: abstracts the OS graphics stack in a new layer

obligatory xkcd: https://xkcd.com/927/

Re: Chrome ships WebGPU

#200

Post by kevingadd »

bschwindHN wrote: post #142
pjmlp wrote: post #68

Get ready to rewrite all your shaders in WGSL.

You're in almost every thread about WGPU, with negative opinions about it. What would your ideal graphics API be, and why isn't it coming to fruition, do you think?

Not the person you're replying to, but a start would be to use an existing proven shader format like SPIRV or DXIL instead of making up an entirely new shader ecosystem in order to satisfy the whims of a single browser vendor and waste everyone's time.
Post reply on HN