AMD's Morphological Anti-Aliasing

Tamlin_WSGF said:
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.
Click to expand...

Which doesn't appear to be accurate, especially if that number was based on the recorded framerate alone, which wouldn't take into account the delayed output added my MLAA any more than it would take into account delayed output caused by monitor electronics. I'm seeing way more input lag than that when MLAA is enabled.

Snowdog said:
Again you are wrong.
Click to expand...

Again, your explanation does not cover all of the observed effects, mine still does. According to you, there should be no noticeable input lag...but there is, and there's a lot of it.

If you have an alternate theory that also manages to explain excessive input lag (as is observed), I'd love to hear it.
 
Last edited:
Unknown-One said:
Which doesn't appear to be accurate. I'm seeing way more input lag than that when MLAA is enabled.
Click to expand...

I'm not saying that you feel wrong, but that the numbers according to an actual on/off benchmark test disputes your observations. You haven't shared much about what in your setup differs from THG's setup.

The obvious factors that differs, are that THG use a 6XXX card with 1080P resolution and not 5850 and Eyefinity resolutions as you do.

You do agree to the math from SC2, that each frame cannot have more input lag then 0.5872 ms and thats including the performance hit? :)

Edit: You edited while I was replying, so I edit it in:

Unknown-One said:
Which doesn't appear to be accurate, especially if that number was based on the recorded framerate alone, which wouldn't take into account the delayed output added my MLAA any more than it would take into account delayed output caused by monitor electronics. I'm seeing way more input lag than that when MLAA is enabled
Click to expand...

All the math here is based upon recorded framerate. THG recorded framerate for MLAA on and framerate for MLAA off. The performance delta shows how much time that is added to each frame after MLAA process is finished. So, unless MLAA also holds back completed frames(after MLAA has been applied), each frame cannot have more then 0.5872 ms per frame input lag and thats including any performance hit.
 
Last edited:
Revdarian said:
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 :p.. fun times :) )


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

Yeah I'm going to have to agree and say that 8x MSAA is easily better for top-end systems playing WoW. MLAA made my UI a blurfest and only think it'd be realistic if you were struggling with GPU resources on a low-end system.
 
I don't have metro yet but i was wondering, is that AA set ingame?
If so, the devs are the culprits for the blurry implementation :S (it washes out and whitens the colors from what i could observe).

Wow AA thanksfully isn't like that :-P :) and nice use of MLAA hehehe
 
Revdarian said:
I don't have metro yet but i was wondering, is that AA set ingame?
If so, the devs are the culprits for the blurry implementation :S (it washes out and whitens the colors from what i could observe).

Wow AA thanksfully isn't like that :-P :) and nice use of MLAA hehehe
Click to expand...

I just bought Metro and the pictures are from the very beginning. I'm not going to play it until I'm finished with Stalker, but it was on Steam sale :p

I had to use high settings to force AAA off, so the No AA is really set as AAA, but it doesn't apply AAA. The MLAA is done with the AMD MLAA tool discussed earlier in this thread and the 4X AA is set ingame, not in CCC. :)
 
Tamlin_WSGF said:
Metro is a bit funny when it comes to 4X AA vs. MLAA. 4X AA is actually the blurry version:

Metro no AA (seems quality settings high and AAA turns off the adaptive AA):
http://img514.imageshack.us/img514/8343/metronoaa.jpg

MLAA:
http://img835.imageshack.us/img835/9879/metromlaa.jpg

4X AA:
http://img820.imageshack.us/img820/8946/metro4xaa.jpg

They are jpg's, so its not full quality vs. PNG originals. :)
Click to expand...

MLAA is a slight improvement over no AA in those pictures but it helps. Still a few jags on the books. AA blurred the edges and altered the colors of the image, especially the blue wall. I would choose to play with MLAA in Metro 2033. The colors looks a lot richer and the books are more detailed in appearance.
 
Are you guys seeing things? The only difference between MLAA and MSAA shots is that there are shadows in the MLAA shot.
 
I think what unknown one is trying to explain is that he believes its similar to where

Two groups of marathon racers of same height, stride length, etc. Almost identical.

In theory, they take these same number of steps (frames) and at the same rate(fps) give or take a very small amount (0.25ms ish) during however long the race course is(how long your playing your game). At the end of the race to the monitor, racers from group A step up onto the podium(displayed on monitor). Unknown-one seems to think that racers from Group B stop to tie their shoes(post-processing effect applied) then step up onto the podium(display on monitor). Therefore although their qualifying times are virtually identical +/- 2 fps there's that added lag of tieing the shoe prior to stepping up on the podium.

In this analogy, each group of marathon racers probably both finished in say 1 hour and 3 minutes. However, the time till podium(display) might be a bit different for those tieing their shoes making the effect of 'they finished later' though the 'recorded times/fps meters/fraps' would show the same-value.

Is there somehow to calculate how long the post-processing effect takes once the frame is rendered by the game logic? I know we heard the calculation number of 0.58ms ish thrown around a bunch for MSAA but are these two effects MLAA and MSAA rendered at different points in the rendering pipeline? Could the effect of applying MLAA cause a slight delay in the time it takes for the racers to reach the podium(ie tieing their shoes before getting up to the podium). If so, is there any chance this added delay could be > the 0.58ms from MSAA.
 
WorldExclusive said:
MLAA is a slight improvement over no AA in those pictures but it helps. Still a few jags on the books. AA blurred the edges and altered the colors of the image, especially the blue wall. I would choose to play with MLAA in Metro 2033. The colors looks a lot richer and the books are more detailed in appearance.
Click to expand...

I think I'd go with no MLAA over MLAA.

The wall looks like its lost detail/sharpness. I'm not sure if that might be DoF effects being applied? but it seems shaper looking at the wall. Like you can see the cracks in the wall-paper/paint more clearly defined. MLAA seems to have blurred the fine details and I don't notice a huge difference in the books tbh.

I did notice a huge difference in the straight-ness of the edge of the book with 4xaa. It actually looks like a flat-edge as opposed to a jagged edge. MLAA looked like a jagged edge with 2 less jags but jaggeded nonetheless. Granted there's almost no performance loss with MLAA compared to 4xaa but ... there seems to be almost no clear-advantage. It feels much more like a trade-off. Here you can have slightly sharper books but everything else will be blurry or you can have a large performance hit and all your edges will look great.

Really, why not turn on 4xAA? with the exception of 'the game is giving me under 60 fps/120 fps' but perhaps if your picky enough to want 4xaa you should pick up an antillies when its released and keep on the cutting edge -or- play last years game with medium-edge hardware from this year. -or- play last-last year's games with this years low-end hardware -or- pick a lower resolution monitor.
 
Matrices said:
Are you guys seeing things? The only difference between MLAA and MSAA shots is that there are shadows in the MLAA shot.
Click to expand...

Download them and check then, or check yourself if you have the game. Especially notice the mosaic on the wall. Its like a thin veil has been drawn over it. :) This is not shadows, but focus. Advanced DOF is off. :)
 
Last edited:
Tamlin_WSGF said:
All the math here is based upon recorded framerate. THG recorded framerate for MLAA on and framerate for MLAA off. The performance delta shows how much time that is added to each frame after MLAA process is finished. So, unless MLAA also holds back completed frames(after MLAA has been applied), each frame cannot have more then 0.5872 ms per frame input lag and thats including any performance hit.
Click to expand...
If what I've been saying about the pipeline is correct, then any estimation of input lag based solely on recorded framerate will not be accurate.

The frames will still fly past at 60 frames per second, the recording software will see them fly past at 60 frames per second, THEN they get stuck in the MLAA pipeline which delays their output to the screen.

WBurchnall said:
I think what unknown one is trying to explain is that he believes its similar to where

Two groups of marathon racers of same height, stride length, etc. Almost identical.

In theory, they take these same number of steps (frames) and at the same rate(fps) give or take a very small amount (0.25ms ish) during however long the race course is(how long your playing your game). At the end of the race to the monitor, racers from group A step up onto the podium(displayed on monitor). Unknown-one seems to think that racers from Group B stop to tie their shoes(post-processing effect applied) then step up onto the podium(display on monitor). Therefore although their qualifying times are virtually identical +/- 2 fps there's that added lag of tieing the shoe prior to stepping up on the podium.

In this analogy, each group of marathon racers probably both finished in say 1 hour and 3 minutes. However, the time till podium(display) might be a bit different for those tieing their shoes making the effect of 'they finished later' though the 'recorded times/fps meters/fraps' would show the same-value.
Click to expand...
That's actually rather good. Heh.

WBurchnall said:
Is there somehow to calculate how long the post-processing effect takes once the frame is rendered by the game logic? I know we heard the calculation number of 0.58ms ish thrown around a bunch for MSAA but are these two effects MLAA and MSAA rendered at different points in the rendering pipeline? Could the effect of applying MLAA cause a slight delay in the time it takes for the racers to reach the podium(ie tieing their shoes before getting up to the podium). If so, is there any chance this added delay could be > the 0.58ms from MSAA.
Click to expand...

You would have to measure from the display head on the video card directly, with and without MLAA active (need to get a baseline). Subtract the input lag without MLAA from the input lag with MLAA, then subtract the input lag measured via software.

The input lag measured from the display head will take place after the MLAA pipeline has added its delay (subtract baseline to remove any inherent delay from the hardware). The input lag measured from software will take place before the MLAA pipeline has added its delay. Subtracting one of those figures from the other will tell you exactly how much delay was added in between.
 
Unknown-One said:
If what I've been saying about the pipeline is correct, then any estimation of input lag based solely on recorded framerate will not be accurate.

The frames will still fly past at 60 frames per second, the recording software will see them fly past at 60 frames per second, THEN they get stuck in the MLAA pipeline which delays their output to the screen.
Click to expand...

The video card can only do one thing at a time. If it's working on MLAA, it isn't rendering frames. It is impossible for the framerate to remain the same with MLAA causing input lag. These are not parallel events, they happen in serial.

This is what happens:
Frame 1 gets rendered
Frame 1 gets MLAA
Frame 1 gets shown
Frame 2 gets rendered
Frame 2 gets MLAA
Frame 2 gets shown
Frame 3 gets rendered
Frame 3 gets MLAA
Frame 3 gets show
etc...

This weird fucked up parallel chain you suggest doesn't work and is unnecessarily complicated in the first place.

Now, it is potentially possible that ATI does MLAA in a different CPU thread, which would allow the game logic to begin while MLAA is still being applied. So you'd have something like:
Frame 1 gets rendered
Frame 1 gets MLAA while game processes input for frame 2
Frame 1 gets shown
Frame 2 gets rendered
Frame 2 gets MLAA while game processes input for frame 3
Frame 2 gets shown
etc...

That is at least in the realm of possibility, and may actually make sense since it hides most of MLAA's performance impact, but that still won't add anything close to significant input lag (as in, 1-3ms tops for 60fps).
 
kllrnohj said:
The video card can only do one thing at a time.
Click to expand...
Are you even listening to yourself? GPU's are known for their ability to carry out massively parallel operations.

In fact, GPUs are hugely inefficient when they ARENT doing multiple things at once...

kllrnohj said:
These are not parallel events, they happen in serial.

This is what happens:
Frame 1 gets rendered
Frame 1 gets MLAA
Frame 1 gets shown
Frame 2 gets rendered
Frame 2 gets MLAA
Frame 2 gets shown
[snip]
Click to expand...
Yikes, you really have no idea... Graphics cards would be horribly slow if they had to wait for one frame to be displayed before they could start rendering the next. That's a huge waste of resources.

Whoever told you GPUs are limited to serial operation, please...punch them in the head. You have been lied to.

kllrnohj said:
Now, it is potentially possible that ATI does MLAA in a different CPU thread, which would allow the game logic to begin while MLAA is still being applied. So you'd have something like

[snip]

That is at least in the realm of possibility, and may actually make sense since it hides most of MLAA's performance impact, but that still won't add anything close to significant input lag.
Click to expand...
Yeah, you're not making any sense at all... Why would you attempt to run game logic and MLAA both on the CPU, a processor that's horrible at parallel operations in comparison to a GPU? That would also force you to copy the frame buffer from video RAM to system RAM, then back again. That's a huge and pointless waste of PCIe bandwidth, especially when the GPU could just handle MLAA processing itself, in parallel with rendering.

Not only do you sound completely backwards, but your explanation doesn't even explain or predict all of the visible effects of enabling MLAA. The pipeline theory still makes a lot more sense, and still predicts all of the observed effects.
 
Last edited:
Unknown-One said:
Yeah, you're not making any sense at all... Why would you attempt to run game logic and MLAA both on the CPU, a processor that's horrible at parallel operations in comparison to a GPU? That would also force you to copy the frame buffer from video RAM to system RAM, then back again. That's a huge and pointless waste of PCIe bandwidth, especially when the GPU could just handle MLAA processing itself, in parallel with rendering.

Not only do you sound completely backwards, but your explanation doesn't even explain or predict all of the visible effects of enabling MLAA. The pipeline theory still makes a lot more sense, and still predicts all of the observed effects.
Click to expand...

It's surprising that MLAA has significant Input lag
- as a post-process, I, like most people, would assume it's just added on at the end the normal frame-processing
- and since the drop in framerate is small, this shouldn't add significantly to the Input lag (as others have pointed out above)

So, if there actually *is* more Input lag, then, I think you are right
- it implies a frame-pipeline like you are suggesting
- this is the only real way to get more input lag without a massive drop in frame-rate

Equally, it could very well imply that the MLAA is handled by a separate CPU thread, which controls the running of the DC tasks on the GPU
- and it may be that AMD/ATI found this was the best way to make use of the CPU & GPU resources available, and keep the highest possible frame-rates
- and maybe the pipeline delay is only one extra frame, and the MLAA team thought this would be ok.

To me this is the most plausible explanation of the extra input lag, with minimal frame-rate loss.
- certainly most CPUs these days have spare cores/threads available that could be used, and it may also, that there's some GPU idle time that MLAA can make use of in this situation.......
 
Unknown-One said:
Are you even listening to yourself? GPU's are known for their ability to carry out massively parallel operations.

In fact, GPUs are hugely inefficient when they ARENT doing multiple things at once...

Yikes, you really have no idea... Graphics cards would be horribly slow if they had to wait for one frame to be displayed before they could start rendering the next. That's a huge waste of resources.

Whoever told you GPUs are limited to serial operation, please...punch them in the head. You have been lied to.

Yeah, you're not making any sense at all... Why would you attempt to run game logic and MLAA both on the CPU, a processor that's horrible at parallel operations in comparison to a GPU? That would also force you to copy the frame buffer from video RAM to system RAM, then back again. That's a huge and pointless waste of PCIe bandwidth, especially when the GPU could just handle MLAA processing itself, in parallel with rendering.

Not only do you sound completely backwards, but your explanation doesn't even explain or predict all of the visible effects of enabling MLAA. The pipeline theory still makes a lot more sense, and still predicts all of the observed effects.
Click to expand...

The CPU has to prepare the frames before they go to the GPU, this is what the render ahead limit is in your drivers. The driver will buffer calls for up to so many frames for the GPU to try and avoid stalling the CPU. Your GPU won't just go running rampant on its own rendering tons of frames because it can, it needs to be fed by the CPU.

MLAA was originally convinced as CPU code afaik (by Intel, no less), it being brought over to the GPU is a recent development. CPUs can have SIMD units too, and as core counts rise, doing something like MLAA on a x86 CPU isn't as far fetched as you might think... especially with the advent of on board GPUs.

The GPU being parallel doesn't mean it can go off and do whatever as it pleases, it has a massive pipeline with a ton of latency behind it, it being so parallelized is why it can hide it as well as it does.
 
I find it funny ya'll are complaining about input lag on an unqualified hack driver in an unqualified Radeon HD 5xxx usage scenario.

Once AMD delivers Radeon HD 5xxx compatibility and an official driver update, and there is input lag, then you'd have an issue.
 
Unknown-One said:
Are you even listening to yourself? GPU's are known for their ability to carry out massively parallel operations.

In fact, GPUs are hugely inefficient when they ARENT doing multiple things at once...
Click to expand...

No, you misunderstand. Yes, GPUs are massively parallel, but they can only do one "thing" in the sense of a task as a whole. If the card is doing MLAA, it isn't doing *anything* else. The ability to run multiple kernels is actually a feature Nvidia was showing off on Fermi for GPGPU.

If you understand processes and threads, think of it like this. A GPU can have many threads, but only one process.

Yikes, you really have no idea... Graphics cards would be horribly slow if they had to wait for one frame to be displayed before they could start rendering the next. That's a huge waste of resources.
Click to expand...

Uh, actually they do and always have. Both DirectX and OpenGL will block until rendering is complete when the game tries to swap buffers (they have to - there is only a single render buffer). Multiple frames are never in the pipeline simultaneously for a couple of reasons:

1) That is ridiculously complex
2) That would hurt performance because you now have the overhead of managing all that without gaining anything
3) Allowing multiple frames simultaneously means multiple buffers. This might not matter quite as much now, but go back even just a couple of years and multiple buffers would eat up practically all the VRAM.

Whoever told you GPUs are limited to serial operation, please...punch them in the head. You have been lied to.
Click to expand...

Sure, I'll just call up Nvidia, ATI, Microsoft, and Kronos and tell them that they have no idea how video cards or rendering works. Let's just ignore the fact that they, you know, make the cards, drivers, and specs. Clearly they don't have a clue what they're doing.

Yeah, you're not making any sense at all... Why would you attempt to run game logic and MLAA both on the CPU, a processor that's horrible at parallel operations in comparison to a GPU? That would also force you to copy the frame buffer from video RAM to system RAM, then back again. That's a huge and pointless waste of PCIe bandwidth, especially when the GPU could just handle MLAA processing itself, in parallel with rendering.
Click to expand...

Again, you misunderstand (although I admit I wasn't very clear on this). GPUs have to be managed by a CPU thread. They can't run off and do their own thing. What I meant was when the buffers are flipped (and thus rendering is complete), the driver fires up a CPU thread to manage the MLAA process while allowing the game to continue doing it's thing (processing input, etc...). As soon as the first graphics call comes in, though, it would need to block until MLAA is finished.

Not only do you sound completely backwards, but your explanation doesn't even explain or predict all of the visible effects of enabling MLAA. The pipeline theory still makes a lot more sense, and still predicts all of the observed effects.
Click to expand...

Uh, my explanation works just fine. Your explanation makes no sense because it is a very radical departure from what happens without MLAA on, and has no benefits. ATI has some pretty smart cookies. They aren't going to spend a ton of time creating a complicated pipeline system just to slow things down, that makes no sense whatsoever.
 
WBurchnall said:
I think I'd go with no MLAA over MLAA.

The wall looks like its lost detail/sharpness. I'm not sure if that might be DoF effects being applied? but it seems shaper looking at the wall. Like you can see the cracks in the wall-paper/paint more clearly defined. MLAA seems to have blurred the fine details and I don't notice a huge difference in the books tbh.

I did notice a huge difference in the straight-ness of the edge of the book with 4xaa. It actually looks like a flat-edge as opposed to a jagged edge. MLAA looked like a jagged edge with 2 less jags but jaggeded nonetheless. Granted there's almost no performance loss with MLAA compared to 4xaa but ... there seems to be almost no clear-advantage. It feels much more like a trade-off. Here you can have slightly sharper books but everything else will be blurry or you can have a large performance hit and all your edges will look great.

Really, why not turn on 4xAA? with the exception of 'the game is giving me under 60 fps/120 fps' but perhaps if your picky enough to want 4xaa you should pick up an antillies when its released and keep on the cutting edge -or- play last years game with medium-edge hardware from this year. -or- play last-last year's games with this years low-end hardware -or- pick a lower resolution monitor.
Click to expand...

I'm just making an observation. AA looks better overall but the MLAA looks decent also. The card I have now is just a stop gap, I will have more than enough GPU power this coming December like my other rigs.
 
The following is from Exploring Input Lag Inside and Out - AnandTech (2009)


--- Cut ---

Realworld Testing w/ High Speed Video

First we'll look at the case with no vsync. Look for when the finger stops moving to when the shotgun blast appears on the wall (Valve makes sure to calculate the hit before it even starts the gun firing animation; sometimes hit and gun fire happen in the same frame, sometimes they are one frame separated). This certainly isn't frame by frame, but you should be able to download the clip from youtube and step through it yourself if you are so inclined.

Video (vsync off) @ YouTube.com

This test took about 45 frames: between 37ms and 38ms from input generation to display. This is very good considering what we predicted as a best case. Average over multiple runs was a little higher, resulting in 51ms of typical input lag plus or minus about 12ms (our maximum being 63ms). This fluctuation is due to how all the factors we talked about either line up or don't.

When we turn on vsync, we see a lot more delay.

Video (vsync on) @ YouTube.com

We can see even better how the hit happens before the gunfire animation again. This is very key in any twitch shooter. The lag is significantly longer with vsync enabled. This example shows about 94 or 95 frames (~79ms) input lag, which was our lowest input lag time in this test. Our average was about 89ms ranging up to 96ms at maximum. In this case, we lose the input latency advantage of no vsync but we gain more consistent input lag times and no tearing.

--- Paste ---


So... who has access to high speed equipment?
Bickering and speculation is getting this thread nowhere fast.
 
Snowdog said:
Looking at this German review MLAA is actually a lot more expensive than the previous impression I had.

http://www.computerbase.de/artikel/grafikkarten/2010/bericht-radeon-hd-6800/4/

It seems to take a much higher FPS hit than many other methods. I thought the whole point was that this was a lightweight method.

Not so impressed now.
Click to expand...

Honestly, it depends on the game, and the level of shader intensity in the game, and the level of alpha textures when being compared to Supersampling AA in the game. There are variables.

I'm finding that it is about the same performance hit as going from No AA to 8X MSAA or going from No AA to 2X Adaptive Supersampling AA. It is faster than 4X and 8X Adaptive Supersampling however, in my testing.

There is a bug btw in the current 10.10c driver that is causing it not work in DX10/11 games because the option doesn't stick in the driver even if it does show as checked, and there will be a hotfix driver out next week to fix this.

We are going to use the feature in all reviews where appropriate, so what you see in my article next week is an in-depth look at performance and IQ in one game where it works flawlessly, but we will use it in other games in our full retail video card reviews.
 
Digital Viper-X- said:
well from the SS

MLAA looks better then 8xaa
Click to expand...

Its game dependent, but I agree. In some games MLAA looks better then any MSAA in game. MLAA gives a full-scene anti-aliasing, while MSAA sometimes have jaggies everywhere that never goes away.

Edit:
I looking very much forward to [H]'s MLAA review Brent! When is it due? :)
 
Last edited:
Tamlin_WSGF said:
Its game dependent, but I agree. In some games MLAA looks better then any MSAA in game. MLAA gives a full-scene anti-aliasing, while MSAA sometimes have jaggies everywhere that never goes away.

Edit:
I looking very much forward to [H]'s MLAA review Brent! When is it due? :)
Click to expand...

Monday, working as hard as I can captain! We'll get there, even if I have to get out and push!
 
Brent_Justice said:
Monday, working as hard as I can captain! We'll get there, even if I have to get out and push!
Click to expand...

LOL! :D

I think many are looking forward to this and hopefully it will kill some of the myths of what it can and cannot do. Love [H]'s reviews, since they focus on what it actually gives you in games, the good, bad and ugly. :p
 
Tamlin_WSGF said:
LOL! :D

I think many are looking forward to this and hopefully it will kill some of the myths of what it can and cannot do. Love [H]'s reviews, since they focus on what it actually gives you in games, the good, bad and ugly. :p
Click to expand...

Be warned up front, it doesn't cover a lot of games, the time wasn't there, and I encountered a bug that kept me from looking at it in DX10/11 games, but that bug will be fixed in a driver hotfix coming next week. It worked flawlessly in every DX9 game I threw at it though. We'll use the feature in full retail video card reviews where appropriate, just like any other AA setting. So if you your questions aren't answered in the article next week, perhaps they will be in subsequent video card reviews. And you can of course ask me, and I'll do my best to answer them with what I know about the technology. The article will be in two sections, performance and IQ, I've looked at performance scaling on a 6850 and a 6870, and then compared both cards against each other with MLAA, and then IQ comparisons.

I'm hoping to do even more with it when the 6900 series is out, I'm not expecting the kind of performance hit I'm seeing on the 6800 series.
 
Brent_Justice said:
Be warned up front, it doesn't cover a lot of games, the time wasn't there, and I encountered a bug that kept me from looking at it in DX10/11 games, but that bug will be fixed in a driver hotfix coming next week. It worked flawlessly in every DX9 game I threw at it though. We'll use the feature in full retail video card reviews where appropriate, just like any other AA setting. So if you your questions aren't answered in the article next week, perhaps they will be in subsequent video card reviews. And you can of course ask me, and I'll do my best to answer them with what I know about the technology.
Click to expand...

What I am hoping for, is more of a "when to use it and when not" with a few games as examples of do's and don'ts. :)

From what I have seen with the hacked drivers, MLAA is not an "end all AA method", but very nice to use in some games and others not. Especially in places where MSAA leaves a lot of jaggies, even on high settings. SSAA can be used sometimes, but doesn't always work and gives a huge performance hit. MLAA is a good middle road there.

Edit: I've heard rumors that 6900 series brings some kind of edram? Any truth to that?
 
Brent_Justice said:
I have no idea, but eDRAM would be nice indeed.
Click to expand...

That would have been sweet. Its the "off chip buffer" hint that makes people believe that there might be edram. Of course, it could also mean some new GDDR memory swapping, since GDDR 5 have some new features there, but most think edram due to AMD's Xbox 360 GPU and bandwidth. :)
 
Tamlin_WSGF said:
That would have been sweet. Its the "off chip buffer" hint that makes people believe that there might be edram. Of course, it could also mean some new GDDR memory swapping, since GDDR 5 have some new features there, but most think edram due to AMD's Xbox 360 GPU and bandwidth. :)
Click to expand...

If it's eDRAM, it wouldn't be an "off chip" buffer.
 
Brent_Justice said:
Be warned up front, it doesn't cover a lot of games, the time wasn't there, and I encountered a bug that kept me from looking at it in DX10/11 games, but that bug will be fixed in a driver hotfix coming next week. It worked flawlessly in every DX9 game I threw at it though. We'll use the feature in full retail video card reviews where appropriate, just like any other AA setting. So if you your questions aren't answered in the article next week, perhaps they will be in subsequent video card reviews. And you can of course ask me, and I'll do my best to answer them with what I know about the technology. The article will be in two sections, performance and IQ, I've looked at performance scaling on a 6850 and a 6870, and then compared both cards against each other with MLAA, and then IQ comparisons.

I'm hoping to do even more with it when the 6900 series is out, I'm not expecting the kind of performance hit I'm seeing on the 6800 series.
Click to expand...

odd. I haven't noticed a big performance hit from it. then again it might explain why I don't notice it in some games. (I will have to try crysis in in DX9 and see what it does.) other games it seems to do well in. (I am using the hacked driver for the 5870)
 
Snowdog said:
If it's eDRAM, it wouldn't be an "off chip" buffer.
Click to expand...

Normally no, but the speculation started with this I think and they've called it eDRAM (though it might be some other memory buffer). As always with rumors, information gets mixed up in each other.

Here you can see from Chinese the rumors as well, this time not connected to "off chip buffer":

It is said that Cayman has 64M eDRAM, PCI-E seem to remember also mentioned that Cayman has a large chip cache, it appears that the high credibility, ah, just did not expect 64M actually have such a big, I do not know true or false.

eDRAM stands for "embedded dynamic random access memory", which is based on dynamic random access memory capacitors. Based on the external DRAM module or different transistor SRAM, eDRAM is usually integrated with the main ASIC or processor in the same die (die) or package. This embedded feature provides a wider bus and faster operating speeds. Because DRAM has a higher density than SRAM and, therefore, be able to use a larger number of memory. However, the manufacturing process to integrate the different makes it difficult to die, so few die must be packaged in a chip which raises the cost increase. By using a standard CMOS process to manufacture eDRAM, the latest development to eliminate this restriction, for example, in the 1T-SRAM is the case.

Does AMD want to rely on this to the L2 Cache and Fermi than performance? ? ? ?
Click to expand...

source

Its a bit OT though and I brought it up since Brent mentioned the 6900 vs. 6800 and MLAA performance hit. :)
 
MLAA wouldn't be affected by eDRAM though, its a shader thing. The more stream processors, the merrier in essence.
 
Brent_Justice said:
MLAA wouldn't be affected by eDRAM though, its a shader thing. The more stream processors, the merrier in essence.
Click to expand...

According to Dave Baumann, they used LDS for buffering to avoid roundtrips to memory. Wouldn't eDRAM increase the buffer without lowering bandwidth too much? I posted this earlier in this thread:

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.
Click to expand...
http://forum.beyond3d.com/showpost.php?p=1487070&postcount=4199
 
You must log in or register to reply here.
Back
Top