CMAA2 integration

[KirillAlekseeenko]

-Integration implemented with different quality modes (higher mode means lower edge detection threshold) -Tonemaping switches to compute when CMAA2 is on in order to avoid additional copy from RT resource to UAV. -Created additional HDR luminance resource, but currently it's not used, since there is a problem, that in some locations HDR range is so small, that almost no edges are detected even on max quality preset.

[KirillAlekseeenko]

1) 4 presets is too much, I just repeated Intel's demo here; MIDDLE and ULTRA should be enough. 2) I thought about potential integration with MSAA in a future where MSAA is for geometry aliasing and CMAA2 is for anything else.

[KirillAlekseeenko]

About copy_img.comp, yeah, it's better to commit separately

[Try]

@KirillAlekseeenko Pr generally looks good. Last few changes can do by myself.

Let me know, when you happy with current state of PR, so I can start testing/finalizing

[KirillAlekseeenko]

Seems that it's ready for integration

[Try]

Experimenting with edge detection in HDR space:	Final image(HDR)	Footprint
Final image(LDR)	Footprint

In LDR path, I've changed encoding from packR11G11B10E4F to packUnorm4x8, as image is already tonemapped and in gamma-space. In HDR path I'm using packR11G11B10F, to math frame buffer format.

HDR luminance resource, but currently it's not used, since there is a problem

Computing luminance in flight via CMAA2_SUPPORT_HDR_COLOR_RANGE==1 seem to work.

At this point I'm thing to make HDR as default and only path, since it fits better into existing pipeline (0.06ms performance saved on RTX, compare to LDR!) and some VRAM bandwidth savings.

@KirillAlekseeenko let me know what you think about it.

[KirillAlekseeenko]

I wanted to use HDR luminance but encountered cases where HDR is much darker than LDR like on the shots below. So finally decided to stay with LDR. The game was run without cmd args except for -aa, colors on screens are in [0, 1] range HDR: LDR:

[Try]

I wanted to use HDR luminance but encountered cases where HDR is much darker

It seems that tonemapping been applied twice or not applied at all on you image.

Here same spot on my working branch (9:00am):

[KirillAlekseeenko]

There's an input to tonemapping pass and sky pixel history. I didnt look deeply into this but for some reason after sky and fog passes color values are around 0.1. Could I mess up with game settings or something else (maybe some hidden setting)? Capture is done on PR's branch without local changes.

[Try]

I didnt look deeply into this but for some reason after sky and fog passes color values are around 0.1.

Here how sceneLinear (pre tonemapping) look on my end:

if we divide it by exposure value in a frame = 0.0000088533, we will get sky brightness = 18 072lum, what is fine for day-time, with clear sky.

Can you check if after my changes (HDR path) rendering works fine?

[KirillAlekseeenko]

It works fine but there's two-three times less candidate pixels than with LDR pass, maybe it's worth trying adaptive edge detection threshold based on exposure value

[Try]

maybe it's worth trying adaptive edge detection threshold based on exposure value

Probably no, at least I don't see how it can be better. Right now input is pre-exposed, close to [0..1] range. Maybe raise cmaa2EdgeThreshold; but I'm not sure how to reason about quality then - as it's gonna be subjective.

[KirillAlekseeenko]

Seems that there's no need to raise threshold, I just took a look at nsight trace and it's even faster than fxaa

[Try]

Merged, thanks!