Depends on the change – some are on the fly, some require restart, some force reload all scenery.

Changes in X-Plane 10 will also need a restart or they will be applied “on-the-fly”?

X-Plane 9 uses the hardware FSAA provided by the card. You must restart X-Plane to see the effect.

Now I understand a bit about X-Plane 10 anti-aliasing, it begs the question, how does it work in X-Plane 9? To be honest, I could never see the effect of changing the rendering setting, anti-alias level.

fair enough, guess this will be December

Well, for what it’s worth, CSAA has 4 real color samples, so probably the API would just claim “yeah you have 4 color samples” and off we go…I think there’s no way for a deferred implementation to get access to the coverage information when it needs it, but such is life.

Ah, CSAA – Completely Secret AA. As I understand it it should ideally be comparable to my ‘ideal’ MSAA description. CSAA may mess up occasionally, but the result should be comparable regardless of the type of rendering. Performance should be comparable to MSAA (yeah, the deferred work would probably be done pretty much directly on the color values). But then, being primarily a Mac user, I haven’t even seen CSAA in action yet.

I should read some of the newer specs to get a clearer image myself, at least of what the API allows…

If the GPU is using something like CSAA, the number of coverage samples may be larger than the number of color samples. I suppose this would be exposed via the smaller color table. (When I last read the CSAA notes I mistakenly thought they had separated the number of color and depth samples; this is clearly not the case.)

Whether this matters is a question of whether the deferred renderer is bottlenecked on raster ops/internal bandwidth or shader ops. At this point I don’t know which one we’re using more of, relative to card capacity.

I have actually seen it with my own eyes once when I confused the driver with a particular glReadPixels path. It ended up transferring the color values straight out of the multisample buffer, giving me a double-size image full of 2×2 blocks and jittery geometry edges (due to the rotated grid). I happened to experiment from within an X-Plane plugin to have some free content to work with, when I ran into that. 🙂

—-

Note I presume the hardware will recognize that a block doesn’t contain geometry edges, so your post-process shader is mostly agnostic to the optimization. Just specify that you’d like to work on individual samples, and if the hardware then sees that the samples in each pixel in a block are the same, it can optimize by only running once per pixel. Again, I’m not sure how it actually works, but it seems like a great solution that’s hard to miss.

Very fine geometry kills either way. It’ll reduce fragment core utilization, add additional vertices to process, etc. I don’t think the hit of having to post-process every sample will be disproportional, seeing what came before it.

Right – a typical modern forward-rendering hw MSAA will multi-sample coverage or depth and blend one shaded sample based on that coverage – the blending can be out of order – and as a result you get nice AA rasterization without increased shader cost.

But we have a deferred renderer…so this yields two problems:
1. In order to reconstruct the final colors, we need to blend sub-samples into a full pixel _after_ we apply lighting, which means we need the full g-buffer state per _sample_ ahead of time. In other words, if the hw computes coverage in pass 1 and mixes down a final per-pixel g-buffer state, that g buffer is the average of all contributing samples and thus totally wrong.

So at a minimum, coverage or depth-only style multi-sampling is not adequate; even if the shader is called once per pixel, the results must be stored per sample.

2. How do we then save any work? I suppose the answer is: if the lighting calcs are expensive, we would loop through our multi-samples and identify and weight the existing fixed number of unique g-buffer tuples. That is, in some cases we might early-exit because all g-buffer tuples are the same, or we’d even get to run the lighting calcs only for as many cases as we have.

(It might be quicker to only optimize the coherent case…hard to say without real data.) For fine geometry, where polygon edges are cutting through a lot of pixels (especially with tessellation) we might not hit the optimal case very much.