FXAA and resolution scaling issue

[quarties]

Using any fxaa preset along with vidResIndex=1 renders games in 1/4 of the screen with blurred sides, that seems to render based on rendered image edge. However, the UI elemnts render in proper position on the screen (see health bar or Nadia text on the screenshot).

[Try]

Hi, @quarties and thanks for report!

Apparently FXAA implementation doesn't account for resolution: it takes half-res input and reads out-of-bounds, assuming that game always in full res.

Text and UI are unaffected, as they are rendered on top.

[Try]

Probably it's worth to turn FXAA off at all, if game runs at lover res. Or use use upscaler instead, such as lanczos

[dreimer1986]

Wouldn't this be a nice opportunity for DLSS?

[Try]

Wouldn't this be a nice opportunity for DLSS?

DLSS is probably defeat the purpose:

• requires at least Turing-gen gpu, where game has no issues on performance (except maybe RT part)
• library requires motion vector - we would have to spend frame time to calculate them

And generally black-box *.dll is not welcome.

On comment above I've suggested to start with Lanczos since it's hardware friendly, for old gpu's and already in use in mobile segment.

[inter-arc]

Is this an option instead of DLSS? https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK

[Try]

@inter-arc

Generally same story. FSR upscale is very hard to integrate and net-cost (with all extra data, that it ask engine to generate) expected to be bigger that native-resolution rendering.

Also FSR in the end is same old Lanczos, with many(too many?) extras: https://gpuopen.com/manuals/fidelityfx_sdk/fidelityfx_sdk-page_techniques_super-resolution-temporal/#id102

[Nindaleth]

I'm very happy that FSR is supported in demanding AAA games such as Horizon: Zero Dawn or The Last of Us Part 1 and I profit from that immensely, but I feel OpenGothic needs it less compared to those. What I feel strongly about, is which upscaling algo should be used in case @Try decides to implement it - DLSS is nV only and closed-source (is there a Linux/macOS version at all?), I haven't heard anything good or bad XeSS and can only assume it's the weakest. FSR is the winner here, works on all major GPU brands and is only slightly weaker than DLSS.

@Try I don't understand your pessimism, but maybe I'm missing some key information:

FSR upscale is very hard to integrate

I've only ever read about devs having the opposite experience, a few sources after a superquick search: source 1, source 2. Obviously I'm not here to teach you about your own engine, but both FSR and DLSS have been, in general, repeatedly praised for being easy to integrate.

net-cost (with all extra data, that it ask engine to generate) expected to be bigger that native-resolution rendering.

Can you elaborate on this? Taken literaly, it sounds as if Tempest would be slower with FSR than without it, which I'm sure is impossible because then nobody would use FSR.

Also FSR in the end is same old Lanczos, with many(too many?) extras

Unlike traditional single-image upscalers, FSR provides shimmering and ghosting reduction, FSR2 is pretty good at it. Also FSR 3 additionaly offers frame generation - I'm not ready to debate its upsides and downsides, but it's available and optional.

[Try]

Can you elaborate on this? Taken literaly, it sounds as if Tempest would be slower with FSR than without it,

Tempest is somewhat orthogonal here, as it purpose is to be something ala standard-library for gpu primitives, such as buffers and textures. Reason why it's difficult to start with FSR, is lack of input, motion vectors in particular. Horizon-games already had them upfront, what made integration simple for them. Introducing motion-vectors to Gothic, mean track current+previous position for each object and each bone(in case of npc's) and effectively bump PCI traffic by 2x. It's bad already, plus someone need to render them - mean extra 32bit(+25%) to gbuffer. And since FSR is only system that cases about vectors, all of this has to be conditional, so we can switch it on/off.

Unlike traditional single-image upscalers, FSR provides shimmering and ghosting reduction

Single image upscaler cannot have ghosting by definition :)

I don't understand your pessimism, but maybe I'm missing some key information

AMD are is the same company that can't still(!) fix mesh shader in RDNA drivers. My expectations are not very high for quality of their code. My suggestion is to implement something simple for start and then will see.

[Nindaleth]

motion vectors in particular. Horizon-games already had them upfront (...) bump PCI traffic by 2x (...) extra 32bit(+25%) to gbuffer

Oh, I see. That really sucks. I mean, it sucks for implementation of state of the art upscalers, otherwise it's cool that you don't have to have these performance sinks.

AMD are is the same company that can't still(!) fix mesh shader in RDNA drivers.

Wait until you experience the quality of Intel discrete card drivers :-D But yeah, AMD is currently getting a lot of flak re: GPU driver quality as they also try to improve their ROCm efforts (you might have recently heard about tinycorp issues with AMD driver quality) and they finally seem to care as they now want to compete with nVidia in the GPGPU area. I can only say that apparently the RADV Linux driver is better quality than their Windows driver.

My suggestion is to implement something simple for start

I don't actually intend to blindly push FSR every time upscaling comes up, but there's no other widely adopted GPU-friendly multi-platform open source upscaler... Would FSR1 be a good starting point? The FSR1 header file says:

This specific header focuses on single-image non-temporal image scaling

[KirillAlekseeenko]

Would FSR1 be a good starting point?

According to https://gpuopen.com/manuals/fidelityfx_sdk/fidelityfx_sdk-page_techniques_super-resolution-spatial/ FSR1 input should have antialiased (MSAA or TAA) input. Maybe FXAA will do, but it seems, that it's better to implement MSAA, since calculating motion vectors for TAA is not an option.

[Try]

Prototyping Lanczos:

Orig (75%)

Upscale:

[Try]

FSR1 input should have antialiased (MSAA or TAA) input.

MSAA? Nice! Given that unresolved MSAA4 pixel literally stores 4 color-fragments and gives antialised result by averaging them :) While funny, there is similar concept implemented by variable-rate-shading. It enables to run fragment shader once per n-pixels (usually per 4 pixels), while still have depth test at full res.

[Try]

With mipBias look even better, but unfortunately apple doesn't have support for that - what is a problem for cross platform:

[Try]

Original issue fixed; Upscaler is committed without mip-bias (due to apple)