拓冰网站定制 
Magpie HDR 兼容架构全解析FP16 规范表面如何串起 DLSS、FSR 与所有效果协议适配器【免费下载链接】MagpieUnofficial experimental Magpie fork with colour-only DLSS, FSR2 and NVIDIA RTX Video integrations项目地址: https://gitcode.com/gh_mirrors/magpie27/Magpie一文看懂 Magpie 的 HDR 兼容链路从捕获到呈现的 6 个适配档位Magpie 是一款 Windows 窗口图像缩放与效果处理工具这个实验分支在此基础上加入了色彩保真的 HDR 兼容架构捕获后的画面会先解码、归一化到统一的 FP16 规范表面再为每个效果DLSS、FSR2、XeSS、RTX Video 等挑选它真正能接受的协议适配器最后经呈现兼容编码送显。关闭总开关时整条 HDR 链路完全旁路原有 SDR 行为一字不变。1. 为什么需要一个HDR 兼容总开关对普通用户来说HDR 兼容只体现为设置页里一个开关。它对应的配置键是{ enableHdrCompatibility: false }这个开关被持久化在配置文件里运行时映射为ScalingFlags::EnableHdrCompatibility位标志并通过IsHdrCompatibilityEnabled()访问见 ScalingOptions.cpp。它控制的是从捕获到呈现的全局 HDR 路径而不是某个捕获方式、也不是某个效果的选择器状态行为Off默认捕获输出直接进入原有 SDR 效果与呈现链HDR 前置处理器与边界适配器全部旁路On捕获后的第一级即解码源色彩表示、归一化曝光产出规范 HDR 工作面每个效果走各自的协议适配器这种总开关 每效果独立协议选择器的三层设计是理解整个架构的钥匙全局开关决定 HDR 链路是否激活规范工作面所有效果之间统一用同一种格式交接效果级协议选择器只有当某个效果被验证存在多条可用路径时才暴露给用户选择。2. 完整链路总览一条画面的一生整个 HDR 兼容链路是一条严格的单向流水线HDR 捕获 → 解码 曝光归一化HdrCaptureProcessor → 规范 HDR 工作面RGBA16F HdrFrame → 效果协议适配器入口转换 → 既有效果后端HLSL / 原生 SDK → 效果协议适配器出口转换 → 规范 HDR 工作面 → 呈现兼容编码 → 屏幕每个效果边界都保持同一种三明治形状规范 RGBA16F HdrFrame → 适配器输入转换 → 后端私有纹理 → 效果执行 → 后端私有纹理 → 适配器输出转换 → 规范 RGBA16F HdrFrame后端只看它协议允许的纹理流水线只看规范交接面。纹理分配、格式转换、色彩转换、alpha 策略、元数据维护全部被隔离在适配器里效果本身一行都不用改。3. FP16 规范表面格式只谈精度语义靠元数据规范交接格式是DXGI_FORMAT_R16G16B16A16_FLOAT。关键设计是FP16 只定义存储精度不定义色彩含义。因此每一帧 HDR 画面都随身携带一份完整的色彩描述纹理FP16 线性 RGB保留源主色域色彩描述ColorDescription主色域、传递函数PQ/HLG/scRGB/sRGB、色彩范围、参考白scRGB 约定 1.0 80 nit、显示峰值亮度、场景/显示参照、曝光状态、HDR 元数据MaxCLL/MaxFALL 等。这套定义在 HdrFrame.h 中核心是三个结构结构职责ColorDescription这一帧的色彩语义主色域、传递函数、范围、亮度参考HdrFrameMetadata帧身份帧号、捕获序列、源格式、当前所处流水线阶段HdrFrameStageHdrFrame纹理 元数据的载体规范格式固定为R16G16B16A16_FLOATHdrFrameStage枚举把每一帧在流水线中的位置显式化RawCapture → CanonicalInput → EffectLocalInput/Output → CanonicalOutput → PublishedOutput → PresentedOutput任何模块拿到一张纹理都能立刻知道它处于哪一段。这就是不能仅凭R10G10B10A2_UNORM判断它是 HDR10这类规则能落地的原因——格式只是容器元数据才是契约。4. 捕获边界HdrCaptureProcessor 把任何来源统一成 FP16无论用户选择哪种捕获方式Graphics Capture、桌面复制、GDI、DWM 共享表面HDR 处理都从纹理产出之后才开始。捕获方式的选择逻辑完全不动HdrCaptureProcessor作为可复用的钩子插在每个帧源之后HdrCaptureProcessor.h选定的捕获方式 → 捕获纹理 源格式 源色彩元数据 → HDR 解码 / 传递函数处理 / 曝光归一化 → 规范 RGBA16F HdrFrame几个值得注意的规则Graphics CaptureHDR 模式下直接请求R16G16B16A16_FLOAT帧池返回面按线性 scRGB 解释其他捕获方式保留既有 8 位 BGRA 表面解释为推断的 sRGB 显示参照值——此时处理器会显式记录这是一次推断假设LastAssumption()并写入诊断日志而不是悄悄当作精确元数据R10G10B10A2_UNORM本身不构成 HDR 声明是否 HDR10/PQ 由关联的色彩空间契约决定尺寸变化时调用ResetForResize()重建可复用纹理避免每帧分配。这个边界的作用一句话概括在任何效果执行之前就杜绝HDR 码值被当 SDR 采样、高光提前截断的事故。5. 六种适配器档案给每个效果选最小损失的已验证协议适配器的调度由HdrAdapterDispatcher完成HdrAdapterDispatcher.h。它根据结构化的协议路由而非效果名字符串比较产出一份HdrAdapterPlan描述这次跨界需要做什么转换、走哪条路径、是否需要 SDR 映射或归一化、是否回退及回退原因。共六种适配器档案5.1 DirectFP16 —— 直通浮点上游 API 或已验证参考路径能直接接受线性浮点 HDR 资源时使用RGBA16F 规范帧 → 按需主色域/传递转换 → FP16 能力后端 → 按需输出转换 → RGBA16F 规范帧此路径中没有 SDR 色调映射也没有 U8 量化。典型成员DLSS SR、FSR2/3/4、NIS、XeSS SRCAS 有一条参考 FP16 路径但需本地验证后才转正。5.2 BoundedHDR —— 有界域编解码后端只接受有界数值域或需要显示相关的 HDR 表示时使用。核心是一对可逆的编码 E() 与解码 E⁻¹()RGBA16F 规范帧 → 有界域编码 E() → 后端 → 反解 E⁻¹() → RGBA16F 规范帧编码中携带曲线标识、参考白、归一化尺度、峰值/余量等参数不允许对所有效果硬编码一个尺度。DLSSNR 就是基于本地实验采用这一档HDR → 有界 HDR 归一化 → DLSSNR → 反向归一化 → HDR归一化参数只有经过验证的离散取值见 GroupBEffectProtocol.h它保证模型输入落在其有界域内同时保留测试中的 HDR 亮度关系——但这不意味着 DLSSNR 存在官方发布过原生 HDR 纹理契约。5.3 SDRCompatible —— SDR 兼容桥接后端文档接口是 SDR、UNORM 或仅 U8 时使用属于兼容性取向RGBA16F → 主色域转换(如需) → HDR→SDR 外观映射 → SDR 传递编码 → 量化到后端格式 → 后端 → 反量化/SDR 解码 → SDR→HDR 重建策略 → RGBA16F色调映射不是数学无损的重建是近似。适配器把色彩变换、色调映射函数、量化器、重建策略绑成一个具名协议整体交付。对 U8 RGBA/BGRA 后端通道编码遵循u8 round(saturate(sdrEncoded) × 255)。RTX Video VSR / DenoiserBGRA/RGBA U8 交错缓冲与 NVIDIA Optical Flow 都走这一档。5.4 ConditionalFP16 / Unknown / PresentationTerminalConditionalFP16路径存在但条件未满足如 CAS 当前生产 CSO 由 R8 契约编译FP16 变体需另行编译先挂在条件档Unknown证据不足以建立映射时HDR 模式只会在本地测试后选适配器目录保留证据缺口允许后续实验刻意提升该条目PresentationTerminal帧生成类效果的终态分支见第 7 节。6. 协议路由结构化数据而非效果名判断每条协议路由HdrFormatRoute记录一条完整的跨界方式effectId / optionId / inputFormat / outputFormat / inputTransfer / outputTransfer / inputRange / outputRange / alphaMode / evidenceLevel / hdrNative / adapterProfile / defaultForHdr / defaultForSdr / normalizationScale其中hdrNative的含义值得强调它表示该表示法直接承载效果的 HDR 输入语义而不是后端接受过浮点格式。一条 FP16 选项可以是 HDR-native一条 R10 选项可以是 HDR10/PQ 有界路径一条 R8 选项通常必须配 SDR 兼容适配器。路由选择由 HdrProtocol.h 中的SelectDefaultHdrRoute()/SelectDefaultSdrRoute()完成HDR 模式的默认优先级是已验证的 HDR-native FP16已验证的 HDR-native R10/HDR10已验证的有界浮点SDR 兼容 R8 回退SDR 模式下则完全沿用既有默认与既有路径。每个效果族的路由集中声明例如 Group AAnime4K、CAS、CRT、CuNNy、MLAA 等在 GroupAHdrRoutes.cpp 中为每个效果声明路由与证据文本DLSS/FSR/NIS/光流族则在 GroupBEffectProtocol.h 中各自声明协议结构。7. 呈现终态效果XeSS FG 的 HDR10 终局路径帧生成类效果通常绑定到后备缓冲与交换链资源它不是返回下一张纹理而是结束一条渲染分支因此被建模为终态规范 RGBA16F HdrFrame → 呈现专用编码器 → 帧生成后端 → 代理交换链/呈现器XeSS FG 的契约最为清晰也是全链路中唯一没有 FP16 选择器的效果RGBA16F 规范 HDR → PQ / BT.2100 编码 → R10G10B10A2_UNORM → XeSS FG → 代理交换链呈现它要求 HDR10/BT.2100 且明确不接受 FP16 HDR 或 scRGB后备缓冲、无 HUD 纹理、UI 纹理三方必须在格式、尺寸、色彩空间上一致。渲染器会阻止在呈现终态后端之后调度普通后处理效果除非存在已验证的再捕获路径。编码器由 HdrSurfaceAdapter.h 的ConvertCanonicalToHdr10()/ConvertHdr10ToCanonical()提供规范 FP16 表面本身保持不变。8. 资源与性能模型池化、乒乓与显式 alphaHDR 路径的资源分配来自声明的表面契约而非全局 R8 假设每个活动渲染尺寸维护一个规范 FP16 纹理池依赖允许时复用乒乓ping-pong规范表面协议专用的暂存纹理只在需要它的那个效果周围分配适配器管线按源契约、目的契约、尺寸、着色器参数缓存适配器边界保持 SRV/UAV/RTV 状态转换让原生效果的资源状态预期不受影响alpha 语义显式化丢弃 alpha 的效果在返回规范链前写入约定值通常 1.0HDR 元数据与纹理元数据分离维护——一次复制或共享句柄本身不保存色彩语义。性能策略一句话FP16 留在效果边界上每个后端用其接受的、损失最小的已验证内部格式真正的成本大头是神经滤波与帧生成本身但适配器分配与转换每帧发生必须池化融合。9. 证据等级与诊断为什么能编译不等于支持 HDR架构中最克制的一条原则是不能因为一个着色器恰好能用浮点纹理编译就宣称它支持 HDR。每个路由都带证据等级HdrEvidenceLevel公开 API 契约、参考实现、社区实验、本地验证四者严格分档无证据的路由走结构化 SDR 兼容回退并发出诊断状态。公开协议的逐效果调研记录在 HDR_PROTOCOL_EVIDENCE.md含机器可读版 HDR_PROTOCOL_EVIDENCE.json其中每个效果族最多 10 轮检索、字段未说明一律记无信息。结构化诊断日志则覆盖HDR 开关状态、捕获方式、源格式与源色彩描述、规范格式、所选适配器档案、所选路由 ID、转换路径、回退原因——同时明确禁止每像素 CPU 回读避免诊断拖垮生产渲染。10. 各效果档案速查与验证清单按当前路由声明主要效果的档案归属如下效果适配器档案说明DLSS SR / FSR2 / FSR3 / FSR4 / NIS / XeSS SRDirectFP16官方文档确认线性浮点 HDR 输入DLSSNRBoundedHDR本地实验验证的有界归一化路径CASConditionalFP16 R8 回退生产 CSO 按 R8 契约编译FP16 待独立变体RTX Video VSR / DenoiserSDRCompatible官方文档锁定 BGRA/RGBA U8FSR1 / xBRZ / NVIDIA Optical Flow / SMAASDRCompatible文档接口为 SDR / U8XeSS FGPresentationTerminal仅 HDR10 R10 终局路径无 FP16 选择器Anime4K / CuNNy / MLAA 等 Group ASDR 回退 证据待补公开契约未枚举保留证据缺口回归验证遵循固定矩阵见 HDR_COMPATIBILITY_ARCHITECTURE.mdHDR 关闭SDR 管线与以往完全一致HDR 开启且无效果捕获与呈现正确每次只开一个效果契约与视觉双重验证暗部细节、饱和红、UI 白、镜面高光、低光渐变;混合链非终态效果之间必须走规范 FP16 交接终态帧生成呈现交接后不允许出现非法后处理效果。结语一套让异构协议和平共处的边界工程Magpie 的 HDR 兼容架构没有追求把所有东西都变成 FP16而是做了一件更务实的事用一张规范表面 一份元数据 六种具名适配器档案把 25 个协议互不相同的效果关进同一条可预测的流水线。新手只需记住三件事一个总开关默认关、关掉零影响、一张 FP16 规范表面格式只谈精度、语义靠元数据、一套按证据等级选路的适配器最小损失、绝不硬编码。想继续深挖建议从架构基线 HDR_COMPATIBILITY_ARCHITECTURE.md、机械实现要求 HDR_MECHANICAL_IMPLEMENTATION_REQUIREMENTS.md 与发布说明 RELEASE_NOTES_v0.6.6-hdr-fp16compat.md 三个文档入手再对照 src/Magpie.Core/ 下的Hdr*源码逐层阅读。【免费下载链接】MagpieUnofficial experimental Magpie fork with colour-only DLSS, FSR2 and NVIDIA RTX Video integrations项目地址: https://gitcode.com/gh_mirrors/magpie27/Magpie创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Magpie HDR 兼容架构全解析：FP16 规范表面如何串起 DLSS、FSR 与所有效果协议适配器
Magpie HDR 兼容架构全解析FP16 规范表面如何串起 DLSS、FSR 与所有效果协议适配器【免费下载链接】MagpieUnofficial experimental Magpie fork with colour-only DLSS, FSR2 and NVIDIA RTX Video integrations项目地址: https://gitcode.com/gh_mirrors/magpie27/Magpie一文看懂 Magpie 的 HDR 兼容链路从捕获到呈现的 6 个适配档位Magpie 是一款 Windows 窗口图像缩放与效果处理工具这个实验分支在此基础上加入了色彩保真的 HDR 兼容架构捕获后的画面会先解码、归一化到统一的 FP16 规范表面再为每个效果DLSS、FSR2、XeSS、RTX Video 等挑选它真正能接受的协议适配器最后经呈现兼容编码送显。关闭总开关时整条 HDR 链路完全旁路原有 SDR 行为一字不变。1. 为什么需要一个HDR 兼容总开关对普通用户来说HDR 兼容只体现为设置页里一个开关。它对应的配置键是{ enableHdrCompatibility: false }这个开关被持久化在配置文件里运行时映射为ScalingFlags::EnableHdrCompatibility位标志并通过IsHdrCompatibilityEnabled()访问见 ScalingOptions.cpp。它控制的是从捕获到呈现的全局 HDR 路径而不是某个捕获方式、也不是某个效果的选择器状态行为Off默认捕获输出直接进入原有 SDR 效果与呈现链HDR 前置处理器与边界适配器全部旁路On捕获后的第一级即解码源色彩表示、归一化曝光产出规范 HDR 工作面每个效果走各自的协议适配器这种总开关 每效果独立协议选择器的三层设计是理解整个架构的钥匙全局开关决定 HDR 链路是否激活规范工作面所有效果之间统一用同一种格式交接效果级协议选择器只有当某个效果被验证存在多条可用路径时才暴露给用户选择。2. 完整链路总览一条画面的一生整个 HDR 兼容链路是一条严格的单向流水线HDR 捕获 → 解码 曝光归一化HdrCaptureProcessor → 规范 HDR 工作面RGBA16F HdrFrame → 效果协议适配器入口转换 → 既有效果后端HLSL / 原生 SDK → 效果协议适配器出口转换 → 规范 HDR 工作面 → 呈现兼容编码 → 屏幕每个效果边界都保持同一种三明治形状规范 RGBA16F HdrFrame → 适配器输入转换 → 后端私有纹理 → 效果执行 → 后端私有纹理 → 适配器输出转换 → 规范 RGBA16F HdrFrame后端只看它协议允许的纹理流水线只看规范交接面。纹理分配、格式转换、色彩转换、alpha 策略、元数据维护全部被隔离在适配器里效果本身一行都不用改。3. FP16 规范表面格式只谈精度语义靠元数据规范交接格式是DXGI_FORMAT_R16G16B16A16_FLOAT。关键设计是FP16 只定义存储精度不定义色彩含义。因此每一帧 HDR 画面都随身携带一份完整的色彩描述纹理FP16 线性 RGB保留源主色域色彩描述ColorDescription主色域、传递函数PQ/HLG/scRGB/sRGB、色彩范围、参考白scRGB 约定 1.0 80 nit、显示峰值亮度、场景/显示参照、曝光状态、HDR 元数据MaxCLL/MaxFALL 等。这套定义在 HdrFrame.h 中核心是三个结构结构职责ColorDescription这一帧的色彩语义主色域、传递函数、范围、亮度参考HdrFrameMetadata帧身份帧号、捕获序列、源格式、当前所处流水线阶段HdrFrameStageHdrFrame纹理 元数据的载体规范格式固定为R16G16B16A16_FLOATHdrFrameStage枚举把每一帧在流水线中的位置显式化RawCapture → CanonicalInput → EffectLocalInput/Output → CanonicalOutput → PublishedOutput → PresentedOutput任何模块拿到一张纹理都能立刻知道它处于哪一段。这就是不能仅凭R10G10B10A2_UNORM判断它是 HDR10这类规则能落地的原因——格式只是容器元数据才是契约。4. 捕获边界HdrCaptureProcessor 把任何来源统一成 FP16无论用户选择哪种捕获方式Graphics Capture、桌面复制、GDI、DWM 共享表面HDR 处理都从纹理产出之后才开始。捕获方式的选择逻辑完全不动HdrCaptureProcessor作为可复用的钩子插在每个帧源之后HdrCaptureProcessor.h选定的捕获方式 → 捕获纹理 源格式 源色彩元数据 → HDR 解码 / 传递函数处理 / 曝光归一化 → 规范 RGBA16F HdrFrame几个值得注意的规则Graphics CaptureHDR 模式下直接请求R16G16B16A16_FLOAT帧池返回面按线性 scRGB 解释其他捕获方式保留既有 8 位 BGRA 表面解释为推断的 sRGB 显示参照值——此时处理器会显式记录这是一次推断假设LastAssumption()并写入诊断日志而不是悄悄当作精确元数据R10G10B10A2_UNORM本身不构成 HDR 声明是否 HDR10/PQ 由关联的色彩空间契约决定尺寸变化时调用ResetForResize()重建可复用纹理避免每帧分配。这个边界的作用一句话概括在任何效果执行之前就杜绝HDR 码值被当 SDR 采样、高光提前截断的事故。5. 六种适配器档案给每个效果选最小损失的已验证协议适配器的调度由HdrAdapterDispatcher完成HdrAdapterDispatcher.h。它根据结构化的协议路由而非效果名字符串比较产出一份HdrAdapterPlan描述这次跨界需要做什么转换、走哪条路径、是否需要 SDR 映射或归一化、是否回退及回退原因。共六种适配器档案5.1 DirectFP16 —— 直通浮点上游 API 或已验证参考路径能直接接受线性浮点 HDR 资源时使用RGBA16F 规范帧 → 按需主色域/传递转换 → FP16 能力后端 → 按需输出转换 → RGBA16F 规范帧此路径中没有 SDR 色调映射也没有 U8 量化。典型成员DLSS SR、FSR2/3/4、NIS、XeSS SRCAS 有一条参考 FP16 路径但需本地验证后才转正。5.2 BoundedHDR —— 有界域编解码后端只接受有界数值域或需要显示相关的 HDR 表示时使用。核心是一对可逆的编码 E() 与解码 E⁻¹()RGBA16F 规范帧 → 有界域编码 E() → 后端 → 反解 E⁻¹() → RGBA16F 规范帧编码中携带曲线标识、参考白、归一化尺度、峰值/余量等参数不允许对所有效果硬编码一个尺度。DLSSNR 就是基于本地实验采用这一档HDR → 有界 HDR 归一化 → DLSSNR → 反向归一化 → HDR归一化参数只有经过验证的离散取值见 GroupBEffectProtocol.h它保证模型输入落在其有界域内同时保留测试中的 HDR 亮度关系——但这不意味着 DLSSNR 存在官方发布过原生 HDR 纹理契约。5.3 SDRCompatible —— SDR 兼容桥接后端文档接口是 SDR、UNORM 或仅 U8 时使用属于兼容性取向RGBA16F → 主色域转换(如需) → HDR→SDR 外观映射 → SDR 传递编码 → 量化到后端格式 → 后端 → 反量化/SDR 解码 → SDR→HDR 重建策略 → RGBA16F色调映射不是数学无损的重建是近似。适配器把色彩变换、色调映射函数、量化器、重建策略绑成一个具名协议整体交付。对 U8 RGBA/BGRA 后端通道编码遵循u8 round(saturate(sdrEncoded) × 255)。RTX Video VSR / DenoiserBGRA/RGBA U8 交错缓冲与 NVIDIA Optical Flow 都走这一档。5.4 ConditionalFP16 / Unknown / PresentationTerminalConditionalFP16路径存在但条件未满足如 CAS 当前生产 CSO 由 R8 契约编译FP16 变体需另行编译先挂在条件档Unknown证据不足以建立映射时HDR 模式只会在本地测试后选适配器目录保留证据缺口允许后续实验刻意提升该条目PresentationTerminal帧生成类效果的终态分支见第 7 节。6. 协议路由结构化数据而非效果名判断每条协议路由HdrFormatRoute记录一条完整的跨界方式effectId / optionId / inputFormat / outputFormat / inputTransfer / outputTransfer / inputRange / outputRange / alphaMode / evidenceLevel / hdrNative / adapterProfile / defaultForHdr / defaultForSdr / normalizationScale其中hdrNative的含义值得强调它表示该表示法直接承载效果的 HDR 输入语义而不是后端接受过浮点格式。一条 FP16 选项可以是 HDR-native一条 R10 选项可以是 HDR10/PQ 有界路径一条 R8 选项通常必须配 SDR 兼容适配器。路由选择由 HdrProtocol.h 中的SelectDefaultHdrRoute()/SelectDefaultSdrRoute()完成HDR 模式的默认优先级是已验证的 HDR-native FP16已验证的 HDR-native R10/HDR10已验证的有界浮点SDR 兼容 R8 回退SDR 模式下则完全沿用既有默认与既有路径。每个效果族的路由集中声明例如 Group AAnime4K、CAS、CRT、CuNNy、MLAA 等在 GroupAHdrRoutes.cpp 中为每个效果声明路由与证据文本DLSS/FSR/NIS/光流族则在 GroupBEffectProtocol.h 中各自声明协议结构。7. 呈现终态效果XeSS FG 的 HDR10 终局路径帧生成类效果通常绑定到后备缓冲与交换链资源它不是返回下一张纹理而是结束一条渲染分支因此被建模为终态规范 RGBA16F HdrFrame → 呈现专用编码器 → 帧生成后端 → 代理交换链/呈现器XeSS FG 的契约最为清晰也是全链路中唯一没有 FP16 选择器的效果RGBA16F 规范 HDR → PQ / BT.2100 编码 → R10G10B10A2_UNORM → XeSS FG → 代理交换链呈现它要求 HDR10/BT.2100 且明确不接受 FP16 HDR 或 scRGB后备缓冲、无 HUD 纹理、UI 纹理三方必须在格式、尺寸、色彩空间上一致。渲染器会阻止在呈现终态后端之后调度普通后处理效果除非存在已验证的再捕获路径。编码器由 HdrSurfaceAdapter.h 的ConvertCanonicalToHdr10()/ConvertHdr10ToCanonical()提供规范 FP16 表面本身保持不变。8. 资源与性能模型池化、乒乓与显式 alphaHDR 路径的资源分配来自声明的表面契约而非全局 R8 假设每个活动渲染尺寸维护一个规范 FP16 纹理池依赖允许时复用乒乓ping-pong规范表面协议专用的暂存纹理只在需要它的那个效果周围分配适配器管线按源契约、目的契约、尺寸、着色器参数缓存适配器边界保持 SRV/UAV/RTV 状态转换让原生效果的资源状态预期不受影响alpha 语义显式化丢弃 alpha 的效果在返回规范链前写入约定值通常 1.0HDR 元数据与纹理元数据分离维护——一次复制或共享句柄本身不保存色彩语义。性能策略一句话FP16 留在效果边界上每个后端用其接受的、损失最小的已验证内部格式真正的成本大头是神经滤波与帧生成本身但适配器分配与转换每帧发生必须池化融合。9. 证据等级与诊断为什么能编译不等于支持 HDR架构中最克制的一条原则是不能因为一个着色器恰好能用浮点纹理编译就宣称它支持 HDR。每个路由都带证据等级HdrEvidenceLevel公开 API 契约、参考实现、社区实验、本地验证四者严格分档无证据的路由走结构化 SDR 兼容回退并发出诊断状态。公开协议的逐效果调研记录在 HDR_PROTOCOL_EVIDENCE.md含机器可读版 HDR_PROTOCOL_EVIDENCE.json其中每个效果族最多 10 轮检索、字段未说明一律记无信息。结构化诊断日志则覆盖HDR 开关状态、捕获方式、源格式与源色彩描述、规范格式、所选适配器档案、所选路由 ID、转换路径、回退原因——同时明确禁止每像素 CPU 回读避免诊断拖垮生产渲染。10. 各效果档案速查与验证清单按当前路由声明主要效果的档案归属如下效果适配器档案说明DLSS SR / FSR2 / FSR3 / FSR4 / NIS / XeSS SRDirectFP16官方文档确认线性浮点 HDR 输入DLSSNRBoundedHDR本地实验验证的有界归一化路径CASConditionalFP16 R8 回退生产 CSO 按 R8 契约编译FP16 待独立变体RTX Video VSR / DenoiserSDRCompatible官方文档锁定 BGRA/RGBA U8FSR1 / xBRZ / NVIDIA Optical Flow / SMAASDRCompatible文档接口为 SDR / U8XeSS FGPresentationTerminal仅 HDR10 R10 终局路径无 FP16 选择器Anime4K / CuNNy / MLAA 等 Group ASDR 回退 证据待补公开契约未枚举保留证据缺口回归验证遵循固定矩阵见 HDR_COMPATIBILITY_ARCHITECTURE.mdHDR 关闭SDR 管线与以往完全一致HDR 开启且无效果捕获与呈现正确每次只开一个效果契约与视觉双重验证暗部细节、饱和红、UI 白、镜面高光、低光渐变;混合链非终态效果之间必须走规范 FP16 交接终态帧生成呈现交接后不允许出现非法后处理效果。结语一套让异构协议和平共处的边界工程Magpie 的 HDR 兼容架构没有追求把所有东西都变成 FP16而是做了一件更务实的事用一张规范表面 一份元数据 六种具名适配器档案把 25 个协议互不相同的效果关进同一条可预测的流水线。新手只需记住三件事一个总开关默认关、关掉零影响、一张 FP16 规范表面格式只谈精度、语义靠元数据、一套按证据等级选路的适配器最小损失、绝不硬编码。想继续深挖建议从架构基线 HDR_COMPATIBILITY_ARCHITECTURE.md、机械实现要求 HDR_MECHANICAL_IMPLEMENTATION_REQUIREMENTS.md 与发布说明 RELEASE_NOTES_v0.6.6-hdr-fp16compat.md 三个文档入手再对照 src/Magpie.Core/ 下的Hdr*源码逐层阅读。【免费下载链接】MagpieUnofficial experimental Magpie fork with colour-only DLSS, FSR2 and NVIDIA RTX Video integrations项目地址: https://gitcode.com/gh_mirrors/magpie27/Magpie创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考