3 ms·

Many engines support Metal, in addition to the plethora of console specific APIs. Saying DX11/12 works on Xbox is glossing over that that it's not actually the

by dagmx 2y ago

Many engines support Metal, in addition to the plethora of console specific APIs. Saying DX11/12 works on Xbox is glossing over that that it's not actually the same DX12 that works on desktop. You then say that if they used Vulkan, it would mean they wouldn't have to debug on a Mac. This is overly optimistic. Even in the OpenGL days, you'd have to test on all platforms because there's so many variances. In general, the game designers are rarely working multi platform, and it's down to the engine devs themselves + QA. Neither should or would be blindly trusting that things are portable. Vulkan/DX on AMD/NVIDIA also perform differently enough that you can't just assume parity. Your other statement about nobody wanting to work on Metal for Blender is a bit odd too. There's no current Vulkan or DX backend for it. Does that mean they're not desired either? AMD and NvidiA contribute support for their favoured API's as well, like Optix that people still desire. > If Apple supported Vulkan, it would have allowed everyone who is not Windows to benefit by making Vulkan become more standard. This didn't prove itself out when OpenGL was a thing. OpenGL was everywhere but barely used. > Luckily Xbox seems to be kind of dying right now so perhaps supporting dx11/12 will not be as important in the future. That doesn't mean that Vulkan would replace it though. Windows gaming still eclipses Linux, and game developers have to target multiple APIs either way. There's very little upside to them switching to Vulkan for it. Also bear in mind that DX is much more than D3D. It's a lot of APIs. There's many reasons to use DX beyond just the 3D graphics APIs.

fngjdflmdflg 2y ago
>if they used Vulkan, it would mean they wouldn't have to debug on a Mac.[...] Neither should or would be blindly trusting that things are portable I didn't mean this, just that you can actually run whatever shaders you compile rather than needing a Mac just to see your output. My point was that you would get "a smoother developer experience," which is true. > Vulkan/DX on AMD/NVIDIA also perform differently enough that you can't just assume parity. Vulkan has some pretty strict conformance tests[0]. It's not like you are going to run into differences between conformant Vulkan implementations every day. It's very different from not being able to run the shaders you've compiled at all. You just need to know what extensions are supported. Also, Apple's support for OpenGL was never good. They only supported OpenGL 4.1 for years while 4.5 was out, for example. I don't know if Apple's OpenGL was ever even conformant, being that 4.1 is not listed on the site.[1] >There's no current Vulkan or DX backend for it. There is actually (as an experimental feature currently).[2] And Khronos did not have to send developers to implement it for them. My understanding is that Blender also implemented CUDA/Optix themsleves and only got help from Nvidia, rather than Nvidia implement the whole thing for them, although I could easily be wrong there. >This didn't prove itself out when OpenGL was a thing. OpenGL was everywhere but barely used. OpenGL was not nearly as performant as direct X. When Direct X came out people switched to it. Vulkan and dx12 are very similar however. > That doesn't mean that Vulkan would replace it though Yeah, because each console wants their own special graphics API to force on everyone instead of using an open standard, despite Xbox and Playstation GPUs being from AMD which supports Vulkan on it's consumer GPUs. >Many engines support Metal, in addition to the plethora of console specific APIs And many don't, including the engines of a lot of AAA games like Elden Ring, Cyber Punk 2077 and Baldur's Gate 3 (although CDPR are now switching to UE5). And studios are generally using modified versions of UE so my guess is that means they are generally making low level changes sometimes, and so it makes sense to me that they sometimes may write their Dx/ Vulkan code for different things sometimes. (this is just my guess. I admit to being uninformed here). Even if not there are still ways that you could program something in UE without writing any direct DX/Vulkan code that could still result in worse performance for one of the backends vs. the other. That is why on games that support multiple graphics backends oftentimes one is better than the other. And developers will release updates improving only certain backends. Adding an extra platform like MacOS is not simply clicking a button. although it is easier today than before, if it was that simple, then literally every UE game would be on MacOS. (Yes, you do 'just click a button' to support MacOS in UE5, but there is still more to it than that.) And increasing the surface area of platform divergence does nothing to help the situation. Also, while it doesn't matter for Apple, having to maintain multiple backends adds needless extra work for engine developers [0] https://docs.vulkan.org/guide/latest/vulkan_cts.html https://docs.vulkan.org/guide/latest/vulkan_cts.html [1] https://www.khronos.org/conformance/adopters/conformant-products/opengl https://www.khronos.org/conformance/adopters/conformant-prod... [2] https://code.blender.org/2023/10/vulkan-project-update/ https://code.blender.org/2023/10/vulkan-project-update/
- philistine 2y ago
  Ultimately, the whole discussion surrounding technologies is discussing the consequences of the problems, not the problem itself. The problem is that Apple, since it decided it was going to make its own GPUs for all its devices, deemed it necessary to simplify their support. Apple's Metal API is custom-made to the silicon Apple is making, and Apple keeps Metal development strictly focused on their hardware. Of course they could have chosen to support more APIs, but the strength of iOS clearly helped them decide to move iOS game developers to the Mac, rather than try to court the so-called AAA companies who are stuck in an x86, Windows+console, heat up the wazoo world. That whole world is difficult to reconcile with Apple's priorities.
  - fngjdflmdflg 2y ago
    >Apple's Metal API is custom-made to the silicon Apple is making Do you have any examples of this? My guess is that the API, being higher level than vk/dx, is designed for ease of use by developers, not to expose hardware level details. In fact Vulkan would be more suitable for that as it is lower level. >the strength of iOS clearly helped them decide to move iOS game developers to the Mac What do you mean by this? Are there a lot of mobile game studios publishing on MacOS now? (this is a legitimate question) >rather than try to court the so-called AAA companies who are stuck in an x86, Windows+console, heat up the wazoo world. Why is that? The only actual barrier there is x86. But Vulkan is not related to x86 anyway. It is only related inasmuchas they are both not supported by Apple. But this discussion is itslef about if Apple should support Vulkan, so the reasoning here seems circular. Also, if Apple doesn't like x86 games that is fine because they don't support x86. So it's not like they are not support Vulkan because they think developers will start distributing x86 games to their customers because that's impossible. >heat up the wazoo I mean, it will use the same about of energy as any other demanding application like Blender or video editing. And you can always lower the graphical settings to make it consume less power. Similarly mobile game developers would likely increase the graphical settings for a mobile game that they port to MacOS.
    - tcmart14 2y ago
      I don't really know if it counts as 'exposing hardware details,' and I may be wrong, but this could be an example of where in their API it does make more sense for Apple Metal being separate. The example I am thinking of is with MTLBuffers and storage options. You have several different storage options for MTLBuffers that wouldn't necessarily make sense on non-apple hardware and especially non-apple silicon. Options that are not backwards compatible with intel macs. When I go to use MTKTextureLoader with the newTexture command, I can set in the options an MTKTextureLoader.Option.StorageMode as shared storage. On Apple silicon, this means that the it is a shared buffer by both the CPU and GPU since with the apple silicon architecture the came peice of memory can be accessed by both. There are a bunch of different storage options that may not apply to other configurations outside of the Apple silicon configurations.
pcwalton 2y ago
> You then say that if they used Vulkan, it would mean they wouldn't have to debug on a Mac. This is overly optimistic. Sure, but supporting two variants of Vulkan is less work than having to support two incompatible APIs. It's not a binary thing.
- pjmlp 2y ago
  The problem is that there isn't two variants, there is an extension soup of Vulkan variants.
  - exDM69 2y ago
    I get by just fine with "one variant" using all the Vulkan 1.3 features that are ubiquitously available on desktop (= almost all of them) platforms with up to date drivers. The fact that there's n+1 extensions does not mean you have to support 2^(n+1) combinations. I can't recall a single situation where I would've needed even two code paths to get something done in the past few years. Situations where you need two or more code paths only arise if you use new hardware features like mesh shaders or ray tracing. For "software" features like dynamic rendering or dynamic states (both of which simplify things a lot), there's no need for a fallback on desktop, just require a recent driver version and you're good. That said, the mobile driver support situation and lack of long term updates is an issue if mobile support is required.
    - pjmlp 2y ago
      [flagged]
      - exDM69 2y ago
        How is it easier said than done? All three major GPU vendors (Intel, nvidia, AMD) have drivers have a very good support on all three major desktop platforms (Windows, Linux and Macos), and it goes back to quite old hardware (Intel Skylake 2015, Nvidia Maxwell 2014, not sure about AMD). If you know exactly which driver version(s) you require, you can explicitly check it at init time, or you can just check for the feature flags and require them at init (you need to do this explicitly anyways). OpenGL 3.3 is a popular choice only because Apple dropped OpenGL support and HW features (tessellation, etc) were required for 4.x. You don't have a situation like that with Vulkan. You get all the latest SW features even on old HW. Vulkan's explicit extensions/features setup is much much better than OpenGL ever was, and there are no "half assed" implementations out there like there were in OpenGL days. You don't end up using a feature by accident, and then have your app not work on a platform you didn't test on. The conformance test suite is very strict, so if a feature is supported it's very likely to work as advertised, much less driver bugs than in the OpenGL days.

by dagmx 2y ago

fngjdflmdflg 2y ago

>if they used Vulkan, it would mean they wouldn't have to debug on a Mac.[...] Neither should or would be blindly trusting that things are portable I didn't mean this, just that you can actually run whatever shaders you compile rather than needing a Mac just to see your output. My point was that you would get "a smoother developer experience," which is true. > Vulkan/DX on AMD/NVIDIA also perform differently enough that you can't just assume parity. Vulkan has some pretty strict conformance tests[0]. It's not like you are going to run into differences between conformant Vulkan implementations every day. It's very different from not being able to run the shaders you've compiled at all. You just need to know what extensions are supported. Also, Apple's support for OpenGL was never good. They only supported OpenGL 4.1 for years while 4.5 was out, for example. I don't know if Apple's OpenGL was ever even conformant, being that 4.1 is not listed on the site.[1] >There's no current Vulkan or DX backend for it. There is actually (as an experimental feature currently).[2] And Khronos did not have to send developers to implement it for them. My understanding is that Blender also implemented CUDA/Optix themsleves and only got help from Nvidia, rather than Nvidia implement the whole thing for them, although I could easily be wrong there. >This didn't prove itself out when OpenGL was a thing. OpenGL was everywhere but barely used. OpenGL was not nearly as performant as direct X. When Direct X came out people switched to it. Vulkan and dx12 are very similar however. > That doesn't mean that Vulkan would replace it though Yeah, because each console wants their own special graphics API to force on everyone instead of using an open standard, despite Xbox and Playstation GPUs being from AMD which supports Vulkan on it's consumer GPUs. >Many engines support Metal, in addition to the plethora of console specific APIs And many don't, including the engines of a lot of AAA games like Elden Ring, Cyber Punk 2077 and Baldur's Gate 3 (although CDPR are now switching to UE5). And studios are generally using modified versions of UE so my guess is that means they are generally making low level changes sometimes, and so it makes sense to me that they sometimes may write their Dx/ Vulkan code for different things sometimes. (this is just my guess. I admit to being uninformed here). Even if not there are still ways that you could program something in UE without writing any direct DX/Vulkan code that could still result in worse performance for one of the backends vs. the other. That is why on games that support multiple graphics backends oftentimes one is better than the other. And developers will release updates improving only certain backends. Adding an extra platform like MacOS is not simply clicking a button. although it is easier today than before, if it was that simple, then literally every UE game would be on MacOS. (Yes, you do 'just click a button' to support MacOS in UE5, but there is still more to it than that.) And increasing the surface area of platform divergence does nothing to help the situation. Also, while it doesn't matter for Apple, having to maintain multiple backends adds needless extra work for engine developers [0] https://docs.vulkan.org/guide/latest/vulkan_cts.html https://docs.vulkan.org/guide/latest/vulkan_cts.html [1] https://www.khronos.org/conformance/adopters/conformant-products/opengl https://www.khronos.org/conformance/adopters/conformant-prod... [2] https://code.blender.org/2023/10/vulkan-project-update/ https://code.blender.org/2023/10/vulkan-project-update/

philistine 2y ago
Ultimately, the whole discussion surrounding technologies is discussing the consequences of the problems, not the problem itself. The problem is that Apple, since it decided it was going to make its own GPUs for all its devices, deemed it necessary to simplify their support. Apple's Metal API is custom-made to the silicon Apple is making, and Apple keeps Metal development strictly focused on their hardware. Of course they could have chosen to support more APIs, but the strength of iOS clearly helped them decide to move iOS game developers to the Mac, rather than try to court the so-called AAA companies who are stuck in an x86, Windows+console, heat up the wazoo world. That whole world is difficult to reconcile with Apple's priorities.
- fngjdflmdflg 2y ago
  >Apple's Metal API is custom-made to the silicon Apple is making Do you have any examples of this? My guess is that the API, being higher level than vk/dx, is designed for ease of use by developers, not to expose hardware level details. In fact Vulkan would be more suitable for that as it is lower level. >the strength of iOS clearly helped them decide to move iOS game developers to the Mac What do you mean by this? Are there a lot of mobile game studios publishing on MacOS now? (this is a legitimate question) >rather than try to court the so-called AAA companies who are stuck in an x86, Windows+console, heat up the wazoo world. Why is that? The only actual barrier there is x86. But Vulkan is not related to x86 anyway. It is only related inasmuchas they are both not supported by Apple. But this discussion is itslef about if Apple should support Vulkan, so the reasoning here seems circular. Also, if Apple doesn't like x86 games that is fine because they don't support x86. So it's not like they are not support Vulkan because they think developers will start distributing x86 games to their customers because that's impossible. >heat up the wazoo I mean, it will use the same about of energy as any other demanding application like Blender or video editing. And you can always lower the graphical settings to make it consume less power. Similarly mobile game developers would likely increase the graphical settings for a mobile game that they port to MacOS.
  - tcmart14 2y ago
    I don't really know if it counts as 'exposing hardware details,' and I may be wrong, but this could be an example of where in their API it does make more sense for Apple Metal being separate. The example I am thinking of is with MTLBuffers and storage options. You have several different storage options for MTLBuffers that wouldn't necessarily make sense on non-apple hardware and especially non-apple silicon. Options that are not backwards compatible with intel macs. When I go to use MTKTextureLoader with the newTexture command, I can set in the options an MTKTextureLoader.Option.StorageMode as shared storage. On Apple silicon, this means that the it is a shared buffer by both the CPU and GPU since with the apple silicon architecture the came peice of memory can be accessed by both. There are a bunch of different storage options that may not apply to other configurations outside of the Apple silicon configurations.

pcwalton 2y ago

> You then say that if they used Vulkan, it would mean they wouldn't have to debug on a Mac. This is overly optimistic. Sure, but supporting two variants of Vulkan is less work than having to support two incompatible APIs. It's not a binary thing.

pjmlp 2y ago
The problem is that there isn't two variants, there is an extension soup of Vulkan variants.
- exDM69 2y ago
  I get by just fine with "one variant" using all the Vulkan 1.3 features that are ubiquitously available on desktop (= almost all of them) platforms with up to date drivers. The fact that there's n+1 extensions does not mean you have to support 2^(n+1) combinations. I can't recall a single situation where I would've needed even two code paths to get something done in the past few years. Situations where you need two or more code paths only arise if you use new hardware features like mesh shaders or ray tracing. For "software" features like dynamic rendering or dynamic states (both of which simplify things a lot), there's no need for a fallback on desktop, just require a recent driver version and you're good. That said, the mobile driver support situation and lack of long term updates is an issue if mobile support is required.
  - pjmlp 2y ago
    [flagged]
    - exDM69 2y ago
      How is it easier said than done? All three major GPU vendors (Intel, nvidia, AMD) have drivers have a very good support on all three major desktop platforms (Windows, Linux and Macos), and it goes back to quite old hardware (Intel Skylake 2015, Nvidia Maxwell 2014, not sure about AMD). If you know exactly which driver version(s) you require, you can explicitly check it at init time, or you can just check for the feature flags and require them at init (you need to do this explicitly anyways). OpenGL 3.3 is a popular choice only because Apple dropped OpenGL support and HW features (tessellation, etc) were required for 4.x. You don't have a situation like that with Vulkan. You get all the latest SW features even on old HW. Vulkan's explicit extensions/features setup is much much better than OpenGL ever was, and there are no "half assed" implementations out there like there were in OpenGL days. You don't end up using a feature by accident, and then have your app not work on a platform you didn't test on. The conformance test suite is very strict, so if a feature is supported it's very likely to work as advertised, much less driver bugs than in the OpenGL days.