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

141–150 of 405 posts

Re: Chrome ships WebGPU

#141

Post by dist-epoch »

Ciantic wrote: post #120

This is a comment from Aras Pranckevičius [1]: > WebGL was getting really old by now. I do wonder whether WebGPU is a bit late too though (e.g. right now Vulkan decides that PSOs maybe are not a great idea lol) > As in, WebGPU is very much a "modern graphics API design" as it was 8 years ago by now. Better late than never, but... What's "modern" now seems to be moving towards like: bindless everything (like 3rd itera…

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.

Re: Chrome ships WebGPU

#144

Post by fulafel »

hexo wrote: post #137
fulafel wrote: post #128

Earlier quoted context omitted.

In this case the runtime would not be able to guarantee that the timing has no externally observable side effects (at least if you do something with t). It would then run in the fixed execution speed mode.

Runtime doesnt have full controll but could introduce a lot of noise in timing and performance. Could it help?

It's hard to reason about how much noise is guaranteed to be enough, because it depends on how much measurement the adversary has a chance to do, there could be collusion beween several sites, etc. To allow timing API usage I'd be more inclined toward the virtual time thing I mentioned upthread.

Re: Chrome ships WebGPU

#145

Post by 7to2 »

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…

> But closer inspection showed that its use was to get user's IP address for better fingerprinting.

Maybe that's why it fell to the wayside: scripts are no longer allowed to get the local IP address (taking with it the most useful aspect of WebRTC, true serverless p2p without internet[1]).

[1] I'm not saying that I disagree with the decision, but still sad that we can't have nice things :(

Re: Chrome ships WebGPU

#146

Post by jefftk »

illiarian wrote: post #41
sebzim4500 wrote: post #33

Earlier quoted context omitted.

Google are the people paying for Chrome, they do not benefit in any way from this kind of fingerprinting. To the contrary, it decreases the value of their browser monopoly.

> Google are the people paying for Chrome, they do not benefit in any way from this kind of fingerprinting. The largest ad company in the world 80% of whose money comes from online advertising does not benefit from tracking...

Google doesn't benefit because Google has committed not to fingerprint for ad targeting, but their competitors do.

Re: Chrome ships WebGPU

#148

Post by codedokode »

7to2 wrote: post #145
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…

> But closer inspection showed that its use was to get user's IP address for better fingerprinting. Maybe that's why it fell to the wayside: scripts are no longer allowed to get the local IP address (taking with it the most useful aspect of WebRTC, true serverless p2p without internet[1]). [1] I'm not saying that I disagree with the decision, but still sad that we can't have nice things :(

Yes instead of IP address the API now provides Apple DNS hostname. But a proper solution would be to put this unnecessary API behind a permission.

Re: Chrome ships WebGPU

#149

Post by isodev »

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…

And if the Chrome team is excited about a feature, then probably it’s good for ads or upselling other Google products.

Re: Chrome ships WebGPU

#150

Post by mike_hearn »

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?

Here are some reasons:

AAA is by definition games that aim at the top end of what can be done in performance and graphical quality. Browsers prioritize other things. Put another way you can't be both AAA and in the browser, because if you tried, other people would come along and simply do better than you outside and you wouldn't be AAA anymore.

Specifically, browsers insist on very strong levels of sandboxing at the cost of high overhead, and they don't want you to run native code either, so you lose both performance and compatibility with most existing game libraries/engines. They also insist on everything being standardized and run through the design-by-committee meat grinder. Whilst Microsoft are polishing up the latest version of Direct3D browser makers are still trying to standardize the version from five years ago.

Browsers are optimized for lots of tiny files, but game toolchains tend to produce a small number of big files. For example browsers aren't good at resuming interrupted downloads or pinning data into the disk cache.

PC gamers have unified around Steam, which offers various advantages that raw web doesn't. Steam is intended for native apps.

Many games need to be portable to consoles because that's where the revenue is (bigger audience, less piracy). Consoles don't run web apps.

Browsers not only don't make it easy to implement anti-cheat but actively make it as difficult as possible.

Debugging tools for native code in the browser aren't as good as outside.

And so on and so on. That's not a full list, it's just off the top of my head. Other types of apps the web ignores: CLI apps, servers, anything to do with new hardware, OS extensions ... the list goes on. Really, we must ask why we'd ever think it'd make sense to ship AAA games as web pages. If you want the benefits the web brings for without the problems then you'd want a new platform that tries to learn from all of this and be a bit more generalized. I wrote up a design doc a month ago that tries to do that, see what you think:

https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI...

Post reply on HN