14 ms·
WebGPU computations performance in comparison to WebGL
- invalidname 5y agoAccessing device low level capabilities implemented by device driver manufacturer? Exploitable vulnerabilities will probably come in faster than the performance...
- flohofwoe 5y agoHow to you get that from the blog post? WebGPU doesn't allow direct access to the GPU just as WebGL doesn't, it's just a different programming model which moves more state management into the initialization phase instead of the render loop.
- 542458 5y agoI recall seeing similar predictions of terrible security vulnerabilities with the WebGL APIs, but AFAIK we never saw real-world attacks here (other than fingerprinting). Much like JIT or video, it does increase the attack surface significantly and you should turn it off if you’re very security conscious… but it’s not apocalyptic for most users.
- pjmlp 5y agoWe could have had compute in WebGL, given that they are part of GL ES, but Chrome refused to support them and since Chrome == Web, now WebGPU is the only way to get compute shaders. https://www.khronos.org/registry/webgl/specs/latest/2.0-compute https://www.khronos.org/registry/webgl/specs/latest/2.0-comp... https://www.khronos.org/assets/uploads/developers/presentations/WebGL-06-Intels-Updates-on-Web-Graphics_SIGGRAPH_Jul19.pdf https://www.khronos.org/assets/uploads/developers/presentati... https://bugs.chromium.org/p/chromium/issues/detail?id=1131991 https://bugs.chromium.org/p/chromium/issues/detail?id=113199...
- flohofwoe 5y agoCompute shaders (and a lot of other useful features) are part of GLES 3.1, while WebGL2 stopped at GLES3.0 (those computer shader experiments were just that: experiments - my guess is that the effort wasn't continued because WebGPU was already on the horizon). edit: GLES3.2 => GLES 3.1
- pjmlp 5y agoIntel showed it working, Chrome abandoned it, because they didn't want to spend resources implementing it, and "In order to reclaim code space in Chromium's installer that is needed by WebGPU, the webgl2-compute context must be removed.". WebGPU is still on the horizon during the next couple of years.
- modeless 5y agoApple abandoned OpenGL and refused to implement newer versions that would include compute shaders. WebGL implementations were based on OpenGL at the time. Intel's prototype did not and could not work on Mac. WebGL on Metal was not even started and there was no indication that Apple would ever work on it. Now, years later, Apple actually implemented WebGL on Metal, so today we could think about implementing WebGL compute on Mac. However WebGPU is now in origin trials. It's very unlikely that Apple would put any effort into a compute shader implementation for WebGL now. And Chrome is not going to go implement a major WebGL feature that has no prospect of ever being supported in Safari.
- pjmlp 5y agoSo for some APIs, Google does whatever they feel like it, e.g. Project Fungus, Houdini and PWAs. But for WebGL it matters what Apple does?
- modeless 5y agoIf Apple was completely blocking progress in web graphics then maybe Chrome would have tried to do something about it. But that's not the case at all. Everyone is aligned on WebGPU as the path forward. It's unfortunate that Apple delayed WebGL for years but there's nothing to do about it now.
- brrrrrm 5y agoIs the benchmark code open source?
- soylentgraham 5y ago"Then the result of computation we have as a set of pixels on a <canvas> element and we have to read it synchronously with getPixelsData then color codes to be converted back to your data. Looks like an inefficient mess, right?" Well, not the fastest path for reading back the rendertarget, so I can see why not doing it would be more efficient
- rough-sea 5y agoIt's a little known fact that Deno has WebGPU built-in already: https://doc.deno.land/builtin/stable#GPU https://doc.deno.land/builtin/stable#GPU
- danielvaughn 5y agoI haven't followed Deno since I first heard of it, back when it was initially announced. If you're following it, how's it going? Do you like it?
- BenoitEssiambre 5y agoHey I was investigating the use of GPUs just out of curiosity since it's one of the few areas of computing I wasn't very familiar with. The above benchmarks are about matrix multiplication. Matrix multiplication seems to be a common theme in gpu api documentation. Now for someone who rarely needs to multiply matrices, are there other good applications the GPU pipeline tends to be useful for? Are there guidelines on how complex a program you can run on GPU cores and still reap benefit? What are (vague, order of magnitude) limits on program size and size of the different memories you have access to? Can you run machine learning algorithms that are not based on matrix multiplication, gradients or derivatives. Can you do monte carlo simulations, decision trees etc?
- krona 5y agoNvidia have an entire library of books dedicated to GPGPU, which can now be (to some extent) repurposed for WebGPU in ways not possible with WebGL. The point of the matrix multiplication example is that it's easy to implement in WebGL without having to be creative; it's a largely apples-to-apples comparison between WebGL/WebGPU/CPU.
- bsenftner 5y agoThe reason matrix multiplication is the focus is because linear algebra is generic, and creates a pipeline for whatever that generic computation requiring task happens to be. The obvious case being things like rendering imagery and transforming point clouds - which if you think about it are completely generic operations.
- dragontamer 5y ago> Now for someone who rarely needs to multiply matrices, are there other good applications the GPU pipeline tends to be useful for? The study of GPU algorithms is completely different and independent of regular CPU algorithms. Sorting: Parallel Bitonic Sort networks. Radix Sort. Mergepath. Hashing: Parallel Cuckoo Hash. Graphs: Strangely similar to CPUs. Depth-first search to save space, breadth-first to generate parallelism. You'll need the parallel SIMD-stack / SIMD-queue with prefix-sums to efficiently push/pull items off the stack/queue, but its not too difficult actually (but non-obvious to the CPU-programmer). Trees: BVH traversal (aka: Raytracing) is extremely common, showing that high-throughput / parallel tree traversal is possible on GPUs. -------- The problem is that GPUs are designed for 10,000 "threads" (really, SIMD-lanes). In fact, I can almost certainly say that any program with less than 1000 threads will run faster on a CPU than a GPU. (unless you're a rare, purely memory bandwidth-bound problem, like memcpy or memset, because GPU-RAM is way faster than standard DDR4) There are all sorts of techniques to discover more "threads" (or parallel streams of computation) through the usage of prefix sum. But ultimately, a "practical" GPU application must perform tens-of-thousands of calculations in parallel to beat a CPU. Indeed: something like parallel-Bitonic Sort is less efficient technically. However, because it creates so many parallel threads of compute, its a great fit as a simple GPU-sorting algorithm. (GPU Mergepath sort is within log2(processors) amount of total work as the sequential version, and is therefore considered almost as efficient as the original sequential algorithm) That's the thing: you end up generating slightly more work with any parallel program than the original sequential algorithm in most cases. Matrix Multiplication is "great" because the parallel version has exactly the same number of additions and multiplications at the original sequential version. So everyone loves it as a simple parallelism example. Its even stronger: the GPU-algorithm not only has the same number of computations, but also the same number of memory reads/writes. Its the most ideal algorithm to run in parallel. Other cases, such as sorting, graph algorithms or whatever, will end up using slightly more overall compute (so there's a tradeoff), or traversing in a different order (CPUs favor depth first search. GPUs will go far more breadth-first before their tens-of-thousands of threads fill up, so you end up traversing the graph / tree in a different order and getting slightly different results) As such, other algorithms require the programmer to make a judgement: is it worth gaining log2(processors) amount of total work, in order to use a GPU and perform the calculation in parallel? Almost certainly. But other algorithms are O(processors) or worse, at which point a purely sequential (or a low-thread count: like 32-threads) would be better than 10,000 threads. GPU lanes are much slower: they access memory at far higher latenciess, and GPUs are in-order processors (lacking branch prediction, out-of-order or superscalar tricks from the CPU world). As such, GPU threads are much much slower individually than CPU threads. You just get a ton of GPU "threads" to make up the difference.
- danielvaughn 5y agoNaive question here. Since WebGPU offers compute, shouldn't it be possible to create a web app where you can join a mining pool directly from your browser?
- pjmlp 5y agoIt is already possible in WebGL using regular shaders, with textures as buffers.
- danielvaughn 5y agoYou can, but my understanding is that they are significantly less performant than using proper compute shaders. Maybe I'm wrong though?
- flohofwoe 5y agoThe more computation happens per 'item/pixel' the less the WebGL-induced overhead should matter, WebGL adds overhead getting the data into and out of the shaders, but the raw pixel- vs compute-shader performance shouldn't differ much.
- kevingadd 5y agoI would expect the real problems are the lack of integer operations and random memory access
- proto-n 5y agoYears back I had the idea of a patreon-like site, where people could support a person/project by keeping a tab open, mining. Nothing like it materialized afaik, guess none of the usual pow algos really shine in browser tabs.
- dljsjr 5y agoMost modern browsers throttle or suspend JS execution in tabs that don't have focus anyway.
- bhouston 5y agoHow if there was only a consistent way to access WebGL, WebGL2 and WebGPU from Node.JS. Was thinking of pushing Headless-GL in that direction: https://twitter.com/BenHouston3D/status/1466054449898659842 https://twitter.com/BenHouston3D/status/1466054449898659842 There is a separate project from Google for just WebGPU in Node.js here but it isn't production ready: https://twitter.com/DaKangz/status/1466063165947527177 https://twitter.com/DaKangz/status/1466063165947527177
- XCSme 5y agoI think the main gist of WebGL and WebGPU is that they run in the browser. If you are going to run it on the server and care about performance, why not use native drivers instead of headless WebGL access? Is code-sharing between browser and server the main reason?
- deleted 5y ago[deleted]
- fulafel 5y agoCalling into native drivers directly is unportable so not suitable for eg a published Node module that's supposed to be generally usable, and the APIs are very unsafe so they'll turn your managed language app into a segfault and security hole prone basket of surprises.
- hutzlibu 5y ago"We do not do expensive and synchronous getPixelsData" Sounds good (along with the performance graph). But I would also just like a asynchronous getPixelData for the canvas now. Does anyone know if there is a chance of this coming anytime soon? From my user perspective, it does not seem too complicated to implement, but the potential benefits seem great. Because WebGL is working quite stable now and WebGPU not yet.
- GhettoComputers 5y agoDo you enable or disable this in your browser? I turned off webGL and webGPU to make it less likely to have processes hogging my device.
- ksec 5y agoDoes anyone know of a high level comparison of features support between Direct X, Metal, WebGPU, OpenGL etc ? I know WebGPU is an subset, but I always wanted to how many features are missing compared to modern Direct X 12 and Metal ( As well as possibly GNMX, Vulkan etc )
- ttoinou 5y agoCan we transfer the result of the WebGPU compute onto a WebGL context to display on canvas afterwards ? So that intermediary computations are fast but we can still use it to display something in WebGL like before
- tominated 5y agoIf you have WebGPU compute support available, you'd probably wanna go straight to using WebGPU instead of WebGL for rendering too. But I don't see why it wouldn't be possible to use the result in WebGL afterwards - there's probably going to be a bit of data conversion involved though
- modeless 5y agoWebGPU can display things on canvases by itself. You don't need WebGL. It is significantly more flexible than WebGL because a single context can present to multiple canvases.
- jdashg 5y agoYou can totally do async downloads out of webgl, and pixels shaders are no more synchronous than compute shaders are. https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/WebGL_best_practices#use_non-blocking_async_data_readback https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/W...