Ags Driver Extensions Dx11 Download

[Nakia Schaf]

AGSis a helper library designed to provide a much clearer view of the GPUs in the system and the displays attached to them. It also exposes the ability to query each display for HDR capabilities and put those HDR-capable displays into various HDR modes, as well as access extensions for DirectX 11 and 12 that provide additional functionality and possibility for optimisations.

Version 5.2 adds support for app registration in DirectX 12. App registration lets you give more information about your game or application to our driver, which can then use that (ideally unique) information to better support the game or app if we need to make driver-side changes to help things run as efficiently and correctly as possible.

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.

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...

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.

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.

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.

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.

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.

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.

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.

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.

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...

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.

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 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.

You give informative information, but I have almost always seen you dismissing other AMD user's posts. This doesn't help in improving the AMD experience, people are complaining about these issues because they want a better experience on AMD, and if it is dismissed it will not be improved upon.

It doesn't help to get too technical on the problems and take on other people's knowledge or authenticity, when someone talks about driver overhead, it can mean a lot of different things for that person, but it comes down to the under-utilization of one's hardware.

And I understand that there are hardware limitations in GCN that has to be specifically developed for, but there has been cases where there has definitely been unacceptable issues introduced or reopened.

I have given a lot of proof how Unreal Tournament 3 has had a 50-60FPS hit in low FPS scenarios going from 16.6.2 to any newer driver causing 29FPS gameplay in said scenarios where it was at 89FPS. Now this might have been due to a Hotfix or Optimization removed, but why do that? At least make the optimization available for download if it doesn't fit the current specification for people who want it.

Furthermore, if I have not reported shadow bugs in RAGE (2011 game) it would not have been fixed, and thankfully to the OpenGL Team it has been fixed, the fact is this was also a issue/problem persistent by the driver; maybe it wasn't the drivers fault; but it has been fixed nonetheless which is necessary for gamers to have an enjoyable experience with AMD.

And I understand with different versions of DirectX11 also OpenGL, but DirectX12 doesn't always fair better CPU-wise if they don't make things asynchronous enough; good example, Total War Warhammer and Serious Sam 4 where I have slightly better FPS and stability in DX11.

Some hack or wrapper must be made for AMD users; even as a 3rd party option or a hotfix download. It is definitely not all blame on architecture since some of the same games perform better on the same XBOX PS4 architecture with higher graphic settings than on PC. Good example, Wolfenstein The New Order and Old Blood (OpenGL games) at 60FPS.

I know if a game has been coded in a certain way a Wrapper doesn't help a lot, but Nvidia made a hack in DX11 for their architecture with Command lists and Context Deferring even if some games didn't support it, AMD must be willing to do something similar with their Compute Units to better disperse load on the GPU or however a hack/wrapper would be able to improve utilization even if it doesn't conform to spec.

Because otherwise it's just a blame game, blame it on the Game Devs or blame it on the driver devs, someone must do something, they should have teams testing for these Quality LOW FPS scenarios in gaming and find consensus as simple as that.

It doesn't help leaving the knowledge battles between the end-users of "who knows the flaws and reasons better than eachother". It's not about who has more knowledge, but consensus, resolution is NEEDED. Ask the community to help create hacks in the driver and oversea it by open-sourcing some things.

In response to my comment just now, according to my 3DMark tests AMD still has a lot more DX11 overhead than my GTX 1060, but this is not the point, because some old DX 9/11 games fly to the sky with AMD and other is a horrible mess, like I said, find consensus and introduce hacks/hotfixes or open source help from the community and make it stable.

3a8082e126