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

261–270 of 405 posts

Re: Chrome ships WebGPU

#261

Post by dahart »

pjc50 wrote: post #108
geysersam wrote: post #98

Earlier quoted context omitted.

Why would I want bit-identical output? Genuinely curious. I see there's some increase in confidence perhaps, although the result can still be deterministically wrong...

It's very hard to do tests of the form assert(result == expected) if they're not identical every time. And it can waste a horrendous amount of time if something is non-bit-identical only on a customer machine and not when you try to reproduce it ...

Trying to reproduce is a good point, but at the same time it’s usually a pretty bad idea to do tests of the form assert(result == expected) with a floating point result though. You’re just asking for trouble in all but the simplest of cases. Tests with floating point should typically allow for LSB rounding differences, or use an epsilon or explicit tolerance knob.

There’s absolutely no guarantee that a computation will be bit-identical even if the hardware primitives are, unless you use exactly the same instructions in exactly the same order. Order of operations matters, therefore valid code optimizations can change your results. Plus you’ll rule out hardware that can produce more accurate results than other hardware if we demand everything be bit-identical always, it will hold us back or even regress. Hardware with FMA units are an example that produce different results than using MUL and ADD instructions, and the FMA is preferred, but hardware without FMA cannot match it. There are more options for similar kinds of hardware improvements in the future.

Re: Chrome ships WebGPU

#262

Post by dist-epoch »

shadowgovt wrote: post #220
dist-epoch wrote: post #141

Earlier quoted context omitted.

Think about bindless as raw pointers vs handles. In bindless (pointers) you say "at this GPU memory location I have a texture with this params". In non-bindless you say "API create a texture with these params and give me a handle I will later use to access it". Bindless gives you more flexibility, but it's also harder to use since it's now your responsability to make sure those pointers point at the right stuff.

How badly can you wreck state in bindless? Badly enough to see the pointers of another process or detect a lot of high-detail information on what computer is running the program? If so, that'd be a non-starter for a web API. Web APIs have to be, first and foremost, secure and protect the user's anonymity.

On Windows GPU memory space is virtualized by the OS, so it has the same kinds of access controls as regular system memory.

Linux/Mac also support GPU virtualized memory, but I'm not sure if it's always enabled.

Re: Chrome ships WebGPU

#263

Post by fulafel »

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…

It doesn't pay off for most apps to run on GPUs because of the fragmentation, bad dev experience, sad programming language situation, proprietary buggy sw stacks and so on. Reining in the cambrian explosion to let non-niche applications actually use GPUs would be a good tradeoff.

(But of course like you say this doesn't detract from the native code apps that are content being nonportable, or want to debug, support, bug-workaround, perf-specialcase their app on N operating systems x M GPU hardware archs x Z GPU APIs, x Y historical generations thereof)

Re: Chrome ships WebGPU

#264

Post by topaz0 »

mschuetz wrote: post #258
topaz0 wrote: post #243

I'd rather not have websites soak up my compute resources, thanks. They are already doing that many times too much for my taste.

You're free to disable features you don't like. For others, this is good news.

Incredible insight, but I fear it won't work out well: when the option is there and ubiquitous, websites will rely on it, so disabling features is basically choosing to save some of my resources in exchange for a broken web experience.

Re: Chrome ships WebGPU

#265

Post by jug »

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.

Dear god no, use CSS for that. It's already hardware accelerated in the regular browsers. You're talking of website presentation and that's the purpose of CSS.

Re: Chrome ships WebGPU

#269

Post by jayd16 »

flohofwoe wrote: post #259
jayd16 wrote: post #256

Earlier quoted context omitted.

Can you explain what the split is supposed to be? I'm fairly confused because mobile GPUs (tile based) are creeping into the desktop space. The Apple Silicon macs are closer to tile based mobile GPUs than traditional cards. What APIs are supposed to be separate, why, and what side of the fence is the M1 supposed to land on?

These are good posts to answer your question I think: - https://www.yosoygames.com.ar/wp/2023/04/vulkan-why-faq/ - https://www.gfxstrand.net/faith/blog/2022/08/descriptors-are... In places where Vulkan feels unnecessarily restrictive, the reason is mostly some specific mobile GPU vendor which has some random restrictions baked into their hardware architecture. AFAIK it's mostly not about tiled renderers but about res…

Ah ok, so its not so much the mobile architecture as the realities of embedded GPUs and unchanging drivers compared to more uniform nVidia/AMD desktop drivers.

This is a real problem but I'm not sure splitting the API is a solution. If a cheap mobile GPU has broken functionality or misreports capabilities, I'm not sure the API can really protect you.

Re: Chrome ships WebGPU

#270

Post by cyral »

codedokode wrote: post #227
kevingadd wrote: post #188

Earlier quoted context omitted.

Saturating the user with permissions requests for every single website they visit is a dead-end idea. We have decades of browser development and UI design history to show that if you saturate the user with nag prompts that don't mean anything to them, they will just mechanically click yes or no (whichever option makes the website work).

Permission popups can be replaced with an additional permission toolbar or with a button in the address bar user needs to click. This way they won't be annoying and won't require a click to dismiss.

Like the site settings page on Chrome, which is in the address bar (clicking the lock icon)? You can set the permissions (including defaults) for like 50 of these APIs.
Post reply on HN