10 ms·

WebGPU – All of the cores, none of the canvas

393 points by jasim 5y ago

brrrrrm 5y ago
great writeup! For those interested, I was only able to get the demos running in Chrome Canary with "Unsafe WebGPU" enabled.
faeyanpiraat 5y ago
Question for someone with gpu programming experience: is it feasible to analyze time series data (eg.: run a trading algorithm through a series of stock prices) in parallel (with the algorithms receiving different parameters in each core)? If not then what is the limiting factor?
- rowanG077 5y ago
  Probably possible, but you would really need some more concrete information. For some easy experimentation with GPUs I would advise looking at Futhark. It's super easy to setup and get started. https://futhark-lang.org/ https://futhark-lang.org/
- raphlinus 5y ago
  This depends on the algorithm. If it has lots of branching and control flow, then it's unlikely to run well. If it's based on something like FFT or any sort of linear algebra really, then it should run really well. WebGPU is accessible enough maybe you should try it! You'll learn a lot either way, and it can be fun.
  - amelius 5y ago
    Isn't there something like SciPy which you can run on WebGPU?
    - raphlinus 5y ago
      At this point, there are very few tools actually running on WebGPU, as it's too new. One to watch for sure is IREE, which has a WebGPU backend planned and in the works.
      - galangalalgol 5y ago
        There is wonnx a rust based webgpu enabled onnx runtime for ml stuff.
    - westurner 5y ago
      https://wgpu-py.readthedocs.io/en/stable/guide.html https://wgpu-py.readthedocs.io/en/stable/guide.html : > As WebGPU spec is being developed, a reference implementation is also being build. It’s written in Rust, and is likely going to power the WebGPU implementation in Firefox. This reference implementation, called wgpu-native, also exposes a C-api, which means that it can be wrapped in Python. And this is what wgpu-py does. > So in short, wgpu-py is a Python wrapper of wgpu-native, which is a wrapper for Vulkan, Metal and DX12, which are low-level API’s to talk to the GPU hardware. So, it should be possible to WebGPU-accelerate SciPy; for example where NumPy is natively or third-partily CUDA-accelerated edit: Intel MKL, https://Rapids.ai https://Rapids.ai, > Seamlessly scale from GPU workstations to multi-GPU servers and multi-node clusters with Dask. Where can WebGPU + IDK WebRTC/WebSockets + Workers provide value for multi-GPU applications that already have efficient distributed messaging protocols? "Considerable slowdown in Firefox once notebook gets a bit larger" https://github.com/jupyterlab/jupyterlab/issues/1639#issuecomment-925223852 https://github.com/jupyterlab/jupyterlab/issues/1639#issueco... Re: the differences between the W3C Service Workers API, Web Locks API, and the W3C Web Workers API and "4 Ways to Communicate Across Browser Tabs in Realtime" may be helpful. Pyodide compiles CPython and the SciPy stack to WASM. The WASM build would probably benefit from WebGPU acceleration?
  - mwcampbell 5y ago
    Since you mentioned FFT, I wondered whether GPU-based computation would be useful for audio DSP. But then, lots of audio DSP operations run perfectly well even on a low-end CPU. Also, as one tries to reduce latency, the buffer size decreases, thus reducing the potential to exploit parallelism, and I'm guessing that going to the GPU and back adds latency. Still, I guess GPU-based audio DSP could be useful for batch processing.
    - raphlinus 5y ago
      Yes. Probably the single most effective use of the GPU for audio is convolutional reverb, for which a number of plugins exist. However, the problem is that GPUs are optimized for throughput rather than latency, and it gets worse when multiple applications (including the display compositor) are contending for the same GPU resource - it's not uncommon for dispatches to have to wait multiple milliseconds just to be scheduled. I think there's potential for interesting things in the future. There's nothing inherently preventing a more latency-optimized GPU implementation, and I personally would love to see that for a number of reasons. That would unlock vastly more computational power for audio applications. There's also machine learning, of course. You'll definitely be seeing (and hearing) more of that in the future.
      - misterdata 5y ago
        Already on it! https://github.com/webonnx/wonnx https://github.com/webonnx/wonnx - runs ONNX neural networks on top of WebGPU (in the browser, or using wgpu on top of Vulkan/DX12/..)
- WithinReason 5y ago
  Depends what you do the analysis with. The state of the art is a neural network, and the best there are transformers which do parallelize (as opposed to the previous generation, LSTMs which don't parallelize as well) The limiting factor is usually parallelism, to utilize a GPU well you need to be running something on the order of 10000 threads in parallel.
- modeless 5y ago
  Yes, in fact GPUs are perfect for this. Here is a Monte Carlo financial simulation I built in WebGL 2. https://james.darpinian.com/money/ https://james.darpinian.com/money/ (Warning, programmer UI) It performs one million Monte Carlo runs instantly every time you move a slider. Each run is one execution of a pixel shader and they all happen in parallel. WebGPU will make this kind of thing more accessible. It's kind of a pain to do it in WebGL, but even so it's still totally possible and worthwhile because you can easily get 20 times the performance in many cases and handily beat native CPU code even on the web.
  - neogodless 5y ago
    Hmm the UI is super unresponsive for me. As in, I try to move a slider, I can't tell where it's moving to... then I let go and it's somewhere I didn't expect. Latest Firefox, Windows 10, Radeon RX 6700XT 16GB.
    - modeless 5y ago
      Do other WebGL 2 demos work well for you? Does it work in Chromium? I haven't tested the code extensively so I'm sure it's broken in some configurations. It's just a proof of concept demo for now.
      - neogodless 5y ago
        Ah sorry - disregard. I had a background process gobbling up GPU, and now I can use it in Firefox or Edge. I do find it confusing, as I can put in numbers that get me well below a 3% withdrawal rate, but still have only 40% success rate. But I'm probably misunderstanding some of the mortgage sliders.
        modeless 5y ago
        Yeah, it's confusing for sure. One day hopefully I'll have time to put a real UI on it. Right now it's assuming you buy a house with a mortgage (and property tax and yearly maintenance costs) at the same time as you retire. Put the house price to zero to eliminate all that. Also the expenses slider is before tax, so the tax rate slider influences how large your withdrawals actually are. The total withdrawal per year is displayed near the bottom.
- skohan 5y ago
  GPUs are largely best suited for providing high throughput for doing similar computations across wide datasets. So if you can break down your algorithm into a series of steps which are largely independent and have limited flow-of-control it might be well suited to the task. If you need to have a lot of random access, or branching logic, it may not work so well. But often times it's possible to re-structure an algorithm designed for CPU to perform better on GPU. But how many stocks even are there? You might not even have enough parallel operations to saturate a modern GPU. Out of curiosity, why use WebGPU for this? If you're really trying to do something high performance, why not reach for something like CUDA?
- javierluraschi 5y ago
  We have a few examples of time series data processing in Hal9 with WebGL (no support for WebGPU just yet): - Simple regression with TensorFlow.js: https://hal9.com/hal9/historic-temperature-analysis https://hal9.com/hal9/historic-temperature-analysis - LSTM with TensorFlow.js: https://hal9.com/hal9/bitcoin-prediction https://hal9.com/hal9/bitcoin-prediction - ARIMA with Pyodide.js: https://hal9.com/hal9/ai-fundamentals-arima https://hal9.com/hal9/ai-fundamentals-arima If you have question or would be open to considering using Hal9 to do time series analysis in JavaScript, let me know! You can find me in Twitter at https://twitter.com/javierluraschi https://twitter.com/javierluraschi
shadowgovt 5y ago
Is this API going to have a permissions lock, like access to the video camera or microphone APIs do? If it doesn't, I'm not looking forward to the future where every website I visit tries to pull a big chunk of my graphics card to mine cryptocurrencies without my explicit authorization.
- skywal_l 5y ago
  It's already the case. Any web page can use WebGL1/2 for general computation. As the author said: > Using GPUs for calculations of any kind is often called General-Purpose GPU or GPGPU, and WebGL 1 is not great at this. If you wanted to process arbitrary data on the GPU, you have to encode it as a texture, decode it in a shader, do your calculations and then re-encode the result as a texture. WebGL 2 made this a lot easier with Transform Feedback
  - shadowgovt 5y ago
    True, but this API will make that use case simple and obvious. Given the tradeoffs, probably worth it for user agents to permission-gate it.
    - skywal_l 5y ago
      You can always disable hardware acceleration in your browser.
      - shadowgovt 5y ago
        That's a big red lever that disables all sites' ability to use WebGL also, isn't it? That kind of thing is the kind of thing I imagine one would want at site-by-site granularity.
        account42 5y ago
        I'm still hoping that someone will revive uMatrix and add new columns for GPU access and other webshittery.
superkuh 5y ago
WebGPU, all the bare metal crashes/exploits and none of the broad support. Browsers should not be operating systems and the move to make them so will end up making them just as exploitable as your host OS only much slower due to the additional abstraction layers.
- dman 5y ago
  That ship has long sailed.
  - autoexec 5y ago
    Doesn't mean people can't drop anchor and get off the boat. Lots of terrible ideas were popular and later became uncommon.
- skywal_l 5y ago
  One benefits is that web browsers have to respect a standard set of APIs which abstract the hardware and makes them all inter-operable (except the usual incompatibilities obviously). Now POSIX was arguably successful, but it was limited in scope (not including the UI aspect of things). Also: Windows... Additionally, the absence of that big global state which is the filesystem makes the development of portable applications way more easier. There's always been limitations to what browsers can do, but personally I don't regret iTunes, Outlook or all those desktop app advantageously replaced by SPAs. I can log from any computer/smartphone and I get my apps. No installation process, configuration, the usual missing/corrutped library/dlls, etc. And the problem of data ownership is not a technical problem. If we didn't have browsers, software companies would have moved those data away from you and have desktop app access them remotely anyway. I get that abstraction levels suck. But only if the cost/benefits ratio is bad. Java applet had awful UX AND they were slow. Now SPAs can be quite responsive and some of them a pretty cool to use.
- no_time 5y ago
  >WebGPU, all the bare metal crashes/exploits It's a goldmine. Think of all the future jailbreak entrypoints this will make possible.
- 5y ago
pjmlp 5y ago
With the "fun" to rewrite all WebGL shaders into WGSL.
- dassurma 5y ago
  You can use the SPIR-V compiler toolchain to just transpile from GLSL to WGSL :)
  - flohofwoe 5y ago
    Minor nitpick: this translation happens in separate libraries/tools which just make use of the SPIRVTools library for some SPIRV processing tasks, but not the actual translation to WGSL. Tint (Google, implemented in C++): https://dawn.googlesource.com/tint/ https://dawn.googlesource.com/tint/ Naga (Mozilla(?), implemented mostly in Rust): https://github.com/gfx-rs/naga https://github.com/gfx-rs/naga Both are a bit similar to SPIRV-Cross, except that they also support WGSL.
    - kvark 5y ago
      Naga (a community project) translates GLSL directly into WGSL, unlike other tools.
      - flohofwoe 5y ago
        Ah alright, thanks for the correction :)
  - pjmlp 5y ago
    Yes I know, even more fun dealing with additional kludges, because 3D on the Web versus native doesn't have enough of them already.
faldore 5y ago
azangru 5y ago
Will there be an http203 episode about this? ;-)
beaugunderson 5y ago
One request for the author: Please don't hide the scroll bars on websites you make like this!
- dassurma 5y ago
  I am not! I have no styles that should affect scrollbar visibility. What browser & OS are you on?
  - Ruphin 5y ago
    Hi Surma. Thanks a lot for this writeup. I have been trying to get into WebGPU but good introductory material was sorely lacking some time ago. I have one question: I have had trouble finding a combination of browser/OS/GPU that would allow WebGPU access at the time, what setup did you use and do you have any recommendations? Particularly looking for options on Linux. (Sorry for hijacking this thread)
  - deleted 5y ago
    [deleted]
  - beaugunderson 5y ago
    Chrome, macOS--I see the issue. The scrollbar does not show up against the lighter segments (e.g. the code examples).
dataangel 5y ago
If I'm already familiar with Rust, how is WebGPU as an introduction to graphics programming if you aren't already familiar with any of the backends that it wraps? Should I try just learning Vulcan first? Is the abstraction layer just going to introduce additional confusion for a newbie?
- hutzlibu 5y ago
  "Is the abstraction layer just going to introduce additional confusion for a newbie?" As a newbie you probably don't want to deal with WebGPU directly, but rather use (wait for) a framework, that takes care of the details.
  - rektide 5y ago
    depends on your objective, doesnt it? if you eant to learn how things work & what the fundamnetals are, im not sure that a big engine or framework "taking care of the details" is going to be as illuminating. also, from the article, some poditive reinforcement about trying WebGPU: > I got my feet wet and found that I didn’t find WebGPU significantly more boilerplate-y than WebGL, but actually to be an API I am much more comfortable with. sometimes, there aint nothing like going to the source, finding out for yourself. is it the fastest way to get a job done? perhaps not. but the school of lifelong learning & struggles has it's upsides, can be a path towards a deeper mastery.
    - hutzlibu 5y ago
      "depends on your objective, doesnt it? " Sure, thats why I said "probably". Anyone who wants the most performance and raw power needs to get to the source. But most people using WebGPU are probably fine with a framework, that hides all the details. Like threejs did for webGL.
  - qbasic_forever 5y ago
    Exactly. It's going to be much more productive for someone totally new to 3D graphics to play with three.js and learn all about models, meshes, textures, shaders, coordinate spaces, cameras, etc. If you're starting with webgpu or even webgl you're going to get mired in eccentricities of buffer management, byte formats, etc. which are important plumbing but just that--plumbing.
j-pb 5y ago
WebGPU is a textbook case of Embrace Extend Extinguish performed by Apple to kill Kronos and SPIRV, and everybody is cheering it on. Crazy.
- dassurma 5y ago
  The WebGPU spec is currently edited by two Google employees and one Mozilla employee. I am not sure how to make sense of your accusation.
  - zamadatix 5y ago
    The WebGPU Shading Language spec is edited by Google and Apple, Mozilla were the ones proposing straight SPIRV and are not among the editors in this case. Still doesn't make any sense but it has nothing to do with who the editors are.
  - j-pb 5y ago
    The author list and W3C document are pretty much irrelevant, the actual working group is what counts. After thinking about it some more, I've come to the conclusion that I've actually not been strong enough in my initial accusation, and that Apple is trying to smother any threat that WebGPU poses to its native App supremacy. The story is essentially: Apple wants SPIRV dead. Mozilla wants SPIRV alive. Google wants SPIRV alive. Google developed a human readable text version for SPIRV, which is isomorphic to the binary version, akin to WASM <-> WAT. Mozilla wants SPIRV, which Apple fully rejects (because of some legal dispute with Chronos, where Apple probably tries to get a patent for something that Chronos has as prior art or something), but they are open to googles proposal of a textural intermediary, which is isomorphic. Mozilla and Google agree, because they'll all compile down to SPIRV anyways, except for Apple which will target Metal. This decision is captured in the W3C proposal which to this day contains the Isomorphism property. That's the Embrace, WGSL is born. Apple convinces Mozilla and Google that WGSL should be even more human readable, since user readable formats are the backbone of the open web. But for more convenience WGSL will need more features. Extend. Apple convinces Mozilla and Google that now that the language has grown anyways they should make it much more compatible with other shading languages in general, SPIRV will not be the only target, so while it should be compilable to SPIRV, that's by no means a primary goal. Isomorphism is abandoned. Google tries a last ditch effort to keep the isomorphism with a proposal literally called: "Preserving developer trust via careful conversion between SPIR-V and WGSL". The proposal is rejected, the working group decides that the isomorphism property will no longer hold (I can only assume malevolence that they haven't removed it from the spec yet, probably to keep dev support.). Extinguished. https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDUNqkkMo3a2N7wR4Z04SQinPg/edit#slide=id.g6176d1223e_0_0 https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDU... Why is that isomorphism so important? Because it's near impossible to develop truly high performance shaders with a load of compiler optimisations between your hardware and your tooling. Apple is successfully giving us GLSL in new clothes, and developers are cheering them on, because they just read the W3C spec and ignore the realities of the standard. --- Apple: "Having an isolated focus on SPIR-V is not a good perspective, we have MSL etc. to consider too" ... Apple: "Extreme A is no interaction with SPIRV?, extreme B is very tightly coupled to SPIRV, we should find a middle point" ... Google: "We take all targets into consideration. We can allow developers do runtime probing and maybe branch according to that. Optimization occurs in existence of uncertainty. Dealing with fuzziness is a fact of life and we should give the tools to developers to determine in runtime." From https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4qLczmVRWQaomfQmGNzo/edit https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4... See also: https://github.com/gpuweb/gpuweb/pull/599 https://github.com/gpuweb/gpuweb/pull/599 https://github.com/gpuweb/gpuweb/issues/582 https://github.com/gpuweb/gpuweb/issues/582 https://github.com/gpuweb/gpuweb/issues/566 https://github.com/gpuweb/gpuweb/issues/566 http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642883924 https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642... https://news.ycombinator.com/item?id=24858172 https://news.ycombinator.com/item?id=24858172
eole666 5y ago
For those looking for a complete 3D engine already supporting WebGPU and with a WebGL fallback if needed, there is BabylonJs (you'll need the 5.0 version still in the release candidate state) : https://doc.babylonjs.com/advanced_topics/webGPU/webGPUStatus https://doc.babylonjs.com/advanced_topics/webGPU/webGPUStatu... ThreeJs is alwo working on its WebGPU renderer
- rektide 5y ago
  Im excited for Bevy engine too. It uses wgpu, which has many backends, including webgpu. https://bevyengine.org https://bevyengine.org https://hn.algolia.com/?q=bevy https://hn.algolia.com/?q=bevy
  - slimsag 5y ago
    I've only heard great things about Bevy, and their community is awesome. Highly recommend looking into it if you like Rust! They also just had a huge gamejam with something like ~70 submissions. Impressive stuff! I'm super excited about WebGPU and think it will be a winning strategy for game engines going forward. I'm working on a (very early stages) game engine in Zig called Mach[0] and am using Google Chrome's implementation of WebGPU as the native graphics abstraction layer, so Zig's C++ compiler builds it all, you get cross-compilation out of the box. It's quite fun! [0] https://devlog.hexops.com/2021/mach-engine-the-future-of-graphics-with-zig https://devlog.hexops.com/2021/mach-engine-the-future-of-gra...
- astlouis44 5y ago
  For any developers interested, our team at Wonder Interactive is working on WebGPU support for Unreal Engine 4 and Unreal Engine 5. Games and real-time 3D applications in the browser will form the basis of the open metaverse. You can register here on our website for early access - https://theimmersiveweb.com/ https://theimmersiveweb.com/
  - TheRealNGenius 5y ago
    just so you know, images don't even work on your site. Using safari
dmitriid 5y ago
So now there are three incompatible graphics APIs in the browsers which are also incomplete in different ways. Each of them is a huge chunk of code that needs to maintained and updated.
- undefined_void 5y ago
  yes
- qbasic_forever 5y ago
  There's at least five now: DOM, canvas, SVG, webgl, webgpu. Could maybe make an argument that fonts are an entirely separate rendering engine with quirks and issues too. CSS Houdini might even be another new one.
- modeless 5y ago
  If I was developing a new browser today, my graphics abstraction would be WebGPU and all other graphics would be built on it. WebGL, Canvas 2D, SVG, and even DOM rendering would be unprivileged libraries on top and only WebGPU would be able to touch the actual hardware. I wouldn't be surprised if some browsers moved that way in the long term.
  - raphlinus 5y ago
    I find your ideas intriguing and I wish to subscribe to your newsletter. More seriously, yes, if you were starting a browser completely from scratch, this would probably be a good approach. There are some subtleties, but probably nothing that couldn't be solved with some elbow grease. If anyone is seriously interested in exploring this direction, one thing that would be very interesting is a port of piet-gpu to run on top of WebGPU (it's currently running on Vulkan, Metal, and DX12). I've done quite a bit of pre-work to understand what would be involved, but don't personally have the bandwidth to code up the WebGPU port. I would be more than happy to work with somebody who does.
    - ______-_-______ 5y ago
seumars 5y ago
This is off-topic but I instantly started reading the article in Surmas voice. I mean this as a compliment. Surma and Jake's HTTP203 on YouTube is superb content.
assbuttbuttass 5y ago
Am I understanding this right, that websites can now run a crypto miner in the background when I visit them?
- formerly_proven 5y ago
  always has been
- wlesieutre 5y ago
  Already a thing, it's just been CPU based and now can be GPU based. Firefox (and probably other browsers) have systems to attempt to block them. https://blog.mozilla.org/futurereleases/2019/04/09/protections-against-fingerprinting-and-cryptocurrency-mining-available-in-firefox-nightly-and-beta/ https://blog.mozilla.org/futurereleases/2019/04/09/protectio... The people sneaking this shit into webpages don't care if it burns $1 of electricity and destroys your battery to generate $0.0000001 of Monero because all of those costs are paid by someone else.
  - prox 5y ago
    Is there a toggle extension like I have for JS?
    - autoexec 5y ago
      I'm keeping an eye out too. I've seen a few vulnerabilities mentioned already for this tech. This site (https://hacks.mozilla.org/2020/04/experimental-webgpu-in-firefox/ https://hacks.mozilla.org/2020/04/experimental-webgpu-in-fir...) suggests that setting the options “dom.webgpu.enabled = true” and “gfx.webrender.all = true” to false (where needed) could prevent it from running. I'm also guessing it's use will depend on javascript which I block by default.
- brrrrrm 5y ago
  If you're using Chrome Canary with the "Unsafe WebGPU" flag turned on, yes. And it'll be a lot faster/more power hungry than before. Otherwise, nothing beyond the normal CPU based miners have been enabled. Adaptation is the cost of progress. Browser vendors will almost certainly implement a way to prevent unauthorized use of such hardware (either by prompt like webcams or automatic detection) before this stuff becomes publicly available.
bob1029 5y ago
I've busted my ass on webgl a few times, and I am not really seeing how WebGPU is a substantially better API looking at the samples in the wild: https://webkit.org/demos/webgpu/scripts/hello-triangle.js https://webkit.org/demos/webgpu/scripts/hello-triangle.js The advantages of WebGPU vs WebGL probably make sense to experts in this area, but I still find most of it to be completely impenetrable at first glance as a relative novice.
- mrpinc 5y ago
  I think one of the big changes will allow for async gpu uploads. Currently those happen on the main thread and lock UI.
- whatever_dude 5y ago
  WebGPU is better in many dimensions, but also worse in others people might care about. More appropriately, in this case, WebGPU is in many ways less approachable for novices. One of the expected advantages of WebGPU is exposing the inner workings of the hardware's GPU support in a more explicit manner. This leads to really verbose code. This is similar to API movements seen in DirectX, Vulkan, and Metal. WebGL was never exactly easy to read either, but you could get started more easily. It tried being something in-betweenm though, and ended up never being the best at either providing explicit behavior, nor being friendly. The idea of WebGPU going forward is that it will make it easier for other libraries to use it in a more deterministic fashion. If you know how the metal works, you'll be able to optimize the sh*t out of it. But for novices, you'll end up using some library or engine that abstracts away a lot of the hardcore functionality like "let's get an adapter that supports this specific texture extension" or "let's reuse a binding group layout to save 2ns when binding uniforms". In the same way most people on the web use Three.js (instead of WebGL), you'll see libraries like Babylon or Three.js making use of WebGPU without really having to know about all that stuff. And that's the right solution.
  - kannanvijayan 5y ago
    Anecdotally, I had the opposite experience. I've wanted to dabble in parallel/gpu programming for a while but the fact that all the material forced me to care about triangles and matrix transforms for nontrivial case examples turned me off. I've recently been playing with WebGPU and while it's still a bit of a boilerplate nightmare (which I wouldn't presume to know how to do better).. it was far more approachable. Wrapping my head around buffers and layouts, and the fact that wgsl is a huge pain in the neck to debug, took a while. I've built myself a really rudimentary perlin noise generator using compute shaders, and managed to pipe that into a rendering shader that uses two triangles to render part of the noise field onto a canvas really smoothly. Trying to do some fancier compute stuff now, and overall the primitives are relatively straightforward. It's just that the documentation around the binding types and layouts, resource limits, and command-encoder/pipeline operational semantics are poor right now.
lmeyerov 5y ago
If anyone wants to play with webgl/webgl2/webgpu/high-perf js, we're looking for a graphics engineer for all sorts of fun viz scaling projects (graphs used by teams tackling misinfo, global supply chains, money laundering, genomics, etc.): https://www.graphistry.com/careers https://www.graphistry.com/careers Agreed with other folks here: We see opportunities to advance over what we did with WebGL (opengl es 2.0 from 10-20 years ago)... but as far as we can tell, still a puzzle to work around missing capabilities relative to what we do with modern opencl/cuda on the server. So definitely an adventure!
bacan 5y ago
Another thing to turn off in FireFox. Already have WebRTC, WebGL, WASM, ServiceWorkers etc disabled. Most sites are so much faster without all this junk
- themerone 5y ago
  How is wasm worse than JS?
- autoexec 5y ago
  I'm with you. It's obnoxious to have to disable a long list of things with every install, but if Firefox didn't support something everyone else does they risk driving people who want that functionality away. I don't mind the bloat as long as it's easily disabled and they go out their way to notify users of the risks when they don't have it disabled by default. I want firefox to keep giving people the option to do whatever they want, I just don't want them forcing anything on people, making them more vulnerable by default, or not being clear about things they've added support for.
Waterluvian 5y ago
Re: compute vs. Graphics pipelines: “and also considerably understates that these pipelines are physically different circuits in your GPU” Wait what?? Can someone fill me in? Why would they have different hardware? Compute is compute, even if the computer is mostly good at triangles.
- kvark 5y ago
  Render pipelines use the same compute cores for running the shaders as of long ago. However, they also involve fixed-function pieces (some implemented in hardware) that compute shaders don’t have access to. Such as: rasterizer, blending, depth/stencil testing.

393 points by jasim 5y ago

great writeup! For those interested, I was only able to get the demos running in Chrome Canary with "Unsafe WebGPU" enabled.

faeyanpiraat 5y ago

Question for someone with gpu programming experience: is it feasible to analyze time series data (eg.: run a trading algorithm through a series of stock prices) in parallel (with the algorithms receiving different parameters in each core)? If not then what is the limiting factor?

rowanG077 5y ago
Probably possible, but you would really need some more concrete information. For some easy experimentation with GPUs I would advise looking at Futhark. It's super easy to setup and get started. https://futhark-lang.org/ https://futhark-lang.org/
raphlinus 5y ago
This depends on the algorithm. If it has lots of branching and control flow, then it's unlikely to run well. If it's based on something like FFT or any sort of linear algebra really, then it should run really well. WebGPU is accessible enough maybe you should try it! You'll learn a lot either way, and it can be fun.
- amelius 5y ago
  Isn't there something like SciPy which you can run on WebGPU?
  - raphlinus 5y ago
    At this point, there are very few tools actually running on WebGPU, as it's too new. One to watch for sure is IREE, which has a WebGPU backend planned and in the works.
    - galangalalgol 5y ago
      There is wonnx a rust based webgpu enabled onnx runtime for ml stuff.
  - westurner 5y ago
    https://wgpu-py.readthedocs.io/en/stable/guide.html https://wgpu-py.readthedocs.io/en/stable/guide.html : > As WebGPU spec is being developed, a reference implementation is also being build. It’s written in Rust, and is likely going to power the WebGPU implementation in Firefox. This reference implementation, called wgpu-native, also exposes a C-api, which means that it can be wrapped in Python. And this is what wgpu-py does. > So in short, wgpu-py is a Python wrapper of wgpu-native, which is a wrapper for Vulkan, Metal and DX12, which are low-level API’s to talk to the GPU hardware. So, it should be possible to WebGPU-accelerate SciPy; for example where NumPy is natively or third-partily CUDA-accelerated edit: Intel MKL, https://Rapids.ai https://Rapids.ai, > Seamlessly scale from GPU workstations to multi-GPU servers and multi-node clusters with Dask. Where can WebGPU + IDK WebRTC/WebSockets + Workers provide value for multi-GPU applications that already have efficient distributed messaging protocols? "Considerable slowdown in Firefox once notebook gets a bit larger" https://github.com/jupyterlab/jupyterlab/issues/1639#issuecomment-925223852 https://github.com/jupyterlab/jupyterlab/issues/1639#issueco... Re: the differences between the W3C Service Workers API, Web Locks API, and the W3C Web Workers API and "4 Ways to Communicate Across Browser Tabs in Realtime" may be helpful. Pyodide compiles CPython and the SciPy stack to WASM. The WASM build would probably benefit from WebGPU acceleration?
- mwcampbell 5y ago
  Since you mentioned FFT, I wondered whether GPU-based computation would be useful for audio DSP. But then, lots of audio DSP operations run perfectly well even on a low-end CPU. Also, as one tries to reduce latency, the buffer size decreases, thus reducing the potential to exploit parallelism, and I'm guessing that going to the GPU and back adds latency. Still, I guess GPU-based audio DSP could be useful for batch processing.
  - raphlinus 5y ago
    Yes. Probably the single most effective use of the GPU for audio is convolutional reverb, for which a number of plugins exist. However, the problem is that GPUs are optimized for throughput rather than latency, and it gets worse when multiple applications (including the display compositor) are contending for the same GPU resource - it's not uncommon for dispatches to have to wait multiple milliseconds just to be scheduled. I think there's potential for interesting things in the future. There's nothing inherently preventing a more latency-optimized GPU implementation, and I personally would love to see that for a number of reasons. That would unlock vastly more computational power for audio applications. There's also machine learning, of course. You'll definitely be seeing (and hearing) more of that in the future.
    - misterdata 5y ago
      Already on it! https://github.com/webonnx/wonnx https://github.com/webonnx/wonnx - runs ONNX neural networks on top of WebGPU (in the browser, or using wgpu on top of Vulkan/DX12/..)
WithinReason 5y ago
Depends what you do the analysis with. The state of the art is a neural network, and the best there are transformers which do parallelize (as opposed to the previous generation, LSTMs which don't parallelize as well) The limiting factor is usually parallelism, to utilize a GPU well you need to be running something on the order of 10000 threads in parallel.
modeless 5y ago
Yes, in fact GPUs are perfect for this. Here is a Monte Carlo financial simulation I built in WebGL 2. https://james.darpinian.com/money/ https://james.darpinian.com/money/ (Warning, programmer UI) It performs one million Monte Carlo runs instantly every time you move a slider. Each run is one execution of a pixel shader and they all happen in parallel. WebGPU will make this kind of thing more accessible. It's kind of a pain to do it in WebGL, but even so it's still totally possible and worthwhile because you can easily get 20 times the performance in many cases and handily beat native CPU code even on the web.
- neogodless 5y ago
  Hmm the UI is super unresponsive for me. As in, I try to move a slider, I can't tell where it's moving to... then I let go and it's somewhere I didn't expect. Latest Firefox, Windows 10, Radeon RX 6700XT 16GB.
  - modeless 5y ago
    Do other WebGL 2 demos work well for you? Does it work in Chromium? I haven't tested the code extensively so I'm sure it's broken in some configurations. It's just a proof of concept demo for now.
    - neogodless 5y ago
      Ah sorry - disregard. I had a background process gobbling up GPU, and now I can use it in Firefox or Edge. I do find it confusing, as I can put in numbers that get me well below a 3% withdrawal rate, but still have only 40% success rate. But I'm probably misunderstanding some of the mortgage sliders.
      - modeless 5y ago
        Yeah, it's confusing for sure. One day hopefully I'll have time to put a real UI on it. Right now it's assuming you buy a house with a mortgage (and property tax and yearly maintenance costs) at the same time as you retire. Put the house price to zero to eliminate all that. Also the expenses slider is before tax, so the tax rate slider influences how large your withdrawals actually are. The total withdrawal per year is displayed near the bottom.
skohan 5y ago
GPUs are largely best suited for providing high throughput for doing similar computations across wide datasets. So if you can break down your algorithm into a series of steps which are largely independent and have limited flow-of-control it might be well suited to the task. If you need to have a lot of random access, or branching logic, it may not work so well. But often times it's possible to re-structure an algorithm designed for CPU to perform better on GPU. But how many stocks even are there? You might not even have enough parallel operations to saturate a modern GPU. Out of curiosity, why use WebGPU for this? If you're really trying to do something high performance, why not reach for something like CUDA?
javierluraschi 5y ago
We have a few examples of time series data processing in Hal9 with WebGL (no support for WebGPU just yet): - Simple regression with TensorFlow.js: https://hal9.com/hal9/historic-temperature-analysis https://hal9.com/hal9/historic-temperature-analysis - LSTM with TensorFlow.js: https://hal9.com/hal9/bitcoin-prediction https://hal9.com/hal9/bitcoin-prediction - ARIMA with Pyodide.js: https://hal9.com/hal9/ai-fundamentals-arima https://hal9.com/hal9/ai-fundamentals-arima If you have question or would be open to considering using Hal9 to do time series analysis in JavaScript, let me know! You can find me in Twitter at https://twitter.com/javierluraschi https://twitter.com/javierluraschi

shadowgovt 5y ago

Is this API going to have a permissions lock, like access to the video camera or microphone APIs do? If it doesn't, I'm not looking forward to the future where every website I visit tries to pull a big chunk of my graphics card to mine cryptocurrencies without my explicit authorization.

skywal_l 5y ago
It's already the case. Any web page can use WebGL1/2 for general computation. As the author said: > Using GPUs for calculations of any kind is often called General-Purpose GPU or GPGPU, and WebGL 1 is not great at this. If you wanted to process arbitrary data on the GPU, you have to encode it as a texture, decode it in a shader, do your calculations and then re-encode the result as a texture. WebGL 2 made this a lot easier with Transform Feedback
- shadowgovt 5y ago
  True, but this API will make that use case simple and obvious. Given the tradeoffs, probably worth it for user agents to permission-gate it.
  - skywal_l 5y ago
    You can always disable hardware acceleration in your browser.
    - shadowgovt 5y ago
      That's a big red lever that disables all sites' ability to use WebGL also, isn't it? That kind of thing is the kind of thing I imagine one would want at site-by-site granularity.
      - account42 5y ago
        I'm still hoping that someone will revive uMatrix and add new columns for GPU access and other webshittery.

superkuh 5y ago

WebGPU, all the bare metal crashes/exploits and none of the broad support. Browsers should not be operating systems and the move to make them so will end up making them just as exploitable as your host OS only much slower due to the additional abstraction layers.

dman 5y ago
That ship has long sailed.
- autoexec 5y ago
  Doesn't mean people can't drop anchor and get off the boat. Lots of terrible ideas were popular and later became uncommon.
skywal_l 5y ago
One benefits is that web browsers have to respect a standard set of APIs which abstract the hardware and makes them all inter-operable (except the usual incompatibilities obviously). Now POSIX was arguably successful, but it was limited in scope (not including the UI aspect of things). Also: Windows... Additionally, the absence of that big global state which is the filesystem makes the development of portable applications way more easier. There's always been limitations to what browsers can do, but personally I don't regret iTunes, Outlook or all those desktop app advantageously replaced by SPAs. I can log from any computer/smartphone and I get my apps. No installation process, configuration, the usual missing/corrutped library/dlls, etc. And the problem of data ownership is not a technical problem. If we didn't have browsers, software companies would have moved those data away from you and have desktop app access them remotely anyway. I get that abstraction levels suck. But only if the cost/benefits ratio is bad. Java applet had awful UX AND they were slow. Now SPAs can be quite responsive and some of them a pretty cool to use.
no_time 5y ago
>WebGPU, all the bare metal crashes/exploits It's a goldmine. Think of all the future jailbreak entrypoints this will make possible.
5y ago

pjmlp 5y ago

With the "fun" to rewrite all WebGL shaders into WGSL.

dassurma 5y ago
You can use the SPIR-V compiler toolchain to just transpile from GLSL to WGSL :)
- flohofwoe 5y ago
  Minor nitpick: this translation happens in separate libraries/tools which just make use of the SPIRVTools library for some SPIRV processing tasks, but not the actual translation to WGSL. Tint (Google, implemented in C++): https://dawn.googlesource.com/tint/ https://dawn.googlesource.com/tint/ Naga (Mozilla(?), implemented mostly in Rust): https://github.com/gfx-rs/naga https://github.com/gfx-rs/naga Both are a bit similar to SPIRV-Cross, except that they also support WGSL.
  - kvark 5y ago
    Naga (a community project) translates GLSL directly into WGSL, unlike other tools.
    - flohofwoe 5y ago
      Ah alright, thanks for the correction :)
- pjmlp 5y ago
  Yes I know, even more fun dealing with additional kludges, because 3D on the Web versus native doesn't have enough of them already.

faldore 5y ago

azangru 5y ago

Will there be an http203 episode about this? ;-)

beaugunderson 5y ago

One request for the author: Please don't hide the scroll bars on websites you make like this!

dassurma 5y ago
I am not! I have no styles that should affect scrollbar visibility. What browser & OS are you on?
- Ruphin 5y ago
  Hi Surma. Thanks a lot for this writeup. I have been trying to get into WebGPU but good introductory material was sorely lacking some time ago. I have one question: I have had trouble finding a combination of browser/OS/GPU that would allow WebGPU access at the time, what setup did you use and do you have any recommendations? Particularly looking for options on Linux. (Sorry for hijacking this thread)
- deleted 5y ago
  [deleted]
- beaugunderson 5y ago
  Chrome, macOS--I see the issue. The scrollbar does not show up against the lighter segments (e.g. the code examples).

dataangel 5y ago

If I'm already familiar with Rust, how is WebGPU as an introduction to graphics programming if you aren't already familiar with any of the backends that it wraps? Should I try just learning Vulcan first? Is the abstraction layer just going to introduce additional confusion for a newbie?

hutzlibu 5y ago
"Is the abstraction layer just going to introduce additional confusion for a newbie?" As a newbie you probably don't want to deal with WebGPU directly, but rather use (wait for) a framework, that takes care of the details.
- rektide 5y ago
  depends on your objective, doesnt it? if you eant to learn how things work & what the fundamnetals are, im not sure that a big engine or framework "taking care of the details" is going to be as illuminating. also, from the article, some poditive reinforcement about trying WebGPU: > I got my feet wet and found that I didn’t find WebGPU significantly more boilerplate-y than WebGL, but actually to be an API I am much more comfortable with. sometimes, there aint nothing like going to the source, finding out for yourself. is it the fastest way to get a job done? perhaps not. but the school of lifelong learning & struggles has it's upsides, can be a path towards a deeper mastery.
  - hutzlibu 5y ago
    "depends on your objective, doesnt it? " Sure, thats why I said "probably". Anyone who wants the most performance and raw power needs to get to the source. But most people using WebGPU are probably fine with a framework, that hides all the details. Like threejs did for webGL.
- qbasic_forever 5y ago
  Exactly. It's going to be much more productive for someone totally new to 3D graphics to play with three.js and learn all about models, meshes, textures, shaders, coordinate spaces, cameras, etc. If you're starting with webgpu or even webgl you're going to get mired in eccentricities of buffer management, byte formats, etc. which are important plumbing but just that--plumbing.

j-pb 5y ago

WebGPU is a textbook case of Embrace Extend Extinguish performed by Apple to kill Kronos and SPIRV, and everybody is cheering it on. Crazy.

dassurma 5y ago
The WebGPU spec is currently edited by two Google employees and one Mozilla employee. I am not sure how to make sense of your accusation.
- zamadatix 5y ago
  The WebGPU Shading Language spec is edited by Google and Apple, Mozilla were the ones proposing straight SPIRV and are not among the editors in this case. Still doesn't make any sense but it has nothing to do with who the editors are.
- j-pb 5y ago
  The author list and W3C document are pretty much irrelevant, the actual working group is what counts. After thinking about it some more, I've come to the conclusion that I've actually not been strong enough in my initial accusation, and that Apple is trying to smother any threat that WebGPU poses to its native App supremacy. The story is essentially: Apple wants SPIRV dead. Mozilla wants SPIRV alive. Google wants SPIRV alive. Google developed a human readable text version for SPIRV, which is isomorphic to the binary version, akin to WASM <-> WAT. Mozilla wants SPIRV, which Apple fully rejects (because of some legal dispute with Chronos, where Apple probably tries to get a patent for something that Chronos has as prior art or something), but they are open to googles proposal of a textural intermediary, which is isomorphic. Mozilla and Google agree, because they'll all compile down to SPIRV anyways, except for Apple which will target Metal. This decision is captured in the W3C proposal which to this day contains the Isomorphism property. That's the Embrace, WGSL is born. Apple convinces Mozilla and Google that WGSL should be even more human readable, since user readable formats are the backbone of the open web. But for more convenience WGSL will need more features. Extend. Apple convinces Mozilla and Google that now that the language has grown anyways they should make it much more compatible with other shading languages in general, SPIRV will not be the only target, so while it should be compilable to SPIRV, that's by no means a primary goal. Isomorphism is abandoned. Google tries a last ditch effort to keep the isomorphism with a proposal literally called: "Preserving developer trust via careful conversion between SPIR-V and WGSL". The proposal is rejected, the working group decides that the isomorphism property will no longer hold (I can only assume malevolence that they haven't removed it from the spec yet, probably to keep dev support.). Extinguished. https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDUNqkkMo3a2N7wR4Z04SQinPg/edit#slide=id.g6176d1223e_0_0 https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDU... Why is that isomorphism so important? Because it's near impossible to develop truly high performance shaders with a load of compiler optimisations between your hardware and your tooling. Apple is successfully giving us GLSL in new clothes, and developers are cheering them on, because they just read the W3C spec and ignore the realities of the standard. --- Apple: "Having an isolated focus on SPIR-V is not a good perspective, we have MSL etc. to consider too" ... Apple: "Extreme A is no interaction with SPIRV?, extreme B is very tightly coupled to SPIRV, we should find a middle point" ... Google: "We take all targets into consideration. We can allow developers do runtime probing and maybe branch according to that. Optimization occurs in existence of uncertainty. Dealing with fuzziness is a fact of life and we should give the tools to developers to determine in runtime." From https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4qLczmVRWQaomfQmGNzo/edit https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4... See also: https://github.com/gpuweb/gpuweb/pull/599 https://github.com/gpuweb/gpuweb/pull/599 https://github.com/gpuweb/gpuweb/issues/582 https://github.com/gpuweb/gpuweb/issues/582 https://github.com/gpuweb/gpuweb/issues/566 https://github.com/gpuweb/gpuweb/issues/566 http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642883924 https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642... https://news.ycombinator.com/item?id=24858172 https://news.ycombinator.com/item?id=24858172

eole666 5y ago

For those looking for a complete 3D engine already supporting WebGPU and with a WebGL fallback if needed, there is BabylonJs (you'll need the 5.0 version still in the release candidate state) : https://doc.babylonjs.com/advanced_topics/webGPU/webGPUStatus https://doc.babylonjs.com/advanced_topics/webGPU/webGPUStatu... ThreeJs is alwo working on its WebGPU renderer

rektide 5y ago
Im excited for Bevy engine too. It uses wgpu, which has many backends, including webgpu. https://bevyengine.org https://bevyengine.org https://hn.algolia.com/?q=bevy https://hn.algolia.com/?q=bevy
- slimsag 5y ago
  I've only heard great things about Bevy, and their community is awesome. Highly recommend looking into it if you like Rust! They also just had a huge gamejam with something like ~70 submissions. Impressive stuff! I'm super excited about WebGPU and think it will be a winning strategy for game engines going forward. I'm working on a (very early stages) game engine in Zig called Mach[0] and am using Google Chrome's implementation of WebGPU as the native graphics abstraction layer, so Zig's C++ compiler builds it all, you get cross-compilation out of the box. It's quite fun! [0] https://devlog.hexops.com/2021/mach-engine-the-future-of-graphics-with-zig https://devlog.hexops.com/2021/mach-engine-the-future-of-gra...
astlouis44 5y ago
For any developers interested, our team at Wonder Interactive is working on WebGPU support for Unreal Engine 4 and Unreal Engine 5. Games and real-time 3D applications in the browser will form the basis of the open metaverse. You can register here on our website for early access - https://theimmersiveweb.com/ https://theimmersiveweb.com/
- TheRealNGenius 5y ago
  just so you know, images don't even work on your site. Using safari

dmitriid 5y ago

So now there are three incompatible graphics APIs in the browsers which are also incomplete in different ways. Each of them is a huge chunk of code that needs to maintained and updated.

undefined_void 5y ago
yes
qbasic_forever 5y ago
There's at least five now: DOM, canvas, SVG, webgl, webgpu. Could maybe make an argument that fonts are an entirely separate rendering engine with quirks and issues too. CSS Houdini might even be another new one.
modeless 5y ago
If I was developing a new browser today, my graphics abstraction would be WebGPU and all other graphics would be built on it. WebGL, Canvas 2D, SVG, and even DOM rendering would be unprivileged libraries on top and only WebGPU would be able to touch the actual hardware. I wouldn't be surprised if some browsers moved that way in the long term.
- raphlinus 5y ago
  I find your ideas intriguing and I wish to subscribe to your newsletter. More seriously, yes, if you were starting a browser completely from scratch, this would probably be a good approach. There are some subtleties, but probably nothing that couldn't be solved with some elbow grease. If anyone is seriously interested in exploring this direction, one thing that would be very interesting is a port of piet-gpu to run on top of WebGPU (it's currently running on Vulkan, Metal, and DX12). I've done quite a bit of pre-work to understand what would be involved, but don't personally have the bandwidth to code up the WebGPU port. I would be more than happy to work with somebody who does.
  - ______-_-______ 5y ago

seumars 5y ago

This is off-topic but I instantly started reading the article in Surmas voice. I mean this as a compliment. Surma and Jake's HTTP203 on YouTube is superb content.

assbuttbuttass 5y ago

Am I understanding this right, that websites can now run a crypto miner in the background when I visit them?

formerly_proven 5y ago
always has been
wlesieutre 5y ago
Already a thing, it's just been CPU based and now can be GPU based. Firefox (and probably other browsers) have systems to attempt to block them. https://blog.mozilla.org/futurereleases/2019/04/09/protections-against-fingerprinting-and-cryptocurrency-mining-available-in-firefox-nightly-and-beta/ https://blog.mozilla.org/futurereleases/2019/04/09/protectio... The people sneaking this shit into webpages don't care if it burns $1 of electricity and destroys your battery to generate $0.0000001 of Monero because all of those costs are paid by someone else.
- prox 5y ago
  Is there a toggle extension like I have for JS?
  - autoexec 5y ago
    I'm keeping an eye out too. I've seen a few vulnerabilities mentioned already for this tech. This site (https://hacks.mozilla.org/2020/04/experimental-webgpu-in-firefox/ https://hacks.mozilla.org/2020/04/experimental-webgpu-in-fir...) suggests that setting the options “dom.webgpu.enabled = true” and “gfx.webrender.all = true” to false (where needed) could prevent it from running. I'm also guessing it's use will depend on javascript which I block by default.
brrrrrm 5y ago
If you're using Chrome Canary with the "Unsafe WebGPU" flag turned on, yes. And it'll be a lot faster/more power hungry than before. Otherwise, nothing beyond the normal CPU based miners have been enabled. Adaptation is the cost of progress. Browser vendors will almost certainly implement a way to prevent unauthorized use of such hardware (either by prompt like webcams or automatic detection) before this stuff becomes publicly available.

bob1029 5y ago

I've busted my ass on webgl a few times, and I am not really seeing how WebGPU is a substantially better API looking at the samples in the wild: https://webkit.org/demos/webgpu/scripts/hello-triangle.js https://webkit.org/demos/webgpu/scripts/hello-triangle.js The advantages of WebGPU vs WebGL probably make sense to experts in this area, but I still find most of it to be completely impenetrable at first glance as a relative novice.

mrpinc 5y ago
I think one of the big changes will allow for async gpu uploads. Currently those happen on the main thread and lock UI.
whatever_dude 5y ago
WebGPU is better in many dimensions, but also worse in others people might care about. More appropriately, in this case, WebGPU is in many ways less approachable for novices. One of the expected advantages of WebGPU is exposing the inner workings of the hardware's GPU support in a more explicit manner. This leads to really verbose code. This is similar to API movements seen in DirectX, Vulkan, and Metal. WebGL was never exactly easy to read either, but you could get started more easily. It tried being something in-betweenm though, and ended up never being the best at either providing explicit behavior, nor being friendly. The idea of WebGPU going forward is that it will make it easier for other libraries to use it in a more deterministic fashion. If you know how the metal works, you'll be able to optimize the sh*t out of it. But for novices, you'll end up using some library or engine that abstracts away a lot of the hardcore functionality like "let's get an adapter that supports this specific texture extension" or "let's reuse a binding group layout to save 2ns when binding uniforms". In the same way most people on the web use Three.js (instead of WebGL), you'll see libraries like Babylon or Three.js making use of WebGPU without really having to know about all that stuff. And that's the right solution.
- kannanvijayan 5y ago
  Anecdotally, I had the opposite experience. I've wanted to dabble in parallel/gpu programming for a while but the fact that all the material forced me to care about triangles and matrix transforms for nontrivial case examples turned me off. I've recently been playing with WebGPU and while it's still a bit of a boilerplate nightmare (which I wouldn't presume to know how to do better).. it was far more approachable. Wrapping my head around buffers and layouts, and the fact that wgsl is a huge pain in the neck to debug, took a while. I've built myself a really rudimentary perlin noise generator using compute shaders, and managed to pipe that into a rendering shader that uses two triangles to render part of the noise field onto a canvas really smoothly. Trying to do some fancier compute stuff now, and overall the primitives are relatively straightforward. It's just that the documentation around the binding types and layouts, resource limits, and command-encoder/pipeline operational semantics are poor right now.

lmeyerov 5y ago

If anyone wants to play with webgl/webgl2/webgpu/high-perf js, we're looking for a graphics engineer for all sorts of fun viz scaling projects (graphs used by teams tackling misinfo, global supply chains, money laundering, genomics, etc.): https://www.graphistry.com/careers https://www.graphistry.com/careers Agreed with other folks here: We see opportunities to advance over what we did with WebGL (opengl es 2.0 from 10-20 years ago)... but as far as we can tell, still a puzzle to work around missing capabilities relative to what we do with modern opencl/cuda on the server. So definitely an adventure!

bacan 5y ago

Another thing to turn off in FireFox. Already have WebRTC, WebGL, WASM, ServiceWorkers etc disabled. Most sites are so much faster without all this junk

themerone 5y ago
How is wasm worse than JS?
autoexec 5y ago
I'm with you. It's obnoxious to have to disable a long list of things with every install, but if Firefox didn't support something everyone else does they risk driving people who want that functionality away. I don't mind the bloat as long as it's easily disabled and they go out their way to notify users of the risks when they don't have it disabled by default. I want firefox to keep giving people the option to do whatever they want, I just don't want them forcing anything on people, making them more vulnerable by default, or not being clear about things they've added support for.

Waterluvian 5y ago

Re: compute vs. Graphics pipelines: “and also considerably understates that these pipelines are physically different circuits in your GPU” Wait what?? Can someone fill me in? Why would they have different hardware? Compute is compute, even if the computer is mostly good at triangles.

kvark 5y ago
Render pipelines use the same compute cores for running the shaders as of long ago. However, they also involve fixed-function pieces (some implemented in hardware) that compute shaders don’t have access to. Such as: rasterizer, blending, depth/stencil testing.