Does that mean the community can enable it for pre-RDNA4 GPU? I know it can be done manually now, but it is much nicer to have it in mesa and enabled with launch variables.
They were just trying to sell as many 9060 and 9070 cards as possible. Now I bet that is slowing down due to the ram price hike, I suspect once they hike gpu prices and it becomes super hard to move inventory. Fsr4 int8 version will be released for 6000 and 7000 series cards
It makes sense to. They are behind Intel for quality and far behind Nvidia. The only play they have is making it easier for devs to adopt it.
The irony of the situation is this is a self inflicted wound. Nvidia made a tool to allow fsr to be integrated alongside dlss and they rejected it. Intel joined it.
Then intelnever updated their code either... Streamline was a PR stunt, and Nvidia controlling that repo would've been a terrible idea, someone more "neutral" and impartial should've been the one leading and controlling that project
How are they behind Intel for quality? FSR4 is widely accepted as better than Xess which is more a DLSS 3 competitor (but is worse in motion and has a bigger performance hit).
They're behind Nvidias DLSS4. 4.5 might be far ahead (I'd wait for reviews to confirm how far ahead it is) but it also has an additional performance cost to 4.
And the whole Nvidias streamline situation isn't as straightforward as you present.
Nvidia and Intel gather game data for super sampling the same way. AMD does it a different way. This deal is really beneficial for Intel but likely detrimental for AMD, as it would give FSR methods of gathering supersampling data that it was not designed for.
AMD couldn’t redesign future FSR releases to match the standard of Nvidia and Intel because that would break backwards compatibility. AMD couldn’t retroactively convert FSR 3.1 and 4 to the Nvidia and Intel way as that would break those versions already implemented in games. AMD had a choice; either game dev ease of use at the cost of accepting an inherent translation layer timing disadvantage, or sacrifice game dev ease of use to prioritize competition in super sampling quality.
It was a smart play by Nvidia since Intel isn’t really a competitor in their market and it was a lose-lose situation for AMD.
Also, I'm fairly certain AMD would prefer MS to make DirectSR happen so game devs just implement DirectSR and the graphics driver handles the implementation
Nvidia and Intel gather game data for super sampling the same way. AMD does it a different way. This deal is really beneficial for Intel but likely detrimental for AMD, as it would give FSR methods of gathering supersampling data that it was not designed for.
AMD couldn’t redesign future FSR releases to match the standard of Nvidia and Intel because that would break backwards compatibility. AMD couldn’t retroactively convert FSR 3.1 and 4 to the Nvidia and Intel way as that would break those versions already implemented in games. AMD had a choice; either game dev ease of use at the cost of accepting an inherent translation layer timing disadvantage, or sacrifice game dev ease of use to prioritize competition in super sampling quality.
This HAS TO be written by somebody who has never heard of "if else" statement in programming.
The way you pretend AMD had no way to use different inputs on different occasions, or include/exclude them dynamically, or better yet help IMPROVE STREAMLINE TO ADD MORE INPUTS THEY SUPPOSEDLY NEED, NOW OR IN THE FUTURE.
This has to be written by someone who doesn’t understand the complexity of game metadata.
Just because you get game metadata doesn’t mean it’s usable. If your program is expecting it to be in a certain form, you need to take the time to convert objects and structs, or to add extra front-facing method calls to get the data in a format of what the program expects. However efficient that conversion is made, that’s time wasted, which adds an fps penalty. Now your algorithm has an inherent disadvantage to your competitor’s.
This is likely not a simple change. This is a likely highly structural tech debt originating from the beginning of FSR and DLSS. It would have been nice for the companies to communicate a standard back then, but here we are now.
The whole point of Streamline was to get close enough in terms of what inputs to ask the game engine for in order to satisfy all parties.
Like, duh. That's the point. It doesn't work any other way. It was obviously going to be that.
AMD just decided to shut it down, and without AMD there was no point to the initiative, this kind of stuff is either all parties participate or it doesn't get off the ground.
Just release it man what is the hold up
FSR4 or the Epstein files?đź’€
It could possible be the case that they don't own all the code.
It happens a lot that companies like AMD outsource or partner with companies to ship them as fast as possible.
Greed and or incompetence
Both should nail it.
Guy with no knowledge on anything he's talking about asks rhetorical question
So brave
Does that mean the community can enable it for pre-RDNA4 GPU? I know it can be done manually now, but it is much nicer to have it in mesa and enabled with launch variables.
Probably, at least on Linux.
you can already use it on CachyOS with lunch veriables. just use PROTON_FSR4_RDNA3_UPGRADE=1
What about dinner variables?
But is it the same library or an updated one? Can we port it over to make DLL files on Windows?
Release the INT-8 files 🗣️
They were just trying to sell as many 9060 and 9070 cards as possible. Now I bet that is slowing down due to the ram price hike, I suspect once they hike gpu prices and it becomes super hard to move inventory. Fsr4 int8 version will be released for 6000 and 7000 series cards
That would be nice for us 7000 users + 6000 series and below.
It makes sense to. They are behind Intel for quality and far behind Nvidia. The only play they have is making it easier for devs to adopt it.
The irony of the situation is this is a self inflicted wound. Nvidia made a tool to allow fsr to be integrated alongside dlss and they rejected it. Intel joined it.
Then intelnever updated their code either... Streamline was a PR stunt, and Nvidia controlling that repo would've been a terrible idea, someone more "neutral" and impartial should've been the one leading and controlling that project
How are they behind Intel for quality? FSR4 is widely accepted as better than Xess which is more a DLSS 3 competitor (but is worse in motion and has a bigger performance hit).
They're behind Nvidias DLSS4. 4.5 might be far ahead (I'd wait for reviews to confirm how far ahead it is) but it also has an additional performance cost to 4.
And the whole Nvidias streamline situation isn't as straightforward as you present.
im curious, what tool is that?
https://github.com/NVIDIA-RTX/Streamline
im curious what really happened in AMD heads there must be some technical limitation, otherwise its really arrogance and sabotage?...
Nvidia and Intel gather game data for super sampling the same way. AMD does it a different way. This deal is really beneficial for Intel but likely detrimental for AMD, as it would give FSR methods of gathering supersampling data that it was not designed for.
AMD couldn’t redesign future FSR releases to match the standard of Nvidia and Intel because that would break backwards compatibility. AMD couldn’t retroactively convert FSR 3.1 and 4 to the Nvidia and Intel way as that would break those versions already implemented in games. AMD had a choice; either game dev ease of use at the cost of accepting an inherent translation layer timing disadvantage, or sacrifice game dev ease of use to prioritize competition in super sampling quality.
It was a smart play by Nvidia since Intel isn’t really a competitor in their market and it was a lose-lose situation for AMD.
Also, I'm fairly certain AMD would prefer MS to make DirectSR happen so game devs just implement DirectSR and the graphics driver handles the implementation
This HAS TO be written by somebody who has never heard of "if else" statement in programming.
The way you pretend AMD had no way to use different inputs on different occasions, or include/exclude them dynamically, or better yet help IMPROVE STREAMLINE TO ADD MORE INPUTS THEY SUPPOSEDLY NEED, NOW OR IN THE FUTURE.
This has to be written by someone who doesn’t understand the complexity of game metadata.
Just because you get game metadata doesn’t mean it’s usable. If your program is expecting it to be in a certain form, you need to take the time to convert objects and structs, or to add extra front-facing method calls to get the data in a format of what the program expects. However efficient that conversion is made, that’s time wasted, which adds an fps penalty. Now your algorithm has an inherent disadvantage to your competitor’s.
This is likely not a simple change. This is a likely highly structural tech debt originating from the beginning of FSR and DLSS. It would have been nice for the companies to communicate a standard back then, but here we are now.
The whole point of Streamline was to get close enough in terms of what inputs to ask the game engine for in order to satisfy all parties.
Like, duh. That's the point. It doesn't work any other way. It was obviously going to be that.
AMD just decided to shut it down, and without AMD there was no point to the initiative, this kind of stuff is either all parties participate or it doesn't get off the ground.
Instead of it being easily usable by all it will be rarely used and mainly for modders.
What could open FSR4 mean for the steamdeck?