企业官网建设流程全解析

我见过太多Vulkan学习者倒在了人生第一个三角形的后面。画出来了，截图了，开心了，然后就停在原地——因为大部分教程讲到三角形就断崖式收尾，等下一次再见Vulkan，已经是“进阶章节”里的硬件光追，跨度大得让人想直接关掉浏览器。这篇文章想聊的，就是我如何以硬件光追Vulkan版为最终目标，从第一个三角形开始，把整套教学框架反过来重构一遍：每一步基础，都不是为了“学会API”，而是为了最终那个三角形被光追照亮的那一刻。

这不是一篇单纯讲光追API用法的教程。我重构的是学习路径本身：一个三角形，不再只是验证窗口创建成功的小玩具，而是理解交换链、渲染流程、资源生命周期、着色器抽象、加速结构的起点。如果你正卡在“三角形之后不知道学什么”，或者你写完了Vulkan基础但面对VkAccelerationStructureKHR和着色器绑定表一头雾水，这篇内容会给你一条能直接照着走的路。

1. 为什么传统Vulkan教学在第一个三角形之后就断了

1.1 第一个三角形的真实复杂度：它根本不是“入门”

随便打开一份Vulkan三角形教程，你会看到一套相当吓人的对象清单：VkInstance、VkPhysicalDevice、VkDevice、VkQueue、VkSwapchainKHR、VkRenderPass、VkFramebuffer、VkPipeline、VkBuffer、VkDeviceMemory、VkDescriptorSetLayout、VkDescriptorSet、VkCommandBuffer、VkSemaphore、VkFence……这还只是创建阶段，没算上同步和队列提交。

我常跟人说，Vulkan的三角形demo，其实是把一整套图形状态机压缩进了几百行代码里。OpenGL版本的三角形只要几十行，因为上下文、资源绑定、编译链路都被驱动藏起来了；Vulkan把每一层都摊开放在你面前：窗口表面怎么和渲染设备对接，渲染流程怎么描述，命令怎么录制、怎么提交、怎么保证顺序。每个对象都有明确的所有者，每个资源都需要显式管理生命周期。

问题恰恰出在这里。很多教程把这一堆对象当成“固定模板”来教，让你照着抄一遍，三角形出来了，然后教程结束。你其实不知道交换链为什么需要三张图像，不知道vkAcquireNextImageKHR和vkQueueSubmit之间到底谁在等谁，不知道描述符集为什么不能随手改。这些不理解暂时不会让三角形消失，但会在你走向硬件光追时变成一堵墙——因为光追管线比图形管线多了加速结构、着色器绑定表、命中着色器这些完全绕不开的状态。

1.2 传统路径的断层：光追被当成“进阶的进阶”

市面上的学习路径一般长这样：图形API基础 → 三角形 → 纹理 → 模型加载 → PBR光照 → 阴影 → 高级渲染……然后，硬件光追被挂在所有内容的末尾，仿佛光追只是光栅化渲染器里的一个加分插件。

这个顺序在阅读体验上是“舒服”的，但在学习逻辑上是错误的。因为它把光追当作“需要先学完光栅化才能碰”的终点，而不是从一开始就参与设计路线图的北极星。结果是：你学了大量的延迟渲染、阴影贴图、IBL，这些知识本身很有价值，但它们在光追框架里并不能直接平移。光追的光照模型是另一套语言：光线从相机出发，穿过像素平面，和场景中的加速结构求交，命中后执行最近命中着色器，未命中就回到miss着色器。

我见过太多人拿着漂亮的光栅化体验，到了VkRayTracingPipelineCreateInfoKHR面前依然手足无措。为什么？因为他们学过的“渲染流程”概念里没有“光线发出”这一步，没有“三角形作为几何求交对象”的认知。传统教学把光追放在最后，本质上是在告诉学生：光追和光栅化是两座山，你先爬完这座，再爬那座。但很少有人告诉他们，两座山在“第一个三角形”的位置是相通的——三角形既是光栅化的输入图元，也是光追加速结构里最基本的包围盒叶子节点。

1.3 重构的核心思路：让三角形成为光追的“钥匙”

所以我的重构思路非常直接：把“硬件光追Vulkan版”当作整个教学框架的终点，往回倒推，看从第一个三角形到最小光追三角形之间，到底需要哪些知识节点。然后把这些节点重新编排成一条连续的、每一步都在为最终目标埋线的路径。

三角形不再是一次性的入门证明，而是一个可以被反复解剖的标本。你先用光栅化把它画出来，然后把它送进计算着色器做后处理，再把它构建成BLAS（底层加速结构），最后写一个raygen着色器发射光线命中它。同一个三角形，四种打开方式，每一个都对应Vulkan里一块核心能力。学生学完这套流程后，才算真正摸到了Vulkan的骨架。

这也是这篇内容适合的人：你不一定是要写商业引擎的大佬，只要你想系统搞懂Vulkan，而不是停留在“跑通demo”阶段，这套框架就能帮你省掉大量瞎逛的时间。

2. 硬件光追的完整知识栈：先看清终点再设计起点

2.1 跑通Vulkan硬件光追需要哪些“新家伙”

在Vulkan里做硬件光追，核心依赖两套扩展：VK_KHR_acceleration_structure和VK_KHR_ray_tracing_pipeline。前者负责加速结构的创建、构建、内存管理，后者负责光追管线、着色器组、着色器绑定表的配置。另外通常还需要VK_KHR_deferred_host_operations，因为加速结构构建这类重操作往往需要延迟到后台执行，靠一个线程硬扛会卡顿明显。

加速结构本身分两层：BLAS（底层加速结构）和TLAS（顶层加速结构）。BLAS描述实际几何体，比如一个三角形网格；TLAS描述这些几何体在场景中的实例层级，包含变换矩阵、实例掩码、着色器绑定索引。画一张简化图的话，BLAS是“物体的形状”，TLAS是“物体摆在哪、怎么被光线访问”。光线发射后，驱动沿着TLAS找到BLAS，在BLAS内部遍历包围盒和三角形，完成求交。

除了这两个扩展，你还需要理解一套新的着色器执行模型：raygen shader（光线生成）、miss shader（未命中）、closest-hit shader（最近命中）、any-hit shader（任意命中，常用于透明裁剪）、intersection shader（自定义求交）。这些着色器不是通过传统图形管线的VkPipelineShaderStageCreateInfo数组挂上去的，而是通过VkRayTracingShaderGroupCreateInfoKHR组织成着色器组，再用着色器绑定表（SBT）把组和具体资源绑定起来。

2.2 从经典三角形到光追的六个知识缺口

对照传统Vulkan教学和光追入门需求，我梳理出了六个最常见的知识缺口，你在重新设计教学顺序时必须补上：

1. 内存所有权：传统三角形里，顶点缓冲和索引缓冲的VkDeviceMemory分配已经让学生头疼。到了加速结构阶段，还要面对“构建时临时缓冲”“构建后设备地址”“TLAS实例缓冲”等更复杂的所有权关系。如果你在三角形阶段没把内存分配和生命周期讲透，光追阶段基本寸步难行。

2. 同步语义：光追里，加速结构构建、TLAS构建、光线查询往往跨越多个队列和命令缓冲。Vulkan的VkSemaphore、VkFence、VkPipelineStageFlagBits在光追场景里会用得更多，因为构建加速结构和提交渲染命令之间必须精确同步。

3. 资源绑定模型：光追着色器通过描述符访问加速结构、顶点缓冲、纹理、Uniform Buffer。与传统图形管线最大的不同是，它不能像VS/PS阶段那样“隐式地”从固定输入装配获取顶点位置，所有数据都必须通过描述符显式声明。

4. 着色器抽象：传统Vulkan的着色器阶段是固定的顶点/片元/几何/细分；光追则要求你把“发射光线、处理命中、处理未命中”拆成不同的shader stage。很多人在这个抽象转换上反复栽跟头。

5. 几何接口：光栅化里，三角形是渲染管线自动插值的图元；光追里，三角形是加速结构内部被求交算法遍历的图元。两者使用相同顶点缓冲，但含义完全不同——前者是“画什么”，后者是“光线和什么相交”。

6. 调试手段：光栅化三角形画歪了，你可以截图看像素；光追的raygen shader发射了一条看不见的光线，出问题时没有“画面”可看，只能靠调试器和日志。

2.3 为什么这些缺口能反向倒推教学顺序

一旦把终点定在“跑通一个最小硬件光追三角形”，你就会发现上面六个缺口的优先级完全不一样了。内存所有权和同步必须提前到三角形阶段就做实，因为它们是光追的基础设施；着色器抽象可以从计算着色器阶段就开始过渡，因为raygen和compute shader在概念上高度相似；几何接口更应该在三角形阶段就埋下“三角形是求交对象”的意识。

我并没有推翻传统教学内容，而是改变了教学顺序和侧重点。每个传统知识点在重构路径里都有一个“未来挂钩点”：交换链图像是为了让你理解帧生命周期，最终挂钩光追的多帧渲染；顶点缓冲是为了让你理解设备地址，最终挂钩BLAS构建；描述符是为了让你理解绑定模型，最终挂钩SBT。这套倒推设计，才是“从第一个三角形重构教学框架”的真正含义。

3. 重构后的教学框架：六个阶段从三角形走到光追三角形

3.1 阶段一：把第一个三角形当成“基础设施说明书”

第一阶段的目标还是画出三角形，但与普通教程不同，每创建一个对象都要回答三个问题：它属于谁？它什么时候需要被销毁？它和下一个对象之间靠什么传递依赖？

我设计课程时，会让学生把三角形demo的创建顺序画成一张表格：实例→设备→交换链→渲染流程→管线→顶点缓冲→描述符→命令缓冲→同步对象，每一步标注“这个对象在光追里会不会以不同形式再次出现”。这样做的心理效果很强烈：学生第一次发现，自己学的不是“画三角形工具包”，而是一套可扩展的资源管理协议。

实操建议是：不要直接粘贴完整代码。拆成两到三个练习——先做清屏练习只创建交换链、渲染流程、命令缓冲，把窗口显示跑通；再加顶点缓冲和管线画出三角形。如果第一遍就跑完整demo，你会把几十个对象的创建顺序背下来，但没有理解任何一个。拆开之后，每个对象的引入都有了明确理由，后面光追阶段遇到新对象时，这种“先问理由再看代码”的模式会救你一命。

3.2 阶段二：把同步讲透，为了光追的多帧与多队列

第一阶段的三角形往往是单帧提交，主循环里acquire、submit、present一条龙。但真实项目里没人这么做，因为下一帧的录制不能等上一帧GPU跑完才启动。所以第二阶段就讲多帧在飞行、VkFence和VkSemaphore的区别、子通道依赖（subpass dependency）、图像布局转换。

为什么这个阶段在光追教学里特别重要？因为加速结构的构建天然是异步的。你不能在录完构建TLAS的命令后立刻执行光追查询，必须用事件或管线屏障保证“构建完成”先于“光线发射”。如果你在三角形阶段已经习惯了“要先知道GPU每一步的进度”，到光追阶段不过是换了个对象名字——从图像布局，换成加速结构构建；从提交信号量，换成TLAS查询等待。原理完全一样，符号不同而已。

一个经验是，让每个学生亲手做一个测试：连续跑10帧，每帧都打印出vkAcquireNextImageKHR返回的帧缓冲索引序列。很多人会惊讶地发现索引不是从0到7顺序轮转的，而是追赶上显示器的Vsync节奏随机轮转。这个观察对理解多帧在飞行非常重要，因为它让你意识到CPU和GPU之间是异步流水线，而不是同步调用。

3.3 阶段三：用计算着色器为raygen着色器铺路

在光追之前，很多教程会先讲compute shader做图像后处理。我的框架里，这一步被赋予了更高的战略地位：因为raygen shader在概念上就是一个“按像素网格执行的计算着色器”。

在compute shader里，你通过gl_GlobalInvocationID拿到当前线程对应的像素坐标，写一个imageStore输出颜色。在raygen shader里，你通过gl_LaunchIDEXT拿到光线对应的像素坐标，调用traceRayEXT查询场景，然后把命中结果写入输出图像。两者都遵循“每个像素一个着色器调用”的模型，都通过描述符访问资源，都自己管理输出图像布局。

这个阶段可以做一个很直观的练习：用compute shader给三角形画面做马赛克效果或索贝尔边缘检测。等学生会“输入图像→计算着色器处理→输出图像”这一套之后，学习raygen shader时的认知负担会骤降——他们只需要把“读像素”换成“发射光线”，把“写像素”的代码保存，再补一组命中/未命中的分支逻辑就行。

3.4 阶段四：给三角形建第一个BLAS

到这一步，我们终于可以接触VK_KHR_acceleration_structure。建议不要直接构建复杂场景，而是用学生最熟悉的三角形顶点数据——就是阶段一那个三角形，构建出一个BLAS。

构建流程看起来长，但实际上比你想象的更像管线的固定流程：先收集三角形顶点和索引到一个VkBuffer里；查询vkGetAccelerationStructureBuildSizesKHR获取需要的临时空间和加速结构空间；分配设备内存；创建VkAccelerationStructureKHR对象本身；填充VkAccelerationStructureBuildGeometryInfoKHR和VkAccelerationStructureBuildRangeInfoKHR；最后调用vkCmdBuildAccelerationStructuresKHR或vkBuildAccelerationStructuresKHR提交构建。

这一阶段的目标不是让你背API，而是理解一件事：“一个由三角形组成的BLAS会被驱动优化成什么样的加速结构”。驱动会用空间划分算法生成包围盒层级，让光线查询避开大部分三角形。学生可以打印出构建后的加速结构内存大小和构建耗时，对比一个三角形和一万个三角形的差距，从而真正理解为什么需要加速结构——不是为了一万倍的三角形遍历速度，而是为了把求交次数从O(N)降到O(logN)。

这里有一个很重要的伏笔：BLAS里装的是“几何数据”，不是“场景数据”。同一个BLAS可以被多个TLAS实例引用，对应场景中多个不同位置、不同朝向的物体。我建议在阶段四末尾就让学员用两个实例引用同一个BLAS，分别平移到不同位置，为阶段六的多物体场景做准备。

3.5 阶段五：最小的光追三角形——raygen、miss、closest-hit跑通SBT

这一阶段是整个重构框架的高潮：写一个raygen shader，让每个像素发射一条光线，命中屏幕上那个三角形，输出带简单颜色的结果；如果没有命中，输出背景色。这个场景比PBR材质、反射、阴影全都简单，但是数字化表示光追管线最完整的最小闭环。

跑通它，你至少需要做四件事：创建光追管线（VkRayTracingPipelineCreateInfoKHR，把raygen、miss、closest-hit三个shader组装成ShaderGroup）；创建着色器绑定表（VkStridedDeviceAddressRegionKHR，包含raygen region、miss region、hit region，每个region有各自的地址、大小、步长）；把TLAS绑定到描述符集上；在光追渲染pass里调用vkCmdTraceRaysKHR。

我踩过的最大坑是SBT的填充格式。每个region里的shader handle不是可以直接拷贝进GPU缓冲的普通代码，而是经过vkGetRayTracingShaderGroupHandlesKHR查询出来的句柄字节串。而且每个句柄的大小和SBT的步长受设备属性限制，不同显卡不同，必须用VkPhysicalDeviceRayTracingPipelinePropertiesKHR查询，不能硬编码。我在教学里经常让学生故意把句柄大小写成固定值，然后观察画面变成什么样——常常是三角形消失、变成纯背景色，或者整屏花屏。这个“错误实验”反而比正确代码更能让学生记住SBT的布局规则。

光追三角形的验证方式很有意思：你可以直接用命令行截图对比光栅化三角和光追三角的输出，两者应该有几乎完全一致的轮廓（光追没有光栅化那条对角线采样差异时，锯齿可能更轻）。这种“同源三角形，两种渲染路径”的对照，会让学生第一次直观感受到光栅化和光追其实在解决同一个问题——屏幕上的像素该是什么颜色。

3.6 阶段六：从单三角形到多物体——实例变换、材质分类与混合渲染

最后一个阶段，把三角形扩展成多个实例，引入实例变换矩阵。你会发现TLAS的构建几乎不需要改代码，只需要在VkAccelerationStructureInstanceKHR数组中为每个实例提供变换矩阵、实例掩码（用来跳过不需要参与光线追踪的对象）、着色器绑定表索引（用来区分命中哪个材质）。整个过程中学生可以复习矩阵变换，但这次变换对象从“光栅化管线的MVP矩阵”变成了“光线与实例求交时的局部空间变换”。

到这一步，可以加入真正的材质区分了：两个三角形，一个输出红色，一个输出蓝色，靠closest-hit shader里判断gl_InstanceID或gl_HitTriangleVertexPositionsEXT区分。你会看到SBT的着色器组索引如何和TLAS实例的着色器编号联动，理解“命中一个物体”和“执行一段命中逻辑”的绑定关系。

我还会建议在这个阶段做一次混合渲染：光栅化一个三角形，光追另一个三角形，两个结果合成到同一帧画面。这并不复杂——你已经有光栅化图像和光追图像，合成到交换链图像上加一个没有任何障碍的compute shader即可，但它对学生概念整合的价值极高：Vulkan版本的光栅化和光追在同一个帧循环里共存，不是互斥的，而是可以共享描述符、命令缓冲、同步机制的两种路径。

4. 环境、工具与验证：让每一步学习都可被观测

4.1 环境选型：SDK、驱动、硬件一个都不能少

硬件光追对开发环境的要求比普通Vulkan开发高一个量级。首先硬件要支持对应扩展：NVIDIA的20系及以上（Turing架构之后）、AMD的RX 6000系列之后、Intel的Arc系列，基本都满足。但要注意移动版GPU可能存在“扩展列表里有，但性能糟糕”的情况，比如用集显跑光追会卡到怀疑人生，但这种卡顿本身就是很好的教学素材——它能让学生直观体会到硬件加速和软件模拟的区别。

软件方面，关键点有三个：Vulkan SDK版本别太老（建议1.3.x，甚至直接更新到当前最新稳定版，因为光追扩展和SDK工具链在持续优化）；系统驱动必须装最新稳定版，特别是NVIDIA和AMD的显卡驱动，光追扩展是跟着驱动走的，驱动不新，扩展文档再熟也没用；调试工具建议直接装完整版的Vulkan SDK并启用Validation Layers，因为光追API错误很难靠肉眼从画面里发现。

一个实操检查清单：在代码最开始用vkEnumerateDeviceExtensionProperties打印出所有支持的扩展，确认存在VK_KHR_acceleration_structure和VK_KHR_ray_tracing_pipeline，同时查询vkGetPhysicalDeviceProperties2KHR里的VkPhysicalDeviceRayTracingPipelinePropertiesKHR，记录shaderGroupHandleSize和shaderGroupBaseAlignment。这两步是光追程序能跑起来的物理前提。

4.2 三层调试工具：每个阶段用哪个、怎么看

三角形阶段主要靠Validation Layers，它会在你忘记设置图像布局、错误依赖子通道时直接弹错误信息。Vulkan Validation Layers对光追扩展的覆盖在最近两三年已经很完善了，能检测出“加速结构绑定到描述符但还没构建”“着色器绑定表地址越界”这类常见问题。

光追阶段的调试最好配合专用图形调试器。我个人的经验是：RenderDoc适合验证加速结构内容，它能把BLAS/TLAS的结构可视化，让你直接看到包围盒层级；NVIDIA Nsight Graphics则更适合分析光追性能，能看到每条光线的遍历深度、求交次数、缓存命中率。前者适合“我的光追为什么画错了”，后者适合“我的光追为什么这么慢”。

还有一个在很多教程里被忽视的工具：Vulkan的vkCmdWriteTimestamp和VkQueryPool。在光追pipeline前后各插入一个时间戳查询，就能精确测量vkCmdTraceRaysKHR的执行耗时。有了这个数据，学生就能定量回答“光追和光栅化差多少”的问题，而不是凭感觉说“大概慢一点”。

4.3 把抽象概念变成可观测的验证标准

教学里最怕的是“看起来懂了，实际没懂”。我给自己定的规矩是，每个学习阶段都必须有一个可观测的验证标准，不是“看懂了文档”，而是“程序输出了预期结果”。

• 同步理解：不是“懂fence和semaphore区别”，而是能画出10帧内acquire和present的时序图。
• 加速结构理解：不是“懂BLAS/TLAS”，而是能解释为什么BLAS构建时间远大于TLAS、为什么TLAS更新比维护BLAS便宜得多。
• SBT理解：不是“懂region分块”，而是能预测修改SBT命中region的步长后画面会变成什么样子。

这套验证标准的起点，就是那一个三角形。它小到你拿放大镜看不完所有细节，但又大到可以承载光追、计算、加速结构、多帧同步这些Vulkan的完整骨架。

5. 实操中的坑与教学心得

5.1 第一个三角形阶段最容易埋下的四个坑

重构框架这几个月，我亲眼看着各种经典坑在“同一个三角形”里反复出现。先说三角形阶段最容易埋下的四个：

第一个是“present mode选错”。很多教程默认用VK_PRESENT_MODE_FIFO_KHR，这是一种垂直同步模式；但如果你没讲清楚不同模式的含义，学生换到VK_PRESENT_MODE_IMMEDIATE_KHR时画面撕裂，还以为是交换链代码写错了。真正的问题不是代码，而是对present mode的语义理解。这个坑虽然简单，但在光追阶段会让你以为“光追管线有bug”——其实只是present mode在不同队列之间同步节奏不同。

第二个是“图像布局转换被省略”。很多初学者在只有一个Attention Triangle时省略了VK_IMAGE_LAYOUT_PRESENT_SRC_KHR到VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL的显式转换，因为有些驱动默认没报错。但这个“侥幸成功”在光追阶段会变成定时炸弹，因为光追输出图像往往需要VK_IMAGE_LAYOUT_GENERAL布局，布局转换一旦出错，Validation Layers会间歇性报错，查起来非常痛苦。

第三个是“同步对象生命周期太短”。如果fence和semaphore创建在帧循环内部，随着窗口尺寸变化和交换链重建，这些对象可能失效或泄漏。光追阶段的对象生命周期更长，这个坑影响会更严重，因为加速结构不能简单地每帧销毁重建。

第四个是“忽略了设备本地内存的可见性”。顶点缓冲如果创建在主机可见内存而不加VK_PIPELINE_STAGE_VERTEX_INPUT_STAGE_BIT的内存屏障，在光追里出现“顶点坐标对但求交结果错误”的诡异现象，往往就是这个原因。GPU端数据写得慢，光线查询读得快——时序没对齐。

5.2 真正进入光追后：SBT、加速结构、实例掩码的三大翻车点

光追阶段最常见的翻车点，第一条就是SBT地址对齐。Vulkan规定SBT的所有region地址必须对齐到shaderGroupBaseAlignment，通常是64字节或256字节。很多人编译通过、Validation Layers也不报错，但画面就是不对。原因往往是句柄写入缓冲时的偏移没对齐，驱动读出来的第一条记录就是“垃圾指令”。排查方法很直接：打印shaderGroupHandleSize、shaderGroupBaseAlignment和SBT缓冲的分配地址，核对偏移是否满足对齐要求。

第二条是“BLAS构建后没有立即冻结”。加速结构一旦构建完成，除非特殊扩展，它是不可变的。很多人在后续帧里继续往顶点缓冲写数据，逻辑上想“改三角形”，但实际上光追每次还在用旧BLAS。要解决这个问题，要么重新构建BLAS，要么用实例变换矩阵模拟，或者使用VK_KHR_acceleration_structure里允许的更新模式。教学里我会让学生做一个实验：直接改顶点缓冲后立刻traceRay看画面，然后重建BLAS后再traceRay看画面，对比结果会让他们一辈子记住“BLAS是静态快照”。

第三条是“TLAS实例掩码设置错误导致看不见物体”。TLAS实例掩码（instance mask）和SBT里的instanceOffset配合决定哪个实例可以被命中。如果你在多个实例里忘了设置掩码，或者把掩码设为0，所有光线都会“穿透”物体，屏幕上只剩背景色。排查这类问题不能靠看代码——先用RenderDoc查看TLAS实例的内容，确认掩码和变换矩阵是否如预期。

5.3 重构之后：周期缩短、理解加深、真正的“掌握”

我按这套框架实践了一轮，最直观的变化是学习路径变短了。以前光学习路径“三角形→光栅化全栈→PBR→光追”可能需要半年；现在按六个阶段走，每周一个阶段、六周能跑通最小光追三角形，后面再去补PBR材质、后处理、光照模型时，已经是在“一个能运行的光追渲染器”上做加法，而不是从头摸一张白纸。

更重要的变化是学习深度。以前学生画完三角形，问他“为什么要用VkBufferDeviceAddressInfo取顶点缓冲的设备地址”，他会觉得这就是个API细节；现在构建加速结构时他自然会明白：BLAS构建时需要知道顶点数据在GPU内存里的确切地址，而没有设备地址机制，就没法让底层遍历代码直接读顶点坐标。同一个知识点，在“面向光追的重构框架”里的解释力度，远大于传统教学里“这是Vulkan新特性”一句话带过。

真要我总结这套重构经验，我会说一句话：不要让学生为了三角形学三角形，要让三角形成为拆解光追的钥匙。一个三角形在光栅化里是图元，在光追里是求交对象，在计算着色器里是像素级并行的一份子。同一个简单几何体，贯穿Vulkan所有核心概念，用最小的复杂度把那条学习路线完整点亮。这比我见过的大多数“从零开始写一个Vulkan引擎”的计划都更务实，也更适合绝大多数只是想搞懂这套图形API的人。