Don't you have no choice but to code for DX12 if you are releasing your game on console?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Future for Mac games in M1 era
- Thread starter cocoua
- Start date
- Sort by reaction score
If anything, that would only be for Xbox Series X, not other consoles. For XBX I'm not sure it's required, still supports DX11 Feature Level 10, doesn't it? They sure are pushing for DX 12_2, but I'm not sure if it's required for final release. I know a beta of Minecraft ran with DX11, but that could have been for internal testing only.
I should meet some Microsoft guys next week and can ask, but I'm not sure if they can answer Xbox specific questions.
I was under the impression that the XDK** only supports DX12 and since MS requires (at least all 1st party games) support for Smart Delivery it seems like you would have to compile at least 1 DX12 executable (not saying that the PC version can't also do DX11). Of course if you make that tradeoff you lose DXR and all the other makes things go faster support (SFS, Mesh Shaders, etc).
**Sorry GDK, not XDK.
I have no need for parallels, and in all honesty, AOE2 runs on my PC, so I didn't really look the requirements
Graphics performance for Windows 11 gaming on Apple's New 14 & 16" M1 Pro/Max MacBook Pros! Here is a FULL Parallels 17 & Crossover 21 Guide!
"On Mac, there is an additional layer of complexity when trying to use VKD3D for DirectX 12 games. That layer of complexity is Metal. Metal is Apple’s low-level, low-overhead, hardware-accelerated graphic and compute shader API. It was introduced back in 2014, and was designed specifically for Apple's GPUs. Metal does provide support for some other GPUs, but because it was geared for Apple hardware it is different from OpenGL, Vulkan, or D3D12 and its predecessors.
In general, Metal does tessellation differently, and is missing geometry shaders and transform feedback. Specific to DirectX 12 and Metal, there is an issue with limits on resources. Generally, games need access to at least one million shader resource views (SRVs). Access to that many SRVs requires resource binding at the Tier 2 level. Metal only supports about 500,000 resources per argument buffer, so Tier 2 resource binding isn’t possible. Metal’s limit of half a million is sufficient for Vulkan descriptor indexing, but not for D3D12. This limitation means CrossOver Mac can't support Tier 2 binding and therefore a lot of DirectX 12 games will not run.
Another problem is that DirectX 12 uses GPU virtual addresses (VAs) to refer to resources for several things; most significantly ray tracing. According to Vulkan, their buffer device address (BDA) extension allows for the creation of complex data structures required for ray tracing, and useful for DirectX 12 porting. However, Apple has yet to add support for VAs or BDAs, insisting that existing argument buffer support is sufficient for what games want to do. While this may be technically true, it requires game designers to make a targeted effort to run on Metal. It is difficult for translation layers (i.e., MoltenVK or VKD3D) to support BDAs/GPU VAs on top of argument buffers, because argument buffers require you to encode the buffer reference into a separate argument buffer, which makes it more comparable to a Vulkan descriptor set or a DirectX 12 descriptor heap.
Considering these obstacles, we believe support for DirectX 12 on Mac could arrive as soon as CrossOver 23."
www.codeweavers.com
In general, Metal does tessellation differently, and is missing geometry shaders and transform feedback. Specific to DirectX 12 and Metal, there is an issue with limits on resources. Generally, games need access to at least one million shader resource views (SRVs). Access to that many SRVs requires resource binding at the Tier 2 level. Metal only supports about 500,000 resources per argument buffer, so Tier 2 resource binding isn’t possible. Metal’s limit of half a million is sufficient for Vulkan descriptor indexing, but not for D3D12. This limitation means CrossOver Mac can't support Tier 2 binding and therefore a lot of DirectX 12 games will not run.
Another problem is that DirectX 12 uses GPU virtual addresses (VAs) to refer to resources for several things; most significantly ray tracing. According to Vulkan, their buffer device address (BDA) extension allows for the creation of complex data structures required for ray tracing, and useful for DirectX 12 porting. However, Apple has yet to add support for VAs or BDAs, insisting that existing argument buffer support is sufficient for what games want to do. While this may be technically true, it requires game designers to make a targeted effort to run on Metal. It is difficult for translation layers (i.e., MoltenVK or VKD3D) to support BDAs/GPU VAs on top of argument buffers, because argument buffers require you to encode the buffer reference into a separate argument buffer, which makes it more comparable to a Vulkan descriptor set or a DirectX 12 descriptor heap.
Considering these obstacles, we believe support for DirectX 12 on Mac could arrive as soon as CrossOver 23."
We're Getting There — CrossOver Support for DirectX 12 | CodeWeavers Blog
By All Blogs | CrossOver support for DirectX 12 on Linux and Mac.
www.codeweavers.com
I wonder if Apple is going to make some API/hardware changes to match those features."On Mac, there is an additional layer of complexity when trying to use VKD3D for DirectX 12 games. That layer of complexity is Metal. Metal is Apple’s low-level, low-overhead, hardware-accelerated graphic and compute shader API. It was introduced back in 2014, and was designed specifically for Apple's GPUs. Metal does provide support for some other GPUs, but because it was geared for Apple hardware it is different from OpenGL, Vulkan, or D3D12 and its predecessors.
In general, Metal does tessellation differently, and is missing geometry shaders and transform feedback. Specific to DirectX 12 and Metal, there is an issue with limits on resources. Generally, games need access to at least one million shader resource views (SRVs). Access to that many SRVs requires resource binding at the Tier 2 level. Metal only supports about 500,000 resources per argument buffer, so Tier 2 resource binding isn’t possible. Metal’s limit of half a million is sufficient for Vulkan descriptor indexing, but not for D3D12. This limitation means CrossOver Mac can't support Tier 2 binding and therefore a lot of DirectX 12 games will not run.
Another problem is that DirectX 12 uses GPU virtual addresses (VAs) to refer to resources for several things; most significantly ray tracing. According to Vulkan, their buffer device address (BDA) extension allows for the creation of complex data structures required for ray tracing, and useful for DirectX 12 porting. However, Apple has yet to add support for VAs or BDAs, insisting that existing argument buffer support is sufficient for what games want to do. While this may be technically true, it requires game designers to make a targeted effort to run on Metal. It is difficult for translation layers (i.e., MoltenVK or VKD3D) to support BDAs/GPU VAs on top of argument buffers, because argument buffers require you to encode the buffer reference into a separate argument buffer, which makes it more comparable to a Vulkan descriptor set or a DirectX 12 descriptor heap.
Considering these obstacles, we believe support for DirectX 12 on Mac could arrive as soon as CrossOver 23."
We're Getting There — CrossOver Support for DirectX 12 | CodeWeavers Blog
By All Blogs | CrossOver support for DirectX 12 on Linux and Mac.
Doubt it. They want to have developers play their own game, which means "obey!". They think their way is the right one and everyone else is wrong. Now for native Metal, that isn't a problem. It just costs much, much more to develop Multiplatform or port. For crossover support, well, that's a bummer. There's either going to be a hit on visuals or a massive performance bottleneck (or both). But at least, they're moving.
On the other hand we already knew all of this. So we will see DX12 support for Linux in 2022 and might see some form of DX12 support for macOS in 2023 at the earliest. Time will tell.
"On Mac, there is an additional layer of complexity when trying to use VKD3D for DirectX 12 games. That layer of complexity is Metal. Metal is Apple’s low-level, low-overhead, hardware-accelerated graphic and compute shader API. It was introduced back in 2014, and was designed specifically for Apple's GPUs. Metal does provide support for some other GPUs, but because it was geared for Apple hardware it is different from OpenGL, Vulkan, or D3D12 and its predecessors.
In general, Metal does tessellation differently, and is missing geometry shaders and transform feedback. Specific to DirectX 12 and Metal, there is an issue with limits on resources. Generally, games need access to at least one million shader resource views (SRVs). Access to that many SRVs requires resource binding at the Tier 2 level. Metal only supports about 500,000 resources per argument buffer, so Tier 2 resource binding isn’t possible. Metal’s limit of half a million is sufficient for Vulkan descriptor indexing, but not for D3D12. This limitation means CrossOver Mac can't support Tier 2 binding and therefore a lot of DirectX 12 games will not run.
Another problem is that DirectX 12 uses GPU virtual addresses (VAs) to refer to resources for several things; most significantly ray tracing. According to Vulkan, their buffer device address (BDA) extension allows for the creation of complex data structures required for ray tracing, and useful for DirectX 12 porting. However, Apple has yet to add support for VAs or BDAs, insisting that existing argument buffer support is sufficient for what games want to do. While this may be technically true, it requires game designers to make a targeted effort to run on Metal. It is difficult for translation layers (i.e., MoltenVK or VKD3D) to support BDAs/GPU VAs on top of argument buffers, because argument buffers require you to encode the buffer reference into a separate argument buffer, which makes it more comparable to a Vulkan descriptor set or a DirectX 12 descriptor heap.
Considering these obstacles, we believe support for DirectX 12 on Mac could arrive as soon as CrossOver 23."
We're Getting There — CrossOver Support for DirectX 12 | CodeWeavers Blog
By All Blogs | CrossOver support for DirectX 12 on Linux and Mac.
So, can some one dumb this down for me? It says Metal is not good enough because its has 500K shaders and games need minimum 1M shadders (why apple makes their api worse?) then says DirecX 12 will come to Crossover 23 which no timeframe was given?
Also, I am not sure WHO is using CrossOver for gaming. It seems as a hit or miss, I was running the original DOOM (1993 game, yes) horrible or not at all. When it works it works great, but if you want to play games you might just buy a gaming PC and save yourself time and frustration. I mean a Windows game in CrossOver on a MacOS its just... too much I guess.
Bit in a hurry, so here’s the short version. Thats not what it says at all. It says 1 million resources are accessible by shaders. So there’s a structure/table containing pointers to actual resources which shaders can access. That’s 32 byte per resource for a total of 32 MByte which is manually managed by the developer and gives full heap control (type and access). That’s the case for Tier 2. Tier 3 allows more, I’d have to look up how much exactly, it could be the full 96MByte, but don’t quote me on it.
This is the low level management that comes with DX12. You’re much more flexible with resources and therefore it can be a massive performance boost, but you have to manage this yourself. In DX11 or Vulkan that is not the case as the resources are basically managed by the system for you. Metal tried to look at Vulkan for this “hey look, we can do what Vulkan does + our own stuff”. They simply did not see this coming, so there was no need for more than what Metal can do. It’s also hardware related, there are limits by Apples hardware design.
Game developers have struggled with these new DX12 features for a long time, before they got it and we’re able to use it properly.
Sure, maybe they find a way around it. That would be slow, much slower than DX11 via Crossover. Or they are going to use compute shaders instead which do not have the 500k limit and can issue render calls. We don’t know yet. In any case, unless Apple is shipping new hardware and a new version of Metal we will see a performance hit to get around these limitations. Doesn’t mean it can’t be done, even if it’s at 5fps.
Resource binding follows very different philosophy in Metal and DX12/Vulkan. Metal started out with a very simple slot-based binding model, but argument buffers (2017+) brought full bindless support, indirection via pointers, GPU-writeable bindings. Metal also does not force you to pack constants into separate buffers (you can freely mix and match any kind of resources, be it pointers to textures or constants of user-defined types) and it does not have that really odd restriction of DX12 and Vulkan where samplers and other resource descriptors must reside on different heaps.
I am very curious about the nature of all these limitations. They must somehow reflect the least common denominator hardware. For example, the DX12 and Vulkan requirement that samplers and other resources do not mix must mean that some popular hardware has a dedicated register file for samplers — most likely Nvidia. In fact, since both DX12 and Vulkan follow the descriptor heap model — and Metal does not — almost makes me suspect that this is Nvidia's hardware model. Metal makes it clear that AMD GPUs are fully capable of encoding resource bindings within arbitrary GPU memory buffers (not sure about Intel, although they do support VK_EXT_descriptor_indexing with 1mio descriptors).
Overall, it does seem like Metal's limitation of 500k unique resource (texture + buffer) handles is due to Apple hardware itself (we know that AMD does not have these restrictions). That is really unfortunate and IMO a blunder on Apple's side. It's not a problem for Metal itself as it does not rely on the descriptor heap dance like other APIs do, but it does make things much more difficult when trying to emulate DX12/Vulkan patterns. From what I understand, a common pattern in DX12 is just to allocate the entire available descriptor heap and use it as ring buffer, assigning new descriptors on every frame. This approach sounds like it would be extremely inefficient in Metal.
One way to solve this from Apple's side would be to add a lower-level compatibility binding API that more closely mirrors the descriptor heap model, but there are many potential issues here from the buffer layout to hardware limits... Compatibility layers like MoltenVK can probably get around it by recording descriptor assignments and only encoding them into a buffer when a draw call is encountered — this will likely keep the number of active resources under the limit (I doubt that any game actually uses more than 500k of active resources per frame, that would be bonkers), but performance won't be the best...