You really want us to play newest games with DX12, dont you?
What terrible Driver Overhead in DirectX 11?
Are you just assuming that the poorer performance in DirectX 11 is from Driver Overhead?
While the Dx11 Driver Overhead is typically greater than competing NVIDIA Cards., it's perhaps important to keep in mind that GCN was designed with "Next Gen" (at the time) Graphics APIs in mind...
This results in some necessary Driver Wizardry to get it to execute in a way the Architecture likes., and you can never really hit the same level of "Optimisation" to fully utilise the Hardware.
NVIDIA on the other hand well their Architecture was always designed for said Older Graphics APIs., it still realistically is. This is why even the "Latest and Greatest" NVIDIA Hardware doesn't place nice with what have become the current Graphics APIs.
So that has been a bit of a role reversal that has occurred.
AMD simply bet on DirectX 12 / Vulkan being adopted much quicker (2015/2016 when they were first released) rather than 4-5 years down the line.
It's always going to be a trade off, which if you don't like it... just get an NVIDIA Card for Older Games., and use your Radeon for newer games.
Its over 10 years since release DX11, new games are released still on DX11, and AMD don't want to fix their drivers. AMD doesn't have better DX12 driver, despite pouring resources into it. It just doesn't suck like their DX11 API, so that's why it looks good in comparison.
You know what's actually funny? The worst combination of CPU and GPU is actually both amd cpu and amd gpu. Slower draw calls in amd cpus, paired with driver overhead that puts more strain on the cpu[especially single thread] and you get a much worse performance in DX11 games. I really laugh at AMD fanboys defending this. I was too duped with their weasel words and bought amd cpu AND gpu. Never again, next time im doing my research better before i buy GPU and CPU, and not just look at meaningless performance graphs...
Its over 10 years since release DX11, new games are released still on DX11, and AMD don't want to fix their drivers.
DirectX 11 should've been retired in 2015.
Developers are technically still using DirectX 11., however it is important to keep in mind that they're not all using the SAME DirectX 11.
Now this can get a little confusing and complicated but right now, DirectX 11.2 and 11.3 are used.
In order to explain just how different... I will have to summarise how the Graphics APIs and Drivers Interact.
So there are two types of Graphics API.
Hardware Abstraction Layer (HAL) and Low-Level Virtual Machine (LLVM)
In essence HAL APIs are Implicit by Nature... you're more making suggestions of what you want the end result to be, then the API and Drivers "Fill in all the Steps" before telling the Hardware.
LLVM on the other hand are Explicit by Nature... all they're doing is more-or-less directly translating what you're telling the Hardware into it's Native Language.
Now if we take something, like Multi-Threading as an example here... this actually tends to work very poorly in an Implicit API. Why? Well, consider what Multi-Threading actually is.
You're creating a very large (albeit repeatable) workload, and what you want is the Hardware to break down said workload into smaller tasks and delegate it to all of the available Workers (Cores).
This is fine, if for example the Hardware actually has a Manager for such (i.e. GigaThreading or Hyper-Threading) but when the Hardware doesn't... well then it falls on the Driver to translate said Implicit Threading (i.e. "I want to you delegate this task to all available Threads") into Explicit Threading.
Now DirectX 11.2 does add support for such., but the thing is that it's added as an Extension... so the API itself was never designed to be Multi-Threaded., thus it can only really Thread "Big" Jobs that would make more sense to Thread to Multiple Graphics Processors; as opposed to Thread within a single Processor.
If we take GCN for example., well it's Compute Units are in clusters of 4 to create a "Core"... but it lacks a Thread Manager., so this is the smallest / largest workgroup that can be assigned.
Where-as if we look at any Unified Shader Architecture (Maxwell to Ampere)., these have a Thread Manager; so it can break down the assigned work to the individual Cores more efficiently.
As a result., while both Architectures do benefit from Multi-Threading in DirectX 11.2... you're simply going to be under-utilising any GCN Processor comparatively speaking.
DirectX 11.3 changes this, as it was re-written to be Multi-Threaded; this means that it dispatches smaller workloads that now GCN can better utilise., while the benefits for USA are minimal.
DirectX 12 takes this a step further, because it's Explicit... you as the Developer can keep tabs on every Graphics Cores "In-Flight" and Dispatch whatever Workloads you want, when possible to said Hardware.
This means the Hardware can potentially be used very close to 100%., provided the Programming Team / Engine is making the most of this approach.
The same is true regarding other aspects., because we're not Explicitly being translated to the Hardware as opposed to Phrases being translated (which on GCN would often then have to be further translated by the Drivers in order for it to make sense to the Hardware)... well this as you can imagine reduces overhead and gives us much more control over what the GPU is doing at all times.
A key point to note however, is that DirectX 11.2 and 11.3 are DIFFERENT APIs., even though they will always be listed as the same API.
It's why for example Resident Evil VII / II Remake / III Remake have such impressive DirectX 11 performance., in fact when they first launched it was better than DirectX 12... it's because it's using DirectX 11.3 NOT DirectX 11.2.
This has the benefit of still being Abstracted (Implicit) by nature, making it easier to program; as you don't necessarily really need to be aware of what the Hardware is doing; while many of the performance improvements added to DirectX 12 are still present (in a limited fashion).
You can of course still squeeze better performance via optimisation and hardware utilisation from DirectX 12., and this is especially true in regards to the 1% Low Frame Times. There are also various things you can do that are simply not possible via an Implicit API, which DX11.3 is still using; but generally speaking you can get very similar performance "Out-of-the-Box" on any Hardware on it.
Now why doesn't AMD fix this? Simple, they can't.
GCN was developed as a DirectX 11.3 (DirectX 12) Architecture... it works in a way and lack some key hardware elements that rely on more Explicit Control to make the most out of it.
While AMD could of course add to the Drivers to improve how Command Buffers are translated to the Hardware to better utilise it... this would come at the cost of more Driver Overhead / CPU Utilisation.
Conversely, making it more lightweight... means that the Hardware (GPU) Utilisation would drop and you'd loose performance.
As it stands the Drivers are about as good as they're going to get, to provide that balance between Overhead and Utilisation to provide the best performance possible on DirectX 11.2.
You know what's actually funny? The worst combination of CPU and GPU is actually both amd cpu and amd gpu.
A big part of that is Developer Support.
If Developers utilised the AMD SDKs, such-as AGS more often... then you'd find the utilisation of unique features to AMD Hardware actually ends up quite beneficial.
That said... AMD can't FORCE Developers to utilise their SDKs., and given most will opt to use Gameworks (NVIDIA's SDK); well this situation generally gets worse as those are explicitly designed to NOT utilise anything that would allow favourable performance. AMDs on the other hand are more Hardware Agnostic, and being open source can be extended / improved to support Native Hardware "Features" should a developer chose to.
You can't do that with Gameworks, as they are what is known as a "Black Box" Solution; you have access to the API to utilise them... not the actual library code that performs said tasks.
Slower draw calls in amd cpus
Part of that is that AMD CPUs simply have Lower Clocks than their Intel Counterparts., which can be offset by proper support by Developers... but few are willing to put in the extra time and resource to make that happen.
Keep in mind that MOST "Commonly used" Libraries., are optimised for Intel Processors... but aren't for AMD Processors.
You ever wonder how Console Developers were able to squeeze clearly better performance out of what was a terrible Architecture compared to PC? It's because they took the time to optimise it, as they had little choice other than to do so.
On PC, most Studios tasked with Porting rarely bother.
paired with driver overhead that puts more strain on the cpu[especially single thread] and you get a much worse performance in DX11 games.
DirectX 9.0 - 11.2 Games., but even then the Driver Overhead actually isn't really a particularly big bottleneck.
What can give a false impression is how NVIDIA Graphics Cards (typically) run better on Intel Processors., but that's misleading... the reality is that NVIDIA are quite petty.
Back when Ryzen first launched., there was an oddity that Tech Reviewers kept drawing attention to; where-in AMD GPUs were running better on Intel Processor (which makes sense, as they had MUCH higher Frequencies and lower Latency) while NVIDIA GPUs were running better on AMD Processors...
Why did this happen? Well because NVIDIA was having a disagreement with Intel., so they removed the Intel Optimisations and add Ryzen Optimisations in their Drivers.
Right now, NVIDIA is "Concerned" with AMD' rising Market Share and potential Dominance., so we've seen this situation reverse again.
Even still., this isn't the main reason for the performance difference.
Driver Overhead accounts (at most) for maybe a 2-5% Loss in Performance and this is a "Worst Case" scenario., typically it's less than 1%... meaning it's unimportant for anyone other than Developers.
Architecturally however., you can see up to a 45% Performance Difference on GCN in DirectX 11.2 (or earlier) because that's the peak hardware utilisation that can be achieved.
It has very little to do with the Drivers and everything to do with how the Architecture and Graphics API work., specifically to what you (as the Developer) are trying to get it to do for your Engine.
Typically you can dramatically shrink said performance gap by taking a different approach, but again... that would take more time and resources. Most Developers don't see it worth it given AMD' Market Share., not enough End-Users are going to be affected to warrant doing it.
I really laugh at AMD fanboys defending this. I was too duped with their weasel words and bought amd cpu AND gpu. Never again, next time im doing my research better before i buy GPU and CPU, and not just look at meaningless performance graphs...
And I find those who spread misinformation as fact due to how grossly uninformed they are to be exceptionally frustrating., as it give a false impression of AMD and an unrealistic sense of what they can do to improve their Hardware Performance; as if they just can't be bothered to.
Keep in mind that ALL GCN Hardware has seen up to a 15% Performance increase from Driver Optimisation since they were launched. Just because this isn't "Good Enough" for you, doesn't mean they can't be before to resolve something that YOU personally perceive as a Software Issue; which is in-fact a Hardware limitation.
You say you were "Duped with their Weasel Words" ... but what exactly did AMD say that had you "Duped"?
AMD has never claimed incredibly DirectX 11 performance.
All I've seen them showcase is the improvements to close the performance gap in popular titles as best they can... and now Architectural improvements have provided such.
Performance Graphs typically do showcase a good indication of how a Game will play., but it does of course depend on what Combination of Hardware you chose.
Take 1% Lows for example... well Low-End CPU / APUs tend to lack or have greatly reduced Level 3 Cache; this translates to Micro-Stutter in A LOT of Games.
Again we're talking a Hardware Issue, not a Driver Issue.
Developers can work around this... but again most chose not to, which is odd given most people have "Low-End" Hardware.
As it stands you're just blanket blaming AMD here., and specifically their Drivers.
While, I'll fully admit that they've had some stability issues the past few Generations (Polaris, Vega and Navi)... performance issues typically are VERY rare occurrences within AMD Drivers.
You entirely focus on blaming Drivers Overhead., well I don't even know where this could've come from; especially if you're "not looking at meaningless performance graphs"., as the Driver Overhead Benchmark in Futuremark, showcases just how small the overhead is on all Drivers today.
But without such., you have ZERO basis for your arguments.
Provide the Data to backup your claims, otherwise these are just baseless claims.
Retrieving data ...