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

341–350 of 405 posts

Re: Chrome ships WebGPU

#341

Post by codedokode »

pulpfictional wrote: post #303
codedokode wrote: post #140

I remember when WebRTC was introduced, it was found that it became very popular and was used by almost every page. But closer inspection showed that its use was to get user's IP address for better fingerprinting. I predict that WebGL/WebGPU will be mainly used for the same purposes. Nobody needs new fancy features, what people really need is more reliable fingerprinting (this is proven by number of uses of WebRTC for…

I was reading that WebGPU leaves you open to fingerprinting by your hardware info, particularly your GPU. It seems that it is even possible to distinguish between GPUs of the same model through tolerances in frequency.

WebGL allows to read graphic card name.

Re: Chrome ships WebGPU

#343

Post by codedokode »

cyral wrote: post #270
codedokode wrote: post #227

Earlier quoted context omitted.

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.

You can display only permissions that a page requests, starting from most important ones.

For example, toolbar could look like:

Enable: [ location ] [ camera ] [ fingerprinting via canvas ] ...

Re: Chrome ships WebGPU

#344

Post by mike_hearn »

adam_arthur wrote: post #318
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…

You could say the same about working off a common html, browser, language spec. There are tradeoffs, but industry consensus hasn't really stifled innovation in a meaningful way. Why can't a common graphics API evolve through well researched and heavily scrutinized proposals? The amount of societal loss of efficiency in having competing specs that do the same thing in slightly different ways, but require immense effor…

There are tradeoffs, but industry consensus hasn't really stifled innovation in a meaningful way.

Stifled innovation in what context? I wouldn't describe the web stack as an industry consensus given the rejection of it (for apps) by mobile devs, mobile users, video game devs, VR devs and so on. If you mean within the web stack, then, well, there have been plenty of proposals that died in the crib because they couldn't get consensus for rather obscure reasons that are hard to understand from the outside. Certainly, there were innovations in the earlier days of the web when it was more open that have never been replicated, for example, Flash's timeline based animation designer died and nothing really replaced it.

Fundamentally we can't really know what cool things might have existed in a different world where our tech stack is more open to extensions and forking.

Why can't a common graphics API evolve through well researched and heavily scrutinized proposals?

Why can't everything be done that way? It's been tried and results are a tragedy of the commons. These ideas don't originate in the web world. The incentive to develop the tech isn't actually limits in web specs, that's a decade+ after the innovation happens. What we see is that the web stuff is derivative and downstream from the big players. WebGPU traces its history through Vulkan to Metal/D3D12 and from there to AMD's Mantle, where it all started (afaik). So this stuff really starts as you'd expect, with some risk taking by a GPU designer looking for competitive advantage, then the proprietary OS design teams pick it up and start to abstract the GPU vendors, and then Khronos/Linux/Android realizes that OpenGL is going to become obsolete so they'd better have an answer to it, and then finally the HTML5 people decide the same for WebGL and start work on making a sandboxed version of Vulkan (sorta).

N.B. what made Mantle possible is that Windows is a relatively open and stable environment for driver developers. Ditto for CUDA. They can expose new hardware caps via vendor-specific APIs and Microsoft don't care/encourage it. That means there's value in coming up with a radical new way to accelerate driver performance. In contrast, Apple write their own drivers / APIs, Linux doesn't want proprietary drivers, ChromeOS doesn't even have any notion of an installable vendor driver model at all.

Re: Chrome ships WebGPU

#345

Post by Baeocystin »

pdpi wrote: post #241
pier25 wrote: post #215

Earlier quoted context omitted.

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

I genuinely think personal computing has been severely hamstrung over the past decade+ due to the race to be all-encompassing. Not everything has to be for everyone. It's ok to focus on tools that only appeal to other people in tech. It really is.

Re: Chrome ships WebGPU

#347

Post by topaz0 »

mschuetz wrote: post #283
topaz0 wrote: post #264

Earlier quoted context omitted.

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.

Since I'm doing 3D graphics in Web Browsers, I consider not having 3D graphics APIs in Web Browsers a broken web experience. The browser is the easiest and safest way to distribute applications with virtually no entry barrier to users. I don't trust downloading just any binary and therefore I won't execute them unless they are from a trusted source. But with 3D in browsers, I can trust any web site not do damage my s…

There are applications where the point is 3d graphics. I don't object to letting them use my gpu if they ask nicely. There are other applications -- really the vast majority of them -- where 3d graphics is completely beside the point, and has nothing to do with the reason I'm on your website. That is my concern: that that second class, being the vast majority, will say, "hey, I have access to all this compute power, why don't I just throw some of it at this needless animation that I think looks cool, or at this neural network, or at this cryptominer". Past experience suggests that this is a reasonable concern.

Re: Chrome ships WebGPU

#348

Post by Lichtso »

topaz0 wrote: post #282
cyral wrote: post #272

Earlier quoted context omitted.

Ironically by hardware accelerating those resources, they will be less noticeable.

What do you think there will be more of: a) existing functionality moves to more efficient implementation on gpu, or b) "hey, we can use gpus now, let's shove some more compute-intensive features into this app that add nothing but make it seem more innovative".

> Jevons paradox occurs when technological progress or government policy increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the falling cost of use increases its demand, increasing, rather than reducing, resource use.

https://en.wikipedia.org/wiki/Jevons_paradox

Re: Chrome ships WebGPU

#349

Post by epolanski »

ericflo wrote: post #154
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.

Look to the cookie fatigue fiasco for how that might turn out. This simple idea is not always the right one.

Why fiasco?

Re: Chrome ships WebGPU

#350

Post by phendrenad2 »

Maybe I'm dumb but what does WebGPU get you in reality that WebGL doesn't currently get you? I don't think we're going to see browser games any time soon (because it's trivial to just install a game and run it, and also the browser audio API sucks). And most visualizations on the web would be perfectly fine with plain old WebGL.
Post reply on HN