WebGPU is now available on Android
developer.chrome.com
developer.chrome.com
> ...
> 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...
I agree the article could have made that clearer though.
As if we didn’t have a enough already.
Of course I mean setTimeout/interval because js doesn't even expose a sleep function.
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.
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
Android: 0.34%
Chromium OS: 78.15%
iOS: 0.09%
Linux: 0.75%
Mac OS: 54.43%
Windows: 77.96%
1: https://gs.statcounter.com/os-version-market-share/android/m... (Android 14 is still counted as "other")
https://webkit.org/blog/14879/webgpu-now-available-for-testi...
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
I didn't say it was absolutely right. Re-read my comment above.
> So how can it possibly be even close the correct?
I suggested in my previous comment that when the numbers are close to extremes they are more accurate. Basically as the survey approaches either 0% or 100% (look at iOS support for WebGPU above), it is indicative that the stddev of the distribution is small and thus any sampling bias is likely to not really have much of an effect. The more problematic numbers are those that are near the middle, like 50%, as the stddev is likely much higher and thus sampling bias can introduce more skew.
But generally this survey started out last year when I made the website as <1% for WebGPU support and it has climbed above 50%. That is real movement and is indicative as a whole that WebGPU support is climbing.
For the most part, you want to have WebGPU support to be >> 80% on this type of survey if you want to introduce a website that uses it exclusively without some type of fallback available.
Given the list of sites, I don't think the data will show me the long tall of low powered older phones that are used by the majority of people because the people visiting sites like those on the list are more than likely to be tech people who have newer tech.
PS, I'm not dissing the site or your effort. It's awesome that you put it together. Rather, I'm saying the numbers are not reliable. You can't say "50% of people can use feature x". You can only say "50% of people that visit sites like those listed can use feature x". I suspect that 50% is way way off. It's more like only 10% of the general population can use feature x"
Here's hoping you can get one or more mainstream sites to add your survey script.
So... won't work on any exynos, since they have the AMD RDNA3 arch? Do I get that right?
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.
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.
search for "accel"
Disable the blacklist for your GPU.
Which fully supports pjmlp's point in the sibling comment.
Having drivers installed is not enough as the browser lords decided the computer isn't worthy of playing games.
The rest enjoyed the games, to the point that Flash is being brought back thanks WebAssembly, with Unity and Flutter as spiritual sucessors.
In seriousness though, WebGPU in Chrome with “non-free” Linux GPU drivers should work, no?
Edit: I see it’s still behind a flag
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.
* 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
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.
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.
Does Android Chrome have the per-tab hover card RAM use feature as desktop chrome?
From https://news.ycombinator.com/item?id=37840416 :
>> From "Manifest V3, webRequest, and ad blockers" (2022) 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
Can you expand your comment somewhat?
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".
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.
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.
I recommend pixijs.
But it depends what you do, smooth animations of some elements is possible with html. But in my case it got complex and html was the bottleneck. Now I have the same assets in Pixi and it runs around 100× faster. No more lags, no stuttering. No more html.
(Allmost, some static content is still HTML, but that is fine, as long as the DOM does not get modified)
If your “app” runs in a browser window—a window presented by a browser engine—it’s fundamentally a web page. (They’re two distinct words.)
So no, I do not want to replace native code with a web page. But in some cases with web apps.
Additionally it is more suited to GPU based compute, which can be used to accelerate neural network inferencing, though not quite as well as dedicated NN accelerators which are fairly common these days.
I would tend to agree that the business case for these things is not as strong as many would like though, and things have a distinct habit of ceasing to be interesting the moment they are widely achievable.
Unless your stance is that WebGL itself had no real use case, which is just silly.
Or, say, literally any number of e-commerce sites that give the user an interactive and/or customisable view of products and not just static imagery.
Or, say, any number of pages that embed complex data visualisations.
"Why does a graphical UI platform need performant graphics" is an incredibly tautological question.
Do you mean the clusterfuck that is matching carefully your compiler, ID, hardware, instruction set architecture, incompatible dependency versions, installers, package managers, etc.?
So far, WebGPU was the first and only time that I was able run Stable Diffusion on my own hardware.
Assuming you want to use 2024 hardware features in 2024.
If you're writing new gfx code though and are more familiar with web technology, there's definitely utility there. That's the bigger value prop: that people with web development skills can work on more pro (GPU-required) applications.