Well considering the sdk hasn't been released yet and it's still beta software, it's asking a bit much. I don't see why AMD should detail how Nvidia can make use of it anyway?
All of the devs who have access to it so far have said that there is nothing inherently preventing Nvidia from using Mantle though. It's not hard-wired to GCN. Why not believe them?
Because that is a vague marketing slide. Because they haven't filled in any details, despite praising this API as being revolutionary for months. Again, the issue comes down to consistency and confusion in messaging.
Initially, A PR rep from AMD did say that Mantle consists of a GCN card as a necessary part of the equation. I'm not going to go look it up, but it was in that horrific locked Mantle thread. It took place at some time relatively early in the release process, and so you could make the claim that it has been invalidated by the conference wherein they presented the slide you've included above.
There's still a logical issue with that though.
This slide you've copied again shows that the API "does require a minimum feature level from hardware". Great. That's incredibly vague.Why not, in the intervening months, now that the second game using this API is set to sometime soon get a post-release patch fully describe the requirements?
Currently they are saying that Mantle is not necessarily hardwired to GCN...forever. However, functionally, AMD could mandate a minimum feature set that effectively excludes everything but GCN cards, and be technically correct and clear on that statement.
Effectively, they aren't lying if NVIDIA and Intel
could use the API in the future, as long as NVIDIA and Intel exactly replicated all of the function of a current GCN card, either though abstraction, emulation, or paying big licensing fees to AMD. Therefore, in this scenario, Mantle is not actually 'hardwired' to GCN, just so much trouble for everyone else to try and use that it is effectively only for AMD hardware.
I'm not saying this is the case, but it smacks a little bit of mixed messaging when AMD proudly claims that anyone can use it, and then obfuscate exactly what it really takes to go ahead and do that.
If it is inclusive, and can run on other hardware, why not just publish the spec? Let people know what the specifications are, and how one goes about trying to program for it.
It would seem if AMD were trying to convince people how easy and inclusive Mantle is,
showing them how easy and inclusive it is, IE showing how easy it is to have hardware conform to that minimum feature set, would be a good move.
Weather it is in beta or not, AMD should know the baseline requirements for their own API. I would hope. If so, why not publish or at least release them>? I'm inclined to think that it's because they haven't even been able to fully roll out full featured support for their own GCN 1.0 cards yet, and to try and pitch other IHV's using it while they are having issues would seem silly.
You have evidence of all that? Because anything I've read has said the opposite - ie Mantle is *not* difficult to develop for. If the multi-threading was a basic copy/paste job from DX12 then that would be half the job done already.
Again, the point seems to have been lost. In your example, if half of the job is done already from cut and paste from DX 12, you see that as a win. Looking at it the other way, the other half, the half that isn't done still has to be budgeted for. Again, two scenarios.
1) Code for the newer, slimmer DX implementation, that works for everyone with capability reporting scaling, from Dx 9 cards up, from all three manufacturers. Perform QA, code support, and pipeline new games as has been normal practice for years, using DX.
or
2) Code for the newer, slimmer DX implementation, that works for everyone with capability reporting scaling, from Dx 9 cards up, from all three manufacturers. Perform QA, code support, and pipeline new games as has been normal practice for years, using DX. Copy and paste half of the code from the DX version into the Mantle version, troubleshoot the problems caused thereby, and now code the remaining Mantle implementation, troubleshoot that code path, and maintain separate QA and programming resources for the second implementation.
See how one scenario includes more steps and processes than the other? I'm not saying Mantle isn't easy to code for, far from it. How easy it is isn't relevant. It still requires more work to support two API's than one.