8.2 跨平台着色器实践

8.2 跨平台着色器实践

本节摘要：跨平台不是"会两门语言"就够了——编译链、精度差异、引擎抽象层各有各的脾气。本节从源码到 GPU 的完整旅程讲起，梳理 SPIR-V 与 DXIL 的中间层角色，整理引擎集成的现状与一份跨平台编写清单。

学习目标

读完本节，你应当能够：画出从着色器源码到 GPU 执行的编译链路；解释 SPIR-V 对 Vulkan 生态的意义；说出移动端精度差异的典型症状与对策；在引擎着色器框架里定位自己该写的部分。

从源码到 GPU：中间层的角色

着色器源码从来不会被驱动直接执行，中间隔着一层中间表示（IR）。GLSL 由编译工具（如 glslang）编译成 SPIR-V，HLSL 由 DXC 编译成 DXIL，两者都是字节码形态的中间语言。这一层设计带来三个直接好处：编译校验前移（无效代码在构建阶段就被拦下，而不是运行时黑屏）；驱动对接简化（厂商驱动只需消费标准化的字节码）；缓存与分发成为可能（字节码可离线编译、打包、热更新）。

Vulkan 把 SPIR-V 定为唯一入口——你甚至可以拿 HLSL 写完用 DXC 编译成 SPIR-V 喂给 Vulkan，"HLSL 写 Vulkan"已是成熟路线。WebGPU 走的也是同族思路：各家的着色器语言（WGSL）之外，工具链可以把 HLSL 或 GLSL 转译过去。这一趋势的工程含义很实在：着色器语言正在从"平台绑定物"变成"前端选择"——语言之争的重要性逐年下降，管线与算法的理解才是长期资产，这也正是本教程把重心放在后者上的原因。

引擎在这个体系里的角色是"统一前端"：Unity 的 ShaderLab 用类 HLSL 语法书写，由引擎为各目标平台分别编译出对应后端产物；Unreal 的 HLSL 风格源码经交叉编译支撑全平台。你写一份材质，引擎负责翻译与分发——前提是你没有踩到平台差异的暗礁，这正是下面清单存在的意义。

跨平台编写清单

一份着色器要在桌面、主机、移动端都表现一致，以下几条是反复被验证的兜底项：

**精度显式化。**桌面 GPU 对 highp 与 mediump 的区分近乎无视，移动端却是实打实的硬件差异。共享代码里给片元着色器显式声明精度档位（第 2 章的规则），不要赌默认值。症状很特征化：桌面完美、手机上 UV 抖动或光照闪烁，先查精度。

**宏隔离平台差异。**用预处理器宏把"确实不一样"的部分圈起来，其余代码共享：

#ifdef HIGH_PRECISION
    precision highp float;
#else
    precision mediump float;
#endif

#ifdef PLATFORM_MOBILE
    // 移动端砍特性：少一盏灯、小一圈阴影
    #define LIGHT_COUNT 2
#else
    #define LIGHT_COUNT 8
#endif
​

**数值行为写保守。**导数指令（fwidth 一族）在不同硬件上的精度有差异；浮点结合律在 GPU 上不成立，别指望改变加法顺序结果不变；pow 对负输入的行为依赖实现。涉及视觉一致性的关键计算，写法上规避而不是事后修补。

**离线编译与缓存。**平台数量一多，运行时编译着色器的卡顿与兼容风险都上升。把"源码到字节码"挪进构建管线，产物按平台打包——这对启动速度与崩溃率都是双赢。

**保持单一事实源。**效果逻辑只写一份（宏圈差异），严禁维护"GLSL 版"与"HLSL 版"两套平行代码。两套代码必然漂移，漂移的 bug 会以"只在 A 平台出现"的方式消耗你数倍时间。

💡 关键直觉：跨平台的本质是"把差异最小化并集中管理"。语言差异已被编译链吸收，剩下的差异（精度、特性、数值行为）用宏与规范圈起来——差异集中在一处是工程，散落各处是事故。

引擎集成：找到自己的位置

引擎用户写着色器，实际是在写"框架的一部分"。以 Unity 为例：ShaderLab 结构定义状态与子着色器，内部的 CG/HLSL 程序块才是你熟悉的着色器语言；引擎预置了变换矩阵、光照数据、贴图声明等"基础设施"，你只需要写核心逻辑——本教程的每个片元函数几乎可以原样贴进一个片段着色器。Unreal 的 Custom 节点与材质表达式是另一种封装粒度：简单效果用节点连线，复杂算法在 Custom 节点里写 HLSL。

集成的通用思路是先认清楚"引擎替你做了什么"：顶点变换多半已由引擎的顶点着色器模板完成，你写的是表面属性（反照率、法线、粗糙度）的加工；后处理与粒子系统的入口各自独立。把第 1 章的管线地图套在引擎框架上，每个可编程槽位对应到框架的哪个入口——这张对应表成型后，任何引擎的着色器文档都能按图索骥。

至于前沿支线（网格着色器、光线追踪管线、可变速率着色），它们改变的是管线拓扑而非着色语言，本章不展开——兴趣驱动的读者可以在掌握主干后，按平台文档逐个点亮，学习成本远低于从零入门。

变体的代价：隐藏的编译爆炸

跨平台工程里有一个不太显眼却常酿事故的机制：着色器变体。为不同平台、不同特性组合（有无阴影、有无雾、光源数）各编译一份着色器，运行时按需挑用——每加一个宏开关，变体数量翻倍。三份特性开关就是八种组合，十份就是一千余种：编译时间爆炸、包体膨胀、运行时首次加载卡顿，全部由此而来。

工程上的治理思路：

• 开关做减法：能用 uniform 运行时判断的（整组线程同值的分支是安全的，第 2 章的结论），就不要做成编译期宏。变体只在"代码结构本身不同"时才值得。
• 预热与缓存：加载页或启动阶段把热点变体提前编译，产物落盘复用——玩家看到的卡顿与开发者看到的编译时长都会显著下降。
• 统计真实使用：埋点记录实际用到的变体集合，砍掉从未命中的组合。大量项目的变体表里，九成组合从未被任何玩家触发。

变体管理的投入产出比随项目规模陡增：小项目随手开关无妨，中型以上就必须当成构建系统的一等公民来治理。这也是"学管线而不是学语法"的又一处回报——变体差异的根源是管线状态差异，理解了管线，变体清单自然能看懂、能裁剪。

本节要点回顾

• 中间层是枢纽：GLSL 走 SPIR-V、HLSL 走 DXIL，校验前移、驱动简化、可离线分发；
• 语言变前端：HLSL 写 Vulkan、多语言转译 WebGPU，语言绑定弱化是大势；
• 清单五条：精度显式化、宏圈差异、数值写保守、离线编译缓存、单一事实源；
• 引擎即框架：认清引擎代管的槽位，教程代码几乎可以原样落位到核心逻辑里。

语言与平台全部打通。最后一章回到工程师的日常战场：性能优化与调试。