Custom AA Resolves

Does anyone know anything about a similar extension for OpenGL/GLSL to access the Samples of a MSAA Rentertarget like in that presentation page 50 to 53:

http://developer.amd.com/assets/Riguer-DX10_tips_and_tricks_for_print.pdf

I would help much to add MSAA to a deferred renderer…

Don’t see anything yet. I’ll bet we’ll see something like this in the LP/ME time frame.

Shame they screwed the pooch on DX10 for XP.

I’d hate to have to market DX10 cards to developers and users when it’s roadblocked by Vista penetration (an OS with a 3D desktop that only needs DX9), what a disaster.

Just one more reason why you don’t want to rely on an API controlled my Microsoft for your hardware interface. This manipulative debacle that screws curtomers and OEMs is right up there with their OpenGL MCD U-turn debacle.

I think this feature is only available on ATI hardware, so I don’t think we are going to see this feature soon, since ATI don’t care about OpenGL.

AFAIK, ATI hardware has no specialised resolve units, AA is done via shaders internally, while G8x still has “real” hardware AA. Custom resolve is still possible on G8x, but results in poorer performance then the competitor. The “Call of Juares” DX10 benchmark is an example.

The problem is that the only possible AA mode for a deferred renderer is a 4x supersampling without a rotated grid (double the Gbuffer width and height and use a bilinear filter) The quality is ugly, because there’s no rotated grid for the samples.

With MSAA and “slow” custom resolves there are some advantages for a deferred renderer (4x MSAA compared to the 4x SSAA):

  • The GBuffer filling could be (a little bit) faster, because the shader load is only 1/4
  • The rotated grid
  • Lighting can be accelerated by skipping fragments in areas without polygon borders
  • Transparent AA could work (Transparency is possible too)
  • CSAA (16x with 4 color samples) could raise the antialiasing quality extreme, if it’s possible to write the samples into a “MSAA” colorbuffer like with a multiple render target (read 4 samples + write 4 samples)

With that features, the last arguments for a forward renderer are completely obsolete

Since deferred renderers seem to be the way of the future, this is a logical feature to add. The sooner the better.

Is anyone paying attention to this issue?

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.