为离线渲染器打造着色语言：设计思路与实现解读

背景

作为一名图形程序员，作者通常不会将过多精力投入到与计算机图形学或游戏引擎无直接关联的技术领域。然而，在去年利用业余时间，他花费了四个月时间，为其离线渲染器 SORT 构建了一套名为 Tiny Shading Language (TSL) 的着色语言。

在项目的初期，由于缺乏对编译器工作原理的普遍认知——这并非图形程序员日常接触的核心领域——作者并不确定最终成果如何。但事实证明，凭借现有的工具链，一个人完全可以在几个月内完成这一任务。

本文旨在简要阐述设计该着色语言库时的思考过程，重点在于系统架构的设计及其与离线 CPU 渲染器的集成方式，而非语言实现的底层细节。TSL 库附带了一个示例教程，其中球体表面的图案便是通过 TSL 过程化生成的。

核心内容

动机：为何不直接使用 OSL？

每当人们听说作者开发了新的着色语言时，第一个问题 invariably 是：“既然已经有 OSL (Open Shading Language)，为什么还要自己造轮子？”

在动手之前，作者自己也对此产生了长达半年的疑虑。经过深入调研，他列出了选择自研而非使用 OSL 的几个核心理由：

1. 从零学习的价值：这是最主要的原因。通过从头构建着色语言，作者可以深入理解编译器的工作原理。这种知识积累对其职业生涯具有长远价值，能使其对编程语言编译机制有更深层次的理解。
2. 代码库的灵活性：拥有自己的代码库意味着可以根据需求随意修改。相比不熟悉的 OSL 实现，自研方案提供了更高的灵活性。
3. Apple Silicon (ARM) 的兼容性挑战：
   • Apple 正从 Intel 芯片过渡到 ARM 架构。
   • 在 ARM 上构建 OSL 需要同时构建其所有依赖项。如果任何依赖项包含 x86 特定的实现，则必须在 ARM 上寻找替代方案。
   • 虽然 OSL 的路线图支持 Apple Silicon，但在文章撰写时，其可用性尚不明确。没有 OSL 的支持，渲染器无法移植到 Apple Silicon。
4. 依赖关系的复杂性：
   • OSL 重度依赖 Open Image IO (OIIO)，而 OIIO 又依赖 OpenExr、libpng、libtiff 等多个小型库。
   • 一些基本数据结构仅在 OIIO 中定义。将 OSL 与 OIIO 解耦需要大量工作。
   • 若进行本地修改以解耦，后续更新 OSL 将变得极其困难。
5. 依赖项过于“沉重”：
   • OSL 的依赖链远超预期，不仅包含多个库，且在某些平台上需要动态链接。
   • 理想情况下，应确保所有依赖项静态编译，但这比听起来复杂得多。作者不愿花费大量时间从源代码构建这些库。
   • 部分预编译库依赖于特定的 Ubuntu 版本，导致跨版本兼容性麻烦。
   • 最终，渲染器并未使用 OIIO 提供的功能，这些依赖纯粹是因为 OSL 需要它们。
6. 其他因素：作者当时是 Sony (Naughty Dog) 的员工，因此有意避免对 OSL 进行过多负面评论，尽管还有其他动机促使他自研。

作者清醒地认识到，自研实现肯定不如拥有专业团队且历经十余年发展的 OSL 稳健。但他确信，在几个月内完成基础功能是可行的，且不会偏离其图形程序员的本职太远。

利用现有工具链

从零开始构建一切是不现实的。通过调研，作者发现可以利用成熟的工具链来降低难度：

• Flex：常用的词法分析器。它将字符串流按照预定义的方式标记化（Tokenize）。
• Bison：语法分析器。它接收 Flex 生成的标记，并生成抽象语法树（AST）。
• LLVM：低层虚拟机（Low Level Virtual Machine）。这是一个复杂的基础设施，可将 LLVM IR 转换为不同目标架构（如 PC、X86 等）的机器码，并执行优化。

利用这些工具，工作流程简化为：

1. 为 Flex 编写配置文件以标记化着色语言。
2. 为 Bison 编写配置文件，使用 Flex 生成的标记生成 AST。
3. 根据 Bison 生成的 AST 生成 LLVM IR。
4. 使用 LLVM 将 IR 编译为 JIT（即时编译）机器码。

这一流程比完全自研更具可操作性，增强了作者单人完成的信心。

在光线追踪器中的定位

除了将高级语言转换为 JIT 机器码的基础语言支持外，项目的大部分工作在于设计用户友好的接口，使其完美适配离线渲染器。这部分工作量并不亚于语言转换本身。

为了说明 TSL 在系统中的位置，作者回顾了简化的路径追踪算法流程：

1. 为每个像素样本生成主光线。
2. 寻找与场景的最近交点。
3. 使用材质信息构建 BSDF（双向散射分布函数）。
4. 评估 BSDF，更新吞吐量并累加到结果中。
5. 对 BSDF 进行重要性采样，生成次级光线（如果需要）。
6. 返回步骤 2 循环。

循环在步骤 2 未找到交点时停止。

TSL 的执行发生在步骤 3，这正是着色语言发挥作用的地方。在 PBRT (Physically Based Rendering Tool) 第 3 版中，预定义的材料具有硬编码的 BSDF，且 BXDF 的参数被暴露出来。TSL 的设计旨在更灵活地处理这一环节，允许用户通过代码定义复杂的材质逻辑，而非仅依赖硬编码参数。

关键要点

• 自研动机多元化：除了学习编译器原理和获得代码控制权外，解决 Apple Silicon (ARM) 架构下的依赖兼容性问题，以及摆脱 OSL 对 Open Image IO (OIIO) 等重型且不必要的依赖链，是促使作者自研 TSL 的关键技术动因。
• 工具链的选择：项目并未从零实现编译器，而是组合使用了 Flex（词法分析）、Bison（语法分析）和 LLVM（IR 生成与 JIT 编译），极大地降低了单人开发的门槛。
• 集成重点：相比语言本身的实现，将着色语言无缝集成到离线 CPU 渲染器的管线中（特别是路径追踪的第 3 步：材质/BSDF 构建）是更具挑战性的部分。
• 现实约束：作者承认自研方案在稳健性上无法与经过十年发展的 OSL 相比，但其目标是在可接受的时间范围内（几个月）实现功能可用且易于维护的解决方案。

意义与影响

这篇文章为独立开发者和小团队提供了一条可行的技术路径：即通过组合成熟的开源工具（Flex/Bison/LLVM），在有限资源下构建定制化的着色语言。

它揭示了在图形编程领域，除了算法本身，构建工具链和解决跨平台（特别是 ARM 架构）依赖问题往往占据大量精力。对于追求极致控制力、希望避免重型依赖链（如 OSL/OIIO）或需要深度定制材质系统的开发者而言，这种“自研着色语言”的思路具有重要的参考价值。同时，它也强调了理解编译器基础原理对图形程序员职业发展的长远益处。