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

91–100 of 405 posts

Re: Chrome ships WebGPU

#91

Post by flohofwoe »

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

WebGPU brings some important improvements that are simply impossible to implement with the WebGL programming model (such as moving all the expensive dynamic state validation from the draw loop into the initialization phase).

It's not perfect mind you (e.g. baked BindGroups may be a bit too 'rigid'), but it's still a massive improvement over WebGL in terms of reduced CPU overhead.

Re: Chrome ships WebGPU

#92

Post by pjmlp »

flohofwoe wrote: post #86
pjmlp wrote: post #70

Earlier quoted context omitted.

There are lots of ways to write code cross-platform graphics outside the browser, it has been available for decades, it is called middleware. WebGPU outside of the browser not only suffers the pain of being yet another incompatible shading language, it is also offers the additional possibility of having code incompatible with browsers WebGPU support, due to the use of extensions not available on the browsers.

AFAIK the WebGPU implementations outside the browser can all load SPIRV directly, no need to translate to WGSL first.

Yes, and that is one of the reasons why I wrote it is also offers the additional possibility of having code incompatible with browsers WebGPU support.

Re: Chrome ships WebGPU

#93

Post by xchkr1337 »

illiarian wrote: post #37
hutzlibu wrote: post #28

Earlier quoted context omitted.

"ad-hoc shader language that kinda looks like, but is totally not rust." But is that language actually bad, or is it just not your favourite language? What don't you like about it?

No idea what the comment about Rust means, but we already have several shader languages. There was literally no reason to invent another incompatible one

Most current shader languages are very close to C in terms of syntax and behavior and these are some of the worst aspects of C as a language. I guess they could have went with SPIR-V but generally a compilation step shouldn't be required in web standards.

Re: Chrome ships WebGPU

#94

Post by jeroenhd »

grishka wrote: post #38

Can this be disabled when it is released?

Firefox has dom.webgpu.enabled for browser control. Chrome has flags for it right now, but those often disappear once a feature is introduced. You can probably disable hardware acceleration to get rid of webgpu though.

Re: Chrome ships WebGPU

#95

Post by flohofwoe »

pjmlp wrote: post #92
flohofwoe wrote: post #86

Earlier quoted context omitted.

AFAIK the WebGPU implementations outside the browser can all load SPIRV directly, no need to translate to WGSL first.

Yes, and that is one of the reasons why I wrote it is also offers the additional possibility of having code incompatible with browsers WebGPU support .

These differences are smaller than the differences between desktop GL and WebGL though. It's just another option in the low-level vs high-level 3D API zoo. As far as wrapper APIs go, the native WebGPU implementation libraries are a pretty good option, because being also used in browsers there's a ton of testing and driver bug workarounds going into them which other 3D API wrapper projects simply can't afford to do.

Re: Chrome ships WebGPU

#96

Post by tuyiown »

Alifatisk wrote: post #40

Soon, there will be no need to install softwares to the computer. A modern browser will cover it all. What scares me is browsers getting bloated with all kinds of features while webapps getting bigger and bigger in size for no reason. Note, I am all for this feature getting widely adopted.

The real problem is more that bad and malicious code get more and more easier to deploy, the browser getting more complex to mitigate this.

The good news is that the level of trust in the code to run app natively is very high, and in the age of highly connected computers, if not done in the browser, it would have been needed at OS level anyway.

So maybe browser looks like a sad future as an OS replacement, but at least, it collected issues and solutions to mitigate arbitrary code loaded from the networks.

Whatever happens after, this history will be kept. (it has already started on current OSes with sandboxed software and on demand permissions).

Re: Chrome ships WebGPU

#97

Post by mike_hearn »

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 blocking it until your competitors all have it too.

Luckily the GPU industry is driven by video games and nowadays AI, industries that don't write code using the web stack. So they'll be alright. Still, that same incentives problem exists in other areas of computing that sit underneath the browser (CPUs, hardware extensions, operating systems, filesystems, etc). Abstractions don't have to erase all the differences in what they abstract, but people who create them often do so anyway.

Re: Chrome ships WebGPU

#98

Post by geysersam »

pjc50 wrote: post #47
nextaccountic wrote: post #35

Earlier quoted context omitted.

> all the operations are specified to deterministically produce the same bit-exact results on all hardware, I want this so badly. A compiler flag perhaps, that enables running the same program with the exact output bit for bit on any platform, perhaps by doing the same thing as a reference platform (any will do), even if it has a performance penalty.

I'm surprised people accept non-bit-identical output. Intel did a lot of damage here with their wacky 80-bit floating point implementation, but really it should be the norm for all languages.

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...

Re: Chrome ships WebGPU

#99

Post by pjmlp »

flohofwoe wrote: post #95
pjmlp wrote: post #92

Earlier quoted context omitted.

Yes, and that is one of the reasons why I wrote it is also offers the additional possibility of having code incompatible with browsers WebGPU support .

These differences are smaller than the differences between desktop GL and WebGL though. It's just another option in the low-level vs high-level 3D API zoo. As far as wrapper APIs go, the native WebGPU implementation libraries are a pretty good option, because being also used in browsers there's a ton of testing and driver bug workarounds going into them which other 3D API wrapper projects simply can't afford to do.

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.

Post reply on HN