So I just found out that GL_MAX as a blend func is supported pretty much universally (~92%). Pretty nice considering I kinda gave up my baricentrics based anti-aliasing technique months ago

Depending on performance this might roll up the my whole thoughts...

Mostly for comparing/sorting values... (though I might just sort them in the resolve step anyways) because for in place sorting without readback I would have to write a 32 bit value (24 bit depth + 8 bit payload). So I might aswell just write two values (which is literally half, plus minus additional depth) and do the resolve step post.

Damn.

Wouldn't it be easier to use the driver's AA implementation? Much faster and it'd be true AA based on filtering (just blending values as in averaging would be filtering via a box filter which is pretty terrible compared to better ones like Mitchell-Netravali and Lanczos)

@RememberMe This would be a completely new technique. It should be pretty fast hopefully. But there aren't really any built in anti aliasing techniques except MSAA which I don't want to use for several reasons

@12bitfloat new doesn't mean it hasn't been considered before and rejected for some reason. What's wrong with MSAA?

If you're doing it for the lols/interest/etc. though, then please go ahead. I've done tons of stuff that way and it's usually pretty interesting if nothing else.

@RememberMe It's mostly for lols, just trying to push the envelope. The idea itself has been tried before but I'm not quite happy with the results. DFAA is a super obscure technique that basically does this but there are some other ones that I forgot the name of and can't for the life of me find again.

I'm actually one of the few advocates of MSAA and it would fit into my architecture as it's a spin on forward based rendering. Although quite good it's also surprisingly slow and not that amazing either

My idea is using prebaked barycentric coordinates in meshes to store order independent edge information per pixel which later gets used to reconstruct the edges in the resolve pass.
If this works it would be amazing because not only is the scene pass super fast (mostly just storing the already interpolated vertex attrib in a render target) but the resolve should also be very fast

@12bitfloat you mean this? This looks quite straightforward. https://alexpolt.github.io/dfaa.htm...

Should, but I have my doubts. But I'll have a look at it tomorrow, 3am here and my brain is dead lol

@RememberMe Basically like this. But you probably have to do edge detection based on depth in order not to blur already seamless edges of adjacend triangles.

Another problem of DFAA is that without conservative rasterization (or another trick I already thought about) it misses pixels that the triangle only slightly covers. You can see it in the bottom middle picture