Cube and shadow multisample textures

[JoshKlint]

I was disappointed when I tried to use multisample textures for my shadowmaps, for 2D and cube shadowmaps. It doesn't appear there is support for these texture types:

• sampler2DShadowMS
• samplerCubeMS
• samplerCubeShadowMS

Why not? Shadowmaps are a great application for multisample textures. We could perform fewer texture lookups in the lighting fragment shader, and shadow maps could be lower resolution and use less memory.

[Nowhere-01]

First of all, you could just use multisampled depth-texture or you could render depth to a regular texture with a simple fragment-shader.

Why not?

Well, probably, because there's no high demand for such feature. Multisampling for shadow maps makes very little difference and it makes sense only on rare occasions, when shadows are supposed to be very sharp and shadow map is almost pixel-perfect. If you make any shadow filtering, multisample would be a waste of resources contributing little to nothing to shadow quality. I don't think anybody in the industry uses it for shadow maps. Even MSAA by itself is not a very widely used feature now, it's tricky to implement with deferred rendering.

and shadow maps could be lower resolution and use less memory.

Actually, MSAA uses additional memory to store each subsample. Your memory consumption will be directly proportional to MSAA factor. It just executes fragment shader for sub-samples only when it's required. Unlike supersampling, where it's just you rendering scene at higher resolution and executing fragment shader for each extra sample. Otherwise it's kinda same as supersampling. Is such memory consumption acceptable for shadow-maps? No. Just no.

[JoshKlint]

Even MSAA by itself is not a very widely used feature now, it's tricky to implement with deferred rendering.

Why would you say such a silly thing? It's extremely easy to set up MSAA with deferred rendering. I have it running right now. It would take me about five minutes to add this to shadowmaps, if OpenGL supported it.

Actually, MSAA uses additional memory to store each subsample.

MSAA uses less memory than super-sampling the image. MSAA uses a randomly rotated grid for texture lookups. An MSAA 2x texture uses twice the memory as a plain texture of the same size, while SSAA would use 4x the memory.

[Nowhere-01]

Why would you say such a thing? It's extremely easy. I have it running right now. It would take me about five minutes to add this to shadowmaps, if OpenGL supported it.

Do you just make all your G-Buffer render-targets MSAA? That's not tricky, neither it is efficient. It is, again, a huge waste of memory. Google "deferred MSAA"(if you didn't use this approach already). It's not exactly rocket science, but it's still not just changing texture format. And it's not gonna be that fast.

MSAA uses less memory than super-sampling the image. MSAA uses a randomly rotated grid for texture lookups. An MSAA 2x texture uses twice the memory as a plain texture of the same size, while SSAA would use 4x the memory.

Well... Did you compare 4x MSAA to just 2x bigger texture for shadow-map? And do it with at least some filtering. And see, if it looks any better and if it makes much sense to use it. MSAA fixes some portion of aliasing, it's not going to provide any significant details, like resolution does. And generally, for shadow maps, latter is determinant, you always grasp for it. And i'm even not sure, that, equivalent MSAA is going to be any faster, than SSAA in that case(for rendering to SM with pass-through fragment shader). But you may test it and share results.

[Dark Photon]

Even MSAA by itself is not a very widely used feature now, it's tricky to implement with deferred rendering.

The latter is true, but what are you basing the former assertion on? Deferred has its advantages on some hardware and shading scenarios, but is far from the silver-bullet take-all winner, for AA, transparency, and other reasons.

MSAA uses less memory than super-sampling the image.

No, MSAA memory consumption is about the same as SSAA. Theory and practice (verified with your favorite GPU memory info extension) should reveal this; at least it does for me.

MSAA... It just executes fragment shader for sub-samples only when it's required.

Don't think so. AFAIK, the fragment shader is not run per-sample with standard MSAA, even for edge pixels. It is run at most once per pixel.

The kicker is that within pixels which contain an edge, fragments from different triangles set only the subset of samples that are within the bounds of their respective triangle, so you get multiple fragments per pixel affecting the final downsampled color. A single fragment (fragment shader execution) could set (or affect, if blending is enabled) anywhere from 0 to N samples within a pixel, for Nx MSAA.

[Dark Photon]

... G-Buffer render-targets MSAA? ... it's not gonna be that fast.

Have you done some reading and tried it (e.g. Killzone 2 technique)? You might be surprised. If your GPU has plenty of memory bandwidth, and your lighting and shading isn't hideously complex, it's surprisingly efficient. And even that's without the complexity of Lauritzen-style GPU-thread repacking to avoid SIMD efficiency in an effort to extract the full "MSAA shading speedup".

And i'm even not sure, that, equivalent MSAA is going to be any faster, than SSAA in that case(for rendering to SM with pass-through fragment shader). But you may test it and share results.

I have some of the same reservations/questions there. You might get some MS bandwidth compression reading from and writing to pixels which have the same value stored for multiple samples over a raw SS render target though. Please do share any interesting results!

[Nowhere-01]

The latter is true, but what are you basing the former assertion on? Deferred has its advantages on some hardware and shading scenarios, but is far from the silver-bullet take-all winner for AA, transparency, and other reasons.

To be fair yes, i've misjudged, MSAA is still quite often available as an option as well as it's expansion - CSAA(which i didn't know was based on MSAA, it never caught my attention). But you can see FXAA and MLAA more and more often. Because they're a lot simpler to implement and don't affect your engine's rendering pipeline at all. They make a lot more sense for tight deferred pipeline(and today a lot of games use it or it's derivations). But post processing antialiasing is not very precise, it has it's problems. But so does MSAA, it's quite bad in comparison with pure supersampling, it doesn't handle transparency in any way and it suffers from moire. It's not suitable for OMG_HD_4K_TEMPORAL_ANTIALIASED_VSYNC_3MONITOR lunatics\fetishists as well.

Have you done some reading and tried it (e.g. Killzone 2 technique)? You might be surprised. If your GPU has plenty of memory bandwidth, and your lighting and shading isn't hideously complex, it's surprisingly efficient. And even that's without the complexity of Lauritzen-style GPU-thread repacking to avoid SIMD efficiency in an effort to extract the full "MSAA shading speedup".

i had a glimpse on pdf. but it doesn't specify, how MSAA affects memory consumption on PS3. making full MSAA G-Buffer seems crazy on PS3 with it's extremely tight memory constraints. But i can't spot the part, there they specify, what textures use MSAA, but i'm a bit tired right now(i think i'd better shut up and go to sleep now). They do simplify algorithm itself, sacrificing quality(it may be not noticeable at all, because lightning is very soft, without specularity and rough surfaces). but G-buffer size brings questions.

And initial question was about shadow map MSAA, maybe it makes more sense to you... OP didn't elaborate much on how does he think it should improve shadows in real scenario.

[JoshKlint]

I'm not sure how faster shadow antialiasing and lower memory usage need to be elaborated. The benefits seem pretty obvious to me. I just assumed they would be supported and was surprised when I tried to implement them and couldn't.