批处理/合并生成/更新调用和几何图形非常重要。最终，在对小批量原语执行AS操作的情况下，GPU将被占用。利用一个构建可以接受多个几何描述符的事实，并在构建时转换几何体。这通常会导致最有效的数据结构，特别是当对象的aabb相互重叠时。将事物分组到BLAS/实例应该遵循空间局部性。不要“把所有有相同材料的东西扔进同一个BLAS中，不管它们最终在太空中的什么地方”。
知道何时更新，而不是（重新）构建。持续更新BLAS会降低其作为空间数据结构的效率，使遍历/交叉查询相对于新构建的查询要慢得多。作为一般规则，应该只考虑动态对象进行更新。如果部分网格相对于其局部邻域的位置发生剧烈变化，则更新后的遍历质量将迅速下降。如果事情只是“弯曲而不是断裂”，那么更新将非常有效。示例：树在风中摇摆：update=good；mesh exploding:update=bad。决定更新或重建蒙皮角色：这取决于。假设最初的构建是以t-pose的形式完成的，那么每次更新都会假设脚很近。在行走/跑步动画中，这可能会影响跟踪效率。这里的一个解决方案是建立几个关键姿势的加速度结构，然后使用最接近的匹配作为重新装配的来源。建议采用实验指导的流程/工艺。
对所有静态几何图形使用压缩。压缩速度很快，通常可以回收大量内存。当对压缩加速度结构跟踪光线时，性能没有下降。
Use the right build flags.从下表中选择一个组合开始…
然后考虑添加这些标志：
ALLOW_COMPACTION。对所有静态几何体执行此操作通常是一个好主意，以回收（潜在的）大量内存。
对于可更新的几何体，压缩那些具有较长生存期的blas是有意义的，因此额外的步骤是值得的（压缩和更新不是互斥的！）。
对于每帧都重建（而不是更新）的完全动态几何体，使用压缩通常没有好处。
不使用压缩的一个潜在原因是利用BLAS存储需求随原始计数单调增加的保证—这在压缩上下文中不成立。
MINIMIZE_MEMORY (DXR) / LOW_MEMORY_BIT (VK)。仅当应用程序在如此大的内存压力下，如果不尽可能优化内存消耗，光线跟踪路径将不可行时才使用。此标志通常会牺牲构建和跟踪性能。并非所有情况下都是这样，但要注意，未来的驱动程序版本可能会有不同的行为，因此不要依赖实验数据“确认”标志不会降低性能。
2.0 – Ray-Tracing 2.1 – Pipeline Management避免在关键路径上创建状态对象。集合和管道编译可能需要几十到几百毫秒。因此，应用程序应该预先创建所有pso（例如，在level load），或者在后台线程上异步创建状态对象，并在准备就绪时进行热交换。
考虑使用多个光线跟踪管道（状态对象）。当跟踪几种类型的光线（例如阴影和反射），其中一种类型（阴影）具有几个简单的着色器、小的有效载荷和/或较低的寄存器压力，而另一种类型（反射）涉及许多复杂的着色器和/或较大的有效载荷时，这尤其适用。将这些情况分为不同的管道有助于驱动程序更高效地调度着色器执行，并在更高的占用率下运行工作负载。