posted by wap, platform: Android
ns2因为速度限制导致原来支持dlss的游戏跨过来时为了帧率不支持，我的理解是比如原始帧生成15ms.dlss10ms.，帧时间就是两者相加为25ms,也就是40fps,但是为什么不能多缓冲一帧，让dlss和原始帧同时生成呢？是因为实际上dlss占用的显卡资源很多，运行时候显卡无法进行原生帧运算？资源冲突主要在哪个方面？

这什么标题仿写

一台PC生成原始画面和DLSS是那个时间
但NS2的Raw Power和Tensor Core算力是跟那台PC一样的么
不一样就没有可比性

那视频都贴了，实验也早就做了
https://www.bilibili.com/video/BV1t5R2YHEF7/
说白了靠DLSS做个480p画面然后强拉1080p的实验也做过了，效果比纯马赛克强，但依然难尽人意，任天堂应该也是不满意的
但这里比较有意思的是一个Lite DLSS的新专利，不一定实装，但要是能落地，那就是一个给掌机设备准备的折中办法

posted by wap, platform: Android
任天堂那个专利我记得是540p拉到1080p，不知道效果怎么样，等后续吧

posted by wap, platform: Android

引用:

原帖由 @Nemo_theCaptain  于 2025-4-8 14:36 发表
这什么标题仿写

一台PC生成原始画面和DLSS是那个时间
但NS2的Raw Power和Tensor Core算力是跟那台PC一样的么
不一样就没有可比性

那视频都贴了，实验也早就做了
https://www.bilibili.com/video/BV1t5R2YHEF7/
说白了靠DLSS做个480p画面然后强拉1080p的实验也做过了，效果比纯马赛克强，但依然难尽人意，任天堂应该也是不满意的
但这里比较有意思的是一个Lite DLSS的新专利，不一定实装，但要是能落地，那就是一个给掌机设备准备的折中办法

我问的是如果dlss和原生帧计算并行，类似多缓冲一帧，那么dlss后处理就不会增加帧时间了，为什么这类处理不这么做

引用:

原帖由 爱猫咪的薛定谔 于 2025-4-8 23:30 发表
posted by wap, platform: Android
我问的是如果dlss和原生帧计算并行，类似多缓冲一帧，那么dlss后处理就不会增加帧时间了，为什么这类处理不这么做

会影响操作延迟，而且DLSS3对操作延迟的影响还挺明显的，DLSS4有所降低，但没任何证据表明NS2是完全版DLSS4

NS2和PS5 PRO的处境差不多
芯片面积和售价决定了Raw Power和Tensor Core不能兼得，最后都选择了优先保Raw Power
NS2是用了标准的DLSS3，但是Tensor Core算力不够
PS5 PRO是没用标准的FSR4单元，缩了水
于是两家都开始画饼，只不过NS2是隐秘的（注册专利没大张旗鼓），PS5 PRO是公开的（FSR4有索尼参与，但PSSR要模仿需要一年，还不保证模仿度有多高）

posted by wap, platform: Chrome
因为UI和部分后处理得在upscaler之后画

posted by wap, platform: Android

引用:

原帖由 @Nemo_theCaptain  于 2025-4-8 15:34 发表
会影响操作延迟，而且DLSS3对操作延迟的影响还挺明显的，DLSS4有所降低，但没任何证据表明NS2是完全版DLSS4

NS2和PS5 PRO的处境差不多
芯片面积和售价决定了Raw Power和Tensor Core不能兼得，最后都选择了优先保Raw Power
NS2是用了标准的DLSS3，但是Tensor Core算力不够
PS5 PRO是没用标准的FSR4单元，缩了水
于是两家都开始画饼，只不过NS2是隐秘的（注册专利没大张旗鼓），PS5 PRO是公开的（FSR4有索尼参与，但PSSR要模仿需要一年，还不保证模仿度有多高）

只是多一帧，好处是让dlss增加的帧时间接近0，这对于ns2这类ai性能有限的设备是很划算的吧？

posted by wap, platform: Android

引用:

原帖由 @ginaamix  于 2025-4-8 15:35 发表
因为UI和部分后处理得在upscaler之后画

记得dlss有时候ui也会有鬼影，我以为已经是最后的流程了？而且理论上这些也可以并行吧？反正一样是多缓冲一帧

posted by wap, platform: Chrome
请教业内喷了，阿杠你自己就挺业内的

理论上tensor core和shader core是不同单元，应该可以并行，不过涉及到具体游戏应用，异步则会让事情麻烦很多，主要是资源的保留与释放，以及引擎本身的渲染流程以及API框架的匹配。
如果DLSS是个只依赖color buffer的最后一步后处理，那么自然相对容易做成异步的，DLSS还需要运动向量buffer等buffer，当然这也不是什么大问题，无非是double buffer时多一个buffer而已，而关键是dlss并非渲染流程的最后一步，在dlss之后，往往还会有其他渲染操作，包括UI甚至一些后处理效果。那么这时候，哪些资源应该需要保留到DLSS结束，哪些可以在进DLSS前释放，就会变得很复杂，同时也会使每帧的可用显存空间降低。所以，以一个通用化的库存在的DLSS，自然是使用顺序化操作，最为简单健壮。

posted by wap, platform: Chrome

引用:

原帖由 @爱猫咪的薛定谔  于 2025-4-8 23:38 发表
记得dlss有时候ui也会有鬼影，我以为已经是最后的流程了？而且理论上这些也可以并行吧？反正一样是多缓冲一帧

UI肯定要在upscaler之后画，现在没有哪个超分方案是考虑UI的。
如果要并行那意味着你得把整个后处理+UI pass做成异步计算和下一帧重叠，理论是完全可行的，ID Tech好几年前就这么干了，但是：
1、GPU异步计算可不好写。
2、异步计算很有可能会是负优化。

所以ns2游戏都没有用dlss吗

引用:

原帖由 nkaito 于 2025-4-9 01:06 发表
所以ns2游戏都没有用dlss吗

数毛社说目前没看到，可能是在等DLSS Lite的大饼
用光追的好像有，树屋的马车能隐约看出光追反射

[ 本帖最后由 Nemo_theCaptain 于 2025-4-9 01:17 编辑 ]

posted by wap, platform: Android
光追单元是另外部分吧？

posted by wap, platform: Android
ns2的dlss有没有可能只用在了掌机模式，毕竟720p到1080p或者540p到900p对tensor core的算力要求相对低