A few days ago it was confirmed that none of AMD’s current GPUs are capable of supporting the new rendering features in DirectX 12 level 12_1, namely Conservative Rasterization and Rasterizer Ordered Views.
I already mentioned that back when Maxwell v2 and DX11.3 were introduced.
Back then a guy named ‘Tom’ tried to push the idea that these features are supported by Mantle/GCN already. When I asked for some specifics, it became somewhat clear that it would simply be some kind of software implementation rather than direct hardware support.
When I asked for some actual code to see how complex it would actually be to do this in Mantle, there was no reply.
Software approaches in general are no surprise. AMD demonstrated a software version of order-independent-transparency at the introduction of the Radeon 5xxx series.
And a software implementation for conservative rasterization was published in GPU Gems 2 back in 2005.
So it’s no surprise that you can implement these techniques in software on modern GPUs. But the key to DX12_1 is efficient hardware support.
That should have already confirmed that AMD was missing out on these features, at least on the current hardware.
Rumours have it that a large part of the new 3xx series will actually be rebranded 2xx GPUs, so nothing changes there, feature-wise.
So the only unknown is what the new Fiji chip is going to be capable of, for the Radeon Fury series.
The most info I’ve found on the Fiji chip so far is a set of leaked slides posted at Beyond3D.
But it still isn’t clear whether it supports conservative rasterization and rasterizer ordered views. The slides do not mention it, which is not a good sign. They do mention “Full DX12 support”, but only in combination with resource binding tier 3 (a feature that Maxwell v2 does not support).
I think it is safe to assume that if they supported conservative rasterization and ROV’s, that we would have heard of it by now, and it would definitely be mentioned on the slides, since it is a far more interesting feature than resource binding tier 2 vs tier 3.
So I contacted Richard Huddy about this. His reply pretty much confirmed that conservative rasterization and ROV’s are missing.
Some of the responses of AMD’s Robert Hallock on Twitter also point to downplaying the new DX12_1 features, and just pretending that supporting DX12 is supporting DX12, regardless of featurelevel.
Clearly that is not the case, 12_1 includes some rasterizing features that 12_0 does not. But if AMD needs to spread that message, with a new chip being launched in just a few days, I think we know enough.
Edit:
Oh wow, there goes the hate campaign again:
Does this mean that Nvidia didn’t support DX 11 because they couldn’t do DX 11.1 or feature level 11_1? Does the fact that Nvidia downplayed the benefits of 11.1/11_1 mean that they didn’t support DX 11? That guy just sounds like an idiot/fanboy when he says that even if it may not have been his intention.
Of course if he said the same things about Nvidia back then, well, then he’s just an idiot. 🙂
Is it just me, or is this logic broken beyond repair? I don’t know what to make of this…. “nVidia didn’t support DX11 because they couldn’t do DX11.1?”
How is that an analogy to this? Nobody said AMD doesn’t support DX12. I’m just saying that the statement AMD is making is “DX12 is DX12, regardless of whether you support level 12_0 or 12_1”.
I’m just pointing out the obvious flaw in AMD’s statement: there are different levels in DX12 because they are different.
Not to mention that the situation with DX10/DX10.1 or DX11/DX11.1 are very different to the current situation. Namely, those were updates to the API that were done after the API had been on the market for years already. Back when DX10 and DX11 were launched, there was no concept of DX10.1 and DX11.1 respectively. And neither nVidia nor AMD had DX10.1/DX11.1 hardware at the launch of DX10/11.
In this case, there are different feature levels for DX12 introduced right at the launch of the API. So that does not compare at all to the situation with earlier versions of DX.
So who is sounding like an idiot/fanboy here?
Scali's OpenBlog™ 
Scali, AMD has tried to manage the roll out of Fiji and the rebranded set of Hawaii cards. Holding back samples from independent tech sites has back fired. Even Charlie Demerjian at SemiAccurate wrote a scathing story and called AMD’s deceptive tactics out
https://semiaccurate.com/2015/06/19/amd-outs-caribbean-islands-aka-r9-300-series-gpus/
I trust you have read the reviews from reputable sites like HardOCP that do not buy into the AMD marketing ways…
http://www.hardocp.com/article/2015/06/24/amd_radeon_r9_fury_x_video_card_review#.VYxHp2fbKic
The AMD fanboys will continue to defend AMD no matter at what cost. And AMD? What does AMD think it can get away with?
Well, if sites like SemiAccurate and HardOCP are anything to go by, it looks like AMD is starting to lose its goodwill, at last.
I’m afraid the next 5 years will just be about AMD claiming we don’t need 12_1 features, and everytime they are used in a game, it’s nVidia’s evildoing and whatnot. Basically the same as tessellation all over again. Speaking of which… Fury X still isn’t particularly good at tessellation.
I’ve just gotten tired of the whole thing. All the rabid AMD fanboys calling you out for being anti-AMD or pro-nVidia. I’m not, I’m just interested in new technology. It’s not my fault that nVidia delivered the best DX11-implementation, with the most usable implementation of tessellation to date. Again, I can’t help it that nVidia already has 12_1 implemented on Maxwell v2 chips, and AMD does not.
Yes, I currently prefer nVidia hardware. But not because it’s nVidia. That’s what they don’t get. I prefer it because it delivers the best implementation of the DX standard, which is what I want for software development. If Fury X had supported 12_1 and decent tessellation, I would probably have ordered one right away.
But sadly, it is exactly as I had feared, and which I wrote down in this blog before the new Radeons were launched: Fury X is little more than GCN1.2 with HBM.
HBM is a nice new technology, and I think it’s great that AMD took the risk to be the first to market. Sadly it does not translate in much of a tangible benefit at this point.
“So who is sounding like an idiot/fanboy here?”
I would say it’s you, Scali. 😉 Supporting DX12 means supporting at least FL12.0. AFAIK GCN supports CR in hardware. It seems it’s just about ROVs. If ROVs are really that much more efficient than current OIT implementations still has to be proven. Anyway, I think it’s not really a big deal not to support it now because developers won’t use it now.
Are you really so naive to think AMD cannot implement ROVs in the next 5 years? It shouldn’t be much of a problem. Likely Arctic Islands will support it already next year. OTOH Nvidia very likely cannot support resource binding tier 3 that soon. That’s more of a disappointments for developers. AMD also supports async shaders which is a big advantage. Or in other words, do you really prefer Nvidia just because of ROVs, ignoring all the advantages of AMD’s architecture? That sounds really idiotic.
It’s wrong from you to say AMD isn’t good at tessellating. In fact AMD is good at tessellating. AMD is just not good at over-tessellating like Nvidia. But who cares? No one needs that because it only costs performance and cannot improve visual quality or sometimes even degrades it.
CR can be exposed as an optional feature even on 12_0. GCN does not expose this feature, ergo it does not support it.
Why would that be exactly? All developers I spoke to, figured tier 2 was more than enough for any real-world scenarios for years to come.
This includes developers at Square Enix, developing with AMD.
Look before you leap, nVidia actually does this considerably better than AMD on Maxwell v2: http://www.anandtech.com/show/9124/amd-dives-deep-on-asynchronous-shading
They can run 31 compute shaders at a time in parallel with the graphics core, where AMD can only do 8.
Even Kepler can run 32 compute shaders at a time, it just cannot combine this with graphics workloads.
“It’s wrong from you to say AMD isn’t good at tessellating. In fact AMD is good at tessellating. AMD is just not good at over-tessellating like Nvidia.”
…which basically means AMD’s tessellation performance isn’t as good as nVidia’s.
Foot-in-mouth disease much?
“But who cares? No one needs that because it only costs performance and cannot improve visual quality or sometimes even degrades it.”
…and yet it’s always AMD fanboys who lauded 5-10 fps performance advantage over certain nVidia product(s)…at 60-100 fps range.
Who cares, right?
Also, give examples on where ‘over-tessellation’ (whatever that means…oh right, it means AMD still performs worse than nVidia on tessellation) actually degrades visual quality.
Overtessellation is an arbitrary metric to differentiate between the tessellation performance level of inferior implementations compared to superior implementations.
In practice it is used as an excuse for the inferior implementation of a particular vendor.
Over-tessellation is tessellating beyond what can be seen, thus offering no visual benefit but reducing performance. Nvidia does that and it helps no-one (except their investors)
You’re basing your Async shaders info on anandtechs misinformation. Ryan refuses to change it even though its shown wrong everywhere else. Maxwell 2 has one engine, that can do 1 graphics and 1 compute at the same time. GCN has 8 ACEs that can do 8 queues. + the graphics Queue. 1 graphics + 64 compute if I understand right.
I already covered the claims of ‘over-tessellation’ before in blogs such as this: https://scalibq.wordpress.com/2011/09/13/what-people-like-caveman-jim-still-dont-get-about-tessellation/
The wireframes clearly show that tessellation is not “smaller than 1 pixel” or “beyond what can be seen” or whatever other claims I’ve read over the years. This simply is not true. Tessellation is not blindly maxed out, and indeed, people mainly complain when AMD loses. Note for example Crysis 2. AMD lost in tessellation. However, once AMD introduced the 7970 card, with improved tessellation, they suddenly were the fastest card in Crysis 2 with tessellation (and no cheating in drivers).
How exactly is Ryan’s info wrong then? I’m not sure what you’re trying to say, but it seems you want to base your claims on the number of engines. The number of engines is irrelevant, it is about how well each engine can manage multiple shaders. If designed properly, you only need a single engine to do that. Neither AMD nor nVidia seem to be particularly clear on how their engines and queues actually feed the compute units. One would imagine that there’s no point in having a queue depth of 31 if the entire GPU can only be fed a single compute shader at once.
It seems logical that the queue is used as a ‘first come, first served’ basis, where each SM will grab the next work from the queue and run it async to whatever the rest of the GPU is doing.
Some more background on nVidia’s HyperQ-implementation (although outdated, basically nVidia already had the parallelism for compute shaders, they only had to add the ability to also run graphics workload simultaneously in Maxwell v2 to get DX12 async shader support): http://docs.nvidia.com/cuda/samples/6_Advanced/simpleHyperQ/doc/HyperQ.pdf
Aside from that, nVidia also has ‘Dynamic Parallelism’ where shaders can queue workloads without any CPU intervention, so nVidia has a lot of flexibility in when and how to execute shaders.
In the case of AMD, it is not quite clear why they have multiple engines AND queues, but it seems their design is a lot less flexible. Apparently their queues and engines are very different from nVidia’s HyperQ, and just comparing numbers of engines and sizes of queues is rather meaningless.
Crysis 2 wasn’t over-tessellation it was just stupid tessellation. I didn’t know people complained about the tessellation level . what I remember was that it was being used in dumb pointless ways.
Witcher 3 was the case I was thinking about when it came to over-tessellation
You clearly favor nvidia. When we start seeing devs claim they’ve gotten huge gains from asynchronous shaders on nvidia hardware we can say for sure nvidia has something there. As it is, there’s been nothing but GCN GCN GCN. to the point that people aren’t even sure if nvidia supports it to the same degree. AMDs design allows very fine grained compute so not sure why you would think its not flexible. That’s what everyone has said about it. Why you would interpret nvidias setup as more flexible in face of multiple engines and 64 queues is beyond me.
Anandtech was wrong whether counting queues or engines.
All you’ve said does not show they have the hardware support. You’re talking about potentially related features but lack the actual “yes this is supported”. I’d bet Hilary Clinton’s money they don’t support it as well if at all. You mentioned HyperQ and dynamic parallelism, both things found in kepler which we know does not support asynchronous shaders.
People called Crysis 2 ‘over-tessellation’, just google it. In fact, even in the comments on my blog it is called that.
I ‘clearly favour nVidia’? Why? By pointing out that nVidia has had very advanced scheduling of compute shaders for years now, being used in their Cuda implementations? Which now gets support from DX12 at last?
And yes, it’s all GCN GCN GCN, because AMD is paying developers to promote AMD’s technology such as Mantle and now async shaders (mostly console-related).
Just read http://blogs.msdn.com/b/directx/archive/2015/07/29/windows-10-and-directx-12-released.aspx
Microsoft even mentions “GPU-generated workloads”, which is exactly what Kepler was already capable of, long before DX12 was out.
Or this: https://msdn.microsoft.com/en-us/library/windows/desktop/dn899217(v=vs.85).aspx
Yes, AMD is marketing the shit out of this stuff, but that doesn’t actually mean nVidia doesn’t support it. As MS says:
“Most modern GPUs contain multiple independent engines that provide specialized functionality. Many have one or more dedicated copy engines, and a compute engine, usually distinct from the 3D engine. Each of these engines can execute commands in parallel with each other. Direct3D 12 provides granular access to the 3D, compute and copy engines, using queues and command lists.”
And as you could already read in the Anandtech article, Maxwell v2 does have separate 3D and compute engines (neither nVidia nor AMD mention specific copy queues on the hardware side, so copy operations are presumably put on the compute queue).
We saw the same with OpenCL for example. AMD marketed it a lot, nVidia did not. Yet nVidia had driver support for OpenCL long before AMD did. nVidia hasn’t really done much marketing for DX12 so far, because their DX12 hardware was already on the market long before DX12 was out.
Why bother, when you’re already out-selling AMD 4-to-1 anyway? Better save your marketing budget for the next generation of hardware.
I don’t need a fanboy answer but can you tell me from a gamer’s perspective,by buying which among furyx and 980ti, 2 years from now I regret less for sacrificing quality and performance. I am in a serious confusion here to decide..
I would say the 980Ti is the safest bet:
– It currently outperforms the Fury X in most games
– It has 6 GB of memory instead of 4 GB
– It supports the new 12_1 featurelevel
– It supports HDMI 2.0
Thought I’d revisit these old comments.
I found this benchmark from 2018, which concluded that indeed the 980Ti aged better than the Fury X:
https://babeltechreviews.com/amds-fine-wine-revisited-the-fury-x-vs-the-gtx-980-ti/3/
Based on history you would be better off with the AMD card. For performance right now, nvidia 980ti.
“Based on history”? What does that even mean?
‘Based on history’, AMD was cutting support for older cards faster than nVidia.
AMD was also late getting proper support for OpenCL compared to nVidia.
On Linux, AMD’s proprietary driver performs worse than nVidia’s, is slower on supporting newer OpenGL specs than nVidia, and actually performs worse than the open source driver.
So, yeah, go AMD by all means.
Cutting support for which cards? How many years ago is this?
Doesn’t AMD have better openCL support than Nvidia?
Don’t care about linux.
yeah, will go AMD. Till nvidia hardware looks better and doesn’t come with a risk of being shafted like my recent 970
nVidia still officially supports GeForce 8 series that came out on 2006 on Win10.
http://www.geforce.com/drivers/results/87988
The oldest generation AMD still supports on Win10 is Radeon HD 5xxx that came out on 2009.
You said ‘based on history’, right?
History stated that nVidia had PROPER support for OpenCL on their drivers first.
AMD started supporting OpenCL with their drivers earlier than nVidia, but they were still buggy until a couple of months later after nVidia got it right.
And no, you just don’t care that nVidia have more support on another OS.
Being shafted by the 970?
You mean the whole 3.5GB fiasco?
The fact that applications still can use 4GB on that GPU?
The fact that it’s still a card with a great price/performance ratio for high-end?
I was talking about recent history and performance scaling (290x vs 780, 780ti and titan, now 390x vs 980). I guess you could say 6 yeras from now the AMD cards might not be supported (longer since windows 10 will be around beyond six).
You are being simplistic. The question was about gaming clearly, but even if you want to bring up opencl drivers, who got there first does not matter. Unless you have some reason to think AMD support of openCL will somehow get worse because they didn’t do it as well as nvidia at the start.
I don’t care about linux.
I felt like one of nvidias fools after the truth came out. It also is not a non-issue that the VRAM is split. It can be a problem when 4GB is used. There were also spec errors. Ultimately I did not feel secure in the purchase and wasn’t about to be nvidias little b*t*h like so many are. If they come better I will buy, but a 290x is a better choice (funny enough I can downclock the 290x and get the same performance as the 970 was giving me). The only area nvidia can be recommended is the very high end but based on what has happened in the recent past with performance, I would not bet on that holding for too long. They also have the advantage when power/connectors is an issue in the lower end.
Here’s a quite recent review on a factory OC’d R9 290X.
Single card:
http://www.hardocp.com/article/2015/06/08/xfx_r9_290x_black_oc_edition_4gb_video_card_review/
CF:
http://www.hardocp.com/article/2015/06/29/xfx_r9_290x_black_oc_edition_crossfire_video_card_review/
I really don’t get the ‘funny enough I can downclock the 290x and get the same performance as the 970 was giving me’ part.
Funny, the 970 outperforms the 290x in BF4 even though the 290x uses Mantle instead of DX11.
Those hardocp results weren’t mine so that might be why. had a 290x lightning (1080Mhz) getting the same scores as a 1504 Mhz 970 did.
Doesn’t seem like mantle in BF4 was meant to be a huge performance boost in general. Biggest gains are to be seen in CPU intensive areas so if a benchmark is not targeting that you see so-so gains on the 290x.
http://battlelog.battlefield.com/bf4/news/view/bf4-mantle-live/
The more damning example of “history” is where the 780 now sits in performance. sometimes equaling a 280x
Pffft, guess you need your memory refreshed? BF4 is the poster child game for Mantle, seeing as Dice was AMD’s partner with Mantle, and BF4 was the game used to develop Mantle. So any claim that was made about Mantle, should apply to BF4.
Mantle is just one of many claims from AMD over the years that AMD never quite managed to live up to.
What I have come to realize about AMD partnering with a developer, is that its for the betterment of the game, the developer and the gamers experience. You will not likely see the same kind of skew towards the IHV, you see with nvidias “assistance”. Bf4 is just really well optimized for dx11 and 11.1 like they said. Rest is up to the GPU and Drivers.
Partnering with nvidia could not have produced that game IMO. Not at that level of drool inducing visuals with that performance.
Not sure what you mean by not living up. What they said is there. Better performance under CPU-limited situations. The features that would produce much better performance in regular scenarios, found in dx12, weren’t in mantle.
Okay, it’s time to shut you up now, because you are spreading far too much FUD. You are now comparing AMD technology that simply does not even run on other GPUs at all (Mantle) to nVidia’s add-ons (GameWorks/HairWorks/PhysX), which actually DO run on other systems, just not very well. However, you can disable these features, and the games run just fine on all hardware. And there is even evidence of TWIMTPB-games which actually run fine on newer AMD architectures, even with the ‘nVidia’-features enabled.
What AMD claimed about Mantle, was literally that it was revolutionary, both in performance and in graphical quality. In reality, it is neither (as I have said all along on this blog). Not to mention their other claims, about it becoming available to all programmers, being an open standard, even being open source…
Here, just look at AMD’s own slides to see their claims: http://www.anandtech.com/show/7371/understanding-amds-mantle-a-lowlevel-graphics-api-for-gcn
I wasn’t comparing mantle with anything, I was comparing involvement and resulting product. With or without mantle, the same holds true.
I’m not seeing the issue. All of whats in the slide is just what the API is. Given up to 58% boost in performance in certain situations, what’s the problem?
Plans change. The thing was never even officially released iirc. Always in closed beta and with Dx12 taking the form it has there was no reason to. You seem to just want to nitpick at everything.
What exactly is wrong in those slides?
No, with or without Mantle, the same does NOT hold true. I am getting tired of people like you, who claim AMD is the saviour of PC gaming and nVidia is the Antichrist. In reality, no developer will accept any kind of cooperation with any IHV that will hurt performance/sales for the rest of the market. Especially in the case of Mantle, since obviously at the time BF4 was developed, only about 12% of the entire installed base of GPUs was capable of running Mantle at all. Obviously Dice was going to work hard to make it run properly in DX11 for 88% of the market, with our without AMD’s help. Mantle was and is irrelevant.
And what’s wrong with the slides? Nothing, except that they literally claim “New rendering techniques”, which Mantle never delivered on. It does nothing that can’t be done with DX11, and no game with Mantle support does anything it doesn’t do in DX11 mode.
It also doesn’t quite deliver in the CPU-department either. Some games actually run slower in Mantle-mode than in DX11 on certain configurations, and even in cases where they do run faster, the differences are marginal.
And this isn’t ‘nitpicking’… What you’re doing with the GTX970 is nitpicking. I am simply pointing out that AMD made a lot of promises over the years, that they haven’t lived up to. Should we also get into physics acceleration or OpenCL for example? AMD hasn’t really delivered on those promises either.
Also, Mantle isn’t the only case of AMD ‘changing their minds’… The same goes for DX11 for example. Their initial claims about DX11 were that tessellation was a great feature, and that DX11 had wonderful new features for lower CPU overhead and multithreading. Once nVidia started doing both these things better than AMD, AMD changed their stance around 180 degrees.
And then there’s the CPU-side… like how Barcelona was 40% faster than any Intel CPU, or John Fruehe’s claims about Bulldozer’s performance…
Basically, AMD has constantly been lying to the end-users. nVidia’s GTX970 doesn’t weigh up to that in the least (heck, aside from the placebo-effect, it’s still a fine card).
“The thing was never even officially released iirc. Always in closed beta and with Dx12 taking the form it has there was no reason to.”
DX12 was well underway before Mantle and AMD should’ve known that.
There was never a reason for AMD to jump the gun and reveal Mantle in the first place unless they’re trying to promote something that’s a selling point for their GCN-based products.
The plot is starting to thicken, as a German site has revealed that the GPU in Intel’s Skylake has featurelevel 12_1 as well, and even more features than Maxwell 2: http://www.pcgameshardware.de/Core-i7-6700K-CPU-260905/Tests/Skylake-Test-Core-i7-6700K-i5-6600K-1166741/#a3
Now, it can’t really be coincidence that both Intel and nVidia have support for this 12_1 featureset. Clearly this has been communicated between Intel, nVidia and Microsoft, before the hardware was designed. And by AMD’s own admission, AMD was present through all of this process as well.
Pingback: nVidia does support D3D_FEATURE_LEVEL_12_0 | Scali's OpenBlog™
Will you prise Nvidia for that too?:
Scores in DX12 bench>> http://arstechnica.com/gaming/2015/08/directx-12-tested-an-early-win-for-amd-and-disappointment-for-nvidia/
Maxwell problem with Asynchronous Shaders>> https://www.reddit.com/r/pcmasterrace/comments/3j2wpj/x_post_rpcgaming_nvidia_gpus_do_not_support_dx12/
Nvidia pressure on devs>> http://www.dsogaming.com/news/oxide-developer-nvidia-was-putting-pressure-on-us-to-disable-certain-settings-in-the-benchmark/
Let’s not take Oxide seriously… Their StarSwarm ‘benchmark’ was a total joke, paid by AMD to promote Mantle at the cost of unrealistically slow, inefficient and bulky DX11 code (such as sending extremely long command queues to the driver, knowing this is a potential performance bottleneck, which has nothing to do with DX11 as an API).
I have no reason to believe that their DX12-code is any less AMD-sponsored/AMD-centric and any less unrealistic.
The fact that the DX12 code actually performs WORSE than DX11 on nVidia hardware should be enough of an indication that something funky is going on. Since DX12 is all about improved efficiency, you’d expect DX12 to be as fast as DX11 worst-case (GPU-limited). If DX12 is actually slower, something weird is going on, and it has little to do with the hardware (the DX11 code is unquestionable proof that the hardware can perform better), and everything with the software.
As for this:
Older hardware (be it nVidia, Intel or AMD) indeed does not support async compute (but make no mistake, this is about Maxwell v1, Maxwell v2 does support it… Note also that nVidia support for DX12 goes all the way back to Fermi (4xx/5xx-series) where AMD only goes back to GCN, leaving the earlier DX11-cards from Fermi-era unsupported altogether, which doesn’t expose them to the fact that they can’t do async shaders either).
So it would be unrealistic for Oxide to enable it by default, if it causes a performance penalty (unless that is what they want of course, see above). Because that is not what actual games would do. They would offer the most optimal paths for a range of popular hardware. You don’t just use a feature ‘because the driver says it’s there’. We’ve seen that with geometry shaders for example. They were rarely used in practice because vertex-shader based solutions were often faster. A developer will try a few codepaths, benchmark on actual hardware, then decide what the best path is for a certain family of hardware.
Let’s wait for some more independent DX12-code (and a chance for all vendors to iron out the early bugs and performance issues in their DX12 drivers), and you’ll see that nVidia has no structural issues (as also demonstrated in that other DX12-benchmark, by Futuremark: http://www.anandtech.com/show/9112/exploring-dx12-3dmark-api-overhead-feature-test/3), where AMD is missing some of the newer features. AMD is scared to death of DX12. This whole Mantle and Oxide thing is AMD in full-on panic damage control mode. Their GPUs are outdated and they lack the funds to get back in the race, and they’ve known it for a few years now (Radeon Fury doesn’t even have HDMI 2.0, need I say more?).
Also, nVidia wouldn’t just call out an MSAA bug for no good reason. I don’t see anything from Oxide other than some handwaving and the dubious statement that ‘nothing changed from DX11 to DX12’ (as if that is any guarantee… on the contrary).
I would like to see Oxide produce the actual code, then show nVidia’s criticism on it, and put together a sound argument as to why nVidia’s criticism is not valid.
Until then, I’d take nVidia’s word over Oxide’s. nVidia was actually one of Microsoft’s partners in the development of DX12, and was the first to market with a DX12-capable GPU, so they probably know a lot more about the API’s ins and outs than Oxide does. Most developers aren’t actually all that knowledgeable about APIs and the inner workings of GPUs, and game code tends to have truckloads of bugs.
Given Oxide’s past with StarSwarm, they also don’t have any credibility (once again they are releasing a benchmark of an alleged ‘game’ which is in a very VERY immature state. One can only question their motives for doing so).
This is also complete nonsense. Tier 2 does not ‘require more CPU overhead’ than Tier 3 does. It just means you can’t bind as many resources to the pipeline in a single pass as you can on Tier 3. But still Tier 2 allows far more than DX11, where the limits were never an issue, so Tier 2 should be fine for years to come… Unless… you deliberately want to create unrealistic scenarios just to create bottlenecks on certain hardware, see above.
Of course
Well, the problem is that its not entirely clear the dx12 support for older cards.
I can agree that Oxide benchmarks may be biased, but that is for all benchmarks out there. Benches may be cheated by drivers (look intel) or paid.
I cannot agree AMD shits in the pants. It should be otherwise. The amount of graphic cards that are selling today decreases. While Nvidia posesses major dedicated graphic cards market, its this company which gonna lost the most money in the future.
Amd is not scared of dx12 (haha) They supply gpus for all console manufactures, they should have know how about low level coding. Firstly Microsoft announced that DX12 is coming to Xone. This Console has apparently GCN 1.0 cores so not so bad that it support dx12, huh? (besides, where are pple shouting about limited dx12 in Xbox hhee). Secondly, AMD is contributing to Vulcan, Low level API, that is based off Mantle, thats what can be read here or there.
And finally, back to first sentence of my post. Few Maxwell2 cards support dx12.1, ok. But status of all previous nvidia cards is unknown to support dx12, some slides shows support only 11.x WHILE AMD gcn cards supports at least Dx 12.0. Doesnt look that better know?
In case you didn’t realize, these consoles were already outdated and underpowered at launch.
They aren’t going to be very relevant to what is going to happen on the PC in AAA-titles.
Just like XB360 and PS3 were outdated at launch (DX9-level when Vista/DX10 were on the desktop), and weren’t very relevant to desktop games.
The API is, but the new rendering features and the extra performance offered by desktop GPUs are not.
Nothing is really going to change for XB1 games for the end-user, as Microsoft has stated. DX12 won’t bring a performance boost or new rendering features, because everything was already available via the DX11.x SDK.
It will just be easier to develop with DX12 on both XB1 and desktop at the same time, instead of using DX11.x on XB1 today.
Who cares? The gaming world revolves around DX, not OpenGL/Vulkan. Besides, Vulkan is a standard maintained by Khronos group, where all major vendors have an equal share of input. AMD is nothing special there, and will have no advantage over nVidia, Intel or others.
AMD can be hurt by lack of performance and/or features just as badly as they can in DX12/OpenGL.
No.
What do you mean ‘few’? *All* Maxwell v2 cards support DX12_1
And the status of previous nVidia cards is not unknown at all. Fermi and higher all support the DX12 API. The exact featurelevels of support for each family has been well-documented on the web, basically 12_1 for Maxwell v2, and 11_0 for others.
And no, not all GCN cards support DX12_0, GCN1.0 is only DX11_1.
nVidia actually talks about Vulkan and asynchronous shaders here: https://www.youtube.com/watch?v=8xBuAdnIrJQ&feature=player_detailpage#t=2209
I take it you’ve read this update: https://www.extremetech.com/extreme/213519-asynchronous-shading-amd-nvidia-and-dx12-what-we-know-so-far
Clears up a lot. Basically what I’ve said earlier. Oxide was spreading lies.
I pointed out console gpus and mantle/Vulcan to show AMD was in touch with low level language for quite long time. Console coders usually dont write high level (eg. dx3d) so its irrelevant what high version console supports. Why AMD would be afraid of another low level language as DX12? Maybe AMD PR might be afraid regarding 12_1? In fact, gcn 1.2 was introduced bit earlier than maxwell2, so lack of 12_1 may be a bit dissapointing, but happeed due to earlier start.
By few cards i meant few models 🙂
Regarding real feature levels. This is what i found today https://en.wikipedia.org/wiki/Feature_levels_in_Direct3D So my understanding is: Maxwellv1 supports directx3d12 “runtime”, but not all mandatory features, only high as 11_0 FL? So what advantage is having dx12 API “suport” as hardware is not capable??? Wonder if new stuff like Resource binding Tier 1, UAVs at every pipeline stage, UAV only rendering with force sample count, constant buffer offsetting and partial updates.++ is enough to call “suport for DX12”
Dx12 “base” is like new software on today gpus, dx become like opengl, new FL might be compared to new version of opengl.
And nVidia isn’t? Guess who powered the first Xbox or the PS3?
It’s nothing new. Especially not for GPU vendors, since they always need to write drivers to interface with the hardware directly.
Erm what?
Of course the hardware features are relevant. You can’t write code for features the GPU doesn’t support, no matter what API you use.
Again, I was talking about the hardware features that are unlocked by DX12_1 (and DX11.3).
Such as ROVs and conservative raster. AMD will need to redesign their GPUs before they can offer support for these features. That’s what they have been afraid of for years now. Which is why all this misdirection with Mantle and Oxide is going on.
That’s a lousy excuse. Firstly because AMD has been boasting about Mantle and how AMD is revolutionizing graphics and all that.
Secondly, because AMD recently released a NEW range of GPUs, which are actually still only GCN1.2, and still lack all the DX12_1 features, despite being almost a year newer than Maxwell v2.
Even Intel Skylake supports ROVs and conservative rasterization.
So it is going to take another generation of GPUs before AMD can support this, and catch up with nVidia and Intel. Which is not good, considering AMD has been losing marketshare fast in the past year, due to the success of Maxwell, and AMD is bleeding money.
That word ‘mandatory’, I don’t think it means what you think it means…
11_0 is the minimum featureset for DX12, hence ‘mandatory’. Fermi and up all support it. 11_1, 12_0 and 12_1 are optional featuresets in DX12 (and then there are some features that can be optionally supported even in a lower featureset… eg, you could support 12_0 and conservative raster).
That is why you should leave technical discussions up to us real developers, who understand what they’re talking about. DX12 is an API, support for DX12 is as simple as providing a driver that supports the DX12 driver interface (which implies that you support at least featurelevel 11_0).
If you want to talk about what features the hardware supports, you need to be more specific, and talk about featurelevels of the API.
I’m surprised that people still don’t understand how this works in 2015, because it has been like this since the very first version of DX. You have a baseline of features that you need to support for a certain API version, and then there are optional features.
Regarding your last statement. I know “how it works”. It just that new DX introduced some confusion. Its obvious dx3d 10.0 code(features) cannot be run on dx9 type hardware. dx3d11.0 cannot be run on dx10.1 type hardware. So now we have dx12 which is supported on today cards (dx11). There supposedly should be no 12.0 or 12.1. Instead,out of sudden we use 12_0 and 12_1 therminology. To be more confused, to run 12_x features, we would need dx11.3 or dx12 runtime, and MS itself changed 12.0 12_0 usual usage here https://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx
Going further 🙂 dx11.3 api is almost same as dx12, except the latter have multithreading capabilities and api overhead reduction. So big question is what we actually see in benchamrks and future games. We have four feature levels and we dont know what benchmark test apart from standard dx12 api (which could mean as well as 11_0FL) Well we know at least from oxide about async shaders, but that become another AMD vs Nvidia war, leaving dx feature level irrelevant. Much time will be passed since high dx12 feature levels will be used in games. Having four dx12 feature levels, expect developers will be using the lowest ones.
DX10 and 11 have featurelevels though (originally called ‘downlevels’), and yes, you can actually write code that runs on DX9-hardware with the DX11 API. So that is no different from what DX12 does.
I did a blog on this at the time: https://scalibq.wordpress.com/2010/02/05/direct3d11-downlevel-functionality-how-very-nice/
Before that, earlier DX versions did the same (although they used the ‘DXCAPS’ mechanism instead of featurelevels). I have made an overview of that here: https://scalibq.wordpress.com/2012/12/07/direct3d-versioning-and-compatibility/
As I say, you just don’t know about this. Doesn’t mean it hasn’t been this way for many many years. DX features just weren’t discussed at this level in mainstream media back then, because there was no panicking AMD in search of media hypes.
No, the *API* is DX11. DX12 is a completely different API. DX11.3 just adds some hardware features to the DX11 API that are also present in DX12_1.
Oxide’s claims about async shaders are patently false. nVidia does support them. They may have different performance characteristics from AMD’s implementation, but that doesn’t mean they aren’t supported.
People at Oxide are either extremely stupid, or are extremely devious in making such public claims about nVidia’s hardware.
Again, get a clue. Developers have always supported multiple feature levels in their engines (that’s what all those graphics settings are for in your game! Being able to turn certain effects on/off or selecting different types… Some games even work on two completely different APIs, such as Crysis, with separate DX9 and DX10 renderers).
So, the more feature-rich your card is, the more eyecandy you can expect in games.
Pingback: DirectX 12 is out, let’s review | Scali's OpenBlog™
Pingback: Dahakon, of: laffe personen die mij denken te kennen | Scali's OpenBlog™