291–300 of 405 posts
Earlier quoted context omitted.
I think I meant to ask "how is machine learning support for things like neural networks instead of graphical 2D/3D operations with WebGPU"?
Well, you could implement that on top of the wrappers as well I guess. Anyway!
This is a huge milestone. It's also part of a much larger journey. In my work on developing Vello, an advanced 2D renderer, I have come to believe WebGPU is a game changer. We're going to have reasonably modern infrastructure that runs everywhere: web, Windows, mac, Linux, ChromeOS, iOS, and Android. You're going to see textbooks(*), tutorials, benchmark suites, tons of sample code and projects to learn from. WebGPU…
Suppose you're a ML practictioner. Would you still recommend learning WebGPU, over say spending more time on CUDA?
In case you confused this with webgl as I did: > WebGPU is a new API for the web, which exposes modern hardware capabilities and allows rendering and computation operations on a GPU, similar to Direct3D 12, Metal, and Vulkan. Unlike the WebGL family of APIs, WebGPU offers access to more advanced GPU features and provides first-class support for general computations on the GPU.
And to prevent device fingerprinting, all the operations are specified to deterministically produce the same bit-exact results on all hardware, and the feature set is fixed without any support for extensions, right? Or is this yet another information leak anti-feature that we need to disable?
Earlier quoted context omitted.
For a user to correctly answer a permissions dialog, they need to learn programming and read all the source code of the application. To say nothing of the negative effects of permission dialog fatigue. In practice, no-one who answers a web permissions dialog truly knows if they have made the correct answer. Asking the user a question they realistically can't answer correctly is not a solution. It's giving up on the p…
I think browsers should distinguish more aggressively between "web application", "web site", and "user hostile web site". Many APIs should be gated behind being a web application. This itself could be a permission dialog already, with a big warning that this enables tracking and "no reputable web site will ask for it unless it is clear why this permission is needed - in doubt, choose no". Collect opt-in telemetry. We…
Distinguishing between site and app, e.g. via an installation process, is equivalent to a permissions dialog, except that you're now advocating for one giant permission dialog instead of fine-grained ones, which seems like a step backwards.
Earlier quoted context omitted.
They don't need to learn programming. Just write that this technology can be used for displaying 3D graphics and fingerprinting and let user decide whether they take the risk.
Most of them will say, "I need to see this site, who cares about fingerprints." Some will notice that they're on their screen anyway, a few will know what it's all about. Maybe "it can be used to display 3D graphics and to track you", but I expect that most people will shrug and go on.
Earlier quoted context omitted.
Aras is right, but the elephant in the room is still shitty mobile GPUs. Most of those new and fancy techniques don't work on mobile GPUs, and probably won't for the foreseeable future (Vulkan should actually have been two APIs: one for desktop GPUs, and one for mobile GPUs - and those new extensions are doing exactly that - splitting Vulkan into two more or less separate APIs, one that sucks (for mobile GPUs) and on…
I think it unrealistic management of expectations that desktop and mobile must or should be equal. There is plenty of web applications use cases one would like to run on a desktop, but they are irrelevant for mobile, for many other reasons as well. E.g. think editing spreadsheets.
Earlier quoted context omitted.
How badly can you wreck state in bindless? Badly enough to see the pointers of another process or detect a lot of high-detail information on what computer is running the program? If so, that'd be a non-starter for a web API. Web APIs have to be, first and foremost, secure and protect the user's anonymity.
“The web” should not first and foremost protect anonymity. It should do what humans need it to do ideally while keeping users private and secure. If there’s a concern, my browser should ask me if I’m willing to share potentially sensitive information with a product or service. I fucking hate this weird angsty idea that the web is only designed for anonymous blobs and trolls.
The browser truly is the new OS, for better or for worse.
They couldn't secure our OSes to run untrusted code safely, so they built a OS on top of a OS (yo-dawg meme here). It wouldn't even be so terrible, if it didn't tie us down to a crappy language (JS).
Also I don't hate typescript and there's always wasm.
Earlier quoted context omitted.
The simplest explanation is that the Chrome developers genuinely want to protect privacy and also genuinely want to add features. Every browser has to make that trade off. There are plenty of fingerprinting vulnerabilities in Firefox and Safari too. The reasoning here seems to be something like "Google is evil; X is an evil reason for doing Y; therefore Google must have done Y because of X". It's not a great argument…
I can only quote Johnathan Nightingale, former executive of Mozilla, from his thread on how Google was sabotaging Firefox [1]: "The question is not whether individual sidewalk labs people have pure motives. I know some of them, just like I know plenty on the Chrome team. They’re great people. But focus on the behaviour of the organism as a whole. At the macro level, google/alphabet is very intentional." [1] Thread: h…
You are literally following the parody argument schema that I mentioned in my previous comment. You make some vague insinuations that Google is evil, then attribute everything it does to non-specific evil motivations. Even if Google is evil, this kind of reasoning is completely unconvincing.
I think Firefox aims to have this in Firefox 113, WebGPU was just enabled by default in nightly last week. https://bugzilla.mozilla.org/show_bug.cgi?id=1746245