More DLSS...

[XoR_]

I am really excited about MF DLSS. It can be a game changer at 4K. Hitting 200 fps in Cyberpunk gonna be amazing.

Me personally am not excited at all for MFG.
It supposedly adds even more lag than normal FG and normal FG when I tried it in CB2077 looked good and was somewhat playable so that is good but it did play worse than without it and had worst issue of all: massive VRR flicker on OLED screen.
Frames are generated and displayed at seemingly at random times which does result in smoother appearance but it also causes VRR flicker.

Maybe this is only CB2077 issue or something is off with my configuration or whatever but if not and MFG has the same issue it would make it even more useless than it obviously is.
Maybe Nvidia improved it?
It still won't mean games will play better - only look better. Games will play worse with MFG.

 

[KickAssCop]

OLED has VRR flicker. There is no escaping it. DLSS and FG doesn't have much to do with it.
As for lag, I can see it in fast paced games like COD BO6 but for a game that has tracer bullets, doubt it will be much of an issue.
Also recent implementations of FG don't have too much lag that I noticed and I consider myself moderately sensitive to it and still use it in most games (e.g., recently I used it in Indiana Jones and it was perfectly fine).

 

[kalston]

OLED has VRR flicker. There is no escaping it. DLSS and FG doesn't have much to do with it.
As for lag, I can see it in fast paced games like COD BO6 but for a game that has tracer bullets, doubt it will be much of an issue.
Also recent implementations of FG don't have too much lag that I noticed and I consider myself moderately sensitive to it and still use it in most games (e.g., recently I used it in Indiana Jones and it was perfectly fine).

VRR flickering is caused by large and frequent frametime variations, with FG your framerate is twice as high, even the minimums, so you won't get flicker anymore if your base is 60+ fps, as it should be.

 

[III_Slyflyer_III]

Also recent implementations of FG don't have too much lag that I noticed and I consider myself moderately sensitive to it and still use it in most games (e.g., recently I used it in Indiana Jones and it was perfectly fine).

Agreed. FG in most games now feels perfectly fine so as long as your base FPS without FG is still around 60. Even when it is not (some parts of Stalker 2 at 4K max settings), it's much better than not having it on.

 

[Pestluder]

Me personally am not excited at all for MFG.
It supposedly adds even more lag than normal FG and normal FG when I tried it in CB2077 looked good and was somewhat playable so that is good but it did play worse than without it and had worst issue of all: massive VRR flicker on OLED screen.
Frames are generated and displayed at seemingly at random times which does result in smoother appearance but it also causes VRR flicker.

Maybe this is only CB2077 issue or something is off with my configuration or whatever but if not and MFG has the same issue it would make it even more useless than it obviously is.
Maybe Nvidia improved it?
It still won't mean games will play better - only look better. Games will play worse with MFG.

I'm still on a 3080, so this is second hand info. HUB reported that they didn't like FG in FPS titles(at low fps), but found it more useful in third person or games with more "laggy" input - controllers/wheels.

ps. as an edge case for those of us who have monitors that struggle with black levels at sub 100 fps, it might be good.

 

[Armenius]

I am really excited about MF DLSS. It can be a game changer at 4K. Hitting 200 fps in Cyberpunk gonna be amazing.

I'm concerned about the latency. I don't care if the game is reaching for 300 FPS if I'm still getting the same input latency as I would at 30 FPS.

OLED has VRR flicker. There is no escaping it. DLSS and FG doesn't have much to do with it.
As for lag, I can see it in fast paced games like COD BO6 but for a game that has tracer bullets, doubt it will be much of an issue.
Also recent implementations of FG don't have too much lag that I noticed and I consider myself moderately sensitive to it and still use it in most games (e.g., recently I used it in Indiana Jones and it was perfectly fine).

I keep hearing about VRR flicker on OLED, but I have yet to see it. I saw it once during the intro of Ratchet & Clank: Rift Apart with the game running at a locked 117 FPS without DLSS or frame generation.

 

[elvn]

VRR flickering is caused by large and frequent frametime variations, with FG your framerate is twice as high, even the minimums, so you won't get flicker anymore if your base is 60+ fps, as it should be.

As I understand it, the gamma on oleds is (or at least was when I bought mine) - set at the peak Hz , in the case of a 120Hz OLED gaming tv for example, gamma is normal at 120Hz. When VRR ranges downward, (or both upward and downward from a lower base frame rate), from what I read on the topic back then, and what I saw in youtube videos and screenshots explaining it - the Hz variations are changing the effective gamma levels, which is noticeable especially in very dark areas that end up lifting rapidly from blacks to grey-blacks. That causes a flicker look as the fpsHz varies rapidly, and because the fpsHz ranges people typically use in a lot of games are in a an unstable "seismograph" (as opposed to use on desktop/apps that is usually the peak Hz of the display as the fps minimum, for all practical purposes, never dipping under).

OLED VRR flicker might be less obvious when your frame rates aren't bouncing up from and down into sludge-low on the bottom end, as you suggested in your reply. However far as I know it's still happening at modest middle fps-Hz ranges, but in those ranges it's not as far from the peak Hz gamma set point so probably isn't as brightly lifted and as jarring, but it is still varying along with your frame-rate graph. A native 60fps is probably 40 to 80 fps graph range +/-, so with FG+1 that would be 80 to 160 and it would probably not be as bad of (as bright of a gamma lift when fluctuating) OLED vrr flicker. I'm not sure how OLED VRR flicker vs gamma set point works with 240Hz OLED screens though, to be honest.

. . . . . . . . .

That said , the 60fps average you mention as a base or native frame rate average is 16.6ms frames so your input lag will be that, and better and worse as that is a frame rate average so could go up to 20ms to 25ms during the graph, and down to 13ms to 12ms as it ranges higher.

Also, as mark R of blurbusters recently stated, to be above flicker fusion threshold of a display (not VRR flicker), you'd need to be above 60fpsHz (minimums) on lcd, and 80fpsHz (minimums) on OLED.

I recommend base framerates above flicker fusion threshold, depending on how fast your display is.

That means pre-framegen framerates of at least ~60fps on LCD, and at least ~80fps on OLED.

This forces oscillating artifacts (framegen-vs-nonframegen) to be hidden by its own blur (flicker fusion)

This dramatically reduces the visibility of framegen artifacts.

The Developer Best Practices section of my famous 10:1 framegen article (that correctly predicted many elements of DLSS 4), also talks about having high base pre-framegen framerates.

. . .

Personally, I suspect that:

..The higher your native frame rate range, the less %difference there will be between two frames for frame gen to guess between, so the resulting frames might be less %inaccurate.

.. A %inaccurate FG'd frame will also be being displayed for a shorter period of time the higher the native frame rate is, so inaccuracies/artifacts might be less apparent or less obnoxious.


..When above the flicker fusion threshold of a screen, especially if above it in the entirety of your frame rate graph, it will mask some of the artifacts due to the screen's own small transition blur (as per MarkR)


.. The higher your native frame rate range, the lower your input lag will be.

. . .

. . . . . . . . . . . . .

Modern FG sounds like it will be good all around, even on some lower ranges (as compared to low native ranges without it), but it will probably operate even better on decently high native frame rate ranges (better meaning getting less visible artifacts, potentially less %inaccuracy on generated frame predictions, and lower input lag). People will probably tune it differently depending what they prefer and on what game, e.g. I'm sure some people will use ray tracing with lower native frame rate range on demanding games -> more artifacting and higher input lag, but the 5080/5090 should get better native performance to start with so there is that, too.

I had guessed that 100fpsHz average might be a more optimal rate for it (where possible to get it). Taking the rate you'd need just to avoid the oscillating artifacts facet of it, to be above the flicker-fusion threshold as markR put it, which is at 80fpsHz for an oled- you'd need about 100fpsHz average as your native frame rate to stay above 80 in your graph.

If already at 100fpsHz average (80 - 120 range for the sake of argument),
your frames would be
12.5ms <<10ms>> 8.3ms

so %difference between frames would be somewhat less to guess between than 60fpsHz average's
40 - 60 -80
25ms<<16.6ms>>12.5ms

you'd also likely see any more poorly (%inaccurate) guessed frame more briefly (generated frames taking half the native frame time, at least at FG+1, I suspect)

your input lag would be at those of the native frame rate numbers

you'd be straying less far away from the OLED's native gamma the closer your end result frame rate range (after FrameGen) is to the OLED's native Hz-gamma. (Or better yet, your post frame gen rate range exceeding the peak gamma-Hz of the screen, minus a frame rate cap)

 

[XoR_]

OLED has VRR flicker. There is no escaping it. DLSS and FG doesn't have much to do with it.
As for lag, I can see it in fast paced games like COD BO6 but for a game that has tracer bullets, doubt it will be much of an issue.
Also recent implementations of FG don't have too much lag that I noticed and I consider myself moderately sensitive to it and still use it in most games (e.g., recently I used it in Indiana Jones and it was perfectly fine).

FG doesn't cause VRR flicker but from what I have seen it introduces large differences between frame times which causes my OLED panel to panic.
If there is a way to fix VRR flicker or not is hard to say. My gut feeling tells me it would not exist if electronics driving each pixel was a bit more complex and did not produce different luminance depending on how frequent it get 'kicks' from pixel refreshes. OLED panels have different brightness at different refresh rates and this is something that is compensated/adjusted to have the same brightness. Perhaps all that needs to be done is improve that compensation. It is of course just my uneducated speculation.

Lag in the case that game normally running above 60fps is frame doubled to 120fps on 120Hz screen to avoid VRR flicker is there but it is not terrible. I saw worse performance from some console games running at 60fps@60Hz and not that many people complain about that.

I would say it is very much usable setup with biggest issue being: I can just play game at original frame rate with lower latency. It looks less smooth and has more motion blur but has lower latency. Also if frame rate is 80+ then the compromise on latency is just unacceptable. Of course all depends on how much OLED panel flickers in this case and games can have very different frame to frame frame-time variance.

I'm concerned about the latency. I don't care if the game is reaching for 300 FPS if I'm still getting the same input latency as I would at 30 FPS.

It is an issue of these kind of technologies and always was.
With better implementations that are based on reprojection versus using latest frame it should be possible to generate new frames while even reducing perceived latency.
Sooner or later this will be a reality. Hopefully we won't have to deal with games optimized so poorly that they actually run 30fps... wait we, already have games that run less than 30fps at max details at 4K on 5090

I keep hearing about VRR flicker on OLED, but I have yet to see it. I saw it once during the intro of Ratchet & Clank: Rift Apart with the game running at a locked 117 FPS without DLSS or frame generation.

It is mostly visible in darker scenes and frame to frame frame-time variations cause it so any sudden frame time increase like stuttering might cause it.
On both of my OLED screens it is very visible during loading screen as in this case frames are delivered very randomly as game is loading. In normal gameplay it is usually hardly noticeable. I see it on occasion but it can usually be easily ignored. Using frame rate limiter can help in some cases.

 

[MavericK]

VRR flickering is caused by large and frequent frametime variations, with FG your framerate is twice as high, even the minimums, so you won't get flicker anymore if your base is 60+ fps, as it should be.

It's really bad in Stalker 2. I had to turn off GSync.

Most games it happens in the menus a bit, but not in-game.

 

[Chief Blur Buster]

FG doesn't cause VRR flicker but from what I have seen it introduces large differences between frame times which causes my OLED panel to panic.

The new DLSS 4 multi-framegen is much better framepaced than the DLSS 3.5, and I saw zero VRR flicker on the 480Hz OLED I saw framegen in. Frametimes were consistently less than 5ms on some of the demos (the demos that maintained north of 200fps with RTX ON), staying above the OLED VRR flicker region pretty nicely.

Mind you if you change the settings, it can gyrate lower obviously. But some settings exist that keeps it relatively sky-high, at least in the demo equipment and demo game they showed off. Hopefully that extends to other games.

From the display's POV, the (visible portion of) frametime of original frames and the frametime of framegen frames are now much more symmetric with DLSS 4

In addition, that specific demo wasn't even running Reflex2, which was a roundabout implementation of the lagless framegen idea, incorporating between-frame mouse input reads for framegen'd frames, to reduce mouselook lag.

I will predict that by the 6000 series (and if not, then the 7000 series), we'll also be relaying zero-latency enemy position updates to the framegen engine, to reduce the lag of enemy positional updates. As long as the inputreads/positionals are fast, and framegen is faster than original frames, you can reduce input latency of framegen to less than original rendered frames.

It's a cesspool pick-poison decision, but with Moore's Law petering out, and the need to get 4K 1000fps 1000Hz RTX ON path traced graphics, I don't see how we're going to be able to avoid framegen for that purpose.

"If framegen must happen anyway, then it MUST become lagless." (or even less lag than original frames! Which is actually possible!)

I must say I am pleased at least NVIDIA stole some of the ideas I've been tooting in the pages, forums, and social media -- Mind you, I'm not sure how many people said the same ideas but I probably had a significant amplying impact. Now I really want AMD and Intel to get onboard this train.

This is my year 2023 infographic, now implemented partially into Reflex2 (sorta). Not as large ratios, and only applies to mouselooks (not aggregate major positional updates like enemy positionals in esports games). Still lots more work to do, though.

 

[pendragon1]

“As per NVIDIA's comparison of DLSS 2.0 vs DLSS 3.5 vs DLSS 4.0, there is roughly no latency difference. NVIDIA might have turned off Reflex with DLSS 2.0 testing, but since DLSS 3.5 and 4.0 have it as an essential requirement, the latency with DLSS 4 is comparable to DLSS 2, which seems odd.”

Source: https://wccftech.com/nvidia-dlss-fr...s-new-ai-model-faster-lower-vram-requirement/

fits here too

 

[chameleoneel]

So does reflex 2.0 stack ontop of DLSS 4 and framegen to mitigate the latency? I can’t seem to find a straight answer.

Yes.

Reflex is required in games with framegen.

 

[arestavo]

Yes.

Reflex is required in games with framegen.

Except for Indiana Jones and the Great Circle. If you force reflex on in the Nvidia Control Panel, you're gonna have a bad time (hopefully the devs fix that).

Nothing like getting 110FPS, but it drops to 10 every other second while panning around.

 

[chameleoneel]

Except for Indiana Jones and the Great Circle. If you force reflex on in the Nvidia Control Panel, you're gonna have a bad time (hopefully the devs fix that).

Nothing like getting 110FPS, but it drops to 10 every other second while panning around.

Not 'except'. Reflex is automatic with framegen. You aren't even needed to manually turn it on.

If it's not working in Indy, it's broken. A few games have had issues with framegen.

 

[kalston]

Reflex is broken in Indy. There is no option for it in the menu while the dlls are present in the folder.

Since it doesn't auto cap framerate with v-sync on and feels laggy (and GPU can hit 100%), it's simply not working in Indy atm. No idea why DF didn't pick on that.

 

[KickAssCop]

I thought FG was fixed in Indiana. I remember getting a patch and fps jumping from 80-90 to 110-120 with FG on in the Cairo area. Can't reinstall game to confirm but I distinctly remember FG being fixed.

 

[kalston]

FG works, but there is more input lag than in other games with FG enabled because Reflex is broken. It's single player though and not a twitch shooter, so that doesn't make it unplayable.

 

[Gideon]

FG works, but there is more input lag than in other games with FG enabled because Reflex is broken. It's single player though and not a twitch shooter, so that doesn't make it unplayable.

This is why I don't like relying on frame generation, it's just like SLI tech. When it works right it's great, but when it's not right it requires either Nvidia to fix it or the developer and god knows if that will happen.

 

[criccio]

I thought FG was fixed in Indiana. I remember getting a patch and fps jumping from 80-90 to 110-120 with FG on in the Cairo area. Can't reinstall game to confirm but I distinctly remember FG being fixed.

Played through that whole thing with it on, certainly works. Input lag felt minimal to not there, but I was also playing Stalker 2 a the same time and literally anything feels better than that game.

 

[XoR_]

This is why I don't like relying on frame generation, it's just like SLI tech. When it works right it's great, but when it's not right it requires either Nvidia to fix it or the developer and god knows if that will happen.

Yeah, it is like SLI in AFR mode.
Just in this case you get it for basically free albeit with some reduction to image quality of these generated frames.

SLI would be cool if Nvidia focused on SFR and optimized drivers for FSR.
Even if they could not achieve scaling close to 100% (for AFR it was like +80-90%?) and more like +50% it would still be much better. And in some games such scaling was actually possible. Often it did not work when forced or scaling was worse and closer to 30% - still better than AFR even if fps was worse.
SLI in SFR when it worked felt like having single stronger GPU with the same input lag single faster GPU would give you.

Given people today sell or try to sell their 4090's to then pay more than twice the money they get from selling the card to get 5090 and +~30% more performance I think there would be people willing to have two 4090's in their PC... or at least it it was possible to fit two 4090's in one PC I am sure there would be specialized cases with PCI-e risers for that very purpose.

Otherwise if you have FG then SLI AFR would make zero sense.
Like you could argue SLI gives 'real' frames but at the end of the day it would be extremely silly to buy second card to get what you can have for free but only be CPU limited. Also I think making FG work with SLI AFR would not be easy and it would add even more lag...

 

[elvn]

Yes I had 1080ti sli for a long time. Certain titles got a lot of performance out of it like GTA V (which I applied mods onto that modded behaviorally and also to be somewhat more demanding and detailed graphically even), and Witcher 3. I also used it on a Vermintide2 and on Nioh2 which I played a lot of, and dishonored and shadow of mordor with good effect also, and I think even jedi got something out of it. Prob a few others but there were always certain titles that it gave a nice boost to. Getting 100fpsHz average or better with graphics dialed in slightly back then at 1440p was nice.

I always thought VR, having a different display per eye could have benefited from dual GPU if they had developed for it, one gpu rendering each eye's perspective.

With frame gen on a regular single display - perhaps, theoretically, one gpu could do the real frames and the other gpu could do the frame gen rendered frame. Idk if that would work, would have to be a good (fast) pipeline. Frame Gen uses buffering so that might be faster to do per single gpu. If it buffered and frame generated faster per cycle on a single gpu, then maybe alternate more like AFR originally did, except native frame + frame gen frame per cycle on each gpu.

I also wondered if some SLI tech could be developed so that a single gpu could do the central section of a larger screen , for example the 4k central portion of an 8k screen or the 4k central section of a 7680x2160 ultrawide, and that another gpu could render the peripheral areas of the screen.
That or or similar with triple monitors but I dislike middling bezels in game fields, There are some bezel masking panels you can get but that would work better for specific games like racing and flight sims.

One of the big problems, as was mentioned, is like a lot of things - they have to put the time, effort and money into developiong for it (HDR and other features for example, frame gen, maybe raytracing, and generally applies to devs optimizing games too).

It's a fun thought experiment but I wouldn't expect anything like that.

 

[XoR_]

These days SLI could be utilized in more clever and easier on Nvidia driver development team ways.

Most obvious use cases for SLI today would be:
1. Ray/Path tracing
More samples => better image quality.
2. DLSS
Upscalers like TAA works by accumulating samples over time. Here by rendering the same frame but twice with with different offsets we could get much faster sample accumulation - in fact we would get two frames worth of samples even for very very fast moving objects.
If we upscale something like 1440p to 4K using single card we get 44% samples but with two cards it is 88%. It would translate to less artifacts and such after upscalers are tuned.

And beauty of such solution would be that all you had to worry about is your DLSS upscaler making it even more important for people who already bought in to your GPUs and making them literally want to use your upscalers even more. No risk that someone else will make better upscaler. At least for the few people having pair of 600W GPUs...

Not sure RT but I guess anything that is already made to be random like direction in which light goes would produce different frame - if it then went to Nvidia's own Ray Reconstruction as the filter it could use all these sweet samples to produce much nicer image. Or in other words the same thing: only thing you need is make DLSS support two inputs produced by two cards. I guess one card would finally execute the model. Requests to draw graphics would need to go to both GPUs. I guess only image would need to be transferred from second GPU to the one executing DLSS model even if normally it gets more data but I am not sure about that. Either way technically it should be doable - maybe even without need for fancy external SLI bridges.

Also rendering exactly the same frame would get both GPUs utilized as much the same as possible. Only one would need to execute DLSS model. Maybe it would be possible to split the model, who knows...

Does it make any sense though?
I cannot imagine putting second 4090 in my already unfit to hold single 4090 case just to get 'faster sample accumulation'
Someone else with even less regard to buying depreciating assets to render pixels on the screen? For sure!

Personally I hope Nvidia does not even think about such things
Otherwise some people would need to buy two "$2000" GPUs from scalpers for $2500 a piece instead of one GPU to have best gaming system. It is mostly needless expense for basically the same outcome

 

[III_Slyflyer_III]

These days SLI could be utilized in more clever and easier on Nvidia driver development team ways.

Most obvious use cases for SLI today would be:
1. Ray/Path tracing
More samples => better image quality.
2. DLSS
Upscalers like TAA works by accumulating samples over time. Here by rendering the same frame but twice with with different offsets we could get much faster sample accumulation - in fact we would get two frames worth of samples even for very very fast moving objects.
If we upscale something like 1440p to 4K using single card we get 44% samples but with two cards it is 88%. It would translate to less artifacts and such after upscalers are tuned.

And beauty of such solution would be that all you had to worry about is your DLSS upscaler making it even more important for people who already bought in to your GPUs and making them literally want to use your upscalers even more. No risk that someone else will make better upscaler. At least for the few people having pair of 600W GPUs...

Not sure RT but I guess anything that is already made to be random like direction in which light goes would produce different frame - if it then went to Nvidia's own Ray Reconstruction as the filter it could use all these sweet samples to produce much nicer image. Or in other words the same thing: only thing you need is make DLSS support two inputs produced by two cards. I guess one card would finally execute the model. Requests to draw graphics would need to go to both GPUs. I guess only image would need to be transferred from second GPU to the one executing DLSS model even if normally it gets more data but I am not sure about that. Either way technically it should be doable - maybe even without need for fancy external SLI bridges.

Also rendering exactly the same frame would get both GPUs utilized as much the same as possible. Only one would need to execute DLSS model. Maybe it would be possible to split the model, who knows...

Does it make any sense though?
I cannot imagine putting second 4090 in my already unfit to hold single 4090 case just to get 'faster sample accumulation'
Someone else with even less regard to buying depreciating assets to render pixels on the screen? For sure!

Personally I hope Nvidia does not even think about such things
Otherwise some people would need to buy two "$2000" GPUs from scalpers for $2500 a piece instead of one GPU to have best gaming system. It is mostly needless expense for basically the same outcome

At 500~600W a card, heat dissipation becomes a real issue with 2 cards, not to mention the current draw from the power supply might exceed some people's circuits in their homes! I was on team SLi through my 1080's, but after that, it simply didn't make sense anymore (mostly because it was no longer really supported with the move to mGPU on DX12). We have to remember MOST of us here are enthuiasts, and even all of us together, a large portion would never buy a second GPU. The money is simply not there for nvidia to go that direction again (at least for quite awhile, if ever as their AI business supports them now).

 

[DooKey]

At 500~600W a card, heat dissipation becomes a real issue with 2 cards, not to mention the current draw from the power supply might exceed some people's circuits in their homes! I was on team SLi through my 1080's, but after that, it simply didn't make sense anymore (mostly because it was no longer really supported with the move to mGPU on DX12). We have to remember MOST of us here are enthuiasts, and even all of us together, a large portion would never buy a second GPU. The money is simply not there for nvidia to go that direction again (at least for quite awhile, if ever as their AI business supports them now).

I ran two AMD 295X2 GPUs in Quadfire. Been there, done that.

 

[rhcliff]

Yes I had 1080ti sli for a long time. Certain titles got a lot of performance out of it like GTA V (which I applied mods onto that modded behaviorally and also to be somewhat more demanding and detailed graphically even), and Witcher 3. I also used it on a Vermintide2 and on Nioh2 which I played a lot of, and dishonored and shadow of mordor with good effect also, and I think even jedi got something out of it. Prob a few others but there were always certain titles that it gave a nice boost to. Getting 100fpsHz average or better with graphics dialed in slightly back then at 1440p was nice.

I always thought VR, having a different display per eye could have benefited from dual GPU if they had developed for it, one gpu rendering each eye's perspective.

With frame gen on a regular single display - perhaps, theoretically, one gpu could do the real frames and the other gpu could do the frame gen rendered frame. Idk if that would work, would have to be a good (fast) pipeline. Frame Gen uses buffering so that might be faster to do per single gpu. If it buffered and frame generated faster per cycle on a single gpu, then maybe alternate more like AFR originally did, except native frame + frame gen frame per cycle on each gpu.

I also wondered if some SLI tech could be developed so that a single gpu could do the central section of a larger screen , for example the 4k central portion of an 8k screen or the 4k central section of a 7680x2160 ultrawide, and that another gpu could render the peripheral areas of the screen.
That or or similar with triple monitors but I dislike middling bezels in game fields, There are some bezel masking panels you can get but that would work better for specific games like racing and flight sims.

One of the big problems, as was mentioned, is like a lot of things - they have to put the time, effort and money into developiong for it (HDR and other features for example, frame gen, maybe raytracing, and generally applies to devs optimizing games too).

It's a fun thought experiment but I wouldn't expect anything like that.

I was a big fan of SLI until the 1080 TI era. I even had quad-SLI at one point lol. It was pretty useful in the Xbox 360/PS3 era when lots of games were poorly optimize and ran around 1080p/30fps even on a 8800 GTX.

But when the 1080 TI came along, I was still using a 1080P monitor so the 1080 TI was good enough. But I think 1080 SLI was really useful for people who got 4K displays. Since DLSS wasn't available yet, 1080 TI in SLI was pretty much the only way to have a good 4k gaming experience.

 

[rhcliff]

These days SLI could be utilized in more clever and easier on Nvidia driver development team ways.

Now that Nvidia has invested so heavily in frame-gen, it might make sense to have a 2nd GPU carry more of the load in frame generation.

With the lossless scaling app, it's possible to dedicate a 2nd GPU to frame-gen so that input latency is significantly reduced. Even a 4090 has much better latency with a low end GPU like the 3060, that is dedicated to frame gen.

 

[sharknice]

If it was that easy to do "sli" Nvidia, AMD, and Intel would not only support it, they would have cards with multiple GPUs on them like they did a long time ago with the 690 and 295X2. They would love selling more cards and making more money.

The reality is that it isn't nearly as easy as a lot of you think it is. It is often slower to share different tasks between different cards. I'm sure something could be done to utilize multiple GPUs more efficiently but it's just not worth the effort.

 

[Marees]

If it was that easy to do "sli" Nvidia, AMD, and Intel would not only support it, they would have cards with multiple GPUs on them like they did a long time ago with the 690 and 295X2. They would love selling more cards and making more money.

The reality is that it isn't nearly as easy as a lot of you think it is. It is often slower to share different tasks between different cards. I'm sure something could be done to utilize multiple GPUs more efficiently but it's just not worth the effort.

AMD has a patent for this but they scrapped all the top-end RDNA 4 cards which had this tech. Rumour is that RDNA 5 is also monolithic & tops out at $1000

So you are looking at minimum 2029 for crossfire to come back again, if AMD can get it to work

 

[pendragon1]

View: https://www.youtube.com/watch?v=tW0veUWslbU

 

[Sycraft]

If it was that easy to do "sli" Nvidia, AMD, and Intel would not only support it, they would have cards with multiple GPUs on them like they did a long time ago with the 690 and 295X2. They would love selling more cards and making more money.

The reality is that it isn't nearly as easy as a lot of you think it is. It is often slower to share different tasks between different cards. I'm sure something could be done to utilize multiple GPUs more efficiently but it's just not worth the effort.

Basically it has only ever been "easy" when you are using them to do better anti-aliasing. If you have 2 or more cards all rendering the same frame, at the same time, just with offset subpixels, then cool you can use them to do SSAA. That has been done on pro visualization systems in the past, might still be (not something I've looked in to for a long time).

Anything else? Always been a pain and only gotten worse with new technologies used in games. Hence companies stopped supporting it. Not enough people were willing to buy two GPUs to make it worth it.

Now maybe this changes with full path tracing, I know that ray tracing on the CPU has been something that historically scales in parallel real well, but I don't know how much that applies to doing it in real-time. Even if it does scale, I can see them not bothering since, again, not many people are willing to spend the money.

Personally, I don't imagine it coming back in the consumer market.

 

[noko]

Basically it has only ever been "easy" when you are using them to do better anti-aliasing. If you have 2 or more cards all rendering the same frame, at the same time, just with offset subpixels, then cool you can use them to do SSAA. That has been done on pro visualization systems in the past, might still be (not something I've looked in to for a long time).

Anything else? Always been a pain and only gotten worse with new technologies used in games. Hence companies stopped supporting it. Not enough people were willing to buy two GPUs to make it worth it.

Now maybe this changes with full path tracing, I know that ray tracing on the CPU has been something that historically scales in parallel real well, but I don't know how much that applies to doing it in real-time. Even if it does scale, I can see them not bothering since, again, not many people are willing to spend the money.

Personally, I don't imagine it coming back in the consumer market.

Well Nvidia was able to get the 5090 in a 2 slot configuration, meaning 2 cards would fit for SLI in many motherboards with 2 pcie X16 slots gen 5. I could see Nvidia coining it AI SLI where the AI load balances the two cards rendering 1 frame at a time, no alternate frame rendering or AFR.

 

[rhcliff]

I read that 3DFX cards back in the day were basically 2X performance in SLI. How did they manage that? Also, they created the term "SLI" but it wasn't the same as what Nvidia did?

 

[kalston]

If it was that easy to do "sli" Nvidia, AMD, and Intel would not only support it, they would have cards with multiple GPUs on them like they did a long time ago with the 690 and 295X2. They would love selling more cards and making more money.

The reality is that it isn't nearly as easy as a lot of you think it is. It is often slower to share different tasks between different cards. I'm sure something could be done to utilize multiple GPUs more efficiently but it's just not worth the effort.

I think it's just the same as multi-threading games on the CPU level. It's not that easy: you need to keep things perfectly in sync, otherwise you get logic errors/rendering errors/stuttering etc.

In some cases this new bottleneck is so heavy that you struggle to even gain performance. Now, using the second GPU to perform secondary and dedicated tasks, like frame gen/anti aliasing? Sure that can work, but the gains are less impressive and you don't even need the second card to be powerful in that case.

 

[XoR_]

I read that 3DFX cards back in the day were basically 2X performance in SLI. How did they manage that? Also, they created the term "SLI" but it wasn't the same as what Nvidia did?

SLI on 3dfx Voodoo2/5 was ScanLine Interleave and worked by having each card render every second line. It did not give 2x performance as in 2x FPS but it did basically double filltrate... back then GPUs were not GPUs and more like accelerators to drawing triangles on the screen. With super fast CPU you could approach 2x improvement in frame rates.

Then Nvidia bought 3dfx after 3dfx made some idiotic decisions and being late to the party with proper Riva TNT2 competititor and not having proper GeForce competitor and Nvidia with it got rights to use SLI name. They renamed it to Scallable Link Interface or something like that and did not render every second frame instead having two modes:
- SFR - frame would render top of the screen on one card and bottom on the other card and where they would split would change depending on which side had more work to do
- AFR - each GPU would render every second frame

Here lies the issue with Nvidia's SLI
If they managed to make rendering every second line they would get advantage of not needing to worry about GPU load because in this case both GPUs would roughly be utilized the same.
The issue was that by the time of GeForce 6 the so called 3d accelerators, now called GPUs, became much more advanced and had programmable shaders which were not so easy to split per-line basis. Also any vertex shader would need to be repeated on each card reducing possible scaling.

Also why I wrote before in this thread that using second card to do DLSS stuff would make more sense. GPU is just producing samples to be processed and in this case we can just render the same frame with different offsets - which for any frame would give the same result as rendering two still frames on one GPU.

In this case result would be more akin to what 3dfx already did with Voodoo 5 5500 where you could use SLI in the same way I described it - so render every second line and get higher performance OR: render the same exact frame at output resolution but using different sample offsets get additional samples to be used to get 2x SSAA or in case of Voodoo 5 6000 having 4 chips get 4x SSAA. Same could be done today albeit using DLSS and simply getting more sample points for DLSS. The issue here would be that adding second GPU would only improve image quality and not improve performance... then again you could lower actual render resolution by half pixels to get the same image quality* basically and this would improve performance.

*) It is a bit more complicated but generally it would be possible depending on how temporal sample accumulation was configured. It could be configured to prioritize looks of higher DLSS levels including above DLAA or to keep the general final looks and cut down time to accumulate samples and therefore reduce motion artifacts.

---
Using second card to generate frames?
Lots of data would need to be moved in and out the GPUs for that and it all depends on how much time GPU spends on frame generation. This can be estimated from scaling of FG. If 100fps gives 180fps with FG then via the magic of napkin calculations it is just 1.1ms per real frame to render additional frame. Still it might be worth it to have better frame gen algorithms working independently of game at always monitor's refresh rate and being able to produce very good motion blur. Here by motion blur I mean more like this effect where lower frame rate material can appear smoother if it is actually generated out of multiple frames blended together. Such tech could make even owners of 480Hz monitors having to lift their jaw off the floor seeing how smooth the image looks. With frame gen since we already create frames it would make sense to generate even more frames around the generated frame to create such motion-blur effect. Calling it as motion "blur" in this case would not capture its looks or purpose.

All in all today possibilities for second GPUs are endless and the whole thing a bit easier to pull off than in Nvidia's SLI times.
Also it doesn't need to be Nvidia who makes such tech. AMD and/or Intel can do it themselves/first.
Maybe such use cases are something Nvidia and/or AMD and/or Intel already considered. We might never know...

 

[elvn]

Using second card to generate frames?
Lots of data would need to be moved in and out the GPUs for that and it all depends on how much time GPU spends on frame generation. This can be estimated from scaling of FG. If 100fps gives 180fps with FG then via the magic of napkin calculations it is just 1.1ms per real frame to render additional frame. Still it might be worth it to have better frame gen algorithms working independently of game at always monitor's refresh rate and being able to produce very good motion blur. Here by motion blur I mean more like this effect where lower frame rate material can appear smoother if it is actually generated out of multiple frames blended together. Such tech could make even owners of 480Hz monitors having to lift their jaw off the floor seeing how smooth the image looks. With frame gen since we already create frames it would make sense to generate even more frames around the generated frame to create such motion-blur effect. Calling it as motion "blur" in this case would not capture its looks or purpose.

I just don't know if there would be any issue (tiny delay) if offloading frame gen to a 2nd card card. I'm not really familiar with the pipeline to be honest. For example, would the game/gpu drivers buffer a frame directly to GPU2 to apply frame gen on, or would it buffer faster on GPU1, GPU1 doing the buffering on itself and sending that to GPU2? Would it be faster to maintain each duty or to alternate the pattern somehow? Some mix and combination of native rendering, buffering, frame generation, and handing off duties between without going out of sync.

Alternately, as you said, do it on both but at some lower quality algorithm that when re-assembled between both card's outputs, makes the scene just as good or better looking quality wise by utilizing a type of redundancy that capitalizes on different %differences in end results to get a better overall frame quality..

Like I said earlier, on larger screen spaces and resolutions, tiling the screen might work also, with the periphery rendered on one gpu and the central viewing angle generated by the primary gpu. Even if there were a potential distortion line/sync thing as an artifact at times it wouldn't be in your central viewing angle. Also, could even run a lower resolution in the wings (kind of like dynamic resolution, or being dynamic resolution in the wings on whatever, potentially less powerful paired gpu), for more performance. Those types of things have been proposed for VR systems but that could also work on a flat screen at a pc on overall screen space by using eye tracking hardware (but keeping a set peripheral in larger screens would probably be easier to define gpu load wise if multiple gpus).

. . .

I can remember when you could put a math co-processor card into early ibm compatibles for some games, which is going back a-ways. I can also remember when graphics cards were pass through display cabled on vga, boosting and making polygons as you said. The first time I saw lara croft go from grainy wet sugar pixels to smooth polygons my jaw dropped. I seem to recall that Quake didn't have opengl, or glide drivers for my gpu at the time, immediately either, so I saw it' pixelated and grainy sugar looking and then one day smooth polys and it was amazing.

Much later, some people used to use a second cheaper gpu or their old gpu just to do certain graphics operations like PhysX too, so there is precedent for offloading work to a second card, even without it being exactly matched (model, power, price) to the first card, (and in some things it theoretically could even be a mix of amd and nvidia gpu). People would use their old gpu or source a used older one, but that could be complicated now by the fact that there are a lot of modern chips and features of specific generations required to be on the same system of dlss, frame gen, AI, etc. Still, maybe you could run a 5080/5090 with a 5060 or something. A tier + C tier.


. . . . . . .


I still think that frame gen might be more accurate if game development broadcast actual vectors of moving in game entities (beings, forces, virtual cameras), and vectors broadcast from player inputs and FoV movement, etc. That could allow for many more generated frames per native frame (like mark R's graphic), more accurately.

From an older oculus quest article (2019) :

https://www.reddit.com/r/oculus/comments/ah1bzg/timewarp_spacewarp_reprojection_and_motion/

https://www.uploadvr.com/reprojection-explained/

"Differences Between Application Spacewarp (Quest) and Asynchronous Spacewarp (PC)

While a similar technique has been employed previously on Oculus PC called Asynchronous Spacewarp, Meta Tech Lead Neel Bedekar says that the Quest version (Application Spacewarp) can produce “significantly” better results because applications generate their own highly-accurate motion vectors which inform the creation of synthetic frames. In the Oculus PC version, motion vectors were estimated based on finished frames which makes for less accurate results."

If getting a high multiple of higher % accurate frames generated per native frame, putting gpu functions on a secondary pcb shouldn't really be necessary.

. . . . . .

Interesting thought experiments but the way devs (and due to their overlord's schemes) failed on even HDR implementation in some games, release unfinished games, unoptimized games, etc. I don't know how much hope I'd have for many of those things unless nvidia dictated and promoted it, and between nvidia and something like unreal engine were able to make it very simple, seamless, (and cheap) to implement without much if any effort by the game creators/studio.

 

[sharknice]

SLI on 3dfx Voodoo2/5 was ScanLine Interleave and worked by having each card render every second line. It did not give 2x performance as in 2x FPS but it did basically double filltrate... back then GPUs were not GPUs and more like accelerators to drawing triangles on the screen. With super fast CPU you could approach 2x improvement in frame rates.

Then Nvidia bought 3dfx after 3dfx made some idiotic decisions and being late to the party with proper Riva TNT2 competititor and not having proper GeForce competitor and Nvidia with it got rights to use SLI name. They renamed it to Scallable Link Interface or something like that and did not render every second frame instead having two modes:
- SFR - frame would render top of the screen on one card and bottom on the other card and where they would split would change depending on which side had more work to do
- AFR - each GPU would render every second frame

Here lies the issue with Nvidia's SLI
If they managed to make rendering every second line they would get advantage of not needing to worry about GPU load because in this case both GPUs would roughly be utilized the same.
The issue was that by the time of GeForce 6 the so called 3d accelerators, now called GPUs, became much more advanced and had programmable shaders which were not so easy to split per-line basis. Also any vertex shader would need to be repeated on each card reducing possible scaling.

Also why I wrote before in this thread that using second card to do DLSS stuff would make more sense. GPU is just producing samples to be processed and in this case we can just render the same frame with different offsets - which for any frame would give the same result as rendering two still frames on one GPU.

In this case result would be more akin to what 3dfx already did with Voodoo 5 5500 where you could use SLI in the same way I described it - so render every second line and get higher performance OR: render the same exact frame at output resolution but using different sample offsets get additional samples to be used to get 2x SSAA or in case of Voodoo 5 6000 having 4 chips get 4x SSAA. Same could be done today albeit using DLSS and simply getting more sample points for DLSS. The issue here would be that adding second GPU would only improve image quality and not improve performance... then again you could lower actual render resolution by half pixels to get the same image quality* basically and this would improve performance.

*) It is a bit more complicated but generally it would be possible depending on how temporal sample accumulation was configured. It could be configured to prioritize looks of higher DLSS levels including above DLAA or to keep the general final looks and cut down time to accumulate samples and therefore reduce motion artifacts.

---
Using second card to generate frames?
Lots of data would need to be moved in and out the GPUs for that and it all depends on how much time GPU spends on frame generation. This can be estimated from scaling of FG. If 100fps gives 180fps with FG then via the magic of napkin calculations it is just 1.1ms per real frame to render additional frame. Still it might be worth it to have better frame gen algorithms working independently of game at always monitor's refresh rate and being able to produce very good motion blur. Here by motion blur I mean more like this effect where lower frame rate material can appear smoother if it is actually generated out of multiple frames blended together. Such tech could make even owners of 480Hz monitors having to lift their jaw off the floor seeing how smooth the image looks. With frame gen since we already create frames it would make sense to generate even more frames around the generated frame to create such motion-blur effect. Calling it as motion "blur" in this case would not capture its looks or purpose.

All in all today possibilities for second GPUs are endless and the whole thing a bit easier to pull off than in Nvidia's SLI times.
Also it doesn't need to be Nvidia who makes such tech. AMD and/or Intel can do it themselves/first.
Maybe such use cases are something Nvidia and/or AMD and/or Intel already considered. We might never know...

I'm sure they have considered, especially intel and AMD because it would give them an opportunity to compete with NVIDIA at the top end. I think it just isn't feasable.

There are a lot of features that require information from one frame to the next that would not work or would have to be re-engineered to work.
This is why even way back when SLI was still a thing there were games that didn't work or had issues. Now there are a lot more features and techniques that are relied on to improve image quality, latency, and timings that would not work with alternate frame rendering. And there are even more thiings that wouldn't work splitting the rendering of a frame between GPUs.

Also like you said sharing information between cards is a big problem. They push the limits on memory bandwidth and an interface between the cards is not going to be any where near as fast and severly bottlenecking. To make current features work the GPUs would basically have to share memory so SLI will probably just never come back.

The only thing I can see SLI coming back for is something like VR where there are 2 distinct views being rendered. Or maybe if streoscopic 3D monitors make a come back

 

[LukeTbk]

Now that Nvidia has invested so heavily in frame-gen, it might make sense to have a 2nd GPU carry more of the load in frame generation.

With how much time is added to go from 1 generated frame to 3, it seem that most of the added latency come from having to wait for an extra frame, not so much the frame generation for the nvidia solution at least (and on 5000 series raw generative image power).

if game development broadcast actual vectors of moving in game entities

I think DLSS frame generation must have motion vector (like upscaling do, they also ask for the depth map and other stuff) and they did start to play with timespace warp it will be released in 2 competitive game:

View: https://youtu.be/zpDxo2m6Sko?t=124

As for the SLI type solution task, I think people talking about data-latency issue are right here, if chiplet seem yet to be possible to make it work, everything is harder on separate GPU with a distance in between and different ram pool, there is a lot of full screen (and previous frames) affair going on here, the monitor split of the past, by line or section is getting just harder and harder. VR would be a rare case where it sound relatively easy

 

[XoR_]

I'm sure they have considered, especially intel and AMD because it would give them an opportunity to compete with NVIDIA at the top end. I think it just isn't feasable.

There are a lot of features that require information from one frame to the next that would not work or would have to be re-engineered to work.
This is why even way back when SLI was still a thing there were games that didn't work or had issues. Now there are a lot more features and techniques that are relied on to improve image quality, latency, and timings that would not work with alternate frame rendering. And there are even more thiings that wouldn't work splitting the rendering of a frame between GPUs.

Also like you said sharing information between cards is a big problem. They push the limits on memory bandwidth and an interface between the cards is not going to be any where near as fast and severly bottlenecking. To make current features work the GPUs would basically have to share memory so SLI will probably just never come back.

The only thing I can see SLI coming back for is something like VR where there are 2 distinct views being rendered. Or maybe if streoscopic 3D monitors make a come back

I was not suggesting to use AFR (Alternate Frame Rendering) because AFR sucks and as far as performance is concerned it is inherently worse than frame generator we already have.
Instead I suggested to always render the same exact frame and collect slightly different samples. It would double the speed of sample acquisition and therefore improve image quality per given DLSS level. Think almost DLAA quality at DLSS Quality performance. Almost because Quality drops number of rendered pixels by slightly more than half so it is 44% rendered pixels and therefore two cards could get 88% pixels. DLAA and especially with RT could have better than "native" image quality.

Implementing this would not be very easy but should be much easier than AFR or SFR and give Nvidia much better control in how things work than hacking games through drivers.

 

[elvn]

With how much time is added to go from 1 generated frame to 3, it seem that most of the added latency come from having to wait for an extra frame, not so much the frame generation for the nvidia solution at least.


I think DLSS frame generation must have motion vector (like upscaling do, they also ask for the depth map and other stuff) and they did start to play with timespace warp it will be released in 2 competitive game:

View: https://youtu.be/zpDxo2m6Sko?t=124

As for the SLI type solution task, I think people talking about data-latency issue are right here, if chiplet seem yet to be possible to make it work, everything is harder on separate GPU with a distance in between and different ram pool, there is a lot of full screen (and previous frames) affair going on here, the monitor split of the past, by line or section is getting just harder and harder. VR would be a rare case where it sound relatively easy

I know Frame Gen works on vector information, but as far as I know so far, unlike SpaceWarp that has actual vector data broadcast from the peripherals and game engine informing the the prediction system of vector directly (as well as comparing two frames) - - - - - afaik current nvidia framegen tech is buffering a frame and using machine leaning/ai chip to make a best guess, inferring what motion vectors are translating between the two frames.

The video says it uses camera, color, and depth data. As I watched in more than once, it seems like they are saying the buffered frame, frames in the past behind the one being delivered and viewed, are being used to "color in the blanks" by predicting the FoV shift, sort of cutting and pasting areas of a prior frame into a new one and interpolating how they will have moved and changed.

from the video : "Nvidia has developed a predictive rendering algorithm" . . . "which uses - camera, color, and depth data" . . . "from prior frames" . . "to inpaint these holes accurately".


while occulus had:

"While a similar technique has been employed previously on Oculus PC called Asynchronous Spacewarp, Meta Tech Lead Neel Bedekar says that the Quest version (Application Spacewarp) can produce “significantly” better results because applications generate their own highly-accurate motion vectors which inform the creation of synthetic frames. In the Oculus PC version, motion vectors were estimated based on finished frames which makes for less accurate results."

.
.
The difference being between solely comparing finished frames using a buffer to best guess what the vectors are by inferring, vs. the actual application broadcasting vectors from the application/drivers/game-engine (in-game entities and forces vectors, virtual cameara/FoV movement/headset movement vectors), in addition to guessing between frames.

 

[LukeTbk]

I know Frame Gen works on vector information, but as far as I know so far, unlike SpaceWarp that has actual vector data broadcast from the peripherals and game engine informing the the prediction system of vector directly (as well as comparing two frames) - - - - - afaik current nvidia framegen tech is buffering a frame and using machine leaning/ai chip to make a best guess

Maybe the new one, but historically you had to pass motion vector to dlss (upscaling or framegen) and we could often see a difference for game asset that did not had them like particle and rain for that reason:
https://developer.nvidia.com/blog/how-to-successfully-integrate-dlss-3/

Maybe it is now good enough for the game engine to do pass them less affair but that would be a dlss 4.0 innovation, when we look say this example:

https://github.com/nvpro-samples/vk_streamline/blob/main/main.cpp
Motion vector is mentionned, but seem calculated in a shaders so could been just frame diff all along.