保持任何击中阴影极简。任何命中着色器在每一个TraceRay中执行多次（与最近的命中或未命中着色器相比，例如，后者只执行一次），这使得它们非常昂贵。此外，任何命中都在调用图中寄存器压力最高的点执行。所以为了获得最佳性能，尽可能让它们变得微不足道。
2.2.4 – Shading Execution Divergence
从一个简单的着色实现开始。当实现需要大量材质着色（例如反射或GI）的技术时，性能可能会受到着色散度的限制。这通常有许多原因，但不限于：指令缓存抖动和/或发散内存访问。采用以下策略来解决这些问题：
使用简化的着色器优化指令发散：
使用较低质量或简化的材质球（相对于光栅化）进行光线跟踪。
在某些极端情况下（例如：漫反射GI或粗糙镜面反射），可以从视觉上接受完全回落到顶点级别的着色（这也有减少噪声的附加好处）。
通过以下方法优化发散内存访问：
降低纹理访问的分辨率-或偏移mip贴图级别
将光线跟踪着色器中的照明计算推迟到帧中的稍后点
在极端情况下，可能需要手动安排（分类/装箱）阴影。当上述优化策略不足时，应用程序可以手动安排着色。但是，这会阻止基于driver/HW的调度生效。英伟达不断改进我们的日程安排。
2.3 – Resources对场景全局资源使用全局根签名（DXR）或全局资源绑定（VK）。这将避免在本地每几何体根表中进行复制，并应导致更好的缓存行为。
避免资源临时性。这通常会导致非原语代码重复。例如，将一个纹理保留在一个临时的位置，并根据某些条件对其进行指定，将导致每个可能的纹理指定的所有采样操作重复。可能的解决方法：使用资源数组并动态索引到其中。
同时访问64位或128位对齐的本地根表数据可以实现矢量化加载。
对于对齐的原始数据，首选StructuredBuffer而不是ByteAddressBuffer。
3.0 – Denoisers使用RTX去噪SDK实现高质量、快速的光线跟踪效果去噪。您可以在GameWorks光线跟踪页面找到更多详细信息。
4.0 – Memory Management对于DXR，将QueryVideoMemory API报告的预算视为软提示。实际节段大小大约大20%。
将命令分配器隔离到不同类型的命令列表。如果可以避免，不要将非DXR-CAs与DXR-CAs混合和匹配。
命令分配器重置将不会释放关联的内存。可以使用destroy/create释放这些分配，但必须在关键路径之外执行此操作，以避免长时间暂停
注意管道的堆栈大小。堆栈大小随着TraceRay调用中保持的活动状态的数量和TraceRay调用周围的控制流复杂性而增加。最大跟踪深度实际上是堆栈大小的一个直接乘法器——尽可能保持低的深度。