He can't explain the delay but pretends to know by incorrectly stating they were doing different training.You can't train an Ai model in Int8. All training is done in FP.
He can't explain the delay but pretends to know by incorrectly stating they were doing different training.You can't train an Ai model in Int8. All training is done in FP.
No... all training is done in FP. You can't train in int8 because of a values limitation, the training model simply will not work. So even when training for an int execution unit, they use FP that is "pretending" to be int. FP preends to be Int by adding fake noise into the training model to account for the rounding errors that are unavoidable with INT.No. It's done using a mix of data formats. Including Integers.
But even after training, the resulting model can be quantitized into lower precision models.
No... all training is done in FP. You can't train in int8 because of a values limitation, the training model simply will not work. So even when training for an int execution unit, they use FP that is "pretending" to be int. FP preends to be Int by adding fake noise into the training model to account for the rounding errors that are unavoidable with INT.
Once the training is done however, it can be compressed down to INT... but it will never be as accurate as a model running in FP. This could explain why even as great as PSSR2 is, there is a tell with how it handles super fine repetitiuve detail with that weird pointilism thing it does.
I believe QAT is when training is done with FP that pretends to be INT by adding fake noise into the model. INT is mathematically incapable of being used for training a model, thats why training is done in FP. QAT trains a model using FP that is already accounting for the limitations of INT, its still technically an FP output, just rounded down for INT. The great thing is that the same output can run natively in FP too. In its pre-rounded form of course.Int is also used, although in limited scale. Such as with in Quantization-Aware Training.
Still, quantitizing a trained model to Int8, is the easy part of the process.
I believe QAT is when training is done with FP that pretends to be INT by adding fake noise into the model. INT is mathematically incapable of being used for training a model, thats why training is done in FP. QAT trains a model using FP that is already accounting for the limitations of INT, its still technically an FP output, just rounded down for INT. The great thing is that the same output can run natively in FP too.
This is likely how sony and AMD's models are trained. Trained using QAT, rounded down and exported for INT while the OG (before rounding) value is ran natively in FP. This is how they can train one model that caters to both platforms. And even with PSSR3, sony is likely sticking with INT, for all Ai functions except those that explicitly need FP.
My bad, you said something about converting from FP to INT not being the problem and that what was, was the training. I thought you were saying that its training in INT that was a problem. I also felt that training in general isn't ven a problem because of QAT, which is most likely what is being used here by both sony and AMD because it kills two biirds with one stone.We are saying the same thing essentially.
But I never said training was done in Int8. I don't even understand why you suddenly started this line of argument.
Because you claimed the training is the hard time consuming part making it seem like they had to do something different. The argument didn't make sense.We are saying the same thing essentially.
But I never said training was done in Int8. I don't even understand why you suddenly started this line of argument.
My bad, you said something about converting from FP to INT not being the problem and that what was, was the training. I thought you were saying that its training in INT that was a problem.
I also felt that training in general isn't ven a problem because of QAT, which is most likely what is being used here by both sony and AMD because it kills two biirds with one stone.
Because you claimed the training is the hard time consuming part making it seem like they had to do something different. The argument didn't make sense.
Yup... it's definitely the hardest part. Or at least the most time-consuming part.That is because training a model really is the hardest part of the process. Converting the model to a lower data format is the easy part of the whole process.
Yup... it's definitely the hardest part. Or at least the most time-consuming part.
Sure but why did you bring it up as if it proved that the reason FSR4 didn't come to PS5 Pro but FSR4.1 did was due to training?That is because training a model really is the hardest part of the process. Converting the model to a lower data format is the easy part of the whole process.
Sure but why did you bring it up as if it proved that the reason FSR4 didn't come to PS5 Pro but FSR4.1 did was due to training?
Your argument didn't make sense at all. People inferred that you were claiming they had to train in int8 for the Pro.
You completely and dodged my post asking you this too. You still haven't explained how the easy part (not the training you claimed was time consuming) prevented FSR4 on PS5 Pro happening earlier.
Because FSR4 was designed with and for AMD's software stack. RoCm and Hip.
It targeted the performance metrics of RDNA4 and it's ML units.
And it's quantitization process was developed for FP8.
It also has to take into account the OS and API. Which are very different.
So it took time to develop a common software stack, and quantitization processes.
If Sony was making FSR4 from the very start, with the goal of putting it on the Pro, then FSR4.0 would be there a year ago. Instead it's here now, with FSR4.1
But this was exactly what you were dismissing as the reason for that delay:And it's quantitization process was developed for FP8.
It also has to take into account the OS and API. Which are very different. Just consider that AMD still has not made a version of FSR4 for Vulkan.
So it took time to develop a common software stack, and quantitization processes.
If Sony was making FSR4 from the very start, with the goal of putting it on the Pro, then FSR4.0 would be there a year ago. Instead it's here now, with FSR4.1
And you replied:Has nothing to do with it. You clearly said
Blatantly incorrect. These things do take time to develop which was why PSSR was launched earlier. They continued working on the next iteration which was FSR4 but the algorithm was fp8 while the delayed PS5 Pro was int8. That took time and effort to implement and AMD did not even bother doing so for their older PC GPUs. Doesn't mean PSSR and FSR4 were separate models before though.
They had trained FSR4 already. Why were you bringing up the training if the next step of quantitization, API/OS, etc was the easy part? That's why people inferred that you're trying to suggest there was some additional time consuming training specifically for int8/PS5 Pro.Converting a model from Int8 to FP8 and vice versa is not the thing that takes more time. It's the training.
Saying that Sony was using PSSR1 for a year, while having made FSR4, makes no sense at all.
But this was exactly what you were dismissing as the reason for that delay:
And you replied:
They had trained FSR4 already. Why were you bringing up the training if the next step of API/OS, etc was the easy part? That's why people inferred that you're trying to suggest there was some additional time consuming training specifically for int8/PS5 Pro.
The argument didn't make sense. You then continued to dismiss AMD and Cerny tweets explicitly stating the joint development of FSR4.
Training doesn't rely on windows, DirectX or int8. It was the "running the model" on PS5 Pro that you were refuting and claiming was easy to do despite it being int8 and RDNA2, claiming it didn't explain the time it took to come to Pro but suggesting training did. What you were saying made no logical sense, sorry.You don't just develop a model. It requires a software stack, both for development and for running the model.
AMD started developing FSR4 targeting RDNA4, on Windows, in DirectX, to run on FP8 quatitization. And that is what came out of FSR4.0
When Sony entered the picture, a lot had to be added and/or changed in the process. And it took time, until we got FSR4.1
Training doesn't rely on windows, DirectX or int8. It was the "running the model" on PS5 Pro that you were refuting and claiming was easy to do despite it being int8 and RDNA2, claiming it didn't explain the time it took to come to Pro but training did. What you were saying made no logical sense, sorry.
FSR 5/Diamond are transformer models for upscaling/framegen/denoising built for RDNA5. Will be pretty much 100% identical between PS6/Xbox Helix/RDNA5 dGPUs regardless of whatever branding each one uses.
Maybe Sony made a deal to have the only INT8 version avaliable, who knows.
What does that even mean? A trained model is not really dependant on "DirectX and windows". It's running that trained model on different hardware/OS/int8 that requires work but you dismissed that time consuming work to mention 'training' as the issue when the model exists.OMG, you can't be serious. Do you really think a model just runs on itself by magic?
What does that even mean? A trained model is not really dependant on "DirectX and windows". It's running that trained model on different hardware/OS/int8 that requires work but you dismissed that time consuming work to mention 'training' as the issue when the model exists.
"running" is not the same as "training". FSR4.1's trained models aren't specific to PS5 Pro, windows Direct X, it didn't require separate training.LOL, you really think that a model like FSR4 just runs on thin air.![]()
"running" is not the same as "training". FSR4.1's trained models aren't specific to PS5 Pro, windows Direct X, it didn't require separate training.
Running it on its hardware with only int8 RDNA2 is specific and that was exactly what you were dismissing as the reason for the time it took to come, in favour of 'training' being the reason you stated. Hence why people inferred you meant it required different "training" using int8. It's not hard to understand unless your skull runs on thin air.
Of course you do but you end up with a mathematical model that can be portable. Your model isn't strictly tied to a programming language, API, OS etc. You can make it work wherever/however you like. People have brought FSR4 to Vulkan, they didn't train new models for it did they?Even for training you need a complete software stack. From the OS, programs, programming languages, APIs, drivers, etc.
It's FSR4.1 int8 basically. And that was denied by many people here...
Of course you do but you end up with a mathematical model that can be portable. Your model isn't strictly tied to a programming language, API, OS etc. You can make it work wherever/however you like. People have brought FSR4 to Vulkan, they didn't train new models for it did they?
I'm confused, you're saying the pro is rdna2?"running" is not the same as "training". FSR4.1's trained models aren't specific to PS5 Pro, windows Direct X, it didn't require separate training.
Running it on its hardware with only int8 RDNA2 is specific and that was exactly what you were dismissing as the reason for the time it took to come, in favour of 'training' being the reason you stated. Hence why people inferred you meant it required different "training" using int8. It's not hard to understand unless your skull runs on thin air.
I'm confused, you're saying the pro is rdna2?
Yeah that's what I thought, don't get the rdna2 int8 reference.Pro raster part is RDNA2.
RT is from RDNA4 and ML is custom. Frankenstein console.
It's custom RDNA with some features from RDNA3 and 4. Didn't want to start that irrelevant debate again.I'm confused, you're saying the pro is rdna2?
This answers the question earlier why they took forever with PSSR2"Great questions, particularly considering that FSR Frame Generation is technology that was co-developed between SIE and AMD, we're intimately familiar with it," Cerny revealed. "All I can say is that we have no more releases planned for this year. And that I look forward to discussing this more in the future!"
![]()
Mark Cerny Confirms Frame Generation "Should Be Seen At Some Point On PlayStation Platforms"
"I look forward to discussing this more in the future!"www.digitalfoundry.net
This almost confirms no Frame Generation for Pro.
"I'm very happy with how that work is progressing, and an equivalent frame generation library should be seen at some point on PlayStation platforms."
I think they would release this year specially for GTA VI if they are really doing on ProI think this statement means it's coming next year in 2027.
It's hard for me to see them releasing it for PS6 and not PS5 Pro when most games in 2027 will be cross-gen.
![]()
Mark Cerny Confirms Frame Generation "Should Be Seen At Some Point On PlayStation Platforms"
"I look forward to discussing this more in the future!"www.digitalfoundry.net
This almost confirms no Frame Generation for Pro.
I think they would release this year specially for GTA VI if they are really doing on Pro
so basically, I am using PSSR2 on my Steam Deck![]()
At that point, why would base PS5 not benefit, it's clearly not about TOPs that much.
base PS5 is RDNA1 with RT hardware added, while Steam Deck is RDNA2... that's the main issue.
Xbox Series X however... that should work without much issue, and the increased number CUs there should help as well.
so it's kinda surprising that Microsoft isn't talking to AMD to bring FSR4 to Xbox consoles.
PS5's version of the GPU didn't include the "limited" but still available RDNA 2 ML ? I thought it did but those hardware debates from so many years ago I guess I forgot. They're fucked then if that's the case. What a missed opportunity.
PS5's version of the GPU didn't include the "limited" but still available RDNA 2 ML ? I thought it did but those hardware debates from so many years ago I guess I forgot. They're fucked then if that's the case. What a missed opportunity.
afaik not even the PS5 Pro has all RDNA2 features. that's why PSSR uses a modified version of FSR4 that runs on their custom ML hardware.
Xbox Series X however... that should work without much issue, and the increased number CUs there should help as well.
so it's kinda surprising that Microsoft isn't talking to AMD to bring FSR4 to Xbox consoles.
LOL
Series X GPU has 49 INT8 TOPS
How exactly could it run FSR4 when the minimum spec of RDNA4 is like 200???
Then Microsoft is sleeping at the wheel if they have full RDNA 2 ML. It would be a nice upgrade for Series S and Series X. If you have it running on a Steam deck, there's no reasons those consoles would not benefit. Of course, might be a game to game basis depending on performances, but say, perhaps a game that used to be 60 fps would have FSR 4.1 in 40 fps mode (? realistic performance drop?) and I imagine a lot of peoples would be happy.
Then Microsoft is sleeping at the wheel if they have full RDNA 2 ML. It would be a nice upgrade for Series S and Series X. If you have it running on a Steam deck, there's no reasons those consoles would not benefit. Of course, might be a game to game basis depending on performances, but say, perhaps a game that used to be 60 fps would have FSR 4.1 in 40 fps mode (? realistic performance drop?) and I imagine a lot of peoples would be happy.
just to show a quick comparison:
XeSS quality mode
![]()
FSR4 balanced mode
![]()
and in motion, the difference is even more in favor of FSR4.
both give me a solid 60fps (aside from UE4 typical I/O stutter)