I should probably add that some of this work is on RDNA3 FSR4 support, which isn’t even supported on Windows. It’s not amazingly fast, but it’s now faster than native and that might be enough to make it worth it (especially in the cases where it improves image quality due to poor TAA implementations).
I admit I don’t follow this type of development at all, but I was very surprised that the work is actually being done by Valve, and not AMD. I wonder if they “back port” this into Windows, that’d be… something.
That would require porting Mesa to Windows, which won’t happen. At best, someone would be able to extract this to a DLL that could replace the FSR DLL bundled with games.
I should probably add that some of this work is on RDNA3 FSR4 support, which isn’t even supported on Windows. It’s not amazingly fast, but it’s now faster than native and that might be enough to make it worth it (especially in the cases where it improves image quality due to poor TAA implementations).
I admit I don’t follow this type of development at all, but I was very surprised that the work is actually being done by Valve, and not AMD. I wonder if they “back port” this into Windows, that’d be… something.
Valve is one of the main contributors to the RADV Vulkan driver for AMD GPUs, and a bunch of other parts of Mesa and the open driver stack in general.
That would require porting Mesa to Windows, which won’t happen. At best, someone would be able to extract this to a DLL that could replace the FSR DLL bundled with games.
Oh I mean AMD going “oh that’s clever, so I can just do this and change that…” and release a new version of their windows drivers.
That would reduce the value of buying an RDNA4 GPU, so I don’t see that happening.