4 ms·
I think you make a good point in general, but "likely not really have helped macOS gaming in any form" I think is taking it too far. The reason why many develop
by fngjdflmdflg 2y ago
I think you make a good point in general, but "likely not really have helped macOS gaming in any form" I think is taking it too far. The reason why many developers only use dx11/12 is because adding more graphics backends increases their support surface unnecessarily, being that Vulkan only works on Windows (and Linux), while dx11/12 work on Windows on Xbox. As an extreme example of this, apparently Cyberpunk 2077 ran Vulkan on Stadia but did not enable it for Windows as an option. (Because what is the point?) If Vulkan worked on both Windows and Mac then developers would have more reason to support it. It would likely also mean game engines would put more time into making Vulkan better. For a related example, Apple had to individually contribute it's Metal backend to Blender because (presumably) nobody wanted to work on it.[0] Why? Because they already have to support OpenGL, Cuda, OptiX, Intel OneAPI, ROCm HIP, and Vulkan. Clearly, something is very wrong with graphics APIs right now. If Apple supported Vulkan, it would have allowed everyone who is not Windows to benefit by making Vulkan become more standard. Luckily Xbox seems to be kind of dying right now so perhaps supporting dx11/12 will not be as important in the future. But the point is if you have a small portion of the market it just doesn't make sense for developers to spend time entering that market for little reward.
Another major point is the development cycle. Since Metal only works on Apple devices that makes developing for it more annoying for game developers which are mainly using Windows. It means they will have to switch to a Mac device to debug issues with their Metal backend. By supporting Vulkan Apple would allow for a much smoother developer experience. (While Metal Developer Tools for Windows exists, as I understand it it only allows you to compile shaders for Metal on Windows, but to actually test that anything works you will need an actual MacOS device.).
[0] https://code.blender.org/2023/01/introducing-the-blender-metal-viewport/ https://code.blender.org/2023/01/introducing-the-blender-met...
- dagmx 2y agoMany 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/