Per Fragment depth mask

[kRogue]

That method essentially makes the AA by comparing depth values (and requires a secondary depth buffer for back facing primitives) identifying edges by looking at depth value differences. Nothing wrong with the technique, i think it is nifty.... other AA techniques without MSAA are on Humus too (for example GPAA which when I look at it smells like a workaround to not having that which I am suggesting/begging for).

My main thoughts on my begging of the first "don't write to depth controlled by fragment shader" is that if (and it is a big freaking if) the hardware can do it but it is not exposed then it should get exposed. Likewise same jazz for the "AA extension pack" though, I strongly suspect that those other 2 things (change rasterization rule on a edge by edge basis and emit a coverage percentage) are NOT in hardware now....

Suggestions, begging, what's the difference, eh?

[Ilian Dinev]

Look at the GBAA again, test it. It's not just an edge-detection identification. It creates almost-perfect coverage info and result. Has a pitfall similar to your idea, but in extremely lesser degree.

[kRogue]

the GBAA uses an extra color buffer .. and a geometry shader (but the geometry shader emits 1-triangle per triangle in, so not a nasty geometry shader) .. the idea being that the gemetry shader emits extra information about the edge distance stuff, and then the fragment shader stores which direction to sample in case of an edge on the post pass... This method also has bits for handling when a primitive is clipped to an alpha value, but it requires that the alpha is computed inside of uniform control (i.e. it needs dFdx/dFdy operating on alpha).. for hard font rendering, which uses dependent texture look up or when the texture data to look up is not to be filtered, the alpha addition will not work correctly.

Each of the techniques at Humus for anti-aliasing without MS are neat, but it just seems to me an engineering effort to get around something that the hardware might be able to do...

The "Second Depth Anti-aliasing" technique could be tweaked so that rather than reading a depth value, the fragment shader writes an "object ID" to a target so that the comparison is simple != rather than worry about depth precision issues...

[Ilian Dinev]

Ah actually I meant the "second depth" instead of GBAA.

With the "object ID", how can you reconstruct the edge/coverage? You'll need a drawcall IDX, primitive IDX, the modelviewproj matrix for the drawcall, and do slower complex maths. In the end you won't get a much-better image result; the current technique seems to be already good enough.

P.S.
Btw I agree that HW should implement+expose a distance-to-nearest-edge data in the fragment shader. Still, it's a chicken'n'egg thing, few people have regained trust in GS's performance to start doing such a thing, that requires a GS; and so a thing that relies on distance-to-edge won't become often-used/defacto-standard, and so won't become accelerated. Unless some/all vendors decide to spare a few gates for this on a whim.

[kRogue]

With the "object ID", how can you reconstruct the edge/coverage? You'll need a drawcall IDX, primitive IDX, the modelviewproj matrix for the drawcall, and do slower complex maths. In the end you won't get a much-better image result; the current technique seems to be already good enough.

for me.. I am mostly worried about rendering UI's... for that which I work on, UI elements are batched together, so a UI element's tag is essentially a tuple: (layer, gl-state-vector-ID, batch-ID, element-ID)... each of these values is less than 255, typically well under 50 often enough.. so rather than do a depth comparison, I make a secondary RGBA and two pixels come from different objects if that value is different.. for (flat) UI's there are "no back facing primitives" and all edges reduce to silhouette edges... but I am beyond wary about putting this on an embedded device (AFAIK only embedded GPU out now that does MRT's is Tegra AND Tegra does not support depth textures [and to add more pain Tegra's depth buffer is 16-bits only]). Even if I restrict it to just Tegra, I am quire concerned on the bandwidth cost... Fullscreen X 2 buffers, then read back, then draw again... lots of bits flying there!