First implementation of of FSR 2.0
Only on Xbox series X
From 1440p to 4K reconstruction
It is intresting to see how reconstruction technique may effect the locked frame rate targets on consoles
Series S doesn’t use FSR 2.0 and is only 1080p native. It is locked 60 FPS.
Series X can go upto 52-55 on one of the areas with which is the most demanding one
Is FSR part of the RDNA2 that XSX has?
FSR is hardware independent upscale technique
It runs on Nvidia and Intel hardware as well
So no, it is not what you are thinking
XSX has no bespoke upres tech in hw. It has ML support which can be used for DLSS-like upres, but also can be used for other tasks, and its ML acceleration isn’t part of RDNA2 (it was an add-on MS asked for). Hw-accelerated VRS is part of RDNA2 though, but that isn’t being used in Scorn by the looks of it. Which is a shame since it seems ideal opportunity to leverage it as it’s a super low contrast art style.
FSR2.0 is hw-independent, but it is odd that there are no examples afaik of FSR1.0 on other consoles.
Thanks!
So we still really haven’t seen the benefits of RDNA2 yet? I remember the tweets before XSX came out and they clearly were very happy about it. Surely at some point it’s going to get used? If not by third parties then first party?
We are still working with fairly last generation engines, I am sure as we get more current gen centric we will start to see some of the newer features be more heavily leveraged. I don’t think things like VRS and mesh shades are things that are super easy to integrate.
RDNA2 is RT, VRS, perf/clock efficiency. There are several games on XSX using VRS to good effect, but the big jump in visuals and whatnot won’t come til new games are built to leverage ML and XVA and mesh shaders. That means stuff built ground up for next gen specifically to use this stuff like Hellblade 2.
It’d say we’re still a good two years away from seeing a video game implementing the full stack of Xbox series features in a video game. The Coalition might just be the first one
They really sent this game to die.
I’d love to talk to a dev on this because this has been a widespread problem on PC, especially with UE4 titles. Curious on why this is such a problem on PC.
GPU code is not published in binary form. Its in intermediate language and has to be compiled in the GPU driver to the correct GPU instruction set. If a game has lots of shader/material variations there is a lot of code to compile.
Combination of a few factors, mainly the shaders are now an intermediate format under DirectX12 instead of compiled ahead of time like they are for consoles.
Good news is future revision of UE5 will make it substantially easier for developers to capture all PSOs (Pipeline State Objects) via their “Automated PSO Gathering”.
With the increasing emphasis in UE5 on DX12 and Vulkan, we’re focusing attention on solving the problem of runtime hitches caused by Pipeline State Object creation, which is inherent to those RHIs. The previous solution required a PSO pre-caching process, which could be burdensome for large projects, and still leave gaps in the cache leading to hitches.
Automated PSO Gathering replaces the manual work required to collect all possible PSO combinations for a project, while at the same time keeping the number of PSOs as small as possible.
Here’s an ongoing over 2 year old thread on B3D about the matter with some buried nuggets of knowledge in there:
Fairly nice and technically simple to follow overview on the PSO stuff on before and after DX12:
https://www.yosoygames.com.ar/wp/2020/08/a-little-clarification-on-modern-shader-compile-times/
Additional clarification on that blog post from Shader Compilation on PC: About to become a bigger bottleneck? | Page 2 | Beyond3D Forum
I feel like the blog post isn’t clear enough on the deeper understanding as to why shader recompilations are becoming more common in newer APIs …
For some historical context, D3D7 to D3D9 and OpenGL were initially designed for HW modeled after state machines and this remains true for some GPU designs like we see today on Nvidia hardware which somewhat matches this paradigm. Shader recompilations usually aren’t triggered often on these types of architectures because they change rendering states via through some individually set register that sends commands to the fixed function HW units.
Today, D3D12 and Vulkan are designed for theoretical HW that’s near stateless. In this model some hardware can potentially emulate these rendering states on their programmable shader cores so changing states would involve patching the shader code which can be very expensive. PSOs in these APIs exist so that some GPUs can associate these rendering states with their binary blobs. Most commonly as we see on mobile GPUs, the blend state has to be emulated with shader code because they might not necessarily have a fixed function blending unit performing these operations. This is true for some other rendering states on AMD HW as well such as the entire input assembler stage. Shader recompilation being triggered by a driver update is the expected outcome due to binary blobs encoding some graphics state and this binary blob can be volatile from different hardware generations or compiler versions.
D3D10 and D3D11 are sort of in between these two extremes where they move away from being designed solely for state machines but they aren’t stateless. Their model is based around “state objects” which grouped together other more granular graphics state from the pipeline and this is arguably where shader recompilations started becoming a bigger issue during this period in time as some newer hardware designs were moving towards emulating some of these states. It was clear at that point that runtime shader compilation wasn’t going to be sustainable for some architectures so the proposed solution was to do shader compilation during boot up or loading times which is exactly what D3D12/Vulkan was set out to be designed for.
To put it simply, shader recompilation is a ramification of modern HW design …
Latest rumors on RDNA3 are here
Word is, its virtual cores are designed to increase throughput at higher resolutions
Will update the post once cat is out of the bag
Till then, if this true then AMD’s strategy is completely different from Nvidia’s
Intel on the other hand is trying to do both things
Let’s see how it goes
Edit: Well it is not rumor but actually speculation on what Lisa Su her self said
I tried not to follow too much on the RDNA3 rumors this past week considering its a scant few hours away. Some of the stuff going around is so farcical. It’s beyond silly season.
Hopefully I remember to tune in for the details (at 1PM PST, 4PM EST):
Thank you both!
Really curious on how the chiplet approach will scale with their GPUs. It’s obviously benefited their CPUs and really want AMD to see success here as well.
DF Tech view on GoW:R and written article at God of War: Ragnarök on PS5 is like a maxed-out PC port with flawless performance | Eurogamer.net
Where’s the CoD DF review? Been waiting for that one.
I think Tom is working on that. He’s done all the coverage of it so far.
FSR 3 … 
So far doesn’t look impressive much
They are dunking on 2.1 display port which to be fair Nvidia can implement when they want it
What’s left now is the price