9 ms·

WebGPU is now available on Android

240 points by astlouis44 3y ago

jsheard 3y ago
> To help you anticipate memory limitations when allocating large amounts during the development of your app, requestAdapterInfo() now exposes memoryHeaps information such as the size and type of memory heaps available on the adapter. Oh nice, I was just complaining about that here the other day. The docs mention that browsers will probably guard that information behind a permission prompt to prevent it from being used for fingerprinting, but it's better than nothing.
mschuetz 3y ago
I'm really looking forward to 2034, when WebGPU features will catch up to 2024.
- vetinari 3y ago
  By that time, it might even get supported by Chrome for Linux.
  - bhouston 3y ago
    Why is linux supporting taking a while? I figured the underlying graphics subsystem on Android is Vulcan right? Wouldn't that also be the main graphics subsystem on Linux these days?
    - zamadatix 3y ago
      Testing/Validation and bugfixing. Just having Vulkan isn't enough to enable it by default, everything actually has to work right. Even for Android this is only for specific types of devices. You should be able to force enable it on Linux right now though. It's just not GA quality guaranteed.
      - p_l 3y ago
        I tried and tried and tried, Chrome 120 will always stick an undocumented Origin Trial for disabling WebGPU.
  - deleted 3y ago
    [deleted]
  - anthk 3y ago
    about:flags in Chromium search for "accel" Disable the blacklist for your GPU.
    - p_l 3y ago
      Doesn't stop disablement done through --origin-trial-disable-feature=WebGPU and I have yet to figure how to drop that without recompiling Chrome.
      - vetinari 3y ago
        Afaik it is possible only in unstable and beta, not in stable. That's why GP mentioned Chromium, not Chrome. Which fully supports pjmlp's point in the sibling comment.
    - pjmlp 3y ago
      Which is exactly why WebGL never really took off for games like Flash did, versus native games, or now streaming. Having drivers installed is not enough as the browser lords decided the computer isn't worthy of playing games.
      - anthk 3y ago
        Flash was a buggy crap which made lots of older computers spawn cycles like crazy and had zero accesibility for the blind. It deserverd to die.
        pjmlp 3y ago
        Usually the only ones complaining are Linux users. The rest enjoyed the games, to the point that Flash is being brought back thanks WebAssembly, with Unity and Flutter as spiritual sucessors.
  - reactordev 3y ago
    You know we’ll have all moved onto Romulan by then, leaving Vulkan and Metal behind - including WebGPU. In seriousness though, WebGPU in Chrome with “non-free” Linux GPU drivers should work, no? Edit: I see it’s still behind a flag
  - pjmlp 3y ago
    On ChromeOS.
    - vetinari 3y ago
      On devices by selected vendors, and only on selected models.
- 2OEH8eoCRo0 3y ago
  In 2034 it'll be as dead as Flash because of security issues.
  - mschuetz 3y ago
    Not really, that is not the problem of WebGPU. The worst you can do is crash the tab. With an unstable graphics driver, there might even be the option to crash the system but that's hardly a security issue, only an annoyance.
    - fourside 3y ago
      Very curious what you see as the problems with WebGPU currently. I’ve been tinkering with it slowly as it has a bit of a learning curve.
    - kevingadd 3y ago
      Historically any time an attack surface as big as WebGPU has been exposed, "the worst you can do is crash the tab" has not ever been true. Also note that for an unstable graphics driver, the way you usually crash the system is by touching memory you shouldn't (through the rendering API), which is definitely something that could be exploited by an attacker. It could also corrupt pages that later get flushed to disk and destroy data instead of just annoy you. Though I am skeptical as to whether it would happen, security researchers have previously come up with some truly incredible browser exploit chains in the past, so I'm not writing it off.
      - mschuetz 3y ago
        WebGL has been around for more than a decade and didn't turn out to be a security issue, other than occasionally crashing tabs. Neither will WebGPU be.
        csande17 3y ago
        By exposing vulnerable graphics drivers to arbitrary web code, WebGL has allowed websites to take screenshots of your desktop (https://www.mozilla.org/en-US/security/advisories/mfsa2013-86/ https://www.mozilla.org/en-US/security/advisories/mfsa2013-8...) and break out of virtual machines (https://blog.talosintelligence.com/nvidia-graphics-driver-vulnerability-roundup/ https://blog.talosintelligence.com/nvidia-graphics-driver-vu...), to use two examples I found via a web search.
- bmitc 3y ago
  What features?
  - jms55 3y ago
    Personally, the ones I'm most looking forward to: * Subgroup operations * Push constants (available in wgpu, but not WebGPU the spec/web impl) * u64 + atomic image ops * Mesh shaders * Raytracing * Binding arrays / descriptor indexing + device buffer addresses
    - raphlinus 3y ago
      Similar. I've done experiments with subgroups suggesting approximately a 2.5x speedup for sorting (using the WLMS technique of Onesweep). Binding arrays will be very helpful for rendering images in the compute shader. A caveat is that descriptor indexing is not supported on mid-old phones like Pixel 4, but it is on Pixel 6. I somewhat doubt device buffer address will be supported, as I think the security aspect is complicated (it resembles a raw pointer), but it's possible they'll figure out how to do it.
- pjmlp 3y ago
  Looking back to 10 years long WebGL adoption, and WebGPU being based on 2015 features, that is pretty much spot on.
bhouston 3y ago
Nice! We just need Linux and iOS. And then we'll have somewhere around 80% support for WebGPU across all devices. I'm getting my numbers https://web3dsurvey.com/webgpu https://web3dsurvey.com/webgpu Android: 0.34% Chromium OS: 78.15% iOS: 0.09% Linux: 0.75% Mac OS: 54.43% Windows: 77.96%
- wongarsu 3y ago
  According to [1] Android 12+ covers nearly 60% of all Android devices. That's more than I would have expected. 1: https://gs.statcounter.com/os-version-market-share/android/mobile-tablet/worldwide https://gs.statcounter.com/os-version-market-share/android/m... (Android 14 is still counted as "other")
- npunt 3y ago
  if safari tech preview is anything to go by, it may come to iOS sooner or later https://webkit.org/blog/14879/webgpu-now-available-for-testing-in-safari-technology-preview/ https://webkit.org/blog/14879/webgpu-now-available-for-testi...
- nox101 3y ago
  I'm pretty sure the numbers on web3dsurvey are skewed. AFAICT only sizes about webgl and webgpu development are surveyed. To get real numbers you need their survey script to run on popular non-techie sites right?
  - bhouston 3y ago
    It does favor users who have likely have better than average graphics devices, but it still is likely relatively right - especially as the numbers get high. It is based on ~250,000 data samples in the last week.
    - nox101 3y ago
      Can you explain how you would know the data is right if you don't have actual data from a site popular with non-techies? Like I go to a tech meetup it will generally be 95% male and mostly white and asian. If I surveyed anything there it would have very little relation to the real population. You list these sites threekit.com webgpufundamentals.org james.darpinian.com realism-effects-obeqz.vercel.app gobattle.io. ict.moe.gov.om modelviewer.dev realism-effects-git-v2-obeqz.vercel.app dev.phaser.io redblobgames.com threejs.org axiomatic-inc.com weatherlayers.com alpha.gobattle.io. gobattle.io spookyball.com mrdoob.com streets.gl realism-effects.vercel.app phaser.io alpha.gobattle.io molstar.org demo.weatherlayers.com old.phaser.io webglfundamentals.org toji.dev jeeliz.com clicktorelease.com Pretty much all of them are not sites any non-graphics person would visit. So how can it possibly be even close the correct? It doesn't matter that there 250k samples per week if those are nearly all programmers interested in 3D rather than the average non-techie
westurner 3y ago
How do you run the task manager with Android Chrome? Does Android Chrome have the per-tab hover card RAM use feature as desktop chrome? From https://news.ycombinator.com/item?id=37840416 https://news.ycombinator.com/item?id=37840416 : >> From "Manifest V3, webRequest, and ad blockers" (2022) https://news.ycombinator.com/item?id=32953286 https://news.ycombinator.com/item?id=32953286 : >> What are some ideas for UI Visual Affordances to solve for bad UX due to slow browser tabs and extensions? >> - [ ] UBY: Browsers: Strobe the tab or extension button when it's beyond (configurable) resource usage thresholds >> - [ ] UBY: Browsers: Vary the {color, size, fill} of the tabs according to their relative resource utilization >> - [ ] ENH,SEC: Browsers: specify per-tab/per-domain resource quotas: CPU
Xeamek 3y ago
>devices running Android 12 and greater powered by Qualcomm and ARM GPUs. So... won't work on any exynos, since they have the AMD RDNA3 arch? Do I get that right?
- jsheard 3y ago
  It should work on slightly older or lower end Exynos chips, which have ARM Mali GPUs. Their switch to AMD RDNA was a fairly recent thing, and so far it has only been integrated into their flagship-tier parts.
- Tojiro 3y ago
  Hi! I'm the Chrome dev that's been working on WebGPU's Android support. As jsheard said the older exynos devices will work because they're Mali-based. The newer RDNA3-based devices aren't enabled by default simply because our team hasn't been able to sufficiently test on them yet. Same goes for Tegra or PowerVR GPUs. It's entirely a question of spending the time to ensure they're performing as expected (and probably implementing a few workarounds) and not a comment on the quality of the GPUs themselves. That said, we know that these GPUs are in an increasing number of flagship devices, which makes them a higher priority for official support in future releases.
  - pjmlp 3y ago
    First of all thank for the effort. Secondly, this was a big issue plaguing WebGL adoption, as contrary to native APIs, devices get blacklisted and telling common users to access browser flags is not an option for most products. Hence why game studios are so keen on streaming instead.
astlouis44 3y ago
My team has been developing out Unreal Engine 5 support for WebGPU, for anyone interested.
- notnullorvoid 3y ago
  Do you work at Epic or is this an external effort?
- ferbivore 3y ago
  What kinds of challenges have you run into?
fidotron 3y ago
What will be curious about WebGPU getting wider Android deployment is if it results in reducing the effect of variation in the drivers, which very much remain a headache. For example, WebGL type API implementations have had a somewhat flexible idea about data sizes and layout which due to the nature of WebGPU are much less acceptable there. One of the big wins of Vulkan has been that it has levelled the playing field somewhat and poor drivers have less of an impact. I think a lot of people will be disappointed by what proportion of devices currently in the wild actually successfully make this jump because it is under appreciated the extent to which shortcuts have been taken. I look forward to the day I never have to think about the Mali GLSL compiler ever again.
- pjmlp 3y ago
  It will be same as ever. The big difference is that on native APIs we can work around them. On browser APIs, the device gets blacklisted end of story for those folks.
rezonant 3y ago
> Timestamp queries allow WebGPU applications to measure precisely (down to the nanosecond) how much time their GPU commands take to execute compute and render passes > ... > Due to timing attack concerns, timestamp queries are quantized with a resolution of 100 microseconds, which provides a good compromise between precision and security. I don't have a particular need of nanosecond granularity timestamps for WebGPU- there are other parts of the web stack where I could really use better time measurement- but I understand the security concern and it's far better to be safe than sorry. But they quote two wildly different granularities in the same article, within a paragraph of each other...
- jsheard 3y ago
  The former is a spec detail (the result is returned in ns) and the latter is an implementation detail (browsers currently quantize the result to 100us). That is a useful distinction since you can use WebGPU outside of the browser by embedding Dawn or wgpu into your own application, and there you should get the maximum resolution the spec allows for. Environments like Electron might also opt-out of that timing attack mitigation since they're intended to run trusted code. I agree the article could have made that clearer though.
  - rezonant 3y ago
    Yes indeed they mention how to opt out of quantization directly in Chrome if you'd like (at your own risk) using the Devtools.
  - no_time 3y ago
    New exciting web fingerprinting vector dropped. As if we didn’t have a enough already.
- eyegor 3y ago
  Meanwhile sleep() in js land is more of a suggestion when it comes to accuracy. Browser standards are strange. Of course I mean setTimeout/interval because js doesn't even expose a sleep function.
eschaton 3y ago
What’s the actual utility of this for anyone that isn’t trying to replace native code with web pages? Is this ever going to be worth the no doubt massive investment it required?
- andybak 3y ago
  I'm not sure I understand you. Can you expand your comment somewhat?
- hutzlibu 3y ago
  "trying to replace native code with web pages? " No one wants that. But many like to write their apps only for one plattform - and then still have them run allmost everywhere. The web is the best we have to achieve this. And this will greatly improve the possibilities. Edit: My app will soon finally use no more html elements. It is not a "webpage".
  - mschuetz 3y ago
    > No one wants that. I very much do want that since the WebGPU API is far easier and nicer to use than Vulkan or OpenGL. Also, it makes apps much more accessible to distribute them over web, and it is much more secure to use web apps than native apps. Unfortunately WebGPU is way too limited compared to desktop APIs.
  - ladyanita22 3y ago
    Can you have an electron app without HTML elements? A pure WebGPU + Webassembly program?
    - jay_kyburz 3y ago
      YEah, but why wouldn't you want HTML CSS to render your ui. I'm going to revisit electron / nw.js for games again this year. Last time I tried 4-5 years ago I could not get smooth animation with request animation frame.
      - 3y ago
FL33TW00D 3y ago
Well done WebGPU team! Looking forward to the announcement one day that this has landed: https://github.com/gpuweb/gpuweb/issues/4195 https://github.com/gpuweb/gpuweb/issues/4195
- modeless 3y ago
  Cool, there's consensus between APIs on how to expose "tensor cores" now? Very exciting! Although I think that relaxing memory limitations and providing more visibility and control there is even more important for running ML on the web right now. And harder to make progress on because there isn't a single team that clearly owns "all memory management".

240 points by astlouis44 3y ago

> To help you anticipate memory limitations when allocating large amounts during the development of your app, requestAdapterInfo() now exposes memoryHeaps information such as the size and type of memory heaps available on the adapter. Oh nice, I was just complaining about that here the other day. The docs mention that browsers will probably guard that information behind a permission prompt to prevent it from being used for fingerprinting, but it's better than nothing.

mschuetz 3y ago

I'm really looking forward to 2034, when WebGPU features will catch up to 2024.

vetinari 3y ago
By that time, it might even get supported by Chrome for Linux.
- bhouston 3y ago
  Why is linux supporting taking a while? I figured the underlying graphics subsystem on Android is Vulcan right? Wouldn't that also be the main graphics subsystem on Linux these days?
  - zamadatix 3y ago
    Testing/Validation and bugfixing. Just having Vulkan isn't enough to enable it by default, everything actually has to work right. Even for Android this is only for specific types of devices. You should be able to force enable it on Linux right now though. It's just not GA quality guaranteed.
    - p_l 3y ago
      I tried and tried and tried, Chrome 120 will always stick an undocumented Origin Trial for disabling WebGPU.
- deleted 3y ago
  [deleted]
- anthk 3y ago
  about:flags in Chromium search for "accel" Disable the blacklist for your GPU.
  - p_l 3y ago
    Doesn't stop disablement done through --origin-trial-disable-feature=WebGPU and I have yet to figure how to drop that without recompiling Chrome.
    - vetinari 3y ago
      Afaik it is possible only in unstable and beta, not in stable. That's why GP mentioned Chromium, not Chrome. Which fully supports pjmlp's point in the sibling comment.
  - pjmlp 3y ago
    Which is exactly why WebGL never really took off for games like Flash did, versus native games, or now streaming. Having drivers installed is not enough as the browser lords decided the computer isn't worthy of playing games.
    - anthk 3y ago
      Flash was a buggy crap which made lots of older computers spawn cycles like crazy and had zero accesibility for the blind. It deserverd to die.
      - pjmlp 3y ago
        Usually the only ones complaining are Linux users. The rest enjoyed the games, to the point that Flash is being brought back thanks WebAssembly, with Unity and Flutter as spiritual sucessors.
- reactordev 3y ago
  You know we’ll have all moved onto Romulan by then, leaving Vulkan and Metal behind - including WebGPU. In seriousness though, WebGPU in Chrome with “non-free” Linux GPU drivers should work, no? Edit: I see it’s still behind a flag
- pjmlp 3y ago
  On ChromeOS.
  - vetinari 3y ago
    On devices by selected vendors, and only on selected models.
2OEH8eoCRo0 3y ago
In 2034 it'll be as dead as Flash because of security issues.
- mschuetz 3y ago
  Not really, that is not the problem of WebGPU. The worst you can do is crash the tab. With an unstable graphics driver, there might even be the option to crash the system but that's hardly a security issue, only an annoyance.
  - fourside 3y ago
    Very curious what you see as the problems with WebGPU currently. I’ve been tinkering with it slowly as it has a bit of a learning curve.
  - kevingadd 3y ago
    Historically any time an attack surface as big as WebGPU has been exposed, "the worst you can do is crash the tab" has not ever been true. Also note that for an unstable graphics driver, the way you usually crash the system is by touching memory you shouldn't (through the rendering API), which is definitely something that could be exploited by an attacker. It could also corrupt pages that later get flushed to disk and destroy data instead of just annoy you. Though I am skeptical as to whether it would happen, security researchers have previously come up with some truly incredible browser exploit chains in the past, so I'm not writing it off.
    - mschuetz 3y ago
      WebGL has been around for more than a decade and didn't turn out to be a security issue, other than occasionally crashing tabs. Neither will WebGPU be.
      - csande17 3y ago
        By exposing vulnerable graphics drivers to arbitrary web code, WebGL has allowed websites to take screenshots of your desktop (https://www.mozilla.org/en-US/security/advisories/mfsa2013-86/ https://www.mozilla.org/en-US/security/advisories/mfsa2013-8...) and break out of virtual machines (https://blog.talosintelligence.com/nvidia-graphics-driver-vulnerability-roundup/ https://blog.talosintelligence.com/nvidia-graphics-driver-vu...), to use two examples I found via a web search.
bmitc 3y ago
What features?
- jms55 3y ago
  Personally, the ones I'm most looking forward to: * Subgroup operations * Push constants (available in wgpu, but not WebGPU the spec/web impl) * u64 + atomic image ops * Mesh shaders * Raytracing * Binding arrays / descriptor indexing + device buffer addresses
  - raphlinus 3y ago
    Similar. I've done experiments with subgroups suggesting approximately a 2.5x speedup for sorting (using the WLMS technique of Onesweep). Binding arrays will be very helpful for rendering images in the compute shader. A caveat is that descriptor indexing is not supported on mid-old phones like Pixel 4, but it is on Pixel 6. I somewhat doubt device buffer address will be supported, as I think the security aspect is complicated (it resembles a raw pointer), but it's possible they'll figure out how to do it.
pjmlp 3y ago
Looking back to 10 years long WebGL adoption, and WebGPU being based on 2015 features, that is pretty much spot on.

bhouston 3y ago

Nice! We just need Linux and iOS. And then we'll have somewhere around 80% support for WebGPU across all devices. I'm getting my numbers https://web3dsurvey.com/webgpu https://web3dsurvey.com/webgpu Android: 0.34% Chromium OS: 78.15% iOS: 0.09% Linux: 0.75% Mac OS: 54.43% Windows: 77.96%

wongarsu 3y ago
According to [1] Android 12+ covers nearly 60% of all Android devices. That's more than I would have expected. 1: https://gs.statcounter.com/os-version-market-share/android/mobile-tablet/worldwide https://gs.statcounter.com/os-version-market-share/android/m... (Android 14 is still counted as "other")
npunt 3y ago
if safari tech preview is anything to go by, it may come to iOS sooner or later https://webkit.org/blog/14879/webgpu-now-available-for-testing-in-safari-technology-preview/ https://webkit.org/blog/14879/webgpu-now-available-for-testi...
nox101 3y ago
I'm pretty sure the numbers on web3dsurvey are skewed. AFAICT only sizes about webgl and webgpu development are surveyed. To get real numbers you need their survey script to run on popular non-techie sites right?
- bhouston 3y ago
  It does favor users who have likely have better than average graphics devices, but it still is likely relatively right - especially as the numbers get high. It is based on ~250,000 data samples in the last week.
  - nox101 3y ago
    Can you explain how you would know the data is right if you don't have actual data from a site popular with non-techies? Like I go to a tech meetup it will generally be 95% male and mostly white and asian. If I surveyed anything there it would have very little relation to the real population. You list these sites threekit.com webgpufundamentals.org james.darpinian.com realism-effects-obeqz.vercel.app gobattle.io. ict.moe.gov.om modelviewer.dev realism-effects-git-v2-obeqz.vercel.app dev.phaser.io redblobgames.com threejs.org axiomatic-inc.com weatherlayers.com alpha.gobattle.io. gobattle.io spookyball.com mrdoob.com streets.gl realism-effects.vercel.app phaser.io alpha.gobattle.io molstar.org demo.weatherlayers.com old.phaser.io webglfundamentals.org toji.dev jeeliz.com clicktorelease.com Pretty much all of them are not sites any non-graphics person would visit. So how can it possibly be even close the correct? It doesn't matter that there 250k samples per week if those are nearly all programmers interested in 3D rather than the average non-techie

westurner 3y ago

How do you run the task manager with Android Chrome? Does Android Chrome have the per-tab hover card RAM use feature as desktop chrome? From https://news.ycombinator.com/item?id=37840416 https://news.ycombinator.com/item?id=37840416 : >> From "Manifest V3, webRequest, and ad blockers" (2022) https://news.ycombinator.com/item?id=32953286 https://news.ycombinator.com/item?id=32953286 : >> What are some ideas for UI Visual Affordances to solve for bad UX due to slow browser tabs and extensions? >> - [ ] UBY: Browsers: Strobe the tab or extension button when it's beyond (configurable) resource usage thresholds >> - [ ] UBY: Browsers: Vary the {color, size, fill} of the tabs according to their relative resource utilization >> - [ ] ENH,SEC: Browsers: specify per-tab/per-domain resource quotas: CPU

Xeamek 3y ago

>devices running Android 12 and greater powered by Qualcomm and ARM GPUs. So... won't work on any exynos, since they have the AMD RDNA3 arch? Do I get that right?

jsheard 3y ago
It should work on slightly older or lower end Exynos chips, which have ARM Mali GPUs. Their switch to AMD RDNA was a fairly recent thing, and so far it has only been integrated into their flagship-tier parts.
Tojiro 3y ago
Hi! I'm the Chrome dev that's been working on WebGPU's Android support. As jsheard said the older exynos devices will work because they're Mali-based. The newer RDNA3-based devices aren't enabled by default simply because our team hasn't been able to sufficiently test on them yet. Same goes for Tegra or PowerVR GPUs. It's entirely a question of spending the time to ensure they're performing as expected (and probably implementing a few workarounds) and not a comment on the quality of the GPUs themselves. That said, we know that these GPUs are in an increasing number of flagship devices, which makes them a higher priority for official support in future releases.
- pjmlp 3y ago
  First of all thank for the effort. Secondly, this was a big issue plaguing WebGL adoption, as contrary to native APIs, devices get blacklisted and telling common users to access browser flags is not an option for most products. Hence why game studios are so keen on streaming instead.

astlouis44 3y ago

My team has been developing out Unreal Engine 5 support for WebGPU, for anyone interested.

notnullorvoid 3y ago
Do you work at Epic or is this an external effort?
ferbivore 3y ago
What kinds of challenges have you run into?

fidotron 3y ago

What will be curious about WebGPU getting wider Android deployment is if it results in reducing the effect of variation in the drivers, which very much remain a headache. For example, WebGL type API implementations have had a somewhat flexible idea about data sizes and layout which due to the nature of WebGPU are much less acceptable there. One of the big wins of Vulkan has been that it has levelled the playing field somewhat and poor drivers have less of an impact. I think a lot of people will be disappointed by what proportion of devices currently in the wild actually successfully make this jump because it is under appreciated the extent to which shortcuts have been taken. I look forward to the day I never have to think about the Mali GLSL compiler ever again.

pjmlp 3y ago
It will be same as ever. The big difference is that on native APIs we can work around them. On browser APIs, the device gets blacklisted end of story for those folks.

rezonant 3y ago

> Timestamp queries allow WebGPU applications to measure precisely (down to the nanosecond) how much time their GPU commands take to execute compute and render passes > ... > Due to timing attack concerns, timestamp queries are quantized with a resolution of 100 microseconds, which provides a good compromise between precision and security. I don't have a particular need of nanosecond granularity timestamps for WebGPU- there are other parts of the web stack where I could really use better time measurement- but I understand the security concern and it's far better to be safe than sorry. But they quote two wildly different granularities in the same article, within a paragraph of each other...

jsheard 3y ago
The former is a spec detail (the result is returned in ns) and the latter is an implementation detail (browsers currently quantize the result to 100us). That is a useful distinction since you can use WebGPU outside of the browser by embedding Dawn or wgpu into your own application, and there you should get the maximum resolution the spec allows for. Environments like Electron might also opt-out of that timing attack mitigation since they're intended to run trusted code. I agree the article could have made that clearer though.
- rezonant 3y ago
  Yes indeed they mention how to opt out of quantization directly in Chrome if you'd like (at your own risk) using the Devtools.
- no_time 3y ago
  New exciting web fingerprinting vector dropped. As if we didn’t have a enough already.
eyegor 3y ago
Meanwhile sleep() in js land is more of a suggestion when it comes to accuracy. Browser standards are strange. Of course I mean setTimeout/interval because js doesn't even expose a sleep function.

eschaton 3y ago

What’s the actual utility of this for anyone that isn’t trying to replace native code with web pages? Is this ever going to be worth the no doubt massive investment it required?

andybak 3y ago
I'm not sure I understand you. Can you expand your comment somewhat?
hutzlibu 3y ago
"trying to replace native code with web pages? " No one wants that. But many like to write their apps only for one plattform - and then still have them run allmost everywhere. The web is the best we have to achieve this. And this will greatly improve the possibilities. Edit: My app will soon finally use no more html elements. It is not a "webpage".
- mschuetz 3y ago
  > No one wants that. I very much do want that since the WebGPU API is far easier and nicer to use than Vulkan or OpenGL. Also, it makes apps much more accessible to distribute them over web, and it is much more secure to use web apps than native apps. Unfortunately WebGPU is way too limited compared to desktop APIs.
- ladyanita22 3y ago
  Can you have an electron app without HTML elements? A pure WebGPU + Webassembly program?
  - jay_kyburz 3y ago
    YEah, but why wouldn't you want HTML CSS to render your ui. I'm going to revisit electron / nw.js for games again this year. Last time I tried 4-5 years ago I could not get smooth animation with request animation frame.
    - 3y ago

FL33TW00D 3y ago

Well done WebGPU team! Looking forward to the announcement one day that this has landed: https://github.com/gpuweb/gpuweb/issues/4195 https://github.com/gpuweb/gpuweb/issues/4195

modeless 3y ago
Cool, there's consensus between APIs on how to expose "tensor cores" now? Very exciting! Although I think that relaxing memory limitations and providing more visibility and control there is even more important for running ML on the web right now. And harder to make progress on because there isn't a single team that clearly owns "all memory management".