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

241–250 of 405 posts

Re: Chrome ships WebGPU

#241

Post by pdpi »

pier25 wrote: post #215
flohofwoe wrote: post #132

Earlier quoted context omitted.

Aras is right, but the elephant in the room is still shitty mobile GPUs. Most of those new and fancy techniques don't work on mobile GPUs, and probably won't for the foreseeable future (Vulkan should actually have been two APIs: one for desktop GPUs, and one for mobile GPUs - and those new extensions are doing exactly that - splitting Vulkan into two more or less separate APIs, one that sucks (for mobile GPUs) and on…

> with mobile being actually much more important than desktop How so? I always thought the more common use case for GPU acceleration on the web for mobile were 2D games (Candy crush etc). Even on low end devices these are already plenty fast with something like Pixi, no?

We live in a bubble where we don't notice it, but desktop as a platform is... not dying exactly, but maybe returning to 90s levels of popularity. Common enough, but something tech-minded people use, and not necessarily for everybody. Mobile is rapidly becoming the ubiquitous computing paradigm we all thought desktop computers would be. In that world, WebGPU is much more important on mobile than on desktop.

Re: Chrome ships WebGPU

#242

Post by kllrnohj »

tormeh wrote: post #88

Anyone know the reason Google created Dawn instead of going with Wgpu? Attachment to C++, or NIH syndrome?

What does Mozilla use Spidermonkey instead of V8? Why did Apple create B3 JIT instead of just using Turbofan?

Competing implementations are a cornerstone of standards. Indeed in many domains it's a requirement for a spec to have multiple compliant implementations to be considered complete at all.

Re: Chrome ships WebGPU

#244

Post by rockdoe »

illiarian wrote: post #178
codedokode wrote: post #136

Earlier quoted context omitted.

Just put WebGL/WebGPU behind permission and the problem is solved. I don't understand why highly paid Google and Firefox developers cannot understand such a simple idea.

Just put WebGL/WebGPU behind permission and the problem is solved. Just put WebUSB behind permission and the problem is solved. Just put WebHID behind permission and the problem is solved. Just put WebMIDI behind permission and the problem is solved. Just put Filesystem Access behind permission and the problem is solved. Just put Sensors behind permission and the problem is solved. Just put Location behind permission…

I can't tell whether you're kidding or not, but this is exactly the path Firefox was advocating: https://blog.karimratib.me/2022/04/23/firefox-webmidi.html

The page implies it no longer requires permissions, but I just tested and you definitely get a permissions popup, just a different one.

WebHID, WebUSB and Filesystem Access are IIRC, "considered harmful" so they won't get implemented. And Sensor support was removed after sites started abusing battery APIs.

Re: Chrome ships WebGPU

#245

Post by victor96 »

This is super exciting for us as we develop interactive browser UIs. I hope future versions of WebGPU will be backwards compatible to all those with Chrome 113.

We need an iOS like pace of updating for browsers!

Re: Chrome ships WebGPU

#246

Post by paulryanrogers »

victor96 wrote: post #245

This is super exciting for us as we develop interactive browser UIs. I hope future versions of WebGPU will be backwards compatible to all those with Chrome 113. We need an iOS like pace of updating for browsers!

> We need an iOS like pace of updating for browsers!

How do you mean? Browsers often update every 6 weeks. IOS releases with new behavior are annual.

Re: Chrome ships WebGPU

#247

Post by kllrnohj »

yread wrote: post #113
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

From the project page:

> Performance is decent with around 30-40 FPS on a modern desktop system (ranges from 20 FPS in Edge, 40 FPS in Firefox, to 50 FPS in Chrome)

Achieving 2004 levels of performance & quality with nearly 20 years of hardware improvements is hardly impressive. It's really rather pathetic if anything, although I also got better performance in the opening area than the project page claims but I didn't play very long to find out if it drops later on.

But also note that it's not actually Doom 3 proper, but includes changes from other ports as well as a completely different renderer. There's sadly no side-by-side original vs. port screenshots to compare what the differences are.

Re: Chrome ships WebGPU

#248

Post by tgsovlerkhgsel »

merlish wrote: post #153
codedokode wrote: post #136

Earlier quoted context omitted.

Just put WebGL/WebGPU behind permission and the problem is solved. I don't understand why highly paid Google and Firefox developers cannot understand such a simple idea.

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…

I think browsers should distinguish more aggressively between "web application", "web site", and "user hostile web site".

Many APIs should be gated behind being a web application. This itself could be a permission dialog already, with a big warning that this enables tracking and "no reputable web site will ask for it unless it is clear why this permission is needed - in doubt, choose no".

Collect opt-in telemetry. Web sites that claim to be a web application but keep getting denied can then be reclassified as hostile web sites, at which point they not only lose the ability to annoy users with web app permission prompts, but also other privileges that web sites don't need.

Re: Chrome ships WebGPU

#249

Post by raphlinus »

This is a huge milestone. It's also part of a much larger journey. In my work on developing Vello, an advanced 2D renderer, I have come to believe WebGPU is a game changer. We're going to have reasonably modern infrastructure that runs everywhere: web, Windows, mac, Linux, ChromeOS, iOS, and Android. You're going to see textbooks(*), tutorials, benchmark suites, tons of sample code and projects to learn from.

WebGPU 1.0 is a lowest common denominator product. As 'FL33TW00D points out, matrix multiplication performance is much lower than you'd hope from native. However, it is possible to run machine learning workloads, and getting that performance back is merely an engineering challenge. A few extensions are needed, in particular cooperative matrix multiply (also known as tensor cores, WMMA, or simd_matrix). That in turn depends on subgroups, which have some complex portability concerns[1].

Bindless is another thing everybody wants. The wgpu team is working on a native extension[2], which will inform web standardization as well. I am confident this will happen.

The future looks bright. If you are learning GPU, I now highly recommend WebGPU, as it lets you learn modern techniques (including compute), and those skills will transfer to native APIs including Vulkan, Metal, and D3D12.

Disclosure: I work at Google and have been involved in WebGPU development, but on a different team and as one who has been quite critical of aspects of WebGPU.

(*): If you're writing a serious, high quality textbook on compute with WebGPU, then I will collaborate on a chapter on prefix sums / scan.

[1]: https://github.com/gpuweb/gpuweb/issues/3950

[2]: https://docs.rs/wgpu/latest/wgpu/struct.Features.html#associ...*

Re: Chrome ships WebGPU

#250

Post by dcow »

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.

“The web” should not first and foremost protect anonymity. It should do what humans need it to do ideally while keeping users private and secure. If there’s a concern, my browser should ask me if I’m willing to share potentially sensitive information with a product or service. I fucking hate this weird angsty idea that the web is only designed for anonymous blobs and trolls.
Post reply on HN