wpy/minecraft-dlss
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
minecraft-dlss/docs/route-C-setup.md
T

47 KiB
Raw Permalink Blame History

路线 C（ReShade 路线）落地现状 — 实测记录

本文所有内容均为实测（文件系统检查、PE 导出表解析、DLL 字符串扫描、注册表读取），非推演。 记录时间：2026-09-16

★ 环境更正（2026-09-16 晚，推翻了本文早先的假设）

早先的记录基于「用户用 Modrinth App 玩 MC」这一错误前提，据此准备的 H:\Java\zulu... 专用 Java 与 Modrinth app.db 的 java_path 改动打在了错误目标上。 （当时搜 javaw.exe 的盘符列表漏了 H 盘，因此也没发现 H:\javahome。）

实测出的真实环境：

项 真实值
启动器 PCL2 便携版 W:\PCL 正式版 2.12.8.2\Plain Craft Launcher 2.exe
PCL 全局设置 W:\PCL 正式版 2.12.8.2\PCL\Setup.ini（仅 RAM/窗口/目录，不含 Java 选择）
MC 实际使用的 Java H:\javahome\bin\java.exe = Oracle JDK 21.0.12.1（318 MB，421 文件）
Java 清单 %APPDATA%\PCL\config.json 的 JavaList（9 项，不含 H:\javahome，说明是自动探测）
游戏目录 W:\PCL 正式版 2.12.8.2\.minecraft\versions\NGT\.minecraft\
真实实例 该目录下 versions\1.20.1-Fabric 0.19.3\（另有 PVP）
版本级设置 实例内 PCL\Setup.ini：VersionFabric:0.19.3、VersionVanilla:20.0.1、VersionArgumentJavaV2:3
该实例的 mods 含 Sodium 0.5.13、DistantHorizons 3.2.0-b、lithium、c2me、modernfix、Jade、JEI 等；另有 gpu-optimizer-0.1.0.jar.disabled 与 mods\disabled\
实例内的 reshade 目录 存在但为空（早先尝试的残留）

结论：ReShade 应注入 H:\javahome\bin\（用户已自行完成），Modrinth 相关的改动与 H:\Java\zulu... 对路线 C 无意义。

注入结果（用户自行完成，已核验）

检查 结果
H:\javahome\bin\opengl32.dll 5,255,448 B，产品名 ReShade，ver 6.8.0.2158
SHA256 B2945C29E7095491A901746B400E58DB9B1592AB092BACF2A888CE37F02D08DA —— 与已验证那份一致
ReShade.ini 506 B，安装器默认：EffectSearchPaths=.\reshade-shaders\Shaders\**、KeyOverlay=36（Home）、无 [ADDON] 段 → addon 默认从 DLL 所在目录加载，正合 DLSS5-Feeder 预期
标准 effect 包 11 个 shader + 2 纹理，含 DisplayDepth.fx（深度自检工具）与 UIMask.fx
ReShade.log 仍是 982 B 安装器占位说明 → ReShade 尚未加载
原因（已定位） MC 进程 21:46 启动，ReShade 21:51 注入 —— 进程早于注入，需重启游戏

NGX 前置条件（已核验，正常）

项 值
注册表 HKLM\SOFTWARE\NVIDIA Corporation\Global\NGXCore → FullPath=C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_b20cc8aeaed64fc2，Installed=1
nvngx.dll 不在 System32 是正常的 —— NGX 靠上述注册表键定位
驱动 RTX 5070 / 616.92（DLSS5-Feeder 实测的坏组合是 616.56 / 616.64，本机更新，未知）

★★ 里程碑：深度检测已实测通过（2026-09-16 22:0x）

这是 C 路线最大的风险点，现已排除。绿色通过。

证据链

用户按 DisplayDepth.fx 的默认设置截图（H:\javahome\bin\java 2026-09-16 22-02-43_1.png，2560×1369，3.7 MB）。 当前模型不支持读图，改用程序化量化分析（PIL + numpy），结论反而更硬。

DisplayDepth.fx 源码里的选项定义：

ui_items = "Depth map\0Normal map\0Show both (Vertical 50/50)\0";

iUIPresentType=2 → 左右分割：左半 = 法线图，右半 = 深度图 （日文说明原文：「左に法線マップ、右に深度マップ」）。

逐格灰度占比分析精确命中该分界：

0|CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD|
  左半 32 格全部 C（彩色）          右半 32 格全部 D（单色 >80%）

判定「深度认到了」的三条依据：

  1. 右半深度图为单色且层次丰富（亮度跨 0-9 全档，第 11-12 行有清晰地平线跃变）。 若深度缓冲缺失，此处应为一片均匀死值。
  2. 左半法线图为蓝绿系、地面偏绿 —— 法线只能由深度缓冲重建。 源码说明原文：「正しい見え方では、全体的に青緑風で、地平線を見たときに地面が緑掛かった色合いになります」，实测完全吻合。
  3. 色相分类图中左侧下半部大量 g（绿），即地面法线朝上的特征。

此前日志里 3 次 WARN | A depth-stencil resource was destroyed while still in use. 经证实是无害噪声，不是失败征兆。（我一度把它当成失败征兆，判断错了。）

深度方向：经用户实时观测确认为正确（我先前判断错了）

我基于单张静态截图的亮度分布（上暗下亮）推断「近亮远暗、方向反相」， 并据此改了 RESHADE_DEPTH_INPUT_IS_REVERSED=1。

用户用可转动视角的实时画面直接观测，确认「远处亮」—— 即 =0 本来就是正确的。 该设置已回退为 0。

我错在哪：从一张定格图推断「画面顶部 = 天空 = 远处」是无效推理 —— 镜头俯仰、地形遮挡都会让「屏幕上/下」与「远/近」不再对应，而静态图无法揭示拍摄时的朝向。 凡是需要判断空间朝向的结论，必须靠可以主动移动视角的实时观测，不能靠单张静态帧。

DisplayDepth.fx 的正确外观（源码定义）：近处暗、远处亮。

一、已确认可用的环境事实

1.1 ReShade 注入位置（已成功）

项 值
启动器 Modrinth App
实例 Aged（1.20.1 Fabric）、Fabulously Optimized（1.21.11 Fabric）
注入目标 C:\Users\Administrator\AppData\Roaming\ModrinthApp\meta\java_versions\zulu21.48.17-ca-jre21.0.10-win_x64\bin\
代理 DLL opengl32.dll，5,255,448 B
版本 6.8.0.2158，产品名 ReShade，公司 crosire，描述 "post-processing injector for 64-bit"
系统原生对比 C:\Windows\System32\opengl32.dll = 983,040 B（证明注入的是代理层）
覆盖层按键 ReShade.ini → [INPUT] KeyOverlay=36,0,0,0 → key code 36 = Home
已生成 ReShade.ini(408 B)、ReShade.log(982 B)、ReShadePreset.ini(0 B)

⚠️ 这个 JRE 是 Modrinth App 的公共运行时，被它所有实例共用 → 注入同时影响 Aged 和 Fabulously Optimized。 如果改用 PCL / HMCL 启动，它们用别的 Java，ReShade 不会加载。

1.2 Add-on 支持：完整版，已用导出表定案

ReShade.log 里那 982 字节是安装器预置的占位说明，不是真日志 —— 原文 "If you are reading this after launching the game at least once, it likely means ReShade was not loaded by the game."，即 ReShade 尚未真正加载过。

DLL 里同时存在这两条字符串，光看字符串无法定案（两种构建可能都编进去）：

Skipped loading add-on from '%s' because this build of ReShade has only limited add-on functionality.
Failed to register an event because only limited add-on functionality is available!

定案证据是导出表（共 494 个导出）：

导出 用途
ReShadeRegisterAddon / ReShadeUnregisterAddon addon 注册入口
ReShadeRegisterEvent / ReShadeUnregisterEvent 事件
ReShadeRegisterEventForAddon / ReShadeUnregisterEventForAddon 每 addon 事件 ← DLSS5-Feeder 必需
ReShadeRegisterOverlayForAddon / ReShadeUnregisterOverlayForAddon 每 addon 覆盖层
ReShadeCreateEffectRuntime / ReShadeDestroyEffectRuntime / ReShadeUpdateAndPresentEffectRuntime effect runtime —— reshade_render_technique 靠这组工作
ReShadeGetImGuiFunctionTable ImGui 函数表
ReShadeGetConfigValue / ReShadeSetConfigValue / ReShadeSetConfigArray 配置读写
ReShadeGetBasePath / ReShadeLogMessage / ReShadeVersion 杂项

→ 受限版不会有 *ForAddon 系列与 effect-runtime 导出。这是完整 addon 版。

1.3 GPU / 驱动（与官方实测表的对照）

项 值
GPU NVIDIA GeForce RTX 5070（+ AMD Radeon 核显）
GL 4.6.0 NVIDIA 616.92，405 个扩展
驱动版本风险 DLSS5-Feeder 实测坏组合是 616.56 / 616.64；本题机器是 616.92，比他们测过的都新，未知
自检手段 host64\dlss5-feed-host64.exe --test，300/300 evaluates succeeded 才算 OK

二、实例现状（决定了能不能测）

2.1 Aged —— 目标实例（1.20.1 Fabric，131 个 mod）

存在 缺失（与用户原述不符）
iris-1.7.5+mc1.20.1.jar Sodium 缺失
DistantHorizons-2.2.1-a-1.20.1-forge-fabric.jar Voxy 无
indium-1.0.34+mc1.20.1.jar Embeddium 无（且 Embeddium 是 Forge/NeoForge 系，Fabric 上本就不适用）
Shut Up GL Error-fabric-1.20.1-1.0.0.jar shaderpacks = 0 个
GeckoLibIrisCompat-Fabric-1.0.0.jar config 目录 0 项（131 个 mod 的实例，配置为空，反常）

两个必须先处理的问题：

  1. Indium 硬依赖 Sodium，而 Sodium 不在 mods/ 里（按文件名核验，未读 jar 清单）。 Fabric 会在启动时报依赖错误弹红屏 —— 这与 ReShade 无关，但极易被误判成 ReShade 搞坏的。
  2. Shut Up GL Error 会吞掉 GL 错误。 调试 ReShade 期间应移出 mods，否则真实报错会被静默吃掉。

好消息：shaderpacks 为 0 → Iris 不走自定义渲染管线 → 深度识别更接近原版， 比"带光影包"的情形通过率更高。这修正了此前"在 Iris 下很难"的判断。

2.2 Fabulously Optimized —— 1.21.11（非目标版本）

45 个 mod，含 sodium-fabric-0.8.11+mc1.21.11.jar、iris-fabric-1.10.7+mc1.21.11.jar、 lithium、entityculling 等；shaderpacks 同样为 0。 可作为"验证 ReShade 能否注入 Minecraft"的干净对照实例（用一个变量隔离问题）。

三、ReShade 的目录约定（关键，容易踩）

DLSS5-Feeder 文档原话：

Add-on discovery is also a non-question: ReShade is the local opengl32.dll, and add-ons load from its own directory.

即 addon 默认要从 opengl32.dll 所在的目录加载 —— 对我们是那个 JRE 的 bin\， 这很不干净。但 DLL 里有 AddonPath 字符串，说明可用配置项改掉：

; 注入目录\ReShade.ini
[ADDON]
AddonPath=<游戏目录>\reshade-addons
DisabledAddons=

[GENERAL]
EffectSearchPaths=<游戏目录>\reshade-shaders\Shaders
TextureSearchPaths=<游戏目录>\reshade-shaders\Textures
  • *.addon / *.addon64 放 AddonPath
  • DLSS5_Feed.fx 放进 EffectSearchPaths 才能作为 effect 加载
  • 当前安装没有装任何 effect 包（reshade-shaders 目录不存在），需要手工建目录或补装

四、所需组件清单

组件 来源 状态
ReShade 6.8+ 含 add-on 支持 reshade.me ✅ 已装（6.8.0.2158，导出表已证 addon 完整）
Generic Depth add-on ReShade 自带，需在 Add-ons 页启用 ⏳ 待首次运行确认
神经消费者：Deep Fried Chicken（推荐）或 Krish renodx-dlss5.addon64 各自 Discord ❌ 需用户获取（AI 无法访问 Discord）
nvngx_dlssnr.dll GUI-DLSS5 包 ✅ 已有
nvngx_dlss.dll（放游戏目录旁） Streamline SDK bin\x64\ ✅ 已有
运动矢量提供者：LumeniteFX Kernel（=3，推荐） github.com/umar-afzaal/LumeniteFX ❌ 需下载
dlss5-feed.addon64 + DLSS5_Feed.fx DLSS5-Feeder release ❌ 需下载

五、C 路线在 OpenGL 下的天花板（引自官方 Limitations）

DLAA contract, optional reduced work extent on D3D11 — render resolution still equals DLAA output resolution, but the private work extent can be 50–100% of the native backbuffer... D3D12, Vulkan and OpenGL paths remain at 100%. This is not jittered DLSS Super Resolution, and a Quality/Balanced/Performance mode cannot be added.

Estimated motion vectors → temporal artifacts in fast motion; the UI is processed with the scene (a UI mask / pre-UI colour capture is future work).

结论：OpenGL 下是纯 DLAA + DLSS 5 神经渲染观感，内部渲染分辨率不降 → 零帧率收益，无超分、无插帧。 且 UI（MC 的物品栏 / 聊天 / F3）会与场景一起被处理而拖影。

底层机制（DLSS5-Feeder 官方描述 + 本项目实测验证）：

game frame → ReShade effects → [motion vectors] → [DLSS5_Feed] → 私有 D3D12 设备
                                                  深度 + MV        跑真正的 DLSS evaluate
                                                                    ↓
                                             神经结果写回画面 → 后续 effects → present

六、独立 Java 运行时（H 盘）— 已完成并验证

动机：Modrinth 的 JRE 是所有实例共用的，且 Modrinth App 可能校验/重下它把注入清掉。 独立一份 Java 可同时解决「污染其他实例」「被覆盖」「JRE 的 bin\ 不适合作 addon 目录」三个问题。

项 值
运行时 H:\Java\zulu21.48.17-ca-jre21.0.10-win_x64\
来源 Azul 官方 https://cdn.azul.com/zulu/bin/zulu21.48.17-ca-jre21.0.10-win_x64.zip（49,573,633 B）
版本校验 Zulu21.48+17-CA (build 21.0.10+7-LTS)；IMPLEMENTOR=Azul Systems, Inc.；OS_ARCH=x86_64 —— 与 Modrinth 那份逐字一致
洁净性 解压后 bin\ 内无 opengl32.dll（原版）
ReShade 代理 bin\opengl32.dll = 5,255,448 B，SHA256 与已工作那份一致：B2945C29E7095491A901746B400E58DB9B1592AB092BACF2A888CE37F02D08DA
配置 bin\ReShade.ini（本项目手写，1,600 B）
内容根 H:\ReShadeMC\{addons, shaders, textures, presets}
备份 H:\Java\_reshade-backup\from_modrinth_jre\（从 Modrinth JRE 移出的 17 个 ReShade 文件）

隔离已验证：Modrinth 共享 JRE 已还原为 327 个文件的原版， H 盘那份为 329 个，差异恰好是 bin\opengl32.dll 与 bin\ReShade.ini 两个文件。

ini 键名已从 DLL 二进制核准（非凭记忆）： AddonPath ✅ DisabledAddons ✅ EffectSearchPaths ✅ TextureSearchPaths ✅ PerformanceMode ✅ NoEffectCache ✅ IntermediateCachePath ✅ ScreenshotPath ❌ 不存在（故未写入）

⚠️ 本 ini 是部分文件，ReShade 首次运行会与自身默认值合并并重写它。 首次启动后必须重读该 ini，确认这些路径被接受而非被重置。

切换实例 Java 的开关（已定位）

%APPDATA%\ModrinthApp\app.db（SQLite）→ 表 instance_launch_overrides， 列 overrides（JSONB），字段 java_path：

{"java_path":null,"extra_launch_args":null,"custom_env_vars":null,"memory":null,
 "force_fullscreen":null,"game_resolution":null,
 "hooks":{"pre_launch":"","wrapper":"","post_exit":""}}

UI 路径：Modrinth App → 实例 → Options → Java 版本 → 覆盖全局设置 → 选 H:\Java\zulu21.48.17-ca-jre21.0.10-win_x64\bin\javaw.exe

另：java_versions 表登记了 Modrinth 自管的那份： 21 | 21 | amd64 | ...\ModrinthApp\meta\java_versions\zulu21.48.17-ca-jre21.0.10-win_x64\bin\javaw.exe

七、实测发现的阻塞项

⚠️ Aged 实例根本没安装完

instances 表：
  legacy:Fabulously Optimized   install_stage = installed        ✅
  legacy:Aged                   install_stage = not_installed    ⚠️ 未完成

这一条解释了此前三个反常现象：

  1. config 目录 0 项（131 个 mod 的实例不该如此）
  2. Sodium 缺失（mods/ 里无 sodium-*）
  3. Indium 存在但依赖缺失 → Fabric 会报依赖错误弹红屏

在修好之前测 ReShade，等于在坏地基上做实验。 且该红屏与 ReShade 无关，极易被误判为 ReShade 搞坏了。

建议的测试顺序（单变量隔离）

  1. 先拿 Fabulously Optimized（installed，Sodium+Iris 正常） 验证「ReShade 能否注入 Minecraft」
  2. 再修好 Aged，验证「1.20.1 下深度识别能否成功」

其他

  • Shut Up GL Error-fabric-1.20.1-1.0.0.jar 会吞掉 GL 错误 → 调试期间移出 mods/
  • 已装上 ReShade 标准 effect 包，其中 UIMask.fx 可能是缓解「HUD 被一起处理」的抓手

八、待办与判据

步骤 判据
1. Modrinth App 里把实例 Java 覆盖为 H 盘那份 Options → Java 版本 → 覆盖
2. 先用 Fabulously Optimized 启动 ReShade 覆盖层能用 Home 呼出
3. 读真 ReShade.log 出现真实初始化日志，且含 Searching for add-ons (*.addon, *.addon64) in '...'
4. 确认 H:\Java\...\bin\ReShade.ini 被重写后仍保留我们的路径 AddonPath / EffectSearchPaths 未被重置
5. 让 Aged 装完（install_stage 变 installed） Sodium 到位，无依赖红屏
6. 移出 Shut Up GL Error —
7. Aged 启动后进 Add-ons 页 Generic Depth 认到 MC 的场景深度 ← 整条 C 路线的生死线
8. 若第 7 步失败 记录 ReShade.log 全文；结论：C 在 MC 上不可行 → 回退路线 A/B

已备好的退路：本项目自己的桥接已实测证明 GL↔VK 互操作完全可用 （见 README 第七节），因此即使 C 失败，超分/插帧仍有 A/B 两条路可走。

★★ 组件部署完成（2026-09-16 晚，全部经静态核验）

文件归位

文件 大小 放置位置 来源 核验
opengl32.dll 5,255,448 H:\javahome\bin\ ReShade 6.8.0.2158 SHA256 B2945C29…08DA
nvngx_dlss.dll 58,956,912 H:\javahome\bin\ Streamline SDK 2.14.1 ver 310.9.1.0
nvngx_dlssnr.dll 165,840,496 H:\javahome\bin\ GUI-DLSS5 v0.1.46 SHA256 E16BCF15…1FC8E，与原始 zip 逐位一致
dlss5-feed.addon64 308,224 H:\javahome\bin\ DLSS5-Feeder 1.16.0-beta.2 见下
DLSS5_Feed.fx 51,193 …\bin\reshade-shaders\Shaders\ 同上 —
lumenite_*.fx ×8 — …\Shaders\ LumeniteFX mainline —
lumenite_*.fxh ×4 — …\Shaders\include\ 同上（必需，缺则编译失败） —
lumenite_bluenoise256.png 259,314 …\reshade-shaders\Textures\ 同上 —

nvngx_dlssnr.dll 导出符号（证实是 NGX 插件）

55 个导出，含完整 NGX API： NVSDK_NGX_VULKAN_Init / _CreateFeature / _EvaluateFeature / _GetScratchBufferSize， NVSDK_NGX_D3D12_Init / _CreateFeature / _EvaluateFeature， NVSDK_NGX_D3D11_*、NVSDK_NGX_CUDA_*。

注：dlssnr_init/process/... 那组不在这个文件里 —— 它们在 dlssnr_host.dll（另一个 shim）。 我一开始按 dlssnr* 过滤导出，什么也没匹配到，就是这个原因。

dlss5-feed.addon64 的加载机制（曾误判，已澄清）

dumpbin /exports 确认它只导出 DESCRIPTION 与 NAME，我一度以为它无法被 ReShade 加载。

真相：它的导入表里只有系统 DLL（VERSION/KERNEL32/USER32/ADVAPI32/MSVCP140/VCRUNTIME140/ucrt）， 没有任何 ReShade 模块依赖。二进制里那些 ReShadeRegisterAddon / ReShadeGetConfigValue / ReShadeRegisterEvent 等是字符串（运行时用 GetProcAddress 解析）。

结论：我们的主机命名为 opengl32.dll（而非 ReShade64.dll）不会造成任何问题。

★★ 重大纠正：ReShade 分两个构建，导出表证明不了是哪一种

我早前从导出表看到 ReShadeRegisterAddon / *ForAddon / ReShadeCreateEffectRuntime 等， 据此写了「已用导出表定案：这是完整 addon 版」。这个结论是错的。

实测对照（同一目录、同一 addon，只换 DLL）：

ReShade DLL 大小 ReShade.log 结果
标准/受限版 5,255,448 WARN | Skipped loading add-on from '...' because this build of ReShade has only limited add-on functionality. ❌
Addon 版 5,592,064 INFO | Registered add-on "DLSS 5 Feed 1.16.0-beta.2" v1.16.0.2 using ReShade API version 20. ✅

教训：受限版照样导出完整 addon API（好让 addon 能编译链接），真正的开关是编译期 RESHADE_ADDON_LITE，只在运行时拒绝加载时才暴露。 → 判断这类能力时，导出表只能证明「API 存在」，不能证明「功能启用」；必须做运行时验证。

ReShade 两个构建的获取方式

构建 安装包 大小
标准版（受限 addon） https://reshade.me/downloads/ReShade_Setup_6.8.0.exe 4,075,064 B
Addon 版（完整 addon） https://reshade.me/downloads/ReShade_Setup_6.8.0_Addon.exe 4,318,424 B

Addon 版安装包是自定义格式（载荷压缩存在 .rsrc），但可用 7-Zip 直接解开， 无需运行安装器：

7z x ReShade_Setup_6.8.0_Addon.exe -o<目录>
  → ReShade64.dll  5,592,064 B   ver 6.8.0.2155
    SHA256 0CEE63F9C9F13F3AC909C5B4903F4DBB4B719A7AB3B4F13B0DEAF83C814B94F7
    （另有 ReShade32.dll + 4 个 Vulkan/XR layer json）

把 ReShade64.dll 改名为 opengl32.dll 放进 Java 的 bin\ 即等效于安装。 受限版已备份：H:\DLSS\reshade_addon_extract\opengl32.dll.limited-build.bak。

依赖预检：15 个依赖全部可解析（MSVC 运行时在 System32 与 JDK 自带副本中均有）。

DLSS5_Feed.fx 源码揭示的必知规则

  1. addon 在 DLSS5_Feed technique 渲染完之后立刻运行 DLSS → 必须勾选 DLSS5_Feed.fx
  2. 运动矢量 provider：0=texMotionVectors（默认）/ 1=Launchpad / 2=VORT（源码标注 recommended） / 3=LumeniteFX Kernel / 4=LumeniteFX QuantMotion。已备好 3 与 4
  3. provider 的 technique 必须排在本 effect 之上才会生效
  4. 它带有一条针对我们最担心失败模式的自我诊断字符串： "<-- depth is FLAT while the scene moves: ReShade's Generic Depth is on the wrong buffer"
  5. 无神经消费者时仍可运行「纯 DLAA」 —— 驱动兼容表里 (none — DLAA only, no neural pass) 一行是 ✅ 300/300。 因此不必等 Discord 组件就能验证整条管线

仍缺（只能从 Discord 取，AI 无法访问）

deep-fried-chicken.addon64 + deep-fried-chicken-nvngx.dll + deep-fried-chicken.cfg 或 Krish 的 renodx-dlss5.addon64（RenoDX Discord #DLSS5）。两者只能放一个。 两者均不自带 nvngx_dlssnr.dll。

下一步操作（用户）

  1. ReShade 全局预处理定义加 DLSS5_MV_PROVIDER=3
  2. 效果列表中：先启用 lumenite_Kernel.fx 的 technique，再在其下方启用 DLSS5_Feed.fx；关掉 DisplayDepth.fx
  3. 重启 MC（addon 与 effect 变更需重新加载）
  4. 读日志：H:\javahome\bin\dlss5-feed.log（新增）与 ReShade.log —— DLSS5-Feeder 要求 dlss5-feed.log 第 1 行为 dlss5-feed 1.16.0-beta.2 commit a6c23bd

★★★ 驱动与 NGX 栈预检：完全通过（2026-09-16 22:24）

DLSS5-Feeder 自带 host64\dlss5-feed-host64.exe --test，可在不启动游戏的前提下 单独验证「驱动 + NGX + NGX 插件」这一栈。它需要三样东西与它同目录：

需要 说明
nvngx_dlss.dll、nvngx_dlssnr.dll 它在自己所在目录查找 NGX 运行时（不是在游戏目录）
dxgi.dll ReShade 的 DLL 改名为 dxgi.dll（同一份二进制可直接改名复用）——它需要自己起一个私有 D3D12 swapchain
工作目录 = 它自己所在目录 结果写进 dlss5-feed-host.log，stdout 无输出，退出码反映结果

实测结果

[host] device adapter: NVIDIA GeForce RTX 5070  PCI 10DE:2F04  driver 616.92
[host] NGX runtime nvngx_dlssnr.dll: 310.8.0.0, NVIDIA DLSSNR - DVS PRODUCTION, CL 38718415
[host] NGX runtime nvngx_dlss.dll:   310.9.1.0, NVIDIA Deep Learning SuperSampling, CL 38868064
[host] NGX feature requirements: SuperSampling (DLSS)          -> supported (min arch 0x160)
[host] NGX feature requirements: feature 18 (neural rendering) -> supported (min arch 0x1B0)
[host] NVSDK_NGX_D3D12_Init -> 0x00000001 (Success)
[host] NGX capabilities: SuperSampling.Available=1  NeedsUpdatedDriver=0  MinDriver=470.0
[host] DLSS Quality at 1920x1080: optimal 1280x720, render range 960x540 .. 1920x1080
[host] feature ready: 640x360 DLAA flags=74
[host] --test finished: 300/300 evaluates succeeded
[host] --test: DLSS GPU 0.43 ms/frame over 299 timed frames at 640x360
[host] exit 0

300/300 evaluates succeeded 即官方规定的通过标准。

这一条解决了哪些悬置的未知

未知 结论
驱动 616.92 可用性（官方实测的坏组合是 616.56 / 616.64，本机更新） ✅ 可用，NeedsUpdatedDriver=0，MinDriver=470.0
nvngx_dlssnr.dll 身份 ✅ NVIDIA DLSSNR - DVS PRODUCTION 310.8.0.0
feature 18（神经渲染）在 RTX 5070 上是否支持 ✅ 支持，最低架构 0x1B0 = Blackwell
DLSS evaluate 实际吞吐 ✅ 实测 0.43 ms/帧 @640×360
无神经消费者时能否运行 ✅ 能 —— 本次即「无消费者」配置，对应官方表 (none — DLAA only, no neural pass) 一行

推论：不必等 Discord 组件即可验证游戏侧整条管线（纯 DLAA 路径）。

已可清理

H:\DLSS\DLSS5-Neural-Render-v0.1.46-windows-x64.zip（467,988,619 B）—— nvngx_dlssnr.dll 已解出并通过哈希核验，此 zip 可删。

★★★ 全部组件安装完成（2026-09-17 18:45）

最终文件清单（H:\javahome\bin\）

文件 大小 来源 校验
opengl32.dll 5,592,064 ReShade 6.8.0.2155 Addon 版 SHA256 0CEE63F9…B94F7
nvngx_dlss.dll 58,956,912 Streamline SDK 2.14.1 Authenticode Valid（NVIDIA）
nvngx_dlssnr.dll 165,840,496 GUI-DLSS5 v0.1.46 SHA256 E16BCF15…1FC8E
dlss5-feed.addon64 308,224 DLSS5-Feeder 1.16.0-beta.2 —
deep-fried-chicken.addon64 4,422,656 DFC 2.0.0-CP184 SHA256 C99C3528…4F303 ✅
deep-fried-chicken-nvngx.dll 3,584 同上 SHA256 9350E044…394FF ✅
deep-fried-chicken.cfg 19,790 同上 SHA256 A52A51EA…6A9AD ✅
ReShade.ini 2,982 — 见下
.dfc-installer\manifest.json 1,558 Chicken Assist status: installed

effect 侧：DLSS5_Feed.fx + lumenite_*.fx(8) + include\*.fxh(4) + lumenite_bluenoise256.png

DFC 安装（用官方 Chicken Assist，非手动复制）

CHICKEN-ASSIST.cmd -Action Install -Target H:\javahome\bin \
  -GameExecutable H:\javahome\bin\java.exe -Api opengl -Yes -NonInteractive

安装卡实测输出：

Route       : DFC through external DLSS5-Feeder
Layout      : x64-external-core
Plan        : An external feeder is already present. DFC will keep it and
              install only the DFC consumer.
[PASS] ×10，仅 [WARN] Runtime evidence（启动游戏后可消除）

路线矩阵里明确列着我们的情况（Chicken Assist installer/README.md）：

| x64 OpenGL | DFC through external DLSS5-Feeder | Chicken Assist invokes the official cross-API route; **optical-flow motion may be required** |

→ 正对应我们已配好的 LumeniteFX Kernel 光流（DLSS5_MV_PROVIDER=3）。

三个 payload 变体是同一份二进制

payload-manifest.json 里 x64-core / x64-external-core / x64-native-d3d11-core 的 SHA256 完全相同（C99C3528… / 9350E044… / A52A51EA…），只是安装器的记账分类， 不存在放错变体的风险。

Chicken Assist 对我们配置的改动：仅一行

安装器主动删除了我手写的 [ADDON] LoadFromDllMain=deep-fried-chicken.addon64， 理由是该键在 2.0 中已废弃（对应 1.4.3 更新说明：Chicken 会自己加入 early-load 列表）。 逐行 diff 确认其余配置一字未动：DLSS5_MV_PROVIDER=3、effect 路径、预设路径全部保留。 精确备份：.dfc-installer\backup\reshade\ReShade.ini.D4A4C0F8….pre-cp47.bak

⚠️ 环境坑：调用 Chicken Assist 必须先修正 PSModulePath

DSH 会话的 PSModulePath 是 PowerShell 7 的（且含空条目与 W:\Fuck）， 子进程 powershell.exe 5.1 继承后会无法自动加载自己的 Microsoft.PowerShell.* 模块， 表现为 Get-AuthenticodeSignature / Get-FileHash "not recognized"，进而误报 [FAIL] Ownership record、DLSS-NR DLL: missing。规律已实测确认：

调用 修正 PSModulePath 结果
Inspect #1 ❌ FAIL（Get-AuthenticodeSignature 找不到）
Inspect #2 ✅ PASS
Install ✅ PASS
Diagnose #1 ❌ FAIL（Get-FileHash 找不到，误报）
Diagnose #2 ✅ 全 PASS

修法：调用前设

$env:PSModulePath='C:\Users\Administrator\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\Windows\System32\WindowsPowerShell\v1.0\Modules'

这是一条通用教训：从本会话派生的任何 5.1 子进程都可能撞上，涉及签名的判断尤其要先确认模块可用。

关键配置现状

项 值
Techniques Lumenite_Kernel@lumenite_Kernel.fx,DLSS5_Feed@DLSS5_Feed.fx
TechniqueSorting 前 3 位 Lumenite_Kernel → Daltonize → Deband（生产者在前 ✅）
DLSS5_MV_PROVIDER 3（LumeniteFX Kernel）
RESHADE_DEPTH_INPUT_IS_REVERSED 0（据用户实时观测确认）
dlss5-feed.cfg enabled=1 mode=2 work_resolution=100 stall_log_ms=50

唯一剩余步骤

启动游戏（此前的 ReShade.log/dlss5-feed.log 都是安装前的）。 DFC 1.4.3 说明：会自己加入 early-load 列表，首次启动是注册，可能需再完整重启一次。 之后应产出新文件 deep-fried-chicken.log，再跑 -Action Diagnose 即可拿到运行期裁决。

2026-09-17 19:07 — 模组侧收尾：/dlss 命令 + 视频设置里的总开关与面板入口

路线 C 已经跑通（见上文运行期证据）。这一轮做的是模组自己的壳：让玩家不需要记命令就能开 DLSS。

交付物

东西 位置
构建产物 build/libs/wpywdlss-0.1.0.jar（3.83 MB，SHA 765E71434912A74F96199FD4C2CE50942F1BAC49FACBB270685F910EBDA125BB）
已部署 …\1.20.1-Fabric 0.19.3\mods\wpywdlss-0.1.0.jar（与构建产物哈希一致）
新增源码 cfg/MasterSwitch.java、gui/VideoSettingsHook.java
改动源码 cfg/FlatCfg.java（行尾保留，见下）、DlssClientMod.java、gui/DlssSetupScreen.java、fabric.mod.json

1. 命令改名 wpywdlss → dlss

子命令：dlss（开面板）/ status / install / uninstall / on / off。

openPanel() 现在用 mc.screen 当 parent，所以从哪个界面进去、关掉就回到哪个界面，而不是一律掉回游戏。

2. 视频设置里注入两个按钮（gui/VideoSettingsHook.java）

左侧 = 总开关（DLSS: 开 / DLSS: 关），右侧 = 面板入口（DLSS · 已安装 等，标签直接带实时状态）。

为什么用事件而不是 mixin

Screens.getButtons(screen) 返回的是 Fabric 的 ButtonList，构造时同时持有屏幕自己的 drawables / selectables / children 三个列表， add() 往三个里都插 —— 也就是 addRenderableWidget 做的事。渲染、点击派发、键盘焦点全部走原版同一条路径， 不需要 accessor / @Invoker。这一点是抽 ButtonList.java 源码确认的，不是推测。

布局常量是 dump 出来的，不是猜的

javap -c net.minecraft.client.gui.screens.VideoSettingsScreen 实测：

new OptionsList(minecraft, width, height, 32, height - 32, 25)
Done → Button.builder(GUI_DONE, …).bounds(width/2 - 100, height - 27, 200, 20)

所以选项行止于 height - 32，Done 所在那条横带左右两侧都是空的，两个按钮就放那里：

side = width/2 - 100 - 6 - 4          // 4 = 离窗口边的余量
w    = min(170, side)                 // side < 64 时干脆不注入，/dlss 仍可用
左侧 x = width/2 - 100 - 6 - w        右侧 x = width/2 + 100 + 6
y    = height - 27

窗口宽度实测：853 → w=170 两侧都放得下；640 → w=170 仍在界内；427 → w=103 仍在界内。

重复注入的疑虑（查清了，是安全的）

Screen.init(mc,w,h) 有个 initialized 标志位，且 ScreenMixin 在 init TAIL 和 resize TAIL 都调 afterInit， 一度怀疑会重复加按钮。dump Screen 字节码后确认三条路径都只重建一次：

路径 init(mc,w,h) 里发生了什么 结果
首次打开 initialized=false → init() 一次
从面板返回（同一个 Screen 实例） initialized=true → repositionElements() 一次
窗口缩放 resize → repositionElements() 一次

关键：Screen.repositionElements() 的实现就是 rebuildWidgets() = clearWidgets(); clearFocus(); init();， 而 resize 只调 repositionElements()、不再回调 init(mc,w,h)，所以不会叠加触发。 而且 clearWidgets() 清的正是 ButtonList 持有的那三个列表，与注入点完全对齐。

探测缓存

analyze() 要哈希 ~10 MB 载荷，所以状态探测带 1.5 s TTL；DlssSetupScreen.refresh() 与 install/uninstall/on/off 都会 VideoSettingsHook.invalidate() 强制下次重读。

3. cfg/MasterSwitch.java：一个开关同时管两个 add-on

DLSS 不是单一标志位 —— DLSS5-Feeder 和 Deep Fried Chicken 各有一个 enabled，必须同时开， 半开状态（Feeder 在请求神经帧但没人渲染）是真实且难查的故障模式。所以 read/write 一律成对处理，且：

  • 任一 cfg 缺失 → 不算「开」（不把「没装」显示成「已开」）；
  • 未安装时 write 直接拒绝，不创建空 cfg 文件；
  • 值没变就不写盘（FlatCfg.set 返回 false），避免无谓重写 666 行、与 add-on 自己的写回打架；
  • 返回的是写完之后磁盘上的真实状态，不是调用方要求的状态。

4. ★ 实测抓到的真 bug：FlatCfg.save() 会把别的程序的文件整份改成 LF

真实环境的行尾实测：

文件 CRLF 裸 LF 字节
dlss5-feed.cfg 23 0 353
deep-fried-chicken.cfg 666 0 19790
ReShade.ini 95 0 2982
ReShadePreset.ini 109 0 2452

而 FlatCfg.save() 固定 String.join("\n", …) —— 一按开关就会把 DFC 那份 666 行的 CRLF 文件连行尾一起重写。 FlatCfg 原本的注释还把「用 LF 保持 diff 友好」当成优点，恰恰搞反了：这两个文件属于别的程序。

修法：load() 读原始字节并探测主导行尾，save() 用读进来的那个行尾；新建文件才回退 System.lineSeparator()。 顺带补了 decodeLines()，语义对齐 Files.readAllLines（末尾终止符不产生空行、中间空行保留）。

IniFile.save() 本来就固定写 CRLF，与真实文件一致，未改动（避免无谓churn）。

5. 验证

MasterSwitch 只碰文件系统、不依赖 MC 与 GL，所以能真跑：E:\deepseek\_tmp\tlstest\MasterSwitchTest.java， 35 项全过：

  • 未安装：不创建文件、write 被拒且给出原因；
  • 半安装（只有 feeder cfg）：switchable=false、on=false；
  • CRLF 场景（照抄真实安装）：605 行 CRLF 文件翻转后 CRLF=605 / 裸 LF=0，且 「恰好一行变化，其余逐字保留」—— 首键、末键、注释行、空行全部原样；
  • LF 场景：LF 进 LF 出，确认修法没有把 CRLF 写死；
  • 冗余写是真空操作（mtime 与字节都不变）；
  • 真值判定：0/1/true/TRUE/enabled = 1（等号两侧空格）。

对真实安装目录只读探测：on=true switchable=true feedPresent=true chickPresent=true。

6. 静态验证清单（每条都对着实际编译好的 jar 查过）

依赖 依据
Screens.getButtons(Screen) → List<AbstractWidget> javap fabric-screen-api-v1-2.0.9
ButtonList.add 同时进三个列表 抽 ButtonList.java 源码
ScreenEvents.AFTER_INIT 回调签名 (client, screen, w, h) 抽 ScreenMixin.java 源码
Button.Builder.tooltip(Tooltip) / Tooltip.create(Component) javap minecraft-merged 1.20.1
OptionsList 只有 addBig/addSmall(OptionInstance…) javap —— 所以塞自定义控件行要 2–3 个 mixin accessor，不划算，放弃
已装 fabric-api-0.92.11 内含 fabric-screen-api-v1 列出 jar 内嵌 META-INF/jars/fabric-screen-api-v1-0.92.11.jar

7. 待用户确认

必须重启游戏（ReShade 是 opengl32.dll 代理，本次启动时早已解析完毕，模组无法在进程内激活它）。 重启后进 设置 → 选项 → 视频设置，应看到：

  • 右侧 DLSS · 已安装（若显示未安装/需修复，说明 H:\javahome\bin 的载荷状态变了）；
  • 左侧 DLSS: 开（只有两个 cfg 都在时才出现）。

点左侧应能即时切换（两个 cfg 都带 CRLF 保留、只有 enabled= 一行变化），点右侧进面板。

8. 顺手发现（与本模组无关）

mods 目录里有两个 MouseTweaks（2.25 与 2.26）同时存在，是重复 mod；另外 gpu-optimizer-0.1.0.jar.disabled 已被改名为 .disabled 所以不会加载。

2026-09-17 19:40 — 【重大】1.21.1 + VulkanMod 的 Vulkan 通路打通

结论先行：能。 DLSS5-Feeder 有一等公民的 Vulkan 传输层，不需要 OpenGL，也不是"勉强识别"。 这一轮把整条链路在不启动 Minecraft 的前提下验证到了 API 层。

8.1 起因：为什么之前认为不可能，以及为什么那是错的

1.21.1 实例的 mods 里有 VulkanMod 0.6.7（== VulkanMod == / Backend library: LWJGL 3.3.3， 日志里没有 OpenGL Version 行），而当时 ReShade 是按 OpenGL 装的（H:\javahome\bin\opengl32.dll 代理）。

19:15 那次启动的实测证据（说明 GL 装法在 Vulkan 游戏上确实拿不到帧）：

事实 出处
ReShade 初始化了，但只挂到 wglSetPixelFormat（GLFW 的临时 GL 上下文） ReShade.log 19:15:21
两个 add-on 注册后 6 毫秒就被卸载（.358 注册 → .364/.365 Unloading） 同上
feeder/chicken 日志只有启动行，零帧 dlss5-feed.log

但那只是"装法不对"，不是"做不到"。 feeder 的二进制里带完整的 Vulkan 实现：

"Feeds DLSS 5 neural rendering ... in D3D11, D3D12, Vulkan and OpenGL games without DLSS"

8.2 feeder 的 Vulkan 机制（源码级）

jlrouzies-fr/DLSS5-Feeder 是开源的，docs/ 与 layer/ 都在。README §The Vulkan path：

  • DLSS 5 add-on 只 hook D3D12 NGX 入口，所以即使 NGX 有 Vulkan API 也没用；
  • 因此 evaluate 跑在私有 D3D12 设备上，帧通过共享内存跨 API 边界（不是拷到内存再回来）；
  • D3D12 侧建 D3D12_HEAP_FLAG_SHARED 纹理 + 两个 D3D12_FENCE_FLAG_SHARED 栅栏并导出 NT handle；
  • add-on 用裸 Vulkan 把它们导入游戏自己的 VkDevice （VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT 等）—— D3D12 栅栏和 Vulkan timeline semaphore 是同一个对象；
  • 互操作扩展在 vkCreateDevice 时就固定了，而游戏很少主动要 → add-on 在 vulkan-1.dll 的 vkCreateDevice 上打 MinHook 把扩展追加进去（src/feed_vk_hook.h）。

8.3 ★ 两个必须知道的坑（都是实测定位的，不是猜的）

坑 1：ReShade64.dll 加载失败 error 1114 —— 根因是 <exe目录>\ReShade.ini 必须存在

现象：loader 报 Failed to open dynamic library "C:\ProgramData\ReShade\.\ReShade64.dll" with error 1114。

定位过程（每一步都排除了一个假设）：

实验 结果 排除了什么
DONT_RESOLVE_DLL_REFERENCES 加载 成功，vkNegotiateLoaderLayerInterfaceVersion 是导出符号 导出表缺失
同字节改名 ReShade64.dll 放同一目录 1114 目录/DLL 损坏
把它加进 ReShadeApps.ini 白名单 仍 1114 白名单（至少不是这么用的）
补 ReShade32.dll / ReShade32.json 兄弟文件 仍 1114 32 位兄弟
同字节命名为 opengl32.dll 成功 → 决定因素是模块名

然后读 crosire/[email protected] 的 source/dll_main.cpp：

const bool is_opengl = _wcsicmp(module_name.c_str(), L"opengl32") == 0;
...
const bool default_base_to_target_executable_path =
    !is_d3d && !is_dxgi && !is_opengl && !is_dinput && !is_asi && !is_uwp_app();
...
// "This e.g. prevents loading the implicit Vulkan layer when not explicitly enabled for an application"
if (default_base_to_target_executable_path && !GetEnvironmentVariableW(L"RESHADE_DISABLE_LOADING_CHECK", ...))
    if (!std::filesystem::exists(config.path(), ec))
        return FALSE;   // ← 1114 的来源

而 ini_file.cpp：

reshade::ini_file &reshade::global_config() {
    return ini_file::load_cache(g_reshade_base_path / L"ReShade.ini");
}

所以那道门就是 <基路径>\ReShade.ini 是否存在；opengl32.dll 这种代理名直接跳过该检查， ReShade64.dll 这种 layer 名则必须过。vulkaninfo.exe 在 System32、那里没有 ReShade.ini → 必然 1114。 （注意：ReShadeApps.ini 在 ReShade DLL 源码里根本不存在，它是 setup 工具的概念。）

坑 2：GL 代理与 Vulkan layer 不能共存于同一进程

dll_main.cpp L200-211：

for (DWORD i = 1; i < ...; ++i)
    if (modules[i] != hModule && GetProcAddress(modules[i], "ReShadeVersion") != nullptr) {
        // "Another ReShade instance was already loaded from '%s'! Aborting initialization ..."
        return FALSE;
    }

ReShadeVersion 是 extern "C" __declspec(dllexport) const char *ReShadeVersion，我们的 opengl32.dll 确实导出它。隔离实验（用 RESHADE_DISABLE_LOADING_CHECK=1 绕过坑 1 以触及坑 2）：

场景 结果
单独加载 layer 的 ReShade64.dll 成功
先加载 GL 代理 opengl32.dll，再加载 layer 1114 —— 被挡

而 GLFW 初始化时必然加载 exe 目录里的 opengl32.dll（wglGetProcAddress），且它常驻不卸载。 所以只要 opengl32.dll 还在 JVM 目录里，Vulkan layer 永远起不来 —— 这解释了为什么 "共用 H:\javahome"这条路走不通。

8.4 解法：给 1.21.1 一个干净的 JVM 目录，配置用绝对 BasePath 共享

H:\javahome 原样不动（1.20.1 的 OpenGL 那套继续用），新建：

H:\javahome-vulkan\                 ← 从 C:\Program Files\Microsoft\jdk-21.0.9.10-hotspot 复制的干净 JDK
                                        (327 MB / 486 文件；bin 里没有 opengl32.dll)
  bin\ReShade.ini                   ← 唯一需要的文件，两行：
                                        [INSTALL]
                                        BasePath=H:\javahome\bin
  conf\ include\ jmods\ legal\ lib\ release    ← 原样复制

get_base_path() 会先读 <exe目录>\ReShade.ini 的 [INSTALL] BasePath（绝对路径直接用）， 于是这个实例的全部配置、预设、shader、add-on、NGX 运行时都取自 H:\javahome\bin，一份都没复制。

机器级 Vulkan layer 目录

C:\ProgramData\ReShade\
  ReShade64.dll   5,592,064 B  ← 与 H:\javahome\bin\opengl32.dll **字节完全相同**
                                  （都是 ReShade 6.8.0.2155 add-on 构建，双方 SHA 一致）
  ReShade64.json  526 B        ← crosire 官方 layer 清单（name=VK_LAYER_reshade）
  ReShade32.dll / ReShade32.json
  ReShadeApps.ini              ← Apps=<java 路径列表>，UTF-8+BOM

注册：HKCU\SOFTWARE\Khronos\Vulkan\ImplicitLayers（名称=json 路径，DWORD 0）。 故意不用 HKLM —— 本会话是 Medium 完整性、写 HKLM 被拒；而本机 OBS 的 obs-vulkan64.json 就在 HKCU，证明这条在 loader 1.4.341 上确实会加载。

8.5 验证结果（不依赖 Minecraft）

把 vulkaninfo.exe 临时复制进 H:\javahome-vulkan\bin\ 再跑（跑完删除）：

[Vulkan Loader] DEBUG | LAYER:  Loading layer library C:\ProgramData\ReShade\.\ReShade64.dll
[Vulkan Loader] INFO  | LAYER:   Insert instance layer "VK_LAYER_reshade"
[Vulkan Loader] INFO  | LAYER:   Inserted device layer "VK_LAYER_reshade"

ReShade.log:
  Initializing ReShade 6.8.0.2155 loaded from 'C:\ProgramData\ReShade\ReShade64.dll'
      into 'H:\javahome-vulkan\bin\vulkaninfo.exe' ...
  Redirecting vkCreateInstance(...)
  Searching for add-ons (*.addon, *.addon64) in 'H:\javahome\bin' ...
  Registered add-on "Deep Fried Chicken 2.0.0"
  Registered add-on "DLSS 5 Feed 1.16.0-beta.4"

dlss5-feed.log:
  [feed] vkCreateDevice hook installed on vulkan-1!vkCreateDevice
  [feed] vkQueuePresentKHR hook installed
  [feed] vkCreateDevice #1/#2: app asked for 0 extension(s), added 7, timelineSemaphore enabled
  [feed]   VK_KHR_external_memory / _win32 / external_semaphore / _win32 /
  [feed]   dedicated_allocation / get_memory_requirements2 / timeline_semaphore   ← 全部 ADDED
  [feed] Vulkan present dependency hook installed at device dispatch
  [feed] vkCreateDevice -> 0

唯一没验证的只剩"真实 swapchain 每帧投递"（vulkaninfo 不呈现画面），那需要真正启动游戏。

8.6 顺带升级与产物

  • feeder beta.2 → beta.4（dlss5-feed.addon64 SHA 从 0994FC75… 变 875B6BAA…； DLSS5_Feed.fx 两份一致）。beta.4 zip 的 SHA-256 与官方 release 页公布值 D16F8B527F76FF1F531682A576D699CB5634838C0E2899585E3671814EDA2745 完全一致。
  • 兜底 layer 放到 H:\javahome\bin\layer-x64\（VkLayer_feed_vk.dll/json + run-with-feed-layer.bat）， 仅当 vkCreateDevice hook 装不上时才需要，当前未启用。
  • H:\javahome\bin\ReShade.ini 的 [ADDON] 补了 AddonPath=H:\javahome\bin（原来是空段）。
  • 官方离线产物存到 tools\feeder\（4.8 MB）：beta.4 zip、Install-DLSS5Feeder.ps1、 Verify-DLSS5Feeder.ps1、ReShade_Setup_6.8.0_Addon.exe、两份 layer json、README。

8.7 待用户执行

PCL2 里把 1.21.1 实例的 Java 单独指到 H:\javahome-vulkan（版本设置 → 设置 → Java 选择）， 不要改全局（全局若变，1.20.1 也会离开带 opengl32.dll 的目录，那条已跑通的路会断）。

启动后看三处：ReShade.log 是否出现 loaded from 'C:\ProgramData\ReShade\ReShade64.dll'、 dlss5-feed.log 是否有 frame N delivered (…, Vulkan transport, 1 submit)、 deep-fried-chicken.log 是否有 feeder_marker= / interop_state=。官方校验脚本： powershell -File tools\feeder\Verify-DLSS5Feeder.ps1 -GamePath H:\javahome-vulkan\bin。

Reference in New Issue View Git Blame Copy Permalink