先看看怎么算，我想了想，发现脑子不太够用，于是画了个示意图来数一数。
先画个理论上的，帧生成本身完全不耗时的：

灰色是没有帧生成时候的渲染延迟，原生延迟应该是这个。
黑色是有帧生成的时候，额外的延迟。
简单一数DLSS3的插一帧理论上最低会增加0.5倍的延迟，DLSS4的插三帧最低是增加0.75倍的延迟。

所以来算一下这个图，原始帧率107。
那么算一下原始渲染延迟就是1s/107fps = 9.345794392523364485981308411215ms。
那么算一下插一帧的时候的理论最低额外延迟就是9.345794392523364485981308411215ms*0.5 = 4.6728971962616822429906542056075ms。
那么我们把原图的原始延迟加上这个理论最低额外延迟，24.3ms+4.6728971962616822429906542056075ms = 28.972897196261682242990654205608ms。
再看看原图的插一帧延迟28.8，居然比理论值还低。

再来看一下实际的，我们假设插帧消耗时间是渲染时间的五分之一。
插一帧的情况下：

继续数格子，发现实际就是简单的加了一格的时间。所以这种情况下延迟增加了0.7倍。

消耗两帧的情况下，实际上也是增加一格，延迟增加0.95。
所以可以总结一个公式就是：原始渲染延迟+(原始渲染延迟*(1-1/(插帧数+1)))+插帧消耗 = 显示延迟
大家学会了吗？以后不要被无良媒体骗了。

另外补充一下，最近某些人看到那个几把弯的造谣视频说什么DLSS FG是补未来帧，还真就当真了。
先从逻辑上来看一下，连乒乓球运动员的人脑这么强大的“AI”都无法准确预测对手的下一招，你个限制在几毫秒运算时间的即时AI有什么资格说你能预测？
如果你仅凭前两帧的运动向量来算的话，那么鼠标一旦脱离原有轨迹，那么是不是视频画面就是“左右横跳”？这是可以游戏可以接受的吗？
抛开逻辑，我们来看看DLSS FG的官方编程指南，随便摘抄一段“4.0 HANDLE MULTIPLE SWAP-CHAINSDLSS-G will automatically attach to any swap-chain created by the application unless manual hooking is used. In the editor mode there could be multiple swap-chains but DLSS-G should attach only to the main one where frame interpolation is used.Here is how DLSS-G could be enabled only on a single swap-chain:”
看见了吗？“frame interpolation”，插帧，帧插值，帧间内插。
完