AA in titles that don't support traditional MSAA.

[Silent_Buddha]

Recently I had a chance to try out the 8.38 release 7 drivers on my HD 2900 XT. And I've noticed that in games where traditional MSAA isn't supported the wide and narrow tent is still applied if AA is forced through the drivers.

Thus in a game like, for example, Vanguard, I still get a very minimal amount of AA, although in this partcular title Wide Tent with no MSAA isn't very useful other than for some of the alpha textures. IE - Wide tent by itself without MSAA appears to my eye to be somewhat less than 2xMSAA for edges.

The question I have is.

Since the shader/ALU part of this AA algorhythm is being used, is it possible to come up with an efficient way for a completely shader based AA algorhythm to provide AA in titles that don't support tradition MSAA?

I certainly don't mind the performance hit if it allows me to use AA in games that I'm currently avoiding due to no AA.

To get away from the general question for a moment and to something a little more specific.

Considering the R600 has an excess of theoretical ALU power and a "fast path" from the RBEs to the ALU arrays, is this something that could reduce the performance hit of doing AA completely in shaders through the drivers?

Regards,
SB

 

[AlexV]

You can do supersampling in the shaders, for example, but that`s an unrealistic solution. Edge detection in order to apply proper AA via shaders is costly to implement(you`d have to use derivatives&other stuff), so, overall, whils it is certainly possible to achieve AA with shaders, it`s unlikely to be implemented, IMHO.

 

[Novum]

The driver is likely just doing a blur then.

You can't do real antialiasing as a postfilter, because the informations are already gone.

 

[CarstenS]

Recently I had a chance to try out the 8.38 release 7 drivers on my HD 2900 XT. And I've noticed that in games where traditional MSAA isn't supported the wide and narrow tent is still applied if AA is forced through the drivers.

Not only that! I've noticed that if you turn off AA in the driver but forget to change the tents back into box and enable AA for example in source-engine-games you also get the super-blurry-blurry-thing.

Caused me major headache because just then i was doing screenshot for comparision and at first i could not figure out why the HD2900 was so blurry when -supposedly - just 4xAA was enabled.

 

[AlexV]

Yup, that`s a nuisance... I`m guessing they`ll sort it out with future driver revisions, but now they have other things to focus on WRT drivers.

 

[Silent_Buddha]

Ouch I hadn't noticed that yet since I haven't put AA to application preference in a while. I'm slowly going through the games I occasionally play to see which ones benefit from a wide or narrow tent and which ones don't.

Hopefully that get that sorted out, as from what I've seen so far, without MSAA then wide and narrow tents by themselves don't offer much.

IE - I still won't be playing the lastest Ghost Recon as the AA from just wide or narrow tent alone still won't make that a good looking game. It's a shame as I was a fan of the series. But no AA is a killer and an easy no-buy/no-play decision for me. I just wish I didn't have a lot of friends playing Vanguard. The jaggies there are driving me nuts also.

In other words, I would KILL...for a shader based AA approach even if it halved performance.

Regards,
SB

 

[Malo]

Does the AA on the 2900XT in Vanguard work regarding the overlapping of invisible boxes on the NPC names Silent_Buddha?

 

[Silent_Buddha]

Actually AA+wide or narrow tent have an interesting side effect in Vanguard right now. I haven't tried with just regular MSAA no tent.

If you enable it, you can see names through walls and terrain. It's a bit of an annoyance.

I'm not sure why it would do this.

Regards,
SB

 

[Malo]

AA in Vanguard is basically broken, it does very strange things with Z resolve for NPC names. I assume thats the problem, I'm far from an expert though.

 

[OpenGL guy]

AA in Vanguard is basically broken, it does very strange things with Z resolve for NPC names. I assume thats the problem, I'm far from an expert though.

Typically, Z is not resolved. That's usually problematic for games using the same Z buffer for rendering to the back-buffer as to textures (textures aren't typically AA'ed).

 

[Jawed]

Typically, Z is not resolved. That's usually problematic for games using the same Z buffer for rendering to the back-buffer as to textures (textures aren't typically AA'ed).

I don't understand what's going on here, anyone care to explain?

Jawed

 

[OpenGL guy]

I don't understand what's going on here, anyone care to explain?

Let's say your application creates the following surfaces:
Front buffer+back buffer
Z buffer
Renderable texture

The app may render to the back buffer, then switch to the texture while using the same Z buffer expecting the contents to be maintained. If you've forced AA through the control panel, this doesn't work because the Z data is in the AA Z buffer and textures don't normally get antialiasing. Z data is not resolved.

When application AA is used, the application will handle this by creating an additional render target with AA. Instead of switching to the texture for rendering, the app will change to this additional AA render target. When the data is needed as a texture, they can copy this AA data to the texture before rendering.

 

[Jawed]

Thanks, I was trying to "misinterpret" what was said earlier as though the final AA resolve pass was somehow being done incorrectly.

Jawed