Hi
As my engine uses defered shading - the antialiasing support is pain in the ass 
I render GBuffer to my multiple color attachment with MSAA
but in the second phase of defered shading I need the access to individual samples from albedo and normal map texture.
GL_EXT_framebuffer_blit provides resolve from MSAA rendebuffer to texture - but the sample information is lost.
Is there any extension to access individual samples of MSAA renderbuffer in shader ? (hardware is capable couse dx10 contains such a thing and it works fine - but iâm doomed to opengl right now 
)
slightly offtopic:
is there any way to use it with CG or it is available only thru native glsl shaders ? (i use gp4fp profile to compile my CG shaders)
Any working example would be great
Olso is this extension (or similar one) exist on high-end ATI hardware ? I do not have ATI at the moment to check :/.
AFAIK ATI doesnât provide this extension or something similar ATM.
However i am pretty sure the ARB is working on a standardized version of it.
Jan.
No, on ATI currently there is no feature to access individual samples of MSAA renderbuffer in OpenGL.
Donât know about CG. I do not see any point of using it instead of GLSL which is in OpenGL core.
I do not see any point of using it instead of GLSL which is in OpenGL core.
One good point is that Cg API is usable with OpenGL AND DirectX unlike the glsl one and it avoid you to rewrite your shaders if you have to support opengl and directx api.
Additionally, with Cg you get âprecompiled shadersâ support and potentially run-time shader compilation support âin the backgroundâ.
For those thatâd like to:
- load/activate materials/shaders from disk at run-time to support extended flights through large databases, OR
- support dynamically changing major rendering engine display modes
âŚwithout breaking frame and without having to know and precompile at startup the plethora of all shaders permutations for all possible materials, Cg is really the only OpenGL-supporting high-level shading language option right now that stands a shot.
As youâd expect, compiling and optimizing high-level language shaders like GLSL is slooowww and totally impractical in the foreground at run-time in the draw thread⌠âŚthat is, unless you donât mind your user thinking your application is trash because it locked up for a while. In our world, thatâd be an instant bug report that had to be fixed at high priority.
Perhaps we could all lobby the other vendors to implement the latest Cg version or even to make Cg a replacement for GLSL⌠
disappears behind wall of stone
Well the CG is the only reasonable shading language if *nix and windows needs to be supported, as Dark Photon says - if a lot of shaders need to be compiled / loaded in rendering thread and shaders are loooooong - glsl compilation time can take few minutes (!!!) and CG allows them to be precompiled and just loaded within few hundret of ms.
CG works (almost) fine on ATI HD Radeons.
