NVIDIA's New FXAA Antialiasing Technology @ [H]

FrgMstr

Just Plain Mean
Staff member
Joined
May 18, 1997
Messages
55,634
NVIDIA's New FXAA Antialiasing Technology - NVIDIA's FXAA technology debuted in Age of Conan, and was recently found in Day 1 Studio's F.3.A.R. We'll look into FXAA and tell you what it is, what it does, and what gamers can expect out of it. We were surprised by the results, and we think you will be too. Will it be methods like this that replace traditional AA? We certainly hope so.
 
Question that I didn't see covered in the article:

How bad are the effects of FXAA on in-game text, and other similar overlays?

Any time text (or HUDs in general) are not a major part of the game interface, I love MLAA, but in any game where text is a regular component, the HUD is more complex, etc. the negatives far outweigh the positives.

I would imagine that as they're similar postprocessing effects, they have similar degradation on the quality of text and other sharp-edged GUI overlay elements, but as I've not seen for myself, I don't want to assume.
 
That is a good question. FEAR 3 does not really make extensive use of text as a UI component, so it is hard to say based on what I've seen with this game. I know exactly what you are talking about. Civ5 is a good example of a game for which MLAA is not ideal. Even with the FRAPS counter, I can see MLAA smudging it up, but I did not notice it with FXAA.

It is likely, however, that the FRAPS counter is inserted into the frame after FXAA has done its thing, so there would be no degradation.

We'd need a game like Civ5 to support FXAA to check this issue for sure.
 
I've seen FXAA as an option inside of Nvidia inspector. And it did do AA on some games I tried, but tonight I'll post some screenshots showing the difference.
 
You know whats funny, it even works on AMD cards. While MLAA kills performance and doesn't work with Nvidia cards. Seems Nvidia wants everyone to enjoy games more :)

Awesome review, can't wait to see the screen shots when I get home again(This laptop+internet is just too damn slow and small for it)
 
I've seen FXAA as an option inside of Nvidia inspector. And it did do AA on some games I tried, but tonight I'll post some screenshots showing the difference.

Interesting, I'm going to experiment with it in a few titles myself, I'm curious now ;). I hadn't realized this feature was in-place/starting to become available in titles at all until I saw this article :D.
 
I run a 6990 and I find the appearance of Morphological and FXAA to be pretty close in games. Where it gets screwed up is when running Morph in Windows, and you go to Email for example, the text is almost unreadable very fuzzy.

I found this to be consistant no matter which driver version, 11.6b current. You can use standard or edge detect both fuzzy for me.
 
Very impressive. Only real con I see to this is that it needs to be implemented by the developer, (which I would imagine is why they can make it so little performance hit) while MLAA can be used with any game out there. I really see both FXAA and MLAA as a total win for the consumer, especially using an AMD graphics card because when FXAA is available, we can use it, and when its not, we can still use MLAA. MLAA is still lighter on the hardware the 4x MLAA.
 
How is it this works on AMD cards too? I'm completely confused by this. Nvidia is suppose to be the closed platform group and AMD the open platform group. However on AA, it's the opposite. Kudus to Nvidia for answering the call here, and hopefully this gains wide spread implemention (more so than PhysX ever did). Only time will tell I suppose on how the adoption of this works out.

The really impressive part though is the preformance. Using less of a preformance hit than 2X AA and delivering preformance on par with 4X. "Free" 4X AA is one hell of a nice idea.
 
Very impressive. Only real con I see to this is that it needs to be implemented by the developer, (which I would imagine is why they can make it so little performance hit) while MLAA can be used with any game out there. I really see both FXAA and MLAA as a total win for the consumer, especially using an AMD graphics card because when FXAA is available, we can use it, and when its not, we can still use MLAA. MLAA is still lighter on the hardware the 4x MLAA.

I'm reading in some places that it works on some titles that don't have official support, regardless, when forced through nVidia Inspector... so it clearly doesn't *have* to be implemented by the developers but rather it will/won't work with some titles/others until they are patched to support it if they don't already. Just speculation off of what I'm reading.
 
IIRC shader based AA was promised since DX9 and then again in DX10. FXAA is a step in the right direction and hopefully evolve into a new hardware based AA.

Since its only a shader program I really can't see a reason why it can't be implemented at a driver level, although there may be some IQ issues. But even if it can't be enabled at a driver level, a developer can easily implement it via a patch. Lets hope developers embrace it and support at least in current and upcoming games.
 
I've seen FXAA as an option inside of Nvidia inspector. And it did do AA on some games I tried, but tonight I'll post some screenshots showing the difference.

As far as I know it only works on OpenGL titles, and leaves a green box in the top corner of the screen. In some games this green box causes a very bad tearing problem the height of the box across the length of the screen.

It doesn't appear to be fully implemented in working manner.
 
I am not so sure why MLAA was brought into this article , MLAA was ATI response to Nvidia crippling titles from using any AMD form of AA.

MLAA was never anything but a stopgap, hardly something which was useful but for Nvidia titles.
 
I am not so sure why MLAA was brought into this article , MLAA was ATI response to Nvidia crippling titles from using any AMD form of AA.

MLAA was never anything but a stopgap, hardly something which was useful but for Nvidia titles.

Errrrrr, that's not at all how I recall things, and even hypothetically pretending that were the case they still are both shader-based AA alternatives, so thus are directly comparable. However in reality MLAA was added as an AA method for titles that use deferred rendering under DX9 which are incompatible (both nVidia and ATI) with traditional multisampling, and not the reason you're claiming. MLAA is and was designed to be an alternative to normal AA, not any kind of "stopgap".
 
This article is amazig. Points out how hard both companies are working for our dollars. Wonder if MLAA can get any better performance from having any in game support, wonder if it can recieve any in game support...
 
Very interesting, and looks like a clear winner. To me at least, the FXAA looked superior to the MLAA in pretty much every shot. Just a shame it has to be developer-enabled to work. Thanks for the article.
 
As far as I know it only works on OpenGL titles, and leaves a green box in the top corner of the screen. In some games this green box causes a very bad tearing problem the height of the box across the length of the screen.

It doesn't appear to be fully implemented in working manner.

Supposedly works in some DX titles as well from what I'm reading such as DNF? Unsure as I don't own that game...
 
So what immediately stood out to me was that FXAA did not decrease the minimum frame rate at all. So while the graphs show an 11% - 14% decrease, that is only a decrease in the max, which was at times well over 60 FPS anyway. To me, if the minimum framerate (which was 42 for the Nvidia card) is sufficiently playable, that is in effect a free IQ enhancement.

Pretty damn impressive, I'm looking forward to seeing more on this going forward.
 
Wow this is really good stuff. I have always been irritated at how much of a performance hit antialiasing caused to the point of wondering why even implement antialiasing at all. It's about time someone did antialiasing right.
 
That is a good question. FEAR 3 does not really make extensive use of text as a UI component, so it is hard to say based on what I've seen with this game. I know exactly what you are talking about. Civ5 is a good example of a game for which MLAA is not ideal. Even with the FRAPS counter, I can see MLAA smudging it up, but I did not notice it with FXAA.

It is likely, however, that the FRAPS counte


r is inserted into the frame after FXAA has done its thing, so there would be no degradation.

We'd need a game like Civ5 to support FXAA to check this issue for sure.

...or check a chat window in Age of Conan?
 
pretty awesome. but the "developer implemented" sounds like the Achilles heel. I haven't looked much at this but is there any chance of getting this at the driver level? (I Know it would kill the performance gains but)
 
Kudos to Nvidia for pushing AA to new heights. I will use this mode in any new game that supports it :D

I do like how the review revisited MLAA quality: it's obviously been improved-upon upon since release, and now leaves texture detail mostly intact. Unfortunately, it's no better than FXAA and comes at a severe performance cost.
 
FXAA will also be an option in BF3 so it will be interesting to see how that goes. While the backwards compatibility with DX9/10 hardware is nice, I wonder if it would be faster as a compute shader.
 
Well it's good to see some advancement made. To be honest, I'm one of those people does not really care for AA. That's because in most games (most, not all), the pace is far greater than to stand still and literally squint at edges to see where they are McJagged or not. Ergo, provides no real appreciable graphic improvement as per the experience.
 
Actually aliasing is far more noticeable in motion. Your eyes are probably not sensitive to it. Drives other people batshit insane though.
 
So if it's just a shader, it's only a matter of time before someone re-creates it and releases it like the ENB shaders. Then every game can use it. It is still awesome though, and every developer should start to use it, or integrate it into older games.
 
Pay closer attention u guys - big parts of the wall in the last pic have been blurred with MLAA.
Also in both pics with text, MLAA took the white color saturation on text.


Question that I didn't see covered in the article:

How bad are the effects of FXAA on in-game text, and other similar overlays?

Any time text (or HUDs in general) are not a major part of the game interface, I love MLAA, but in any game where text is a regular component, the HUD is more complex, etc. the negatives far outweigh the positives.

I would imagine that as they're similar postprocessing effects, they have similar degradation on the quality of text and other sharp-edged GUI overlay elements, but as I've not seen for myself, I don't want to assume.

As per Timothy's paper:

FXAA should be applied prior to drawing the HUD or UI elements.
 
So if it's just a shader, it's only a matter of time before someone re-creates it and releases it like the ENB shaders. Then every game can use it. It is still awesome though, and every developer should start to use it, or integrate it into older games.

Already been done for the most part. Someone has already ported the FXAA shader to be used in ENBseries. It works in GTA4. That's right, you can have FXAA in GTA4, which has zero support for MSAA.

Look ma, no jaggies!
GTAIV2011-07-1706-04-26-34.jpg



This code snippet can be pasted into ENBseries' effect.txt to add the shader effect.
Code:
/*============================================================================
   FXAA3 QUALITY - PC
 	NVIDIA FXAA III.8 by TIMOTHY LOTTES
============================================================================*/

   #define FXAA_LINEAR 0
   #define FXAA_QUALITY__EDGE_THRESHOLD (1.0/16.0)
   #define FXAA_QUALITY__EDGE_THRESHOLD_MIN (1.0/16.0)
   #define FXAA_QUALITY__SUBPIX_CAP (3.0/4.0)
   #define FXAA_QUALITY__SUBPIX_TRIM (1.0/4.0)
   #define FXAA_QUALITY__SUBPIX_TRIM_SCALE  (1.0/(1.0 - FXAA_QUALITY__SUBPIX_TRIM))
   #define FXAA_SEARCH_STEPS     8
   #define FXAA_SEARCH_THRESHOLD (1.0/4.0)

float4 FxaaPixelShader(VS_OUTPUT_POST IN, float2 vPos : VPOS) : COLOR
{   

#define FxaaTexTop(t, p) tex2Dlod(t, float4(p, 0.0, 0.0))
#define FxaaTexOff(t, p, o, r) tex2Dlod(t, float4(p + (o * r), 0, 0))

float2 pos = IN.txcoord.xy;

float2 rcpFrame = float2(1/ScreenSize, ScreenScaleY/ScreenSize);
float4 rcpFrameOpt = float4(2/ScreenSize, 2*ScreenScaleY/ScreenSize, 0.5/ScreenSize, 0.5*ScreenScaleY/ScreenSize);

float lumaN = dot(FxaaTexOff(SamplerColor, pos.xy, float2(0, -1), rcpFrame.xy).xyz, float3(0.299, 0.587, 0.114));
float lumaW = dot(FxaaTexOff(SamplerColor, pos.xy, float2(-1, 0), rcpFrame.xy).xyz, float3(0.299, 0.587, 0.114));


float4 rgbyM;
rgbyM.xyz = FxaaTexTop(SamplerColor, pos.xy).xyz;
rgbyM.w = dot(rgbyM.xyz, float3(0.299, 0.587, 0.114));
float lumaE = dot(FxaaTexOff(SamplerColor, pos.xy, float2( 1, 0), rcpFrame.xy).xyz, float3(0.299, 0.587, 0.114));
float lumaS = dot(FxaaTexOff(SamplerColor, pos.xy, float2( 0, 1), rcpFrame.xy).xyz, float3(0.299, 0.587, 0.114));
float lumaM = rgbyM.w;


float rangeMin = min(lumaM, min(min(lumaN, lumaW), min(lumaS, lumaE)));
float rangeMax = max(lumaM, max(max(lumaN, lumaW), max(lumaS, lumaE)));
float range = rangeMax - rangeMin;

if(range < max(FXAA_QUALITY__EDGE_THRESHOLD_MIN, rangeMax * FXAA_QUALITY__EDGE_THRESHOLD)) return rgbyM;


float lumaNW = dot(FxaaTexOff(SamplerColor, pos.xy, float2(-1,-1), rcpFrame.xy).xyz, float3(0.299, 0.587, 0.114));
float lumaNE = dot(FxaaTexOff(SamplerColor, pos.xy, float2( 1,-1), rcpFrame.xy).xyz, float3(0.299, 0.587, 0.114));
float lumaSW = dot(FxaaTexOff(SamplerColor, pos.xy, float2(-1, 1), rcpFrame.xy).xyz, float3(0.299, 0.587, 0.114));
float lumaSE = dot(FxaaTexOff(SamplerColor, pos.xy, float2( 1, 1), rcpFrame.xy).xyz, float3(0.299, 0.587, 0.114));



float lumaL = (lumaN + lumaW + lumaE + lumaS) * 0.25;
float rangeL = abs(lumaL - lumaM);
float blendL = saturate((rangeL / range) - FXAA_QUALITY__SUBPIX_TRIM) * FXAA_QUALITY__SUBPIX_TRIM_SCALE; 
blendL = min(FXAA_QUALITY__SUBPIX_CAP, blendL);

float edgeVert = abs(lumaNW + (-2.0 * lumaN) + lumaNE) + 2.0 * abs(lumaW  + (-2.0 * lumaM) + lumaE ) + abs(lumaSW + (-2.0 * lumaS) + lumaSE);
   	float edgeHorz = abs(lumaNW + (-2.0 * lumaW) + lumaSW) + 2.0 * abs(lumaN  + (-2.0 * lumaM) + lumaS ) + abs(lumaNE + (-2.0 * lumaE) + lumaSE);
   	bool horzSpan = edgeHorz >= edgeVert;

float lengthSign = horzSpan ? -rcpFrame.y : -rcpFrame.x;
if(!horzSpan) lumaN = lumaW;
if(!horzSpan) lumaS = lumaE;
float gradientN = abs(lumaN - lumaM);
float gradientS = abs(lumaS - lumaM);
lumaN = (lumaN + lumaM) * 0.5;
lumaS = (lumaS + lumaM) * 0.5;

bool pairN = gradientN >= gradientS;
if(!pairN) lumaN = lumaS;
if(!pairN) gradientN = gradientS;
if(!pairN) lengthSign *= -1.0;
float2 posN;
posN.x = pos.x + (horzSpan ? 0.0 : lengthSign * 0.5);
posN.y = pos.y + (horzSpan ? lengthSign * 0.5 : 0.0);


gradientN *= FXAA_SEARCH_THRESHOLD;

float2 posP = posN;
float2 offNP = horzSpan ? 
float2(rcpFrame.x, 0.0) :
float2(0.0f, rcpFrame.y); 
float lumaEndN;
float lumaEndP;	
bool doneN = false;
bool doneP = false;
posN += offNP * (-1.5);
posP += offNP * ( 1.5);
for(int i = 0; i < FXAA_SEARCH_STEPS; i++) 
{
 lumaEndN = dot(FxaaTexTop(SamplerColor, posN.xy).xyz, float3(0.299, 0.587, 0.114));
 lumaEndP = dot(FxaaTexTop(SamplerColor, posP.xy).xyz, float3(0.299, 0.587, 0.114));
 bool doneN2 = abs(lumaEndN - lumaN) >= gradientN;
 bool doneP2 = abs(lumaEndP - lumaN) >= gradientN;
 if(doneN2 && !doneN) posN += offNP;
 if(doneP2 && !doneP) posP -= offNP;
 if(doneN2 && doneP2) break;
 doneN = doneN2;
 doneP = doneP2;
 if(!doneN) posN -= offNP * 2.0;
 if(!doneP) posP += offNP * 2.0; 
}

float dstN = horzSpan ? pos.x - posN.x : pos.y - posN.y;
float dstP = horzSpan ? posP.x - pos.x : posP.y - pos.y;

bool directionN = dstN < dstP;
lumaEndN = directionN ? lumaEndN : lumaEndP;

if(((lumaM - lumaN) < 0.0) == ((lumaEndN - lumaN) < 0.0)) 
lengthSign = 0.0;

float spanLength = (dstP + dstN);
dstN = directionN ? dstN : dstP;
float subPixelOffset = 0.5 + (dstN * (-1.0/spanLength));
subPixelOffset += blendL * (1.0/8.0);
subPixelOffset *= lengthSign;
float3 rgbF = FxaaTexTop(SamplerColor, float2(pos.x + (horzSpan ? 0.0 : subPixelOffset), pos.y + (horzSpan ? subPixelOffset : 0.0))).xyz;

   #if (FXAA_LINEAR == 1)
lumaL *= lumaL;
   #endif
   float lumaF = dot(rgbF, float3(0.299, 0.587, 0.114)) + (1.0/(65536.0*256.0));
   float lumaB = lerp(lumaF, lumaL, blendL);
   float scale = min(4.0, lumaB/lumaF);
   rgbF *= scale;

   return float4(rgbF, lumaM); 
}
 
I see nothing but good things for the future of AA. Hopefully this lights a fire under AMD to rework MLAA to work on all cards at less of a performance penalty.
 
How bad are the effects of FXAA on in-game text, and other similar overlays?

That was just an artifact of the driver level implementation for MLAA. If the developer implements it, they probably do post processing before they do any 2d stuff... it'd look weird if your hud is shadowing shit from SSAO or blooming.

Also this article is mentioned on his blog now:
http://timothylottes.blogspot.com/


I wonder if there's more performance to be found in the shader yet, like a direct compute version. The DX10+ versions are already supposedly faster due to guaranteed hardware features but I wonder if an actual DX11 compute shader version could push it further. MSAA is even more expensive in deferred renderers, even with DX11 features to try and help, so post AA will probably become king there if it's performance you're after. 4x MSAA in FEAR 3 takes my lowly GTX 260 to 30 fps, FXAA was 60~. That's like a 16 ms difference in render time, which is enormous...
 
Last edited:
Already been done for the most part. Someone has already ported the FXAA shader to be used in ENBseries. It works in GTA4. That's right, you can have FXAA in GTA4, which has zero support for MSAA.

Look ma, no jaggies!

How's the HUD look with that implemented?
 
I can confirm that FXAA works great in Doom 3.
GPU hit is almost nonexistent.

ATM I am torn between 8xS (1x2SS + 4xMS)
(which takes a HUGE hit on GPU),

and FXAA.
 
Already been done for the most part. Someone has already ported the FXAA shader to be used in ENBseries. It works in GTA4. That's right, you can have FXAA in GTA4, which has zero support for MSAA.

Look ma, no jaggies!
GTAIV2011-07-1706-04-26-34.jpg

sweetness!
 
I see nothing but good things for the future of AA. Hopefully this lights a fire under AMD to rework MLAA to work on all cards at less of a performance penalty.
I think you have it backwards, AMD has been stoking a nice bonfire under Nvidia for a long time.
If it wasn't for AMD innovating MLAA in the first place you wouldn't have Nvidia doing this. It's about time they caught up to AMD and no shit it should perform better since they've been working on it for so long. If it didn't it would've been a failure.
If It wasn't for AMD innovating with Eyefinity Nvidia users wouldn't even have the half-assed copy that Nvidia came up with which requires two cards to work.
 
Works on all GPUs? That is highly uncharacteristic of Nvidia, but it's a step in the right direction!

Nice to see something with less of a performance hit than MSAA/MLAA.
 
Back
Top