4 ms·

I don't see the problem. There have been lower-level APIs in the graphics stack for a long time (e.g. Mesa's Gallium), only now they are standardised and people

by dvdkon 1y ago

I don't see the problem. There have been lower-level APIs in the graphics stack for a long time (e.g. Mesa's Gallium), only now they are standardised and people are actually choosing to use them. It's not like higher-level APIs don't exist now, OpenGL is still supported on reasonable platforms and WebGPU has been usable from native code for some time. As for true portability of those low-level APIs, you've basically got Apple to blame (and game console manufacturers, but I don't think anyone expected them to cooperate).

cogman10 1y ago
> you've basically got Apple to blame Yeah, that's the thing that really irks me. WebGPU could have been just a light wrapper over Vulkan like WebGL is (or was, it's complicated now) for OpenGL. But apple has been on a dumb war with Khronos for the last decade which has made everything more difficult. So now we have n+1 low level standards for GPU programming not because we needed them, but because 1 major player is obstinate.
- flohofwoe 1y ago
  That would be a problem indeed if Metal wouldn't be a much better designed API than Vulkan. As it stands, Vulkan would do good to 'steal' a few ideas from Metal to make the Vulkan API more convenient to use without sacrificing too much performance.
  - cogman10 1y ago
    Or you could build on top of Vulkan and add the convenience features into middleware. Being simpler is an advantage. It means that 3rd party GPU drivers can more simply implement the interface correctly.
    - flohofwoe 1y ago
      The problem is, for that to happen Vulkan must be convenient and enjoyable enough to use that people are willing to put their free time into such middleware layers, otherwise it mostly won't happen (unless Valve is willing to sponsor the development - because outside of Valve's effort to make Windows games run on Linux via layering D3D on top of Vulkan, Vulkan is actually quite irrelevant).
      - pjmlp 1y ago
        Almost, now with Vulkan being the only 3D API on Android (OpenGL ES now builds on top of Vulkan), it is also relevant there. However, as discussed in other comments, that doesn't change the driver quality mess of the platform.
    - m-schuetz 1y ago
      At least for webgpu, you cant wrap around some of the nonse. Like bindigs. They are an inherently bad concept and the way to go would be bindless, but you cant make a wraper that makes an API that revolves around binding into a bindless API. And there are other things like that, and I'm sure there are plenty between Vulkan and Metal.
dagmx 1y ago
Your last paragraph is fairly revisionist to me. How is Apple solely to blame when there are multiple parties involved ? They went to Khronos to turn AMD’s mantle into a true unified next gen APi. Khronos and NVIDIA shot them down to further AZDO OpenGL. Therefore Metal came to be and then DX12 followed and then Vulkan when Khronos realized they had to move that way. But even if you exclude Metal, what about Microsoft and D3D? Also similarly non-portable. Yet it’s the primary API in use for non-console graphics. You rarely see people complaining about the portability of DX for some reason… And then in an extremely distant last place is Vulkan. Very few graphics apps actually use Vulkan directly. Have you tried writing any of the graphics APIs?
- hmry 1y ago
  People don't complain about DX portability because Windows has first-party support for Vulkan and OpenGL, unlike macOS. Also, since the XBox also uses DirectX, you get two birds with one stone. And third, you aren't forced to use Microsoft hardware to develop for DirectX (these days, you don't even have to use Windows.) Basically, people are mad that you need to buy Apple hardware, use Apple software (macOS), Apple tooling (Xcode), just to develop graphics code for iOS and macOS. At least you don't also need to use Apple language (Swift) to use Metal, though I don't have any first-hand experience with their C++ bindings so I can't judge if it's a painful experience or not.
  - dagmx 1y ago
    Windows has third party support for Vulkan and OpenGL. It is NOT first party. It's definitely more convenient than Mac because it is provided by the driver and so you can almost always guarantee they exist, but Microsoft themselves do not provide them. On Mac, for Vulkan you can use MoltenVK which is also third party, and bundle it in the app, though definitely less convenient and less fully featured. Regarding Xbox, that's a bit of an odd point because you might as well include iOS as a platform at that point which is a bigger gaming platform than Xbox. At least iOS uses the same Metal as Mac, while Xbox does vary in some ways from Windows. Granted, iOS gaming is much more casual oriented but there are some AAA games as well. Regarding Swift, Metal has always been ObjC first not swift first. The C++ bindings are just for convenience, but you've never been bound to Swift even before they existed. Regarding Xcode, that's only to get the toolchain or if you need instrumentation. You don't need to use Xcode to actually develop things, this is no more a burden than needing Visual Studio on Windows.

by dvdkon 1y ago

cogman10 1y ago

> you've basically got Apple to blame Yeah, that's the thing that really irks me. WebGPU could have been just a light wrapper over Vulkan like WebGL is (or was, it's complicated now) for OpenGL. But apple has been on a dumb war with Khronos for the last decade which has made everything more difficult. So now we have n+1 low level standards for GPU programming not because we needed them, but because 1 major player is obstinate.

flohofwoe 1y ago
That would be a problem indeed if Metal wouldn't be a much better designed API than Vulkan. As it stands, Vulkan would do good to 'steal' a few ideas from Metal to make the Vulkan API more convenient to use without sacrificing too much performance.
- cogman10 1y ago
  Or you could build on top of Vulkan and add the convenience features into middleware. Being simpler is an advantage. It means that 3rd party GPU drivers can more simply implement the interface correctly.
  - flohofwoe 1y ago
    The problem is, for that to happen Vulkan must be convenient and enjoyable enough to use that people are willing to put their free time into such middleware layers, otherwise it mostly won't happen (unless Valve is willing to sponsor the development - because outside of Valve's effort to make Windows games run on Linux via layering D3D on top of Vulkan, Vulkan is actually quite irrelevant).
    - pjmlp 1y ago
      Almost, now with Vulkan being the only 3D API on Android (OpenGL ES now builds on top of Vulkan), it is also relevant there. However, as discussed in other comments, that doesn't change the driver quality mess of the platform.
  - m-schuetz 1y ago
    At least for webgpu, you cant wrap around some of the nonse. Like bindigs. They are an inherently bad concept and the way to go would be bindless, but you cant make a wraper that makes an API that revolves around binding into a bindless API. And there are other things like that, and I'm sure there are plenty between Vulkan and Metal.

dagmx 1y ago

Your last paragraph is fairly revisionist to me. How is Apple solely to blame when there are multiple parties involved ? They went to Khronos to turn AMD’s mantle into a true unified next gen APi. Khronos and NVIDIA shot them down to further AZDO OpenGL. Therefore Metal came to be and then DX12 followed and then Vulkan when Khronos realized they had to move that way. But even if you exclude Metal, what about Microsoft and D3D? Also similarly non-portable. Yet it’s the primary API in use for non-console graphics. You rarely see people complaining about the portability of DX for some reason… And then in an extremely distant last place is Vulkan. Very few graphics apps actually use Vulkan directly. Have you tried writing any of the graphics APIs?

hmry 1y ago
People don't complain about DX portability because Windows has first-party support for Vulkan and OpenGL, unlike macOS. Also, since the XBox also uses DirectX, you get two birds with one stone. And third, you aren't forced to use Microsoft hardware to develop for DirectX (these days, you don't even have to use Windows.) Basically, people are mad that you need to buy Apple hardware, use Apple software (macOS), Apple tooling (Xcode), just to develop graphics code for iOS and macOS. At least you don't also need to use Apple language (Swift) to use Metal, though I don't have any first-hand experience with their C++ bindings so I can't judge if it's a painful experience or not.
- dagmx 1y ago
  Windows has third party support for Vulkan and OpenGL. It is NOT first party. It's definitely more convenient than Mac because it is provided by the driver and so you can almost always guarantee they exist, but Microsoft themselves do not provide them. On Mac, for Vulkan you can use MoltenVK which is also third party, and bundle it in the app, though definitely less convenient and less fully featured. Regarding Xbox, that's a bit of an odd point because you might as well include iOS as a platform at that point which is a bigger gaming platform than Xbox. At least iOS uses the same Metal as Mac, while Xbox does vary in some ways from Windows. Granted, iOS gaming is much more casual oriented but there are some AAA games as well. Regarding Swift, Metal has always been ObjC first not swift first. The C++ bindings are just for convenience, but you've never been bound to Swift even before they existed. Regarding Xcode, that's only to get the toolchain or if you need instrumentation. You don't need to use Xcode to actually develop things, this is no more a burden than needing Visual Studio on Windows.