Have nobody noticed you can't force (16x) anisotropic filtering in dx12 with amd? Meaning if the game don't support it, and believe it or not, still happens anno 2021, nothing can be done. Dx12 titles having no af; -Far Cry 6; -Death Stranding; -Some Assassins Creed games. I've send a ticket requesting the feature, but one person won't make a change. Amd recently asked users what they would seen in the radeon software, so maybe they consider it if enough demand. So you find it important, contact Amd about it.(bugreport).
Even that tooltip is wrong, it works with D3D11. I suggested implementing it for D3D12 several times several years ago, 0 response.
on DX12 a lot things are not possible globally due how D3D12 leave the developers to customize how such properties are stored.
so you wish the driver keeps track of every D3D12_SAMPLER_DESC on every command list and command queue type on every thread of application? also it is apply then to textures that are handled by SRVs that are stored in a custom way by application.
It works without issues in CoD Warzone on Nvidia (main terrain ground texture has none or just 4x AF, wtf), and it also works in lots of games without issues with Vulkan on Linux (be it directly via RADV or libstrangle). Concerns are misplaced here. If it doesn't work with a particular game, one can simply turn it off, and there also is some kind of blacklist in the NV driver for some known cases...
Yeah, that's not how it works. Driver doesn't keep track of anything, D3D12_SAMPLER_DESC for AF is one of a handful of types that are persistent and not reconfigured every command submission. besides, the game is responsible for its usage of D3D12_SAMPLER_DESC not the driver, the hardware doesn't even know what D3D12_SAMPLER_DESC is by the time a request for the hardware to apply a skew filter on planar surfaces the APIs call has been decoded to native assembly in the UMD and all that is doing in the end is telling the hardware to set the filtering engine a specific way. If the game has no AF at all (even as a hidden non configurable setting) D3D12_SAMPLER_DESC isn't used for it at all, the driver AF filter is applied completely agnostic to whatever the hell the api wants At the end of the day, D3D12_SAMPLER_DESC is just the application interface telling the driver how it wants the filtering engine set, the driver doesn't require it at all to enable and force its own AF
So you wanna a driver settings that dumbly force apply a AF filtering by user on ALL surfaces in a threadsafe way? Amazing thing on an API that is meant to leave the programmer the concurrency synchronization and how the runtime and driver are fed. Because that's you can do if you ignore the sampler descriptors are telling the runtime (and so the driver). Btw, only D3D12_STATIC_SAMPLER_DESC is persistent since it is not part of the root sign arguments. But by performance point of view this could be a thing on d3d9 old games, not on current modern games, where modern render to texture and other crap would cause a gazillion of performance an quality issues forcing an AF filtering everyehere. It could be useful to track surfaces where there is applied a AF filtering and only overwrite the AF filtering on those surfaces... But yeah, we have more freedom on client side now, so driver must just do what the app and runtimes tell it.
You don't have any idea how AF is actually applied do you? its not toggled with every command submission, once its on its persisted on and all the directx feature is doing is telling the driver it wants it on and at what level. It's not a programmable capability, the filtering engine in the card is static, drivers could nerf the level of filtering before it reached the hardware but you couldn't change how the hardware performs it by changing the software. Thread safety has no part in the matter, its not a post process or programmable filter that is applied per frame The hardware filtering stage of the pipeline is either off or at a value between 2 and 16x levels, its one of the last legacy fixed function aspects of raster graphics left. https://fgiesen.wordpress.com/2011/07/04/a-trip-through-the-graphics-pipeline-2011-part-4/ https://www.extremetech.com/computing/51994-the-naked-truth-about-anisotropic-filtering/2
Nobody is asking a programmable filtering for something that is implemented in a static function. It is NOT about enabling that stupid filter. It's about be smart enough to NOT apply everywhere for PERFORMANCE reason or to NOT alter the expected result. And yes, in modern games it costs. So if you don't wanna apply it EVERYWHERE you must do some kind of selection. The matter is: now is DIFFICULT to do that selection. Apply it on selection (like ignoring some particular texture that may be identified by reading the srv and sampler heaps) is not easy. That's all. The same reasoning is applied to every crap driver settings that would overwrite the application and they are less years by years and with newer API: too complex to do it in a smart way. Of course, clearly you don't have any idea how to discuss with people without insulting them. And you aren't so brilliant for sure otherwise instead of spreading your ridiculous wisdom you would be at AMD at fixing this crap. Oh wait, you are not.. Added to the ignore list.
The hardware already does this, always has. It applies to isotropic planes, doesn't cause a performance impact except where the developer has failed basic culling and kept invisible objects in the pipe. The developer has no control over what surfaces have AF applied asides from Texel weights, Min/MaxAnisotropy is applied as a hint for the hardware configuration, the only Filter related aspects of Sample_Desc that developers can set at texture level is *Linear and mipmapping states. I'm done with RTG limitation apologists.
