This, DLSS3 is just an added mode on top of DLSS2, it benefits from the reduction of latency gained by DLSS2, and also benefits from latency reduction from Refelx.
Maybe, but I'm just trying to understand the basics first since there seems to be some conflicting statements about this. "No latency."
Shouldn't be maybe, the extra frame is solely from the GPU with no CPU involvement, so there can't be new inputs can there?
That doesn't take into account that generated frames don't have user inputs, thus they're really just like pure added latency
Sure. Just didnt wanna get derailed into a different point entirely...
No different than pre rendered frames, the user never actually has control on every single frame, just every "sum" of frames, which varies according to the animation and scene composition.
Gosh, pre-rendered frame queue and frames buffering (double, triple with v-sync or any other) prior to displaying things are totally different things, and you somehow mixed them all
Agree, it is very clear and easy to grasp
Yes, all things equal DLSS 2.0 + Reflex only will be better latency wise.
Which isn't a problem at all because the pre-rendered frame queue you've mentioned already captures input for up to 4 frames, by getting rid of it there are already huge latency savings and DLSS's lower resolution rendering decreases latencies even futher. Have you ever seen end-to-end input latency numbers? They are not 16 ms in your typical 60 FPS game, but rather close to 80 ms, what a shock!)
Yes, numbers may vary of course, but in general you are right.
double triple etc buffering are completely separate from any of this, seriously didn't think you would mean those. My English isn't native so I'll gladly try to clarify if something I write might be misunderstoodGosh, pre-rendered frame queue and frames buffering (double, triple with v-sync or any other) prior to displaying things are totally different things, and you somehow mixed them all
So, like it is today? Input latency is not bind to render time.
No, not like today. Even when input latency isn't bind to render time, your inputs affect every frame. With Frame Generation they only affect every 2nd frame.
That's a complete fabrication on your part, your input DOES NOT affect every frame, has never been the case for quite some time actually. As I told you, it affects every "sum" of frames.
It seems there is confusion when it comes to the word "interpolation". Some people think of it as of method of generating the final frame, i.e. as if it was done with linear combination of 2 frames like on some TVs, while other people, me including, refer to it as of concept of generating intermediate frames. Methods may vary of course, in case of DLSS 3 that's optical flow + ingame motion vectors + neural net that does the heavy lifting of generating the new intermediate frame.
I mentioned double and triple frame buffering because this is exactly the type of buffering that would be required for a frame generation algorithm that attempts to insert frames in-between of other frames (since it would obviously need to hold on the latest rendered frame). Pre-rendered queue is a different story altogether - that's about buffering CPU commands and data for follow up frames.
People have been turning vsync off for a hell of a lot less.
Oh, I've noticed the green method is extrapolation which isn't likely DLSS 3 using.
Smooth transistion at lower frames and using all these high speed LCD and OLEDs. And it should help adaptive sync display to not rely on LFC anymore.
