Why that would be a downright logical and reasoned conclusion,
If it ain't broke, don't fix it.All it looks like is that they renamed API calls and some of the return vars without changing their functionality from Mantle in places.
If you can't tell the difference between "similarly worded documentation" and "I literally copy pasted key sections which implies that the API is identical" then I don't know what to tell you. All it looks like is that they renamed API calls and some of the return vars without changing their functionality from Mantle in places. Im sure there's more work in, just like Vulkan, but its pretty clear there are common roots. That is, if emotional investment doesn't cloud logical judgment.
A lot of software platforms that perform similar functions have similar error handling. More examples are needed before I'll be confinced.
Fair enough. I've seen more than just that screenshot, that one is just the best example since it is highlighted etc. Further supporting the conclusion is the fact that MS and AMD before Mantle or DX12 existed collaborated heavily on the Xbone API for GCN. MS made a lot of noise pre release about how nice their API was. My guess is that the Xbone API was copy pasted into both Mantle and DX12. Such that Xbone = 1.0, Mantle = 2.0, DX12 and Vulkan = 3.0 versions of a similar codebase.
Fair enough. I've seen more than just that screenshot, that one is just the best example since it is highlighted etc. Further supporting the conclusion is the fact that MS and AMD before Mantle or DX12 existed collaborated heavily on the Xbone API for GCN. MS made a lot of noise pre release about how nice their API was. My guess is that the Xbone API was copy pasted into both Mantle and DX12. Such that Xbone = 1.0, Mantle = 2.0, DX12 and Vulkan = 3.0 versions of a similar codebase.
That sounds reasonable. If a game is heavily shader-dependent AND one has very broad async capabilities, then it would make sense to do more async calculations even though many of them will be wasted. All it costs is some power and the currency in short supply will be clock cycles, not watts.If anything should convince you DX12 is going to favor GCN, it should be this:
Devs have praised GCN for DX12 publicly on tech forums, they even go so far as to highlight its ability for fine-grained execution of async compute beyond 1 thread/queue, to saturate the shaders.
But whether it has an impact in games, will depend on the game. Just because its a DX12 game does not equate to it using a lot of async compute features. It could simply be the low lvl CPU overhead reduction being employed.
The Starswarm demo favors NV, while the draw call 3dMark bench favors AMD. Basically synthetics tell us very little, we can only judge once a bunch of DX12 games hit.
Interesting times ahead, but not least because I am looking forward to Battlefront & Deus Ex!
Agreed. But if the language is nearly identical then it's reasonable* to assume that the architecture will perform reasonably identically, assuming both Microsoft and AMD do good jobs on their respective parts.Your theory on its evolution in my opinion is sound, but not necessarily indicative of preferring GCN. DX12 probably does share some code base in general functions that are not hardware specific (and from what I can read on that low resolution capture is all CPU handled code and therefore not vendor specific) with Mantle. However, that doesn't mean that they have simply slapped the rest of Mantle into a DX12 wrapper and called it a day. Not when 75% of the dGPU market isn't the hardware that it was originally based off, and then there's the Intel hardware to consider.
If I were in Microsoft's shoes, each vendor would have their own branch in the API of code translation to keep overhead low and compatibility high. It does mean more effort on their part and a larger install footprint, but it's the best way to go to achieve your objectives uniformly across the market and wildly different hardware.
Except that it wouldn't. Similarly worded documentation doesn't reflect machine code in the slightest. I've programmed on enough different platforms to have seen extremely similar documentation to know this. Am I to expect that C++ and Java are nearly identical? Or how about Python and Falcon?
Hmm, similar programming guides absolutely has to mean it's going to favor GCN! It can't possibly be just a high level document that has no direct representation of the low level code! By George, I think he's got it!
Just more unsubstantiated reaching, just like that patent for a high reliability memory controller for chip he is purporting as AMD's HBM controller patent. Similarites do not mean they are ==.
I've programmed enough to know that documentation wouldn't be that similar if I wrote documentation for a piece of my own code two different times.
You could argue that DX12's error handling is similar to Mantle and MS plagiarized the documentation, but there is no chance in hell it is a coincidence.
Those aren't just similar. They are the same. You can't use something else you disagree with to try and discredit it, either. There's zero logic in that.
What does it even matter?
Don't forget that the xbone/ps4 8core APU architecture heavily favored AMD FX processors,we all know how that turned out.
At the end of the day it is much more important how fast you can run the big, code heavy, serial part then it is to simultaneously run a lot of fine-grained little tid bits.
What does it even matter?
Don't forget that the xbone/ps4 8core APU architecture heavily favored AMD FX processors,we all know how that turned out.
At the end of the day it is much more important how fast you can run the big, code heavy, serial part then it is to simultaneously run a lot of fine-grained little tid bits.
Where can one download the Mantle programming guide? Also when was the Mantle documentation finished? Because it could just as well be Mantle copying DirectX 12 documentation if anyone wants to play that game.
I've programmed enough to know that documentation wouldn't be that similar if I wrote documentation for a piece of my own code two different times.
You could argue that DX12's error handling is similar to Mantle and MS plagiarized the documentation, but there is no chance in hell it is a coincidence.
I thought everyone agreed that DX12 was conceptually just an extension of Mantle (albeit expanded to include NVidia and Intel architecture) and the question was only whether it is command-for-command equal or conceptually equal only?Naysayers will say whatever they want contrary to evidence. It's what they do.
After Metal, Vulkan using Mantle as the foundation for their API, it's apparently too extreme or an impossibility for some to see that Mantle was also the foundation for DX12.
Really, who cares that the creator of Mantle (Johan @ DICE) says DX12 is basically deja-vu with Mantle (same as other devs). That devs say ACE engines are awesome for asynchronous compute in DX12. AMD must have had years of advance knowledge of DX12 specs for them to design their uarch with so many independent compute engines that was useless for DX11 and can only be taken advantage of in a Mantle-like API & DX12. How could they have known so many years ahead, when you factor in the time a uarch is developed to when its released and we know GCN is already old.
ps. The document was from the DX12 SDK for developers who had early access.
pss. I expect Pascal will have multiple compute engines this time, then NV will be ALL ABOARD the async compute train!
I thought everyone agreed that DX12 was conceptually just an extension of Mantle (albeit expanded to include NVidia and Intel architecture) and the question was only whether it is command-for-command equal or conceptually equal only?
As I said earlier, it's entirely possible that since Microsoft had access to portions of Mantle from working on the XB1 API and used it as a starting point. Again, it doesn't meant that it is Mantle wrapped up and called DX12 as Silverforce implies. It's reaching.
Do you have a better screen cap that I might be able to compare? That one is hard to read.
Also, I slipped that in to illustrate another example of where Silverforce draws conclusions that aren't supported because of similarities. In his world a Holden and Ford must be the same thing because they are quite similar.
What does it even matter?
Don't forget that the xbone/ps4 8core APU architecture heavily favored AMD FX processors,we all know how that turned out.
At the end of the day it is much more important how fast you can run the big, code heavy, serial part then it is to simultaneously run a lot of fine-grained little tid bits.
I'm guessing that AMD will benefit more both because of Mantle's similarity to DX12 and because of GCN's similarity to the consoles' GPUs, but it's worth pointing out that there are two wild cards here. First, it's possible for Microsoft to absolutely steal Mantle's concepts as whole cloth (no doubt with AMD's eager permission) and yet implement them in a manner less advantageous to AMD than AMD's own creation. And second, Microsoft has undoubtedly been working with and will be working with both NVidia and Intel to maximize performance on their architectures, so it's possible that NVidia and Microsoft will come up with something for them which works as well or even better. Granted, I don't see how, but smarter and much more knowledgeable people than I are working on it.
http://www.amd.com/en-us/innovations/software-technologies/technologies-gaming/mantle#downloads
https://msdn.microsoft.com/en-us/library/windows/desktop/dn899121(v=vs.85).aspx
Conspiracy theories aside, no-one was able to verify it and Microsoft's manual doesn't look like that.