离线渲染器着色语言 DSL 设计：从语法解析到 Closure 树的工程路径

为离线渲染器设计一套领域特定语言（DSL）并非简单的语法糖包装，而是需要在编译期与运行时之间找到精确的边界。与 GPU 着色语言追求批量并行执行不同，CPU 离线渲染器的着色代码执行模式更接近传统的函数调用：每个光线命中点触发一次独立的着色计算，没有 Warp 或 Wavefront 级别的同步，也不存在绘制调用（Draw Call）级别的批量设置。这种根本差异决定了离线渲染 DSL 的设计必须围绕「延迟执行」与「树形组合」展开，而非直接输出像素颜色。

编译管线分层：Flex/Bison/LLVM 的工程组合

从零实现一套着色语言的完整编译链是一项庞大的工程，但借助成熟的编译器基础设施，个人开发者也能在数月内完成可用原型。Tiny Shading Language（TSL）采用了经典的三层架构：

• Flex 负责词法分析，将字符流切分为 Token 序列
• Bison 完成语法分析，基于 Token 构建抽象语法树（AST）
• LLVM 承担代码生成与优化，将 AST 转换为 LLVM IR，最终 JIT 编译为机器码

这种分层策略的价值在于职责隔离。Flex 与 Bison 的配置文件定义了语言的词法与语法规则，而 LLVM 则屏蔽了目标架构（x86/ARM）的差异。对于需要支持 Apple Silicon 的渲染器而言，这种架构避免了在依赖链中处理 x86 特定代码的麻烦。LLVM 的优化 passes 也能在 JIT 阶段自动完成常量折叠、死代码消除等常规优化，无需在 DSL 前端重复实现。

核心抽象：Closure 树与延迟执行模型

离线渲染 DSL 与 GPU 着色语言最本质的区别在于输出语义。GPU 着色器通常直接输出颜色值或 G-Buffer 属性，而离线渲染器需要更复杂的材质描述 ——BSDF（双向散射分布函数）可能由多个 BXDF 线性组合而成，且某些 BRDF 甚至以其他 BSDF 作为输入参数，形成树状结构。

TSL 采用 Closure 概念解决这一问题。Closure 是一种延迟执行的原语，它携带类型标识与构造参数，但真正的求值（BSDF 评估、重要性采样）推迟到渲染器端的 C++ 代码中完成。着色器代码只需构建 Closure 树，将其作为输出传递给渲染器：

// Closure 支持两种操作：
// 1. Closure + Closure（BSDF 线性组合）
// 2. Closure * color（BSDF 加权）
o0 = make_closure<lambert>(basecolor, normal);

这种设计的关键优势在于解耦。复杂的 BXDF 实现（如 Disney BRDF、多层涂层材质）可以保留在渲染器的 C++ 代码库中，利用 STL 与成熟的数值计算库实现；着色语言只需关注参数计算与 Closure 组合，无需在 DSL 层面重新实现微表面模型或重要性采样算法。Closure 树作为中间表示（IR），既保留了材质图的完整语义，又允许渲染器灵活解析为内部的 BSDF 数据结构。

Shader 组合系统：Unit Template 与 Group Template 的嵌套

离线渲染器的材质系统通常以节点图（Node Graph）形式呈现给美术人员。TSL 通过两级抽象实现这一需求：

Shader Unit Template 是基本编译单元，对应材质图中的一个节点。每个 Unit 独立编译，定义输入 / 输出接口，输出可以是 Closure、颜色、浮点数等。例如，一个 Lambert 漫反射节点可定义为：

shader make_closure_lambert(
    in color basecolor,
    in vector normal,
    out closure o0
) {
    o0 = make_closure<lambert>(basecolor, normal);
}

Shader Group Template 负责将多个 Unit 连接成完整的材质图。它不直接包含着色代码，而是描述 Unit 之间的数据流连接、参数默认值暴露以及最终输出。这种设计使得同一类型的节点（如纹理采样器）只需编译一次，不同的材质实例通过 Group Template 的配置差异复用已编译的 Unit。

TSL 的一个关键改进在于 Shader Group Template 本身可作为 Shader Unit Template 被嵌套。这打破了传统树状结构的限制，形成多维树 —— 每个节点可以是一个子图。这一特性直接支持了「节点组」（Node Group）功能：美术人员可以将常用的节点组合打包为可复用的子材质，在多个材质间共享，修改子材质会自动传播到所有引用处。

工程实现要点与可落地参数

基于 TSL 的设计实践，为离线渲染器 DSL 的实现提供以下可落地的工程参数：

编译时配置

• 词法规则文件（Flex）：定义关键字、类型（color/vector/closure）、全局纹理句柄语法
• 语法规则文件（Bison）：声明 shader 入口、输入 / 输出参数列表、make_closure 模板语法
• 全局常量布局：通过宏在头文件与着色代码间同步定义（如 UV 坐标、世界空间位置）

Closure 类型注册

• 每个 Closure 类型需声明参数结构体（类型 + 名称），通过宏在 C++ 头文件与实现文件中同步定义
• 注册时机：渲染器初始化阶段调用 RegisterClosure()，建立类型 ID 映射
• 支持递归 Closure：允许 Closure 作为其他 Closure 的输入参数（如涂层材质接收底层 BSDF）

运行时执行流程

1. 填充 TslGlobal 结构体（UV、位置、法线等逐像素数据）
2. 获取 Shader Instance 的 JIT 函数指针
3. 调用函数，接收返回的 Closure Tree 根节点
4. 遍历 Closure Tree，根据类型 ID 分发到渲染器的 BSDF 构造逻辑

线程安全

• Shader Instance 设计为线程安全，可在多线程渲染中并发执行
• 每个线程独立维护执行上下文，避免共享状态竞争

局限与权衡

TSL 的实现也暴露出一些工程权衡。由于采用单次执行模式（而非 OSL 规划的 SIMD 批量执行），着色计算无法充分利用 CPU 的向量指令集。此外，作为个人项目，TSL 在错误诊断与语言健壮性方面仍有提升空间 —— 无效着色代码可能导致崩溃而非友好的编译错误。

但正是这些权衡体现了 DSL 设计的核心原则：优先满足领域特定需求（Closure 延迟执行、材质图嵌套），而非追求通用语言的完备性。对于需要深度定制渲染管线的团队而言，一套轻量、可控的自有 DSL 往往比集成重量级外部方案更具长期价值。

资料来源

• Making a Shading Language for my Offline Renderer，Jiayin Cao，2021

compilers