It depends on how much custom programming there is beyond the built in facilities of an engine.
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.
The Vega RX Thread (Rumors and Info)
- Thread starter fendersrule
- Start date
- Sort by reaction score
It also depends on the abstractions of the frameworks and APIs and engines.
CUDA seems to have a good balance of abstraction - the CUDA libraries can usually exploit hardware improvements simply by running the same application code with a newer version of CUDA. When new hardware features are exposed in new CUDA library versions, some additional improvement is possible if your app can be modified to call the new features - but older apps still can get some benefit.
It seems like Metal and Vulkan are a step backwards - instead of updating the frameworks for new hardware you're asked to update the application code.
Last edited:
LOL.
On that page look at:
See also[edit]
Also, the dates are rather suspicious - I doubt that it's a full list of DX9/10/11 titles that have been updated for DX12.
- List of games with DirectX 9 support
- List of games with DirectX 10 support
- List of games with DirectX 11 support
- List of games with Vulkan support
And the Vulcan list is very short.
Thats because not a lot of games use these APIs yet. When you see benchmark sites reusing the same battlefield, ashes of the singularity and doom thats because they were either first or one of the few popular ones.
My point was that "Judging by the list of DX12 games, there are more games out for Metal in macOS than DX12 for windows" ignores the huge number of games that use earlier versions of DX, and implies that there are more Apple OSX games than Windows games.
You didn't say that, but it's not inconsistent with what you did say. I'm just trying to clarify that implication.
Sure, obviously windows has more games than macOS. If our theory is that AMD runs games better that take advantage of low level APIs like Metal, DX12 and Vulkan, then its notable that Apple has a relatively high number of games for Metal, especially given the overall lack of games compared to windows. Perhaps the iOS halo effect is true, or developers simply have no other choice because OpenGL is so out of date.
Metal is based on Mantle, just like DirectX12 and Vulkan are. On core level all of those APIs are the same, they differ in execution, and methods of coding.
Metal is the easiest one API to code, and work with, but at the cost a little bigger abstraction layer, than DX, and Vulkan. It also lacks few key features that are important for the pipelines of execution, and makes it impossible to rewrite code 1:1 from other APIs. You have to change your code coming from Vulkan and DX12, but it is not that bad thing, because the API is much easier to work with, than the others.
The problem I have with Metal, and Vega architecture is Primitive Shaders, and programmable geometry pipeline. Will Metal allow this feature to be implemented in game engines? Will it allow the developers direct control over pipeline?
If Apple is going to use Vega in iMac Pro, and possibly in MP I think it would be good idea to allow it, but this is Apple. Unfortunately.
Metal is the easiest one API to code, and work with, but at the cost a little bigger abstraction layer, than DX, and Vulkan. It also lacks few key features that are important for the pipelines of execution, and makes it impossible to rewrite code 1:1 from other APIs. You have to change your code coming from Vulkan and DX12, but it is not that bad thing, because the API is much easier to work with, than the others.
The problem I have with Metal, and Vega architecture is Primitive Shaders, and programmable geometry pipeline. Will Metal allow this feature to be implemented in game engines? Will it allow the developers direct control over pipeline?
If Apple is going to use Vega in iMac Pro, and possibly in MP I think it would be good idea to allow it, but this is Apple. Unfortunately.
That doesn't make much sense, since Metal also supports some Intel iGPUs, although clearly they're not in the same category as dGPUs.
I do wish for once Apple had adopted an industry standard and gone with Vulkan. Creating your own standard is great, but you need to get people to buy into it, and doing it this way isn't easy.
That's demonstrably false.
Panoramic / computational photography is almost entirely based on OpenGL, with Qt providing providing user interface. Most of the tools are available for Mac, Windows and Linux. Noone uses single platform technologies, because no single platform has a sufficient addressable market to justify splitting the development effort.
Let me refrain so that everybody can understand the context which has been discussed there...
Who cares about OpenGL in gaming?
I see you are pushing this alternative fact again. We have corrected you on this before, only Vulkan shares any code with Mantle.
Ask any of game developers about this.
Even if Mantle code is not in those APIs all of them are based on it.
Based on it in what way? Pre-compiled pipeline state objects? Metal feels much more like a clean rewrite of OpenGL than a Mantle port, since Mantle was full of low-level GCN-specific details and Metal is a very clean API. I wouldn't even consider Metal particularly low level, it's much more of a low overhead API. It's probably trending slightly more low level with Metal 2, since I'm sure they're feeling some pressure to provide equivalent functionality to DX12 and Vulkan, but it's still much higher level than either of those two APIs.
Compare feature sets, and its roots.
Yes you are correct, that Metal not being as low-level as DX12, and Vulkan. DX12 to be precise is combination of DX11.3 with Mantle(only the functional core). Features from DX12 are available in DX11.3 but the low-level stuff comes from Mantle.
Vulkan is different story. It is Mantle in everything what it means.
Mantle gave only the core: low-level optimization to IEMs: Microsoft, Apple, and Khronos. From this point things departed.
Even AMD in their blog note said that if you are a developer who is interested in Mantle features you better watch at DX12 and Vulkan. Because both of them are based on it.
Calling a function in dx12 the same as one that could exist in vulkan doesn't mean the underlying code is the same or that the function work the same. If you had any experience in programming you'd know this. DX12 as no relation to Mantle beside filling the same role.
Again, there is no relation between Mantle an dx12. Why you persist in lying about it when many here have proven it false I really don't know why.
And AMD telling people to use dx12 or vulkan isn't because mantle is part of them, but because Mantle is deprecated.
[doublepost=1501692213][/doublepost]
Just as every accelerator pedal in cars offer the same functionalty, doesn't mean cars have the same engine type or work the same internally.
Have you got any relation to coding a game to claim that? I have discussed this with game developers who have had their hands on all 4(!) APIs: Mantle, Vulkan, Metal, and Mantle.
And the conclusion always is simple: They share the core underneath: low-level stuff. Everything else is built on top of it, except for Vulkan. Which is Mantle from the ground up. And the core underneath them is Mantle core.
P.S. Nobody has proven anything. You just share your opinions about it.
I'm not sure what your point is? Apple had undoubtedly been working on Metal for years before it was first introduced on iOS a few years ago. Are you suggesting that Apple and AMD had been working together in secret to introduce new APIs simultaneously? There's no question that Microsoft was heavily influenced by Mantle with DX12, since DX12 came out after that and has many similarities to Mantle (esp. the fact that it's a very low-level API). Metal really looks like Apple just started from a position of "OpenGL ES sucks, let's make something ourselves for iOS". Thus, I really don't see many similarities at all between Mantle and Metal, and I find it a bit of a stretch to claim that Metal is based on Mantle.
[doublepost=1501692404][/doublepost]
Metal is not low level. It's designed to be a low overhead API. It even says it right there in their programming guide:
https://developer.apple.com/library...e.html#//apple_ref/doc/uid/TP40014221-CH2-SW1
I'm saying this as someone who has written code for all of those APIs as well.
Metal is still in development. If it would be the case as you are describing it, current state of the API we would have had two years ago. Mantle has been shared by AMD, with Apple.
I think you should ask a qustion: where did Raj Koduri came from to AMD, and why does Nvidia drivers suck in Metal, and AMD fly in it?
This is the exact "core" feature that has been taken out from Mantle feature set...
Another one of features taken out from Mantle Feature set is ability to work "like" DX12, Vulkan and Mantle with multi core CPUs...
Last edited:
I still don't understand your point. Please explain in detail how Metal is based on Mantle, in particular please list all the Metal features that are identical to Mantle.
Again, my view of the situation is pretty simple:
AMD has had a terrible driver team for many years, and so designed a very low-level API that threw all control over to the app developer (i.e. similar to console APIs) so that their drivers would be very simple.
Apple didn't like OpenGL ES and so designed their own replacement for it, using a very similar feature set (i.e. no geometry or tessellation shaders) that they had full control over.
I really don't see any similarities here, outside of the two companies saying "let's design a new graphics/compute API".
Because you say so?
https://community.amd.com/community/gaming/blog/2015/05/12/on-apis-and-the-future-of-mantle
AMD appears to be disagreeing with you.