3 ms·
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 laye
by tormeh 4y ago
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 quite a bit more annoying than CPU programming.
- mike_hearn 4y agoYeah, 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 change that. I'm not saying that's a bad trend - the vendors take the perspective that people who need usability are using game engines anyway so "easy but low level" like classic GL is a need whose time has passed. There's probably a lot of truth to that view.
- tormeh 4y agoWhich is fine, IMO, as long as there are user-friendly abstractions on top of those foundations. I'd "just" like to write high-level code that runs on GPUs without having to worry about vendor/OS differences (yay, WebGPU) or writing boilerplate (nay, WebGPU). Currently it's all a bit too annoying for normal programmers to bother with. Every month there's a new programming language for CPUs that intends to make programming easier. I'd like this state of things, but for GPUs.