MSAA rendertargets on ATI hw

[NeARAZ]

I'm doing HDR+AA demo for ordinary DX9 hardware, and it seems that I've got some problems getting MSAA'd rendering on ATI hardware. I've got no Radeon here at the moment, so testing is hard...

What I'm doing is:
* render to MSAA'd backbuffer (A8R8G8B8, RGBE8 encoding)
* StretchRect to same sized RT (using D3DTEXF_NONE - maybe filter is the problem?)
* Do all this HDR stuff (tone mapping, blooms etc.)
* Finally, draw fullscreen quad over the backbuffer

MSAA works perfectly on my GF 6800GT. One person said it also works perfecly on Radeon 9800Pro. However, three other "testers" said they see no MSAA effect on various Radeons (9800Pro, 9600XT, some FireGL).

Some results (radeon, radeon-4xAA, geforce, geforce-4xAA):


The radeon results are different, but I can't say that they're differ in "quality". It seems that samples are offset - like backbuffer-to-RT StretchRect would take only one sample or something.

Any ideas?

 

[Joe DeFuria]

Are people trying to force AA on via the control panel, rather than setting the control panel to "application preference", and then setting AA in the app?

 

[Xmas]

I think you should ask the testers to update their drivers. This StretchRect bug with MSAA surfaces was only fixed recently.

 

[NeARAZ]

I think you should ask the testers to update their drivers. This StretchRect bug with MSAA surfaces was only fixed recently.

I've done that. They say no difference, even with Catalyst 5.10 installed

 

[ehart]

Well, off the top of my head, I can think of two things that might be burning you here. The first one is that IIRC, some R3xx and/or R4xx cards treat the alpha channel differently than the color channels when multisampling. You might want to try visualize the results of the multisampled alpha to see if that is where this is creeping in. The other one you might be getting burned by is the gamma-correct resolve. Since you are handling the remapping, it really isn't necessarily the right thing to do. You can effectively end up getting double gamma'ed, and that can look as bad or worse than not doing anything.

Finally, are you sure that multisampling RGBE as RGBA reliably provides reasonable results? Off the top of my head, I expect some fairly odd results at pixels containing a harsh transition.

-Evan

 

[LeGreg]

yes, maybe try passing D3DTEXF_LINEAR even if it doesn't really make sense.

Also, for the RGBE filtering, you can't of course guarantee that filtering RGBE as RGBA will give you the "expected" result (unless you're willing to sacrifice accuracy for performance and the end result pleases the eye enough). But if you're looking for accuracy then you could
always try to stretchrect to a four times larger (or more depending on how much you're multisampling) render target texture then in the pixel shader that does the tonemapping you can read four values there and take the mean value from the result of the tonemapping pass. (warning this is implementation dependant, since you can't guarantee where the additional samples are in theory)

 

[NeARAZ]

some R3xx and/or R4xx cards treat the alpha channel differently than the color channels when multisampling. You might want to try visualize the results of the multisampled alpha to see if that is where this is creeping in.

Might be this... However visualizing them is kind of hard when all I have is a Geforce

The other one you might be getting burned by is the gamma-correct resolve.

But even if it's gamma-ing me, there should be some AA-like things visible (gamma curve is still a monotonic one). Right now the images look like no AA at all, just with pixels shifted in some places.

Finally, are you sure that multisampling RGBE as RGBA reliably provides reasonable results? Off the top of my head, I expect some fairly odd results at pixels containing a harsh transition.

Yes, it's plausible - i.e. looks definitely better than without multisampling. I just make sure that exponent does not use full -128..127 range - instead it uses something like -32..31 or -64..63, leaving a couple of bits for smooth interpolation.

Also, for the RGBE filtering, you can't of course guarantee that filtering RGBE as RGBA will give you the "expected" result (unless you're willing to sacrifice accuracy for performance and the end result pleases the eye enough).

Yes, but a (bi)linear filter or discrete MSAA is a hack anyway; so changing one hack (linear interpolation) to another hack (RGBE interpolation) does not place you farther from The Truth The results I get are fairly good looking.

 

[Colourless]

Something I noticed ages ago was that on my 9700 PRO was MSAA rendertargets only work properly if the rendertarget buffer was the same dimentions and multisample type as the backbuffer

 

[OpenGL guy]

I'm doing HDR+AA demo for ordinary DX9 hardware, and it seems that I've got some problems getting MSAA'd rendering on ATI hardware. I've got no Radeon here at the moment, so testing is hard...

What I'm doing is:
* render to MSAA'd backbuffer (A8R8G8B8, RGBE8 encoding)
* StretchRect to same sized RT (using D3DTEXF_NONE - maybe filter is the problem?)
* Do all this HDR stuff (tone mapping, blooms etc.)
* Finally, draw fullscreen quad over the backbuffer

MSAA works perfectly on my GF 6800GT. One person said it also works perfecly on Radeon 9800Pro. However, three other "testers" said they see no MSAA effect on various Radeons (9800Pro, 9600XT, some FireGL).

One thing you might have problems with is that older (pre-X1000)HW doesn't resolve the alpha channel of MSAA buffers. The rest of your algorithm seems fine, but, without looking at it under the debugger, I can't say for sure.

Also, it'd be good to look at the output from the debug runtime and see if there are any clues there.

One thing you could try is creating the device without MSAA and then creating an MSAA render target. Then copy the contents of that buffer to your texture and do your tonemapping, etc. as you render to the backbuffer.

 

[NeARAZ]

I released the demo here: http://nesnausk.org/nearaz/projHDR.html

MSAA works on geforces, and I'm not sure about radeons. Could anyone test it?

 

[NocturnDragon]

I released the demo here: http://nesnausk.org/nearaz/projHDR.html

MSAA works on geforces, and I'm not sure about radeons. Could anyone test it?

No AA on a 9800 XT with cat 5.10

 

[jpaana]

D3DTEXF_NONE is valid only for mip filter selection, D3DTEXF_POINT is probably what you want for minification and magnification?

 

[NeARAZ]

D3DTEXF_NONE is valid only for mip filter selection, D3DTEXF_POINT is probably what you want for minification and magnification?

This is in StretchRect context, filter meanings are a bit different than when sampling textures (basically, NONE filter for StretchRect means "use anything you have, I don't care").