计算着色器中顶点数据高效布局探讨——面向路径追踪器

针对你做小型路径追踪器Demo时遇到的顶点数据布局问题，直接分析三种方案的优劣和最优选择：

1. 朴素布局 #

struct Vertex {
   position: [f32;3],
   normal: [f32;3],
   texcoord: [f32;2],
}

• 表面上内存占用是8个f32（32字节），但GPU是按16字节块读取内存的，这种不对齐的布局会导致跨块读取。比如position的第三个f32和normal的第一个f32可能分属两个16字节块，GPU得读两次才能拿到完整数据，反而浪费带宽。更糟的是，很多GPU驱动会自动给结构体补对齐，最终实际占用可能还是40字节（给position补1个f32、normal补1个、texcoord补2个），既没省内存，还搞乱了布局可控性。

2. 宽松对齐布局 #

struct Vertex {
   position: [f32;4],
   normal: [f32;4],
   texcoord: [f32;4],
}

• 内存占用是12个f32（48字节），完全符合16字节对齐要求，GPU每次读取都能精准命中所需的16字节块，内存访问效率拉满。虽然多了几个无用的f32，但对于小型Demo来说，顶点数据量通常不大，这点内存浪费完全可以忽略。而且这种布局代码最简单，不用搞任何拆分拼接，不容易出错。

3. Hack式对齐布局 #

struct Vertex {
   position: [f32;3],
   texcoord_u: f32,
   normal: [f32;3],
   texcoord_v: f32,
}

• 内存占用8个f32（32字节），刚好满足16字节对齐（每个16字节块装position+u、normal+v），试图在省内存的同时符合规则，但有两个明显问题：
  • 局部性差：texcoord的u和v被拆到不同块里，路径追踪中纹理采样是高频操作，每次取完整的texcoord都得读两个16字节块，比连续存储多一次读取，反而可能降低性能。
  • 代码麻烦：着色器里得手动把u和v拼起来，容易出错，对于小型Demo来说，开发效率的损失比内存节省更不值。

最终建议 #

做小型路径追踪器Demo，优先选宽松对齐布局：

• 代码最简单，少踩坑，省开发时间。
• 性能稳定，完全适配GPU内存访问逻辑，不会有意外的性能损耗。
• 这点内存浪费在小场景下根本不是问题，除非你要处理数百万级别的顶点，否则没必要纠结。

如果真的特别在意内存（比如大规模场景），可以试试Hack式布局，但要在着色器里尽量优化texcoord的访问逻辑，减少同时读u和v的情况。

绝对别用朴素布局，它既没真正省内存，还会拖慢GPU访问效率，得不偿失。

内容的提问来源于stack exchange，提问作者julcs