Chrome ships WebGPU

Post by fulafel » Thu, Apr 06, 2023, 10:40 AM UTC

foldr wrote: post #117

fulafel wrote: post #103

Earlier quoted context omitted.

The rest would be optimization while keeping the timing sidechannel constraint in mind, hard to say what the performance possibilities are. For example not all computations have externally observable side effects, so those parts could be executed conventionally if the runtime could guarantee it. Or the program-visible clock APIs might be keeping virtual time that makes it seem from timing POV that operations are slow…

>not all computations have externally observable side effects You can time any computation. So they all have that side effect. Also, from Javascript you can execute tons of C++ code (e.g. via DOM manipulation). There's no way all of that native code can be guaranteed to run with consistent timing across platforms.

Post by foldr » Thu, Apr 06, 2023, 10:43 AM UTC

fulafel wrote: post #121

foldr wrote: post #117

Earlier quoted context omitted.

>not all computations have externally observable side effects You can time any computation. So they all have that side effect. Also, from Javascript you can execute tons of C++ code (e.g. via DOM manipulation). There's no way all of that native code can be guaranteed to run with consistent timing across platforms.

Depends on who you mean by "you". In context of fingerprinting resistance the timing would have to be done by code in certain limited ways using browser APIs or side channels that transmit information outside the JS runtime. Computations that call into native APIs can be put in the "has observable side effects" category (but in more fine grained treatment, some could have more specific handling).

    function computation() { ... }
    before = performance.now();
    computation();
    t = performance.now() - before;

Post by Ellie_Palms » Thu, Apr 06, 2023, 10:46 AM UTC

Post by pl90087 » Thu, Apr 06, 2023, 10:49 AM UTC

jeroenhd wrote: post #84

pl90087 wrote: post #22

Earlier quoted context omitted.

I wish all information-leaky browser features were turned off by default and I could easily turn them on on demand when needed. Like, the browser could detect that a webpage accesses one of them and tells me that I am currently experiencing a degraded experience which I could improve by turning this slider on.

I've set up my Firefox with resistFingerprinting but without an auto deny on canvas access. It's sickening to see how often web pages still profile you, but the setting seems to work. Similarly, on Android there's a Chromium fork called Bromite that shows JIT, WebRTC, and WebGL as separate permissions, denied by default. I only use it for when broken websites don't work right on Firefox, but websites seem to function…

Post by tormeh » Thu, Apr 06, 2023, 10:52 AM UTC

mike_hearn wrote: post #114

tormeh wrote: post #111

Earlier quoted context omitted.

Good and valid point. Effort will naturally focus on the lowest common denominator. Any new features would have to be implemented in software in the WebGPU layer for targets without API support. That's probably going to slow development of new extensions. However, I think what GPU programming needs at the moment is better ergonomics, and code portability is a step in the right direction, at least. Currently it's quit…

Yeah, but that's because performance always takes priority. The Vulkan/DX12/Metal APIs are lower level and much more tedious than OpenGL and shader based OpenGL was itself a step backwards in usability from the fixed function pipeline (when doing equivalent tasks). So the trend has been towards more generality and performance at the cost of usability for a long time in graphics APIs. Prefixing it with "Web" won't cha…