Chrome 94 Beta Released With WebCodecs API Promoted, WebGPU Origin Trial

[Artim]

It's not that they are intentionally wasting battery energy. It's that wasting battery energy doesn't affect clickthroughs or conversion rates, so they don't care.

That makes no sense at all. They have to intentionally use WebGPU, otherwise nothing will change at all. So where would they waste battery when they don't waste it intentionally?

[yump]

That makes no sense at all. They have to intentionally use WebGPU, otherwise nothing will change at all. So where would they waste battery when they don't waste it intentionally?

They intentionally use WebGPU because it lets them add some whizbang effect to their design. The energy waste is incidental. Fully informed users would rather have longer battery life than whizbang effects, but

1. Users aren't fully-informed.
2. Web dev paychecks aren't affected by battery life of user devices.

[Artim]

They intentionally use WebGPU because it lets them add some whizbang effect to their design. The energy waste is incidental. Fully informed users would rather have longer battery life than whizbang effects, but

1. Users aren't fully-informed.
2. Web dev paychecks aren't affected by battery life of user devices.

This is one boatload of bs you made up there... Sure, they will make use of the API of they are smart and develop their sites in a way that that is just used optionally when it's available. But they won't jitsu magically start using WebGPU instead of some boring CSS. They'll use it, if it has actually benefits, like by replacing WebGL written stuff since the WebGPU version will most likely be more efficient, but that's it. They won't just start using WebGPU for no reason because it's way more work than just use the good old CSS+JS stuff they use right now. So if anything, they'll waste less battery when opting to use WebGPU

[piotrj3]

You say that like it matters whether compute shaders are available matters when it comes to implementing crypto on the GPU. You already can do pretty much everything you can do with compute shaders with just plain old fragment shaders, if you're up to rewiring your algorithm a little. It's not like there's a way to rate limit fragment shader execution in WebGL, either. Plus, it's not like the compute shaders in WebGPU or Vulkan or such have anywhere near the same level of control and flexibility as something like CUDA or OpenCL, anyway.


There's nothing in WebGPU that has it giving out any more hardware information than what WebGL already does, seeing as most if not all the parameters that could describe the hardware in more detail are hidden away and managed by the browser just as in WebGL. There's also no reason to believe that browsers would go out of their way to expose more detailed information for no gain at all.

In vulkan i would say you have quite high level of control of compute shaders, and there are examples of Vulkan compute being faster comparing to OpenCL in matters of overhead.

My problem is mostly is that if webGL/webGPU shouldn't be exposed (and all information shouldn't be) at all to web unless user explicitly allows it by browser window. When I can see some legitimate usage (eg. home planer in home arragment website) the default behaviour should be no.

[piotrj3]

Sure, progress is always evil. As is the use of more advanced and efficient APIs...

Progress isn't always evil, but 99.9% of internet users are using browser to just see pictures of cats or videos in decode mode. What means for definitive majority it is uncessery bloat that shouldn't exist, and somewhere this bloat is loaded in your memory everytime you start a browser.

It should be off by default, unless user explicitly allows it and only load its components as they are needed. Also not to mention all security vulnerabilities potentially introduced by low-level GPU API exposed to web. People learned how to steal images from diffrent section of screen using webGL, giving untrusted code even more precize access is opening can of worms.

I really wish there was version of FF or Chrome "lite" that simply is stripped away of all functionality like webGL, webGPU, web encoders, filesystem API, Bluetooth API, god what knows API. They do not provide any functionality to me and most users, while they are a burden, and they have security implications ( I seen a lot of sandbox escapes using them).

[Artim]

Progress isn't always evil, but 99.9% of internet users are using browser to just see pictures of cats or videos in decode mode. What means for definitive majority it is uncessery bloat that shouldn't exist, and somewhere this bloat is loaded in your memory everytime you start a browser.

It should be off by default, unless user explicitly allows it and only load its components as they are needed. Also not to mention all security vulnerabilities potentially introduced by low-level GPU API exposed to web. People learned how to steal images from diffrent section of screen using webGL, giving untrusted code even more precize access is opening can of worms.

I really wish there was version of FF or Chrome "lite" that simply is stripped away of all functionality like webGL, webGPU, web encoders, filesystem API, Bluetooth API, god what knows API. They do not provide any functionality to me and most users, while they are a burden, and they have security implications ( I seen a lot of sandbox escapes using them).

That's the definition of progress for you. That doesn't mean adding only what most people use (or you think most people use) and nothing else. Sure, for efficiency reasons all components not currently in use shouldn't use any resources. And of course, sandboxing and other security measurements need to be in place and constantly improved. That's why the flag still states the API is experimental and you probably still get a fixed by banner warning you as long as it's active. And it also clearly states that GPU sandboxing currently isn't implemented. But those are all no reasons to forbid progress just because there is a slight chance it can be used in malicious ways. Or are you running around with the same hysteria every time the Linux Kernel adds better support for sensor readout, graphical rendering etc?

Fact is, browsers nowadays are more than just a piece of software to view statical websites. They are pushing the envelope on what's possible and blur the line between web apps and native apps. And in doing so, they should use the most efficient tools possible. Everything else is not progress.

[ssokolow]

That's the definition of progress for you. That doesn't mean adding only what most people use (or you think most people use) and nothing else. Sure, for efficiency reasons all components not currently in use shouldn't use any resources. And of course, sandboxing and other security measurements need to be in place and constantly improved. That's why the flag still states the API is experimental and you probably still get a fixed by banner warning you as long as it's active. And it also clearly states that GPU sandboxing currently isn't implemented. But those are all no reasons to forbid progress just because there is a slight chance it can be used in malicious ways. Or are you running around with the same hysteria every time the Linux Kernel adds better support for sensor readout, graphical rendering etc?

Fact is, browsers nowadays are more than just a piece of software to view statical websites. They are pushing the envelope on what's possible and blur the line between web apps and native apps. And in doing so, they should use the most efficient tools possible. Everything else is not progress.

I generally agree with piotrj3 about what I want in my own browser (thus, stuff like uMatrix), but I agree that browsers should advance... at least until Apple gets forced to allow side-loading on iDevices.