5 ms·

I find it interesting that the Web platform ended up being the catalyst to finally get all the OS and GPU vendors to sit down and write a single interoperable A

I find it interesting that the Web platform ended up being the catalyst to finally get all the OS and GPU vendors to sit down and write a single interoperable API. The existence of wgpu is a very nice outcome for all graphics programmers, even those who don't work on the Web.

adamnemecek 5y ago
It makes sense. The standardization effort is pretty involved, I don’t know what besides the Web would have been able to twist their arms into doing it.
- pjmlp 5y ago
  Except the end result are fossilized 3D APIs. WebGL 2.0 is a subset of OpenGL ES 3.0, meaning 2011 mobile GPUs. WebGPU 1.0 is a subset of Vulkan/Metal/DX 12, meaning 2016 GPUs. And on top, you get a new C++/Rust flavoured shading language, throwing away all shaders created for WebGL. If you want top graphics on the Web, the answer is surprise, surprise, server side rendering to textures with native 3D APIs alongside data streaming.
  - adamnemecek 5y ago
    How would the api be different if it was targeting 2022 gpus?
    - pjmlp 5y ago
      It would be exposing stuff like ray tracing and mesh shaders for example. Or having a shading language with C++ like capabilities. WebGL still cannot do compute or geometry shaders, for example. Nor it will ever be able to do them.
      - Jweb_Guru 5y ago
        If you know of a way to portably expose ray tracing even on just the GPUs that actually support it, feel free to tell me (or anyone for that matter). AFAIK the problem of abstracting over the different stuff Nvidia and AMD call "ray tracing" is currently an open research problem. Of course you could respond that portability isn't important if you only care about delivering the best graphics you can on given hardware, but if you're really willing to write totally different pipelines for newer AMD cards, newer Nvidia cards, older cards, consoles, etc. you are probably not in the target audience for WebGPU. (BTW, the biggest reason stuff like wgpu-rs doesn't support geometry shaders on non-Metal is that they're horribly slow on a bunch of GPUs, with vendors indicating that they found it super hard to profitably support them in hardware. That's why Metal removed them entirely. I think all the features of geometry shaders that are actually reliably fast, as well as the stuff required to integrate with tessellation shaders, will almost certainly come eventually in other forms. This is an example of why if you care about performance and portability you shouldn't just dump every feature under the sun into your abstraction layer).
        pjmlp 5y ago
        You can start by using Unreal 5 with Nanite. Yes it isn't quite the same thing, it is however a good example of what Web 3D APIs will never offer, not in 2022, or even in a decade. Unreal 5 with Nanite doing pixel streaming via Azure Cloud Gaming, or WebGPU 1.0, I know which one I would rather play with.
        Jweb_Guru 5y ago
        First, you're talking about a full-fledged game engine (and one that's not actually free or usable by many projects, BTW!) by a huge team that can optimize individually for each platform (and doesn't actually support some platforms at all, e.g. Mac; you may not care about supporting such platforms, but that doesn't mean everyone can afford that luxury). I am talking about a portable low-level graphics API that smaller development teams can use to build their own stuff without needing to rewrite their pipelines for each new target platform. Second, you're also talking about a game engine that does not portably expose ray tracing GPU features; stuff like Nanite that optimistically takes advantage of the hardware where it's available to accelerate ordinary software rasterization is not even close to the same thing. This is a really weak argument. The truth is that neither you, nor I, nor (right now) anyone else knows how to expose that hardware portably, it's all incredibly custom and will probably need big rewrites for each new hardware release. You're complaining about an API not doing something that nobody actually knows how to do yet. Finally, not every application wants to or is able to be rendered in the cloud. It's incredibly expensive to rent out GPUs if you're not being subsidized, and in fact even most AAA attempts haven't worked out economically. Plus not every application can deal with the server latency, or wants to be beholden to an always-online server, or has clients who can tolerate the bandwidth required, or a myriad of other things. So that isn't a solution to a portable low-level graphics API either. I'm not saying WebGPU is perfect, but driveby comments like yours that imply it's missing obvious stuff or handicapped or whatever are pretty annoying. It's a very good attempt at a very difficult goal (efficient, portable, low-level graphics) that has value to a lot of people. It isn't going to be everything to everybody (and neither is UE5, incidentally). When there is a portable way to expose raytracing functionality I have no doubt it will come to WebGPU, but until then it's basically a meaningless gotcha.
pjmlp 5y ago
Except they aren't doing that. Some Rust folks are pushing to run WebGPU outside of the browser, that is all. Native OS 3D APIs are the same business as always.
ben-schaaf 5y ago
Considering it's a web API for JavaScript, not something provided by the OS/drivers, WebGPU is hardly any different to WebGL. It still requires the native OpenGL/Vulkan/Metal/DirectX APIs to be built on top of. As such it really hasn't moved the needle whatsoever in regards to API interoperability, only provided yet another cross-platform abstraction (at least outside the web).
- Jweb_Guru 5y ago
  From an operational standpoint, however, WebGPU is a much better fit for Vulkan/Metal/DirectX than OpenGL is, since it (mostly) exposes abstractions that all three actually support efficiently (and more generally, was designed with modern GPUs in mind, so unless GPU design fundamentally changes it's unlikely that it will require doubling or tripling the API surface to keep up, unlike OpenGL). That represents a pretty significant improvement over OpenGL (particularly the older versions of OpenGL that you have to use if you actually care about portability), and also over solutions like MoltenVK (it's hard to efficiently implement a lower-level API on top of a higher-level one). This doesn't invalidate your point, I just think when you say "yet another cross-platform abstraction" you're implying that this is an xkcd "now there are 15 standards" situation, when in reality the competition is basically just ancient versions of OpenGL. And OpenGL is effectively deprecated--Khronos has no plans to release any more major updates. Unfortunately, without the browser usecase bringing many of the stakeholders on board, there is not a lot of money in this kind of work, which is why there aren't any serious competitors.
  - dmitriid 5y ago
    It is xkcd though. WebGPU as proposed by Apple was basically Metal. Naturally other vendors weren't keen on implementing this, so they arrived at a compromise which is a bastard child of Metal and Vulkan. They couldn't even adopt an existing shader language and invented a new one. That goes as far as invent new and unprecedented language constructs https://github.com/gpuweb/gpuweb/issues/569 https://github.com/gpuweb/gpuweb/issues/569
    - Jweb_Guru 5y ago
jokethrowaway 5y ago
This didn't happen. The rust community needed a cross-platform layer and built it.

adamnemecek 5y ago

It makes sense. The standardization effort is pretty involved, I don’t know what besides the Web would have been able to twist their arms into doing it.

pjmlp 5y ago
Except the end result are fossilized 3D APIs. WebGL 2.0 is a subset of OpenGL ES 3.0, meaning 2011 mobile GPUs. WebGPU 1.0 is a subset of Vulkan/Metal/DX 12, meaning 2016 GPUs. And on top, you get a new C++/Rust flavoured shading language, throwing away all shaders created for WebGL. If you want top graphics on the Web, the answer is surprise, surprise, server side rendering to textures with native 3D APIs alongside data streaming.
- adamnemecek 5y ago
  How would the api be different if it was targeting 2022 gpus?
  - pjmlp 5y ago
    It would be exposing stuff like ray tracing and mesh shaders for example. Or having a shading language with C++ like capabilities. WebGL still cannot do compute or geometry shaders, for example. Nor it will ever be able to do them.
    - Jweb_Guru 5y ago
      If you know of a way to portably expose ray tracing even on just the GPUs that actually support it, feel free to tell me (or anyone for that matter). AFAIK the problem of abstracting over the different stuff Nvidia and AMD call "ray tracing" is currently an open research problem. Of course you could respond that portability isn't important if you only care about delivering the best graphics you can on given hardware, but if you're really willing to write totally different pipelines for newer AMD cards, newer Nvidia cards, older cards, consoles, etc. you are probably not in the target audience for WebGPU. (BTW, the biggest reason stuff like wgpu-rs doesn't support geometry shaders on non-Metal is that they're horribly slow on a bunch of GPUs, with vendors indicating that they found it super hard to profitably support them in hardware. That's why Metal removed them entirely. I think all the features of geometry shaders that are actually reliably fast, as well as the stuff required to integrate with tessellation shaders, will almost certainly come eventually in other forms. This is an example of why if you care about performance and portability you shouldn't just dump every feature under the sun into your abstraction layer).
      - pjmlp 5y ago
        You can start by using Unreal 5 with Nanite. Yes it isn't quite the same thing, it is however a good example of what Web 3D APIs will never offer, not in 2022, or even in a decade. Unreal 5 with Nanite doing pixel streaming via Azure Cloud Gaming, or WebGPU 1.0, I know which one I would rather play with.
        Jweb_Guru 5y ago
        First, you're talking about a full-fledged game engine (and one that's not actually free or usable by many projects, BTW!) by a huge team that can optimize individually for each platform (and doesn't actually support some platforms at all, e.g. Mac; you may not care about supporting such platforms, but that doesn't mean everyone can afford that luxury). I am talking about a portable low-level graphics API that smaller development teams can use to build their own stuff without needing to rewrite their pipelines for each new target platform. Second, you're also talking about a game engine that does not portably expose ray tracing GPU features; stuff like Nanite that optimistically takes advantage of the hardware where it's available to accelerate ordinary software rasterization is not even close to the same thing. This is a really weak argument. The truth is that neither you, nor I, nor (right now) anyone else knows how to expose that hardware portably, it's all incredibly custom and will probably need big rewrites for each new hardware release. You're complaining about an API not doing something that nobody actually knows how to do yet. Finally, not every application wants to or is able to be rendered in the cloud. It's incredibly expensive to rent out GPUs if you're not being subsidized, and in fact even most AAA attempts haven't worked out economically. Plus not every application can deal with the server latency, or wants to be beholden to an always-online server, or has clients who can tolerate the bandwidth required, or a myriad of other things. So that isn't a solution to a portable low-level graphics API either. I'm not saying WebGPU is perfect, but driveby comments like yours that imply it's missing obvious stuff or handicapped or whatever are pretty annoying. It's a very good attempt at a very difficult goal (efficient, portable, low-level graphics) that has value to a lot of people. It isn't going to be everything to everybody (and neither is UE5, incidentally). When there is a portable way to expose raytracing functionality I have no doubt it will come to WebGPU, but until then it's basically a meaningless gotcha.

pjmlp 5y ago

Except they aren't doing that. Some Rust folks are pushing to run WebGPU outside of the browser, that is all. Native OS 3D APIs are the same business as always.

ben-schaaf 5y ago

Considering it's a web API for JavaScript, not something provided by the OS/drivers, WebGPU is hardly any different to WebGL. It still requires the native OpenGL/Vulkan/Metal/DirectX APIs to be built on top of. As such it really hasn't moved the needle whatsoever in regards to API interoperability, only provided yet another cross-platform abstraction (at least outside the web).

Jweb_Guru 5y ago
From an operational standpoint, however, WebGPU is a much better fit for Vulkan/Metal/DirectX than OpenGL is, since it (mostly) exposes abstractions that all three actually support efficiently (and more generally, was designed with modern GPUs in mind, so unless GPU design fundamentally changes it's unlikely that it will require doubling or tripling the API surface to keep up, unlike OpenGL). That represents a pretty significant improvement over OpenGL (particularly the older versions of OpenGL that you have to use if you actually care about portability), and also over solutions like MoltenVK (it's hard to efficiently implement a lower-level API on top of a higher-level one). This doesn't invalidate your point, I just think when you say "yet another cross-platform abstraction" you're implying that this is an xkcd "now there are 15 standards" situation, when in reality the competition is basically just ancient versions of OpenGL. And OpenGL is effectively deprecated--Khronos has no plans to release any more major updates. Unfortunately, without the browser usecase bringing many of the stakeholders on board, there is not a lot of money in this kind of work, which is why there aren't any serious competitors.
- dmitriid 5y ago
  It is xkcd though. WebGPU as proposed by Apple was basically Metal. Naturally other vendors weren't keen on implementing this, so they arrived at a compromise which is a bastard child of Metal and Vulkan. They couldn't even adopt an existing shader language and invented a new one. That goes as far as invent new and unprecedented language constructs https://github.com/gpuweb/gpuweb/issues/569 https://github.com/gpuweb/gpuweb/issues/569
  - Jweb_Guru 5y ago

jokethrowaway 5y ago

This didn't happen. The rust community needed a cross-platform layer and built it.