Are you sure you are remembering this correctly? AFAIR, you always had the option from X1k-series onward to switch from default to HQ AF on ATi/AMD
IHV Preferences, Performance over Quality? *Spawn*
- Thread starter 3dcgi
- Start date
Silent_Buddha
Legend
Yes, the default on AMD was closer to reference AF than NVidia's until a few years ago. But reference quality, while producing sharper textures results in more shimmering.
Regards,
SB
gamervivek
Regular
It was more than that, AMD had higher LoD so the investigation of AMD's shimmering AF ended up being one into nvidia's blurriness.
https://forum.beyond3d.com/threads/...af-filtering-broken.49106/page-9#post-1468349
https://forum.beyond3d.com/threads/...af-filtering-broken.49106/page-9#post-1468349
DavidGraham
Veteran
That's the incorrect interpretation of what happened, Most major sites reported the shimmery and faulty look of AMD's AF. AMD admitted to the problem and partially fixed it via driver, before completely fixing it via hardware later on.
http://www.gpu-tech.org/content.php...adeon-HD-6800-and-Geforce-400-series-compared
http://www.anandtech.com/show/3987/...renewing-competition-in-the-midrange-market/5
Last edited:
Well a bug in hardware was a bug on hardware, nothing to do with "sacrifying quality for performance. "
- Tesselation setting on driver ( who is not set as default ), is a way for user to counter the will of some developpers ( as Ubisoft ) to follow Nvidia on using some incredible high level of tesselation for put the performance of AMD GPU's on the knees.. Way higher that is possible to see on a monitor ( more than 1 triangle / pixel ). I know a lot of Nvidia users who will have love with some games to have this settings ( specially when they was just launched ), and can use it for let say, Hairwork.
- We could still put here some litttle things as the numerous time where games drivers was forcing different quality on Nvidia gpu's. ( starting by AA back on Tom clancy HawX).. or when Nvidia was use lower mipmap . ( back on Geforce 4TI? cant recall ).
We could even speak about full HDR who was not supported fully a long time on Nvidia gpu's or even Video/monitor output with 8bits dithering on Nvidia gpu's.
- Tesselation setting on driver ( who is not set as default ), is a way for user to counter the will of some developpers ( as Ubisoft ) to follow Nvidia on using some incredible high level of tesselation for put the performance of AMD GPU's on the knees.. Way higher that is possible to see on a monitor ( more than 1 triangle / pixel ). I know a lot of Nvidia users who will have love with some games to have this settings ( specially when they was just launched ), and can use it for let say, Hairwork.
- We could still put here some litttle things as the numerous time where games drivers was forcing different quality on Nvidia gpu's. ( starting by AA back on Tom clancy HawX).. or when Nvidia was use lower mipmap . ( back on Geforce 4TI? cant recall ).
We could even speak about full HDR who was not supported fully a long time on Nvidia gpu's or even Video/monitor output with 8bits dithering on Nvidia gpu's.
Last edited:
I was very specific in my statement. I started the comparison from the point of the introduction of unified shaders. Those events predate this starting point. What matters is this: in the past 7 years NV has been more keen on quality than AMD. AMD GPUs didn't exist until after the unified shaders era, before that they were ATi, with different agendas and goals.
Glad other users were quick to correct all these wrong statements, clearly the like system in this forum is getting abused for it to allow posts with wrong information to be more visible than posts with actual facts. Sad thing to happen really, especially in Beyond3D.
They were happy and content to use an ever lower form of AF in the presence of this bug, eeking out little extra performance along the way. They only corrected and admitted it after receiving so much flak from the community.
The developers designed their games with this much tessellation, they should be the one who retain the final say of how their code is processed. You open a can of worms if you allow IHVs to play around games code in this frank and preposterous way. If NV introduced a slider to control the hair strands in Tomb Raider's TressFX implementation instead of working with the developer to optimize it, everybody would be up in arms about it. The right way is to work with the developer not circumvent them and carve your own way and claim it's best.
Thank you all.
The quotes in your comment were actually mainly about the other problem, banding. It was addressed in the Radeon HD 6000 series and again later in the third generation GCN. Nevertheless, even the Fiji was not completely free of the problem. Some examples can be found by searching for "scali blog dodecahedron anisotropic".
Regarding the texture aliasing (shimmering) problem, I agree that it is not a case of the Radeon producing a reference-like image as has been claimed. Perhaps some people have only tried the "tunnel" test in the 3D Center Filter Tester, but the problem is much easier to see on a planar surface. In that test there are distinct bands of shimmering on a first-generation GCN device, while some areas are (almost) free of shimmering. The reference implementation does not behave like that with any LoD bias setting. In that test program the Fiji also produces more shimmering than the reference implementation or a Geforce (with the best quality texture filtering settings) but much less than an older Radeon card.
The can of worms was opened long time ago. As a long time graphics programmer (since DX5) have seen drivers doing much worse things than clamping tessellation level...
Forced MSAA: Breaked first deferred shading implementations (we had DX9 deferred renderer in 2007). The driver forced MSAA to g-buffers and resolved g-buffers (blend values like colors). That doesn't make any sense.
Forced anisotropic filtering: Can break filtering in special cases such as texture atlases (our old terrain renderer, custom virtual texturing). Developer tested with the filtering mode they programmed, but the driver forced anisotropic and seams appeared.
Forced post AA: Seen bug reports of standard windows program's text looking blurry. WPF for example renders with DirectX. User had enabled post AA from driver settings, but that also affected other DirectX programs, not only games.
Forced "disable negative mip bias": Negative mip bias is important for temporal AA, as it mimics supersampling (over multiple frames). Checkerboard rendering has similar needs. If negative mip bias is disabled from driver, these techniques result in blurry textures.
Optimized render target format: Change RGBA16f to R11G11B10f. Breaks if you encode data to floating point sign bit. Breaks if you use alpha channel for anything.
The ugliest thing is that IHV drivers do these changes completely behind the developers back. If you query DirectX API to confirm you render target format, MSAA/aniso mode, etc, the API lies to you. It tells you that everything is like you expect, but the driver has silently changed things behind your back and there's absolutely nothing you can do to detect the situation and program a fix. Customers will obviously blame you and not NVIDIA/AMD. You just need to wait for the IHVs to add custom profile to your game. Look luck with that if you are a small indie developer.
Addition: This technique calculates bezier curves using the GPU filtering hardware. Imagine using a technique like this, and IHV driver forces optimized texture filtering...
http://blog.demofox.org/wp-content/uploads/2016/02/GPUBezier2016.pdf
Last edited:
What is gamework so ?
TressFX was only use tesselation on a low level, no need for Nvidia to optimize for it, And tressFX 2.0 dont even use anymore tesselation..
TressFX have been released secretely because it was presented at the same time of the launch of their new GPU's. It was more a marketing tricks than anything else. If developpers have shown, the code to Nvidia, Nvidia will have launch his own Hairwork for DX games just some weeks, month before. The point for AMD was to show it in a games, instead of a demo ( as hairwork CUDA was ).
During a long time peoples have tell that AMD/ATI was show many thing in demo, but it was not applied to games ( look tesselation showed in 2009 HD2900XTX demo ).. .. Hence why Mantle and TressFX have been demonstrated directly in games ( BF and TR ).
Last edited:
My statement, which spawned this thread, was saying AMD has no policy of favoring performance over quality. This doesn't mean there can't be individual examples of favoring on over the other. There is no official or unofficial corporate policy to favor either.
Lanek, TressFX never used tessellation.
AMD has better bilinear texture filtering quality than Nvidia. I was debugging this a few years ago in a 3d volume texture (SDF) raytracer. On Nvidia the surfaces looked "voxelated" instead of smooth. This was GCN1 vs Maxwell.
This is the same problem, but for 2d texture sampling:
http://www.iquilezles.org/www/articles/hwinterpolation/hwinterpolation.htm
I tracked the problem, and it seems to be low precision bilinear/trilinear blend weight calculation. Texture format (8/16/32 bit, float/unorm) or texture value's scale doesn't affect this (so texel blending isn't the culprit). This problem is only visible when you drastically "zoom in" to a texture. Not a problem with standard 2d textures with mipmaps. But in case of 3d texture based geometry and free camera movement (can go close to a surface), this problem is real. Heightmap ray tracers are also affected (see link above). It can similarly be seen in filtered lookup textures that are (for any reason) stretched to cover big area of screen/world. For example: light fall off ramp. 32x1 pixels. Move close to light source -> 32 pixel lookup gets stretched over 4K or more pixels -> bilinear filter banding.
In case of single channel 2d textures (heightmaps), custom filtering is pretty good way to avoid this. Use gather4 to fetch 4 texels at once (much faster than Inigo's example above). This is almost as fast as hardware filtering. Unfortunately same trick is not possible for 3d textures. Gather4 is only supported for 2d textures. You need to do 2x2x2 = 8 texture lookups. I have measured that custom filtering makes volume ray tracing roughly 5x slower compared to hardware filtering. Alternatively you can use 2d texture arrays and store 3d data there. This supports gather4. You need two of them (one per Z slice). This is still more than 2x slower than hardware filtering. The main reason is that 2d texture arrays have worse memory locality than 3d volume textures. Each slice is separate. Two gather4s never share cache lines.
DirectX mandates tight error limits for float math and triangle math. I just wish the requirements for texture filtering maximum error were tighter. The days are long gone when textures only stored 8 bit LDR color data. Float data and 16 bit integer data are common. Data represents surfaces, curves, etc instead of colors. Precision issues in weight calculation are much more noticeable.
This is the same problem, but for 2d texture sampling:
http://www.iquilezles.org/www/articles/hwinterpolation/hwinterpolation.htm
I tracked the problem, and it seems to be low precision bilinear/trilinear blend weight calculation. Texture format (8/16/32 bit, float/unorm) or texture value's scale doesn't affect this (so texel blending isn't the culprit). This problem is only visible when you drastically "zoom in" to a texture. Not a problem with standard 2d textures with mipmaps. But in case of 3d texture based geometry and free camera movement (can go close to a surface), this problem is real. Heightmap ray tracers are also affected (see link above). It can similarly be seen in filtered lookup textures that are (for any reason) stretched to cover big area of screen/world. For example: light fall off ramp. 32x1 pixels. Move close to light source -> 32 pixel lookup gets stretched over 4K or more pixels -> bilinear filter banding.
In case of single channel 2d textures (heightmaps), custom filtering is pretty good way to avoid this. Use gather4 to fetch 4 texels at once (much faster than Inigo's example above). This is almost as fast as hardware filtering. Unfortunately same trick is not possible for 3d textures. Gather4 is only supported for 2d textures. You need to do 2x2x2 = 8 texture lookups. I have measured that custom filtering makes volume ray tracing roughly 5x slower compared to hardware filtering. Alternatively you can use 2d texture arrays and store 3d data there. This supports gather4. You need two of them (one per Z slice). This is still more than 2x slower than hardware filtering. The main reason is that 2d texture arrays have worse memory locality than 3d volume textures. Each slice is separate. Two gather4s never share cache lines.
DirectX mandates tight error limits for float math and triangle math. I just wish the requirements for texture filtering maximum error were tighter. The days are long gone when textures only stored 8 bit LDR color data. Float data and 16 bit integer data are common. Data represents surfaces, curves, etc instead of colors. Precision issues in weight calculation are much more noticeable.
Interesting tidbit, but irrelevant to this discussion about quality. There are no games where NV suffer quality wise due to this shortcoming. Whether this is due to NV's own guidance, developer intervention or both, the final result is the same between AMD and NV. On contrary to AMD's faulty AF situation, which affected many games already.
Agreed, What's uglier is IHV's doing that plus IQ reduction in games, this practice is condemned in the past, and will continue to be condemned in the future, no matter the perpetrator.
Thank you.
TressFX doesn't use tessellation, I merely inserted it in an anlogy. You can replace it with whatever effect you deem fit.
I appreciate your clarification. I didn't mean to imply AMD's having a performance first policy. It just seems that -recently- they are sometimes less concerned about upping the image quality aspect, compared to the competition, whether it is feature wise or standard wise.
Much respect and thank you all.
Ike Turner
Veteran
I would guess that rasterizer ordered views (ROV) is harder to implement for AMD, since their ROPs are not directly connected to L2 cache (there's no coherency between ROP output and input data). Vega will change this and also introduce new tiled rasterizer. I would expect Vega to have ROV support. I'd guess that conservative raster and volume tiled resources would have been easy to implement, but since DirectX is all-or-nothing style API (12.1 requires all three), it would make no sense to implement 2/3 of these new features. Similarly Kepler wasn't DX11.1 compatible because they missed TIR and UAV output from vertex shader. ATI had the same problem with geometry instancing. It was SM3.0 feature and ATI lacked vertex texture fetch.
AMD is the only IHV that has half rate RGBA16f bilinear filtering. Both Nvidia and Intel have full rate RGBA16f bilinear. We don't obviously know AMDs reasoning, but it is still worth noting that AMDs bilinear filtering has higher image quality and lower performance compared to their competitors. This particular tidbit seems to contradict that AMD always prefers performance over quality.
Anisotropic filtering is an approximation. It doesn't converge to perfect integral of (sub-)texels covered by the pixel. The best balance you can achieve results in slightly bit of shimmering and blurriness (depending on case). IHV preferences between reducing either one (and increasing the other) has been slightly different. Of course we have seen bad approximations as well, but not on modern GPUs. Perfect anisotropic filtering is a pointless goal anyway, because developers are still using it to filter normal maps and other non-linear data. No matter how perfect integral the filtering hardware produces, the result is still wrong, since you can't average normals and expect a good result. You will still get shimmering specular highlights. In modern rendering pipelines using temporal supersampling, you'd actually want to have random noise instead of softer result, as long as the noise contains statistically meaningful data (for example a random single sample from aniso).
DavidGraham
Veteran
It's obvious he meant quality degradation wise. And in that respect I agree with his argument. This isn't a discussion about hardware capabilities, as each architecture has it's own hardware shortcomings and pitfalls that require some software circumventing. The original premise is about IHV's negligence or degradation of quality standards.
Yeah, I know of this argument. Several developers believe there is no perfect or agreed upon way of doing AF. DirectX doesn't impose tight specifications for it, however customers and IHVs can agree upon certain quality guidelines on the grounds of common sense. Shimmering is not a good way of doing AF, it's ugly and distracting. In fact before this hardware AF bug, AMD used to have an excellent AF implementation. However after the bug, they resorted to a lower form of AF (quality wise). Then made a U turn and changed it back after a couple of generations after the bug has been fixed. Clearly they share the same views as the rest of us, regardless of their past AF stumbling.
Anyhow I gotta admit, this discussion has been most illuminating, thanks sebbbi, and Neumann.
FL12_1 requires only two features, Conservative Rasterization Tier 1 and Rasterizer Ordered Views:
http://www.pcgameshardware.de/screenshots/medium/2015/03/DX_12_Feature_Level-pcgh.jpg
https://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx
And since there are a lot of features you can request as standalone without the necessity of using a higher feature-level it's not an all-or-nothing API, you can use Conservative Rasterization or ROVs on hardware which only supports FL11_1.
Obviously it would be better if AMD would support both features (and more).
And I like to be nitpicky here, Kepler does support DX11.1, Kepler doesn't support FL11_1.
I always thought that tiled resources tier 3 was required for feature level 12_1 (but it seems that tier 2 is only required). Might be because these 3 features were always marketed together. Doesn't really matter in practice since all FL 12_1 GPUs support all three features. Too bad that stencil ref output is not supported by Nvidia. Both AMD and Intel support it.
You can't use FL 11_1 features on Kepler. If you query for 11_1 feature support, you get nothing. Even those features that are actually supported by the hardware cannot be used. DX 12 seems to be different than previous DX versions in this regard. All the new features are marked "optional" for FL 12_0 and FL 11_1. Doesn't really matter in practice since there's no existing FL 12_0 or 11_1 hardware with support to new features introduced in FL 12_1. There's also the problem that DX 11.3 API is required for most of the new FL 11_1 and FL 11_0 optional features, and 11.3 API doesn't exist on Windows 7. So these new optional features can't be used on the most important gaming OS.
Last edited:
An integral of the texels inside an area does not give the best image quality, either. It needs to be multiplied by a weight function and the integration area must be large enough. Although perhaps that is what you meant by "covered by the pixel", allowing for non-constant and even negative coverage. There are indeed tradeoffs even in exact filtering, mainly between frequency response and spatial considerations. Filters with steep frequency response (such as sinc-like) can cause ringing artifacts near sharp edges, which is highly undesirable.
Regarding the idea of the IHVs balancing between shimmering and blurriness, that is necessarily a fact but I do not believe that it was the cause of the difference between AMD and Nvidia. At worst, the old Radeons gave an output where a texture shimmered in certain bands but was temporally stable outside those bands, the change between those bands being abrupt. No one could consider shimmering acceptable in certain bands but not in others. If such a behavior could not be avoided, at least the boundary between shimmering and non-shimmering areas should not be razor sharp, creating a false illusion of a faint object. And let us not forget that it was actually AMD whose filtering was blurry with the first drivers for the GCN Radeons when using standard (default) filtering quality. They did fix it in drivers (as reported in Tom's Hardware), although for some time the blurry AF was still used for 3D Center Filter Tester. IIRC, even with the excessive blur of the first drivers the Radeon still produced a bit more shimmering than a Geforce, at least in the filter tester.
To explain me better: a pixel is a rectangle. The projection of the rectangle in the UV space forms a trapezoid (assuming the surface is planar). You want to take a sum (integral) of all the (sub-)texels inside this trapezoid and divide the result by the area. IIRC hardware anisotropic filtering simply takes up to N trilinear samples along the UV gradient using up to -log2(N) mip bias. N is basically log2 difference between U and V gradient. This is not trapezoid, but a pretty good cheap approximation.
Yes, older hardware had trade-offs with filtering quality and we had various driver bugs (whether bugs or intentional, who knows). Both ATI and NV had problems. Nvidia had "brilinear" filtering: http://alt.3dcenter.org/artikel/2003/10-26_a_english.php. Both had questionable AF quality (angle dependent optimizations). We don't still know whether the AMD shimmering was a hardware bug or intentional optimization to improve performance. Blurry output usually means lower resolution data is used = faster, but shimmering is harder to judge.
Similar threads
