Vulkan

Preface Foundation现在(2025/12/16)也有了能用的RT相关API，Editor的GPUScene也有了BLAS上传/压缩(compact)与逐帧TLAS更新支持。到目前为止用rt做的只有inline query实现硬阴影——在做实时GI相关内容之前，不妨复习下采样/PBR相关知识——那就写个GPU Path Tracer吧？ PBRT/Physically Based Rendering:From Theory To Implementation/Kanition大佬v3翻译版，Ray Tracing Gems 2, nvpro-samples/vk_gltf_renderer 将是我们这里主要的信息来源。 SBT (Shader Binding Table) 及管线 API 之前用过了非常方便的Inline Ray Query - 从fragment/pixel，compute可以直接产生光线进行trace：从这里出发进行PT是可行的，这也是nvpro-samples/vk_mini_path_tracer 的教学式做法。 不过完全利用硬件的RT管线会离不开SBT/Shader Binding Table，即Shader绑定表。除了shader单体更小更快之外，调度也有由驱动优化的可能。此外RHI目前还没有SBT相关设施，借此一并处理。参考 nvpro-samples/vk_raytracing_tutorial_KHR …SBT API应该是Vulkan中最无语的一个设计了。在RHI里决定偷懒，在光追PSO创建过程中直接处理并分组SBT；最后实现完整PT所需的Renderer使用会很轻松，如下： ... renderer->CreatePass( "Trace", RHIDeviceQueueType::Graphics, 0u, [=](PassHandle self, Renderer* r) { r->BindBackbufferUAV(self, 1u); r->BindBufferUniform(self, GlobalUBO, RHIPipelineStageBits::RayTracingShader, "globalParams"); r->BindAccelerationStructureSRV(self, TLAS, RHIPipelineStageBits::RayTracingShader, "AS"); r->BindShader(self, RHIShaderStageBits::RayGeneration, "RayGeneration", "data/shaders/ERTPathTracer.spv"); r->BindShader(self, RHIShaderStageBits::RayClosestHit, "RayClosestHit", "data/shaders/ERTPathTracer.spv"); r->BindShader(self, RHIShaderStageBits::RayMiss, "RayMiss", "data/shaders/ERTPathTracer.spv"); r->BindBufferStorageRead(self, InstanceBuffer, RHIPipelineStageBits::ComputeShader, "instances"); r->BindBufferStorageRead(self, PrimitiveBuffer, RHIPipelineStageBits::AllGraphics, "primitives"); r->BindBufferStorageRead(self, MaterialBuffer, RHIPipelineStageBits::AllGraphics, "materials"); r->BindTextureSampler(self, TexSampler, "textureSampler"); r->BindDescriptorSet(self, "textures", gpu->GetTexturePool()->GetDescriptorSetLayout()); }, [=](PassHandle self, Renderer* r, RHICommandList* cmd) { RHIExtent2D wh = r->GetSwapchainExtent(); r->CmdSetPipeline(self, cmd); r->CmdBindDescriptorSet(self, cmd, "textures", gpu->GetTexturePool()->GetDescriptorSet()); cmd->TraceRays(wh....

Preface Editor暂时还没有任何关于光照，甚至是texture map的相关实现。本篇文章将介绍纹理方面的高效存储及Editor GBuffer的布局，及PBR shading的初步测试。 容器格式 不看轮子和各种私有格式的话，常用的主要有DDS和最近的KTX2。 KTX 虽然工具链很成熟，在新版Vulkan Tutorial中也被绝赞推荐：但由于全平台支持，直接使用的话由于各种编码产生的依赖会多的离谱（--depth=1 clone大小约莫~1GB！），因此这里没有选择。 DDS 最后挑的还是DDS，因为容器本身很简单："DXT " + DDS_HEADER + DDS_HEADER_DXT10后即为对应编码下linear tiled数据，可以分成layer/mip直接上传 GPU。至于为什么不应该(Linear Tiling)整个上传（或者，GPU上的纹理到存储方式为什么是硬件相关的），请参考 Image Copies - Vulkan Documentation。 实现上主要是读文档——部分结构直接从DirectXTex - DDS.h copy过来了。用DDS有一个好处就是能被第三方工具直接打开，同时，Editor序列化纹理也将如此存储。 纹理格式 运行时解码成全精度，原始的R8G8B8A8UNORM等格式存储诚然是…一种选择。不过记得之前和某个Unity游戏打交道见过其在资产里直接存了原始RGB565(RGB 16 bit)量化格式的纹理做NPR 效果。但是至于为什么要用这种格式，搜了半天也没找到个结果（汗） 纹理压缩，可能除了UI带alpha材质的极端情况外，基本是必做的事情。GPU硬件解码其支持的格式开销是几乎不存在的——参考 Unity 给出的材质格式推荐： DXTc/BCn/ETC 桌面端，支持最广泛的包括各种BCn/Block Compression [n]压缩 - 参见 Understanding BCn Texture Compression Formats - Nathan Reed；同时，BC1,BC2,BC3 也被微软叫成 DXT1, DXT3, DXT5，这里提及以防混淆。最后，在近十年支持DX11级别的桌面硬件中，无脑使用BC6(H),BC7 基本没问题。 移动端，ETC曾是主流：Unity的crunch就提供第一方DTXc/BCn和ETC的支持。现在的移动硬件一概支持更优秀且开源的ASTC：Unity自己也在使用ARM官方的开源astc-codec处理编码。但需要注意的是，桌面硬件上对astc的支持几乎不存在。这点也可以自己利用Vulkan Caps Viewer检查： Basis Universal 可见硬件上——上述压缩编码在桌面/移动端的支持是没有交集的。但是纹理压缩做的工作本身会有很多重叠（如 DCT编码等等）—— basisu 即可高效地存储一种统一编码格式，并在运行时非常快速地转换到目标平台使用编码上传GPU。 额外的，basisu也自带一层哈夫曼编码 - 这是在所有block处理完之后全局进行的，因此整体压缩率在相同平均bpp下也会比单纯的BCn等编码一般地会更高。 BC7 最后在GPU和文件本身存储上还是采用了BC7 - Editor内置了来自crunch作者Richard Geldreich 的 bc7enc 实现。这样也方便直接读取并直接转码JPG/PNG存储的glTF模型纹理。...

Preface 对网格数据而言，顶点数可以很多很多：如果存储每个顶点的开销能够减少，显然对GPU显存和磁盘存储压力而言是非常好的事情。以下介绍目前Editor内存在的一些量化操作。glTF中的顶点可以有以下属性（参见 Spec）： Name Accessor Type(s) Component Type(s) Description POSITION VEC3 float Unitless XYZ vertex positions NORMAL VEC3 float Normalized XYZ vertex normals TANGENT VEC4 float XYZW vertex tangents where the XYZ portion is normalized, and the W component is a sign value (-1 or +1) indicating handedness of the tangent basis TEXCOORD_n VEC2 float unsigned byte normalized unsigned short normalized ST texture coordinates COLOR_n VEC3 VEC4 float unsigned byte normalized unsigned short normalized RGB or RGBA vertex color linear multiplier JOINTS_n VEC4 unsigned byte unsigned short See Skinned Mesh Attributes WEIGHTS_n VEC4 float unsigned byte normalized unsigned short normalized See Skinned Mesh Attributes 下面为完整精度的顶点struct，足矣表示glTF标准中的任何非蒙皮（不看JOINTS, WEIGHTS）网格（vertex color暂时忽略）。...

Preface 迄今为止，Editor渲染方面实现仅处理了单个 Mesh 的最简单情况。接下来我们将正式引入场景加载。 在 CPU 上表达物体间关系的方案诸多——本质上也都是为实现某种Scene Graph。同时，本篇体裁内的最终目标仅仅是为了渲染 GLTF 场景。此后内容也将围绕其结构进行展开。 坐标系细节 我们约定使用右手系坐标系统。即在相机视角，$+X$为右，$+Y$为上，$-Z$为前。这也是Blender等的默认坐标系（$+Z$指向相机“内”） 透视及视角矩阵 注：$f$与$a$ $$ f = \frac{1}{\tan(fov_y / 2)}，a = \text{宽高比} $$ 我们想要让$z$轴上，相机处 $ z= z_{n}$ 的NDC为 $z_{ndc} = 1$； 无穷远，或一定$z_{f}$ 处 $z_{ndc} = 0$ 理由是充分的。简要地，$[1,0]$映射可大幅改善near plane附件深度精度。详细解释及动机还请参考： https://mynameismjp.wordpress.com/2010/03/22/attack-of-the-depth-buffer/ https://developer.nvidia.com/content/depth-precision-visualized 下面直接给出改配置对应透视矩阵，可由代入计算$z=z_n,z_{NDC}=1$, $z = z_f, z_{NDC} = 0$易得 $$ P = \begin{bmatrix} \frac{f}{a} & 0 & 0 & 0 \newline 0 & f & 0 & 0 \newline 0 & 0 & \frac{z_n}{z_f - z_n} & \frac{z_f z_n}{z_f - z_n} \newline 0 & 0 & -1 & 0 \end{bmatrix} $$...

Preface 目前为止，Foundation 还没有直接，不依赖于外部工具的性能评估工具。同时：之前读过的 【技术精讲】AMD RDNA™ 显卡上的Mesh Shaders（二）：优化和最佳实践 提到了剔除部分一些Wave Instrisic的优化还暂时没有实现。鉴于后者效果的衡量也可以通过前者反映，且未来好处良多：索性在本篇对这两个方向进行探索。 内置 Profiler 工具上，NV/AMD 也早有了非常成熟的toolchain，即NVIDIA Nsight Graphics，Radeon™ Developer Tool Suite。CPU侧自己也很早集成了tracy profiler：这些都离不开外部工具的加持。当然：内置工具主要是方便即时反馈。真正有诊断意义的数据还是要从第一方，驱动级工具获取分析的。 时序获取 Query 类 API 覆盖率相当广泛 - Vulkan (1.0+)，DX12 等等皆有第一方支持 - 为我们的 RHI 及 Renderer 每个pass添加也并非难事。以下为 Renderer 中节选： void Execute(size_t thread_id) noexcept override { ZoneScoped; ZoneNameF("<%s>", pass->name.c_str()); *cmd = r->ExecuteAllocateCommandList(pass->queue, thread_id); (*cmd)->Begin(); (*cmd)->WriteTimestamp(queryPool, RHIPipelineStageBits::TopOfPipe, pass->handle * 2); (*cmd)->BeginTransition(); for (auto& [res, desc] : (*barriers)) { res.Visit([&](RHIBuffer* p) { (*cmd)->SetBufferTransition(p, desc); }, [&](RHITexture* p) { (*cmd)->SetImageTransition(p, desc); }); } (*cmd)->EndTransition(); (*cmd)->DebugBegin(pass->name....

Preface 预谋多时而虽迟但到的 Foundation 博文系列。 特别中二的名字以外，项（天）目（坑）并非最近开始的工作（开始于约莫 ~2023）。期间诸多内容，如各类无锁 (Lock-free) 数据结构、RHI、RenderGraph细节、Shader 反射等，也都是实现期间相当想留一笔的工作… 嘛、反正也是后期也不得不记的事，不如梭哈开篇为好——那么就开始吧？ 注： Foundation 文档：https://mos9527.com/Foundation/ Mesh Shader? 注： 参考性内容 - 酌情跳过。 深入了解，还请参阅以下文档： Introduction to Turing Mesh Shaders - NVIDIA 【技术精讲】AMD RDNA™ 显卡上的Mesh Shaders（一）： 从 vertex shader 到 mesh shader 脱离 Fixed Function 的整套Input Assembler/Vertex+Geometry管线，繁而就简：Fragment/Pixel之前，Compute模式的Mes 足矣且充分地代替这些功能。 额外的，前置还可以有Task/Amplification环节生成 Mesh Shader WorkGroup（同时，Task Shader 也支持 Indirect Dispatch）。很显然，这样的架构是相当适合当代 GPU-Driven 渲染器的实现的。 最小单元（Primitive）仍然还是三角形 - 为饱和CS单元利用率，Mesh Shader同时引入了Meshlet - 依据一定指标对Mesh进行分区 - 直接地减小overhead， 间接的提供压缩（index buffer压到N个micro buffer/uint8)，剔除机会，和… Enter Nanite 作为 UE5 的招牌特性，Nanite 利用新管线的高粒度与可控性实现了消除 LOD 过渡的任务。...