Yellow-Dog-Man
FSR Options + Foveated Rendering
Is your feature request related to a problem? Please describe.
Let's be real: Resonite (and other platforms) really struggle with user-generated content. While we could all enforce people to follow guidelines, it won't dismiss the usual concerns of people with older systems trying to render various scenes and complain about lowered frame rates.
Describe the solution you'd like
AMD's FSR seems to give some nice performance boosts without sacrifice to too many details, especially based on situations where the VR Performance Toolkit was used. This has often resulted in 10-15% increases in framerate without too much quality loss, even in an unofficial form.
Describe alternatives you've considered
The only alternative is to use the VR Performance Toolkit mod.
Additional Context
Please let me know if this should be marked as its own, but part of the mod uses a radial rendering method in the center of the user's view. While this is fine for static headsets, headsets with eye tracking could benefit from the coordinates moving around, thus establishing Resonite as a potential first to have foveated rendering, giving boosts to performance without sacrificing quality. If this could be combined with more native integration, this could rapidly improve performance costs and base the data on information the client already has (due to the eye tracking integration already being built-in, though this may also involve #975 to be resolved first to avoid issues).
This is something that could potentially be added at some point, but I'm not sure how much of a boost this would be.
Most of the content tends to be bound on the CPU side, while this helps mainly with GPU load (and only some aspects of it), so it might not be worth prioritizing over other types of optimizations right now.
How much of the CPU load is from driver overhead? Generally speaking foveated rendering helps reduce driver overhead, but I don't know what Res's situation is.
I'm not saying this should happen before the new rendering backend is in, I am actually just curious.
I don't have specific numbers, but majority of CPU overhead is not from driver overhead.
I don't see how would foveated rendering would help reduce driver overhead though? If anything, it adds a little more, since you need to do more stuff when doing the actual rendering. You mostly save on fragment shader invocations.
At this rate we'll likely be saving this for Sauce.
But what flavor is it?
Joking aside, the foveated rendering was mostly just an idea. I know from using the FSR mod (which I think is based on v2?) that performance does go up, albeit due to a lower resolution being upscaled or something. The thing is that it does things in a rendered circle at the center of the screen, and since using the Quest Pro with eye tracking, I can't really look around without things being a jagged mess (since I wasn't supposed to look at them).
I'm just assuming that if the coordinates of the 'render circle' were moved, it'd establish no greater impact or, at the very least, make the FSR more usable for cases of eye tracking.
How much of the CPU load is from driver overhead? Generally speaking foveated rendering helps reduce driver overhead, but I don't know what Res's situation is.
I'm not saying this should happen before the new rendering backend is in, I am actually just curious.
Compared to the rest of the engine, minuscule. Besides - this optimization doesn't save us CPU overhead. It saves you fillrate on the GPU.
With the number of new high resolution eye tracking enabled headsets coming to market (Galaxy XR, Beyond 2e) I think foveated rendering is an important feature to have. This also applies to existing headsets because FR allows for significantly higher resolutions in the fovea, helping with aliasing and text readability on e.g. Quest Pro or Steam Frame which have somewhat low resolutions in comparison to e.g. BSB2.
