AMD's Morphological Anti-Aliasing

[socK]

...I just said I was using MLAA, not MSAA.

Since MLAA is applied as a post-processing effect, it adds additional input lag. Hopefully AMD has some way to minimize this problem.

er, every modern game has a million things being done as a post process step already. bloom is effectively a post process. it shouldn't be adding input lag.

mlaa should also be superior because of this because it works with the hdr resolve, not against it like msaa

 

[refraxion]

er, every modern game has a million things being done as a post process step already. bloom is effectively a post process. it shouldn't be adding input lag.

mlaa should also be superior because of this because it works with the hdr resolve, not against it like msaa

I believe I might have been the first one to point that out in this thread, but yes there is input lag in games -- I'm not sure if there is in ALL, but there is definitely input lag in games I play.

 

[Tamlin_WSGF]

I'm way over my head here with the different kinds of AA. I just installed my new 6870 and noticed that MLAA is unchecked by default in the 3D section of Cataclyst with the 10.10a drivers. If I enable this with application control enabled, will it take effect before the AA settings in a game? What if the game doesn't support it? Also, what if I turn up the AA in a game, will the MLAA take precedence? Sorry for the noob questions, I'm just completely lost in the hierarchy of what controls what.

MLAA can be used without any other AA filtering method or with any AA filtering method. I've seen several confused by this on other forums. One believed the 2X, 4X etc. slider in CCC applied to MLAA as well, and complained about performance hit.

MLAA is a post-process effect. It is applied after all other filtering methods. If you use application select on AA in CCC, enable MLAA and disable AA ingame, MLAA will be applied to the game.

So, as an answer to your question: If you turn up AA ingame, it will give X times MSAA + MLAA (like 8X MSAA + MLAA). If you turn off AA ingame, you only get MLAA. MLAA comes alone or in addition to all other methods.

 

[Unknown-One]

er, every modern game has a million things being done as a post process step already. bloom is effectively a post process. it shouldn't be adding input lag.

Technically, those post-processing done by the game engine itself do add input lag (even bloom), it's just a very small amount. Those post-processing filters also have the advantage of having direct access to the rendering pipeline before a rendered frame is dumped into the GPU framebuffer.

MLAA is effectively post-post-processing. It has to wait for the engine to dump a fully rendered frame into the framebuffer, copy it out, process it, then copy it back for display. All of those operations take time.

A noticeable portion of this input lag appears to be due to the amount of time it takes the GPU to run the filter on each frame. The larger the frame, the longer the filter takes to process it, and the more input lag is added. Indeed, when I dropped from Eyefinity resolutions (5040x1050) down to a single monitor (1680x1050), the input lag was greatly reduced.

There are a couple ways they could minimize this problem. Additional optimizations to the MLAA filter for starters. They could reserve some of the GPU specifically for MLAA so that it can process the image more quickly (you'll lose a few FPS, but the input lag will be minimized). They also might be able to implement MLAA load balancing in crossfire configurations to speed things up.

 

[nakedhand]

Lol! No more entertainment for you. We've taken it on PM.

Sounds good, it was nice with an "entertainment" break between the technical deliberations.

You get your entertainment in weird ways!

You might have a point actually. Maybe it was more fascinating than entertaining

Technically, those post-processing done by the game engine itself do add input lag (even bloom), it's just a very small amount. Those post-processing filters also have the advantage of having direct access to the rendering pipeline before a rendered frame is dumped into the GPU framebuffer.

MLAA is effectively post-post-processing. It has to wait for the engine to dump a fully rendered frame into the framebuffer, copy it out, process it, then copy it back for display. All of those operations take time.

A noticeable portion of this input lag appears to be due to the amount of time it takes the GPU to run the filter on each frame. The larger the frame, the longer the filter takes to process it, and the more input lag is added. Indeed, when I dropped from Eyefinity resolutions (5040x1050) down to a single monitor (1680x1050), the input lag was greatly reduced.

There are a couple ways they could minimize this problem. Additional optimizations to the MLAA filter for starters. They could reserve some of the GPU specifically for MLAA so that it can process the image more quickly (you'll lose a few FPS, but the input lag will be minimized). They also might be able to implement MLAA load balancing in crossfire configurations to speed things up.

Thanks for the info. Very well explained, helped me understand this better.


My 6870 has landed in the US, but it needs to find Denmark before I can do some testing especially in regards to input lag, which I absolutely can not stand (hate), even more than jaggies!

I bet Brent and Kyle are going to have their article out soon, nudge nudge... I cant wait to read about their experiences with input lag. I would love to see some HD footage of input lag in action in various games (if the HD cam has returned from repairs hehe).

Has anyone seen any STALKER or Metro 2033 MLAA shots yet? Links...?

 

[socK]

Technically, those post-processing done by the game engine itself do add input lag (even bloom), it's just a very small amount. Those post-processing filters also have the advantage of having direct access to the rendering pipeline before a rendered frame is dumped into the GPU framebuffer.

MLAA is effectively post-post-processing. It has to wait for the engine to dump a fully rendered frame into the framebuffer, copy it out, process it, then copy it back for display. All of those operations take time.

A noticeable portion of this input lag appears to be due to the amount of time it takes the GPU to run the filter on each frame. The larger the frame, the longer the filter takes to process it, and the more input lag is added. Indeed, when I dropped from Eyefinity resolutions (5040x1050) down to a single monitor (1680x1050), the input lag was greatly reduced.

There are a couple ways they could minimize this problem. Additional optimizations to the MLAA filter for starters. They could reserve some of the GPU specifically for MLAA so that it can process the image more quickly (you'll lose a few FPS, but the input lag will be minimized). They also might be able to implement MLAA load balancing in crossfire configurations to speed things up.

Er you aren't presenting the frame if it's not done being drawn on, in full screen it's a pointer flip from backbuffer to front, windowed mode requires a blit. Post processing shouldn't be adding any more input lag than anything else that consumes frame time.

Mlaa is supposed to help in bandwidth starved situations, msaa handily spirals out of control, especially in deferred renderers where it gets even worse.

 

[Tamlin_WSGF]

No MLAA, 8X MSAA, MLAA gallery updated:

http://www.iryokufx.com/mlaa/gallery/index.html

 

[Valset]

No MLAA, 8X MSAA, MLAA gallery updated:

http://www.iryokufx.com/mlaa/gallery/index.html

thanks. you know I have to really look but the 8XMSAA is better. not that I would notice in game though. Certainly not worth the performance hit of it over the MLAA

 

[Flyinfinni]

Nice gallery- MLAA is pretty nice in those.

 

[Tamlin_WSGF]

thanks. you know I have to really look but the 8XMSAA is better. not that I would notice in game though. Certainly not worth the performance hit of it over the MLAA

On the screenshots, it looks like MLAA (probably due to the full scene anti-aliasing) took care of the aliasing much better then the MSAA, so I like that better personally. A matter of taste I belive. In games, I find that its very game dependent. In some games, I prefer MLAA and in others MSAA.

Edit: Checked only the first Unigine Heaven screenshot in previous reply, where MLAA clearly was better (especially fence top left), on the other Heaven pictures it was a mix. Both MLAA and 8X AA seemed to have artifacts in the images.

Edit: did you try it ingame with your 5870?

Here's a quote from Dave Baumann (AMD) about how its done:

With regards to MLAA, the DC comment is a little red herring; it started life as in HLSL but obviously what is present in the driver is not HLSL; it is platform indepentant so it should be in XP aready) and also API independant - we've had some reports of the driver not picking up the correct key's in DX10/DX11 but it should work, additionally OpenGL is still being worked on.

With regards to the hardware support, the LDS really is paying off here because we need to store chunks of the frame for the analysis and blending stages. Without the LDS you're probably going to be doing roundtips to memory constantly, which is going to have a big impact in performance.

http://forum.beyond3d.com/showpost.php?p=1487070&postcount=4199

 

[magao]

HD5770 - confirmed if MLAA was active by looking at the RadeonPro FPS counter (gets rounded).

Fallout 3 - didn't notice any effect on the HUD/text (which already has faded edges) but 12xCFAA looked better and was at 60FPS.

Guild Wars - text has thin lines and sharp edges - close to unreadable. Stick with 12xCFAA only.

Vampire the Masquerade: Bloodlines - didn't make any significant effect - text was fine, but still lots of shimmering. 12xCFAA looks fantastic.

Dungeons and Dragons Online (DX9) - No significant effect. Stick with 4xMSAA + DX11.

Arcanum: Of Steamworks and Magick Obscura - everything was a blurry mess. Text completely unreadable, graphics extremely blurry. Run away!

I've yet to find a game I play where MLAA looks better (or at least makes a significant difference) whether by itself or added to MSAA/CFAA. The text in many is hurt badly, and I can achieve 60FPS with MSAA/CFAA.

 

[Unknown-One]

Post processing shouldn't be adding any more input lag than anything else that consumes frame time.

It's adding that much input lag, and more.

It's not that hard to understand. It takes time for the GPU to process a frame with MLAA post-processing; the longer it takes, the the larger the time-delay between the frame being rendered and the frame getting to your screen.

Lowering your screen resolution (making the frame smaller and quicker to process) helps reduce the input lag. Works great on game consoles with their low-resolution output, not so good for Eyefinity users running massive resolutions.

 

[socK]

25.8397 ms on
25.2525 ms off

There is a half a millisecond difference in render times @ 1920x1080, at that cost you would eat a stunning 2 fps drop from 62 to 60.

there should be no noticeable bubble in the pipeline

1920x1080 to 5040x1050 is a 2.552 increase in pixels, assuming performance scaled linearly, that's about a 1.4985 ms cost which is probably one of the least expensive things your video card is doing, it'd be a cost of 60 fps to 55. It's still incredibly minimal.

 

[fattypants]

This is could be really nice for WoW players. The engine is heavily CPU bound, so turning off AA and enabling this could help in places where framerates chug with AA on. They could just disable AA and offload edge smoothing to the GPU instead.

 

[Forceman]

25.8397 ms on
25.2525 ms off

There is a half a millisecond difference in render times @ 1920x1080, at that cost you would eat a stunning 2 fps drop from 62 to 60.

there should be no noticeable bubble in the pipeline

1920x1080 to 5040x1050 is a 2.552 increase in pixels, assuming performance scaled linearly, that's about a 1.4985 ms cost which is probably one of the least expensive things your video card is doing, it'd be a cost of 60 fps to 55. It's still incredibly minimal.

Input lag and FPS are not directly linked such that high FPS eliminates input lag, or that high input lag implies low framerates. I can be ripping off high framerates and still have input lag.

 

[Tamlin_WSGF]

Input lag and FPS are not directly linked such that high FPS eliminates input lag, or that high input lag implies low framerates. I can be ripping off high framerates and still have input lag.

I think he refers to the delta between MLAA on and off, not the amount of frames per second itself.

 

[Dark12]

Yea this definitely looks badass.
I hope they release drivers for the 4 series! I know there is some hack, but I haven't really heard any 4 series users saying it actually works.

 

[socK]

I think he refers to the delta between MLAA on and off, not the amount of frames per second itself.

yes, this is what i'm getting at, that the card isn't just sitting on frames for a bizarrely long time, it's clearly rendering fast.

 

[serpretetsky]

Here is a quick guide to the subtleties of the algorithm
http://forum.beyond3d.com/showpost.php?p=1486838&postcount=4165

huh, so let me get this straight...
... it's a post processing filter?

 

[Unknown-One]

yes, this is what i'm getting at, that the card isn't just sitting on frames for a bizarrely long time, it's clearly rendering fast.

Rendering fast has nothing to do with the input lag MLAA is causing.

You can render 60 frames per second, but display them on-delay (thus creating input lag). That's exactly what MLAA is doing.

 

[socK]

which shouldn't be happening, if it is. no reviews make any mention of it.

post processing aa is nothing new, it's been done a million times before. there shouldn't be a stall.

 

[Matrices]

Is anyone reporting this lag on NEW hardware? Backported drivers are of course unoptimized.

 

[Snowdog]

This lag could be largely imagined, there is no way to measure it.

Also since it is post processing, I doubt there is any way to back up the frames and buffer more of them, applications have no knowledge frames are having MLAA applied the will keep delivering their frames to the output buffer, if the previous frame was delayed for much time at all, there would be collisions. IMO this has to happen is some fraction of one normal frame (say 8ms), which would essentially be undetectable.

It would be a good question for AMD folks.

 

[Valset]

Is anyone reporting this lag on NEW hardware? Backported drivers are of course unoptimized.

haven't noticed any to speak of. but I have been playing mostly older games so far.

 

[kllrnohj]

Rendering fast has nothing to do with the input lag MLAA is causing.

You can render 60 frames per second, but display them on-delay (thus creating input lag). That's exactly what MLAA is doing.

No, not at all. MLAA will slow down rendering, it doesn't add any input lag. The FPS hit you get from MLAA is *exactly* how much extra "input lag" it adds, just like every other graphical setting. If it takes 0.6ms longer to render a frame with MLAA on, then MLAA has added 0.6ms "input lag". It really is that simple.

 

[Spare-Flair]

I hope official support for 5xxx series comes out soon and it is optimized for it and it is a bit improved over the results we are seeing with the hacked drivers.

If we don't get proper support on 5xxx, MLAA is seriously one thing that might make me sell and upgrade to 6xxx.

 

[Forceman]

No, not at all. MLAA will slow down rendering, it doesn't add any input lag. The FPS hit you get from MLAA is *exactly* how much extra "input lag" it adds, just like every other graphical setting. If it takes 0.6ms longer to render a frame with MLAA on, then MLAA has added 0.6ms "input lag". It really is that simple.

It can still be rendering 60 FPS, but they are are a half millisecond later than they would otherwise be displayed - and that is what input lag is all about. It isn't how fast the card is rendering frames, it is how long it takes from when you move the mouse until that change is reflected on-screen. The whole rendering cycle is shifted slightly, because there are extra steps being added to the rendering pipeline, even though the pipeline itself is still operating at a high rate of speed.

 

[socK]

It can still be rendering 60 FPS, but they are are a half millisecond later than they would otherwise be displayed - and that is what input lag is all about. It isn't how fast the card is rendering frames, it is how long it takes from when you move the mouse until that change is reflected on-screen. The whole rendering cycle is shifted slightly, because there are extra steps being added to the rendering pipeline, even though the pipeline itself is still operating at a high rate of speed.

You don't see the frame if it isn't complete, if it's not ready then it's not there. It's added to the render cost and that's it. It takes an extra 0.5872 ms and that's it... to put it into perspective

The baseline for that SC2 pic is 39.6 fps
noaa: 25.2525 ms
mlaa: 25.8397 ms
4x msaa: 52.9100 ms

msaa effectively takes 47.1006 times longer to do than mlaa.
that's a 27.6575 ms difference in render time.

 

[Morphy]

It can still be rendering 60 FPS, but they are are a half millisecond later than they would otherwise be displayed - and that is what input lag is all about. It isn't how fast the card is rendering frames, it is how long it takes from when you move the mouse until that change is reflected on-screen. The whole rendering cycle is shifted slightly, because there are extra steps being added to the rendering pipeline, even though the pipeline itself is still operating at a high rate of speed.

What does AA have anything to do with input? Regular input lag comes from the inherent display panel and input devices which has nothing to do with how the graphic subsystem renders. So if there is degradation in performance due to the post processing AA not keeping up with the rendering cycle it will manifest in drop frames/stuttering. Input lag is an entirely different thing.

 

[Unknown-One]

post processing aa is nothing new, it's been done a million times before. there shouldn't be a stall.

Something about MLAA is adding a delay. I can repeat it quite easily with more than one game. Halo as well as Batman Arkham Asylum both exhibit severe and noticeable input lag when MLAA is enabled (running both games at 5040x1050).

No, not at all. MLAA will slow down rendering, it doesn't add any input lag. The FPS hit you get from MLAA is *exactly* how much extra "input lag" it adds, just like every other graphical setting. If it takes 0.6ms longer to render a frame with MLAA on, then MLAA has added 0.6ms "input lag". It really is that simple.

It's not that simple, as that's not what I'm seeing here. Input lag is not always tied directly to framerate.

A game is rendering 60 frames every second. The GPU holds on to each frame for a second to apply MLAA to it before sending it out to the display. This means the output stream is slightly behind the input stream (we feel and see this delay as "input lag").

It can still be rendering 60 FPS, but they are are a half millisecond later than they would otherwise be displayed - and that is what input lag is all about. It isn't how fast the card is rendering frames, it is how long it takes from when you move the mouse until that change is reflected on-screen.

Thank you, someone who finally gets it!

You don't see the frame if it isn't complete, if it's not ready then it's not there. It's added to the render cost and that's it. It takes an extra 0.5872 ms and that's it... to put it into perspective

The baseline for that SC2 pic is 39.6 fps
noaa: 25.2525 ms
mlaa: 25.8397 ms
4x msaa: 52.9100 ms

msaa effectively takes 47.1006 times longer to do than mlaa.
that's a 27.6575 ms difference in render time.

Please, actually read the explanations here. Game renders frame, GPU holds and processes frame, GPU sends frame to monitor.

The stage where it has to sit there and process the frame adds a delay to the output (completely independent of the framerate the game is running at). It's STILL passing 60 frames to the monitor every second, but they're delayed. It's really simple...

 

[socK]

Unless you turn on vsync, there is no wait, the frame is just blasted off asap.

The game doesn't directly render the frame, the API and ultimately your hardware does. There's no holding it for extra work, how long it takes to render is the end all measurement of how long it took to do EVERYTHING to get that frame on your screen, both CPU and GPU time.

 

[Unknown-One]

There's no holding it for extra work, how long it takes to render is the end all measurement of how long it took to do EVERYTHING to get that frame on your screen, both CPU and GPU time.

Once again, not in this case.

MLAA is grabbing the final frame out of the framebuffer, adding additional processing, then putting it back for display. This happens outside and independently of the normal rendering process. MLAA is applied so late in the process that it doesn't even show up in screenshots; you just end up with a screenshot of the an aliased frame that MLAA hasn't been applied to yet (unless you take special precautions or use that leaked ATi screenshot tool).

So yes, there IS holding for extra work.

 

[Snowdog]

Once again, not in this case.

MLAA is grabbing the final frame out of the framebuffer, adding additional processing, then putting it back for display. This happens outside and independently of the normal rendering process. MLAA is applied so late in the process that it doesn't even show up in screenshots; you just end up with a screenshot of the an aliased frame that MLAA hasn't been applied to yet (unless you take special precautions or use that leaked ATi screenshot tool).

So yes, there IS holding for extra work.

But since it already in the display buffer, there is no mechanism to stack up frames if it gets behind. The absolute maximum that you could reasonably be delayed is about 1/2 a frame length. ~8ms. This is essentially undetectable.

 

[Revdarian]

This is could be really nice for WoW players. The engine is heavily CPU bound, so turning off AA and enabling this could help in places where framerates chug with AA on. They could just disable AA and offload edge smoothing to the GPU instead.

Dunno how i missed this but ohhhh no, you do NOT wanna do this on WoW.

The UI will get "anti aliased" too, and you will have a real hard time reading anything :S
It could turn into hell with raid warnings and certain PvP mods.


MSAA is already GPU bound, not CPU at all, the drops you feel in certain places have way more to do with things loading in memory and what not, for example, did you know that you can get the crafting spam of someone in dalaran while you are all the way on the actual ground mining//looking for carrots and whatnot?...

And that is at standard settings, if you are your raid's combat logger chances are that you increase your log radius, and thus your data gathering radius so to say, way beyond what is needed (i had mine so that i could log almost a full zone no matter where i was .. fun times )


MLAA is great for many things, WoW is really not one of those.

 

[Unknown-One]

But since it already in the display buffer, there is no mechanism to stack up frames if it gets behind. The absolute maximum that you could reasonably be delayed is about 1/2 a frame length. ~8ms. This is essentially undetectable.

In this instance, that's irrelevant. Frames aren't being deliberately stacked up in order to add a delay (so there's no stacking or buffering mechanism required), they're getting stuck in a pipeline.


1. Aliased frame #1 rendered to frame buffer.

2a. Aliased frame #1 sent for MLAA post-processing.
2b. Aliased frame #2 rendered to frame buffer.

3a. Aliased frame #1 Processes.
3b. Aliased frame #2 Sent for MLAA post-processing (processed in-line behind frame #1).
3c. Aliased frame #3 rendered to frame buffer.

4a. Anti-Aliased frame #1 Sent to monitor.
4b. Aliased frame #2 Processes
4c. Aliased frame #3 Sent for MLAA post-processing (processed in-line behind frame #2)
4d. Aliased frame #4 rendered to frame buffer


We've just rendered 4 frames by the time the 1st one gets to the monitor because of that long pipeline with its inherent delay. Being 4 frames behind (~67ms) is going to be noticeable.
For added weirdness caused by this pipeline, if you take a screenshot by the time Anti-Aliased frame #1 gets to the monitor, you'll get a picture of Aliased Frame #4 in the frame buffer.

 

[Tamlin_WSGF]

According to the math from SC2 provided by socK, it takes 0.5872 ms extra to render a frame with MLAA. If a frame without MLAA is completed at 0 ms, a frame with MLAA is completed at 0.5872 ms. How can an input lag be larger then 0.5872 ms, unless the GFX card somehow stacks finished frames instead of outputting them?

To add to this, that is 35,232 ms per second (about 2 frames per second). This is including any performance hit MLAA might have (since the SC2 benchmark shows performance hit, while the delta between MLAA on and off shows the added time to make a frame including hit), so the actual number can be smaller, but not larger then 0.5872 ms per frame. Provided that the new MLAA feature doesn't stack images it already have processed that is.

 

[Snowdog]

In this instance, that's irrelevant. Frames aren't being deliberately stacked up in order to add a delay (so there's no stacking or buffering mechanism required), they're getting stuck in a pipeline.


We've just rendered 4 frames by the time the 1st one gets to the monitor because of that long pipeline with its inherent delay. Being 4 frames behind (~67ms) is going to be noticeable.
For added weirdness caused by this pipeline, if you take a screenshot by the time Anti-Aliased frame #1 gets to the monitor, you'll get a picture of Aliased Frame #4 in the frame buffer.

This is wrong all around.

Game sends frame to display buffer. This is the final output buffer. It isn't sent anywhere for MLAA, this is post process that happens in place in the final output buffer. It may slow down the whole graphics card by some amount as it will be dispatching more work, but that will be reflected by a slight drop in FPS.

Frame 1: Completely Finshed by game logic, sent to display buffer.
(if active, driver takes over and renders MLAA in place)
Frame 2: Finshed by game logic, sent display buffer. If the display buffer isn't ready, this will back everything up and FPS will drop massively. Frames have no place to stack and get multiple frames behind.

This is a fast and simple post process technique, there is no way in heck that it takes anywhere near a full frame length to process. You are not going to get multiple frames behind. The whole point of a post-process is fast/light and near zero resources used.

This is either easily done well before the next frame arrives or it isn't worth doing.

 

[Unknown-One]

This is wrong all around.

Except my explanation covers all of the observed effects, yours does not.

It perfectly explained the massive input lag. As a happy side-effect, this also explains why taking a screenshot results in a frame that does not yet have MLAA applied to it.

If MLAA were being applied to the frame in the normal frame buffer, to the current frame, it would appear in screenshots. It doesn't (unless you use ATi's special tool that somehow manages to capture the output-frame of the post processing filter). What you see when you take a screenshot is actually a couple of frames ahead of what's currently being displayed on the monitor, and doesn't have MLAA applied to it yet.

 

[Snowdog]

Again you are wrong. You are not looking several frames behind as in your faulty assumption.

The work happens in the actual Display output buffer, that is after all normal processing. This is the final output stage, that is about to be displayed on the monitor, not normal frame assembly area that you can screen grab. This is also why there is a very limited window for processing and it will be accomplished in well under 1frame.

 

[Tamlin_WSGF]

Unknown-One: The maximum delay, according to the SC2 benchmarks is 0.5872 ms per frame. That is including all processes and post processes, performance hits and whatnots.