CN113822788B

CN113822788B - 光线追踪硬件中对资源的早期释放

Info

Publication number: CN113822788B
Application number: CN202110682694.1A
Authority: CN
Inventors: G·穆特乐; J·伯吉斯; R·C·小巴比奇; W·P·纽霍尔
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2020-06-18
Filing date: 2021-06-17
Publication date: 2023-10-03
Anticipated expiration: 2041-06-17
Also published as: US20230041724A1; CN113822788A; US11508112B2; US20210398340A1; US11854141B2; US20240104826A1; DE102021206234A1

Abstract

本发明公开了光线追踪硬件中对资源的早期释放。本发明公开了用于改善由光线追踪硬件加速器执行的光线相交或可见性查询的吞吐量的技术。例如，通过在硬件加速器报告光线可见性查询结果之前释放分配的资源来提高吞吐量。当光线可见性查询结果可以以压缩格式被存储在分配的资源之外时，释放分配的资源。当报告光线可见性查询结果时，基于以压缩格式存储的结果来重建结果。压缩格式存储可用于不返回任何相交或在任何命中光线可见性查询上终止的光线可见性查询。基于将返回的数据类型和/或光线可见性查询的结果，也可以独立释放分配的资源的一个或更多个单独组件。

Description

光线追踪硬件中对资源的早期释放

相关专利和申请的交叉引用

本申请与以下共同转让的美国专利和专利申请相关，其全部内容通过引用结合到本文中：

●于2014年12月8日提交的标题为“树数据结构的短堆栈遍历”的美国申请号14/563,872；

●标题为“基于块的包围体(Bounding Volume)层次结构”的美国专利号9,582,607；

●标题为“基于块的包围体层次结构的相对编码”的美国专利号9,552,664；

●标题为“光束追踪”的美国专利号9,569,559；

●标题为“基于多个本地坐标系的树数据结构”的美国专利号10,025,879；

●于2015年6月11日提交的标题为“基于块的几何数据无损压缩”的美国申请号14/737,343；

●标题为“无需着色器干预的相交点上的连续包围体层次结构遍历的方法”的美国专利申请号16/101,066。

●标题为“对数据路径调度的高速缓存请求进行有效分组的方法”的美国专利申请号16/101,109；

●标题为“健壮、高效的多处理器协处理器接口”的美国专利申请号16/101,247；

●标题为“树遍历的查询特定行为修改”的美国专利申请号16/101,180；

●标题为“保守的水密光线三角形相交点”的美国专利申请号16/101,148；

●标题为“处理乱序的不透明和Alpha(阿尔法)光线/图元相交点的方法”的美国专利申请号16/101,196；以及

●标题为“用于硬件中的树遍历机制的前向进程和可编程超时的方法”的美国专利申请号16/101,232。

技术领域

本技术涉及计算机图形，并且具体地，涉及光线追踪器。更具体地，该技术涉及包括但不限于光线追踪的计算机图形处理的硬件加速。本文中的示例性非限制性技术还涉及基于硬件的光线相交测试，该测试有效地确定例如用于实时光线追踪的光线相交。更具体地，本文的示例性非限制性技术涉及分配的光线追踪硬件资源的数据压缩和/或早期释放。

背景技术

在过去的30年中，实时计算机图形学取得了巨大的进步。随着1980年代功能强大的图形处理单元(GPU)的发展，它提供了3D硬件图形管线，使得基于纹理映射的多边形图元对用户输入的实时响应来生成3D图形显示成为可能。这种实时图形处理器基于被称为扫描转换光栅化的技术，这是一种从单个点或角度确定可见性的方法。使用这种方法，可以从由几何图元(通常是多边形，例如三角形)构成的表面建模三维对象。扫描转换过程将图元多边形顶点建立并投影到视图平面上，并填充图元边缘内部的点。参见例如Foley、Van Dam、Hughes等的《计算机图形学：原理与实践》(第2版Edison-Wesley 1995年和第3版Edison-Wesley 2014年)。

硬件长期以来一直用于确定应如何对每个多边形表面进行着色和纹理映射，以及对着色的、纹理映射的多边形表面进行光栅化以进行显示。典型的三维场景通常由数百万个多边形构成。快速的现代GPU硬件可以实时地响应用户输入为每个显示帧(每秒第1/30个或每秒第1/60个)有效地处理数百万个图形图元(primitive)。结果图形显示已用于各种实时图形用户界面中，包括但不限于增强现实、虚拟现实、视频游戏和医学成像。但是传统上，这样的交互式图形硬件无法准确地建模和描绘反射和阴影。

存在另一种图形技术，其确实执行了对于反射和阴影的物理上现实的可见性确定。这称为“光线追踪”。光线追踪是指将光线投射到场景中，并确定该光线是否以及在何处与场景的几何形状相交。此基本光线追踪可见性测试是计算机图形学中各种渲染算法和技术的基础基本要素。光线追踪是在1960年代末开发的，并在1980年代得到了改进。参见，例如，Appel的“用于实体着色机渲染的一些技术”(SJCC 1968)，第27-45页；Whitted的“阴影显示的改进的照明模型”，ACM通讯，第23卷第6期第343-349页(1980年6月)；以及Kajiya的“渲染方程”，计算机图形学(SIGGRAPH 1986年会刊，第20卷第143-150页)。从那时起，光线追踪已用于非实时图形应用程序中，例如设计和电影制作。任何看过《寻找多莉(FindingDory)》(2016年)或其他皮克斯(Pixar)动画电影的人都可以看到光线追踪方法对计算机图形学的效果，即逼真的阴影和反射。参见，例如，Hery等的“皮克斯(Pixar)的双向路径追踪”(2016年)。

通常，光线追踪是一种渲染方法，其中光线用于确定场景中各种元素的可见性。光线追踪是在包括例如路径追踪和大都会(Metropolis)光传输的各种渲染算法中使用的图元。在示例算法中，光线追踪通过对穿过场景的光传输进行建模来模拟光的物理性质，从而适用光线光学计算所有全局效果(包括例如来自发亮表面的反射)。在这样的光线追踪中，当光线穿过三维场景从潜在的多个光源传播到视点时，可能会尝试追踪成百上千的光线。通常，通过场景相对于眼睛对此类光线进行追踪，并针对场景中所有几何形状的数据库进行测试。可以从光到眼睛向前追踪光线，或者从眼睛到光向后追踪光线，或者可以跟踪光线以查看从虚拟摄相机开始并从眼睛开始的路径是否具有清晰的视线。该测试可以确定最近的相交点(以便确定从眼睛可见的东西)，或者跟踪从物体表面到光源的光线，以确定是否有任何阻碍光传输到空间中的该点的干涉。因为光线与现实中光的光线相似，所以它们提供了许多现实效果，而这些效果是使用过去三十年来已实施的基于光栅的实时3D图形技术无法实现的。由于来自场景中每个光源的每个照明光线在其穿过场景中的每个对象时都被评估，因此生成的图像看起来就像是在现实中拍摄的一样。因此，这些光线追踪方法长期以来一直在专业图形应用程序(例如，设计和电影)中使用，在基于光栅的渲染方面它们占据了主导地位。

光线追踪可用于确定沿光线是否可见(例如，测试几何图元上的阴影点与光源上的点之间的遮挡物(occluder))，并且还可用于评估反射(例如，可能涉及执行遍历以确定沿视线的最近可见表面，以便在流处理器上运行的软件可以评估与所击中的物体相对应的材料着色功能-反过来又可以根据相交对象的材料属性，将一个或更多个其他光线发射到场景中)以确定光沿光线返回眼睛。在经典的惠特(Whitted)式光线追踪中，光线是从视点通过像素网格射入场景中的，但是其他路径遍历也是可能的。通常，对于每条光线，找到最近的对象。然后，可以通过从相交点到场景中的每个光源发射光线并发现它们之间是否存在任何对象来确定该相交点是被照明还是处于阴影中。不透明的物体会挡住光线，而透明的物体会减弱光线。可以从相交点生成其他光线。例如，如果相交表面是发亮的或镜面的，则在反射方向上生成光线。光线可以接受相交的第一对象的颜色，然后对它的相交点进行阴影测试。递归重复此反射过程，直到达到递归限制或后续反弹的潜在贡献降至阈值以下。光线也可以在透明固体对象的折射方向上生成，然后再次进行递归评估。因此，光线追踪技术使图形系统可以形成物理上正确的反射和阴影，而不受扫描转换技术的限制和伪影的影响。

光线追踪已经与光栅化和z缓冲一起使用或作为其替代用于采样场景几何。它也可以用作环境映射和阴影纹理的替代(或与之组合)，以产生比经由纹理技术或其他光栅“黑客(hack)”所能实现的更加逼真的反射、折射和阴影效果。光线追踪也可以用作基本图元，以在基于物理的渲染算法(例如，路径跟踪、光子映射、大都会光传输和其他光传输算法)中精确模拟光传输。

光线追踪的主要挑战通常是速度。光线追踪要求图形系统为每一帧计算和分析撞击在构成场景的每个表面上(并可能被其反射)的数百万条光线中的每条光线。过去，如此庞大的计算复杂性无法实时执行。

现代GPU 3D图形管线在渲染着色的、纹理映射的表面方面如此快速的原因之一是它们有效地使用了相干性。在传统的扫描转换中，假定所有内容都可以通过公共图像平面中的公共窗口查看并向下投影到单个有利的点。每个三角形或其他图元通过图形管线发送，并覆盖一定数量的像素。可以为从该三角形渲染的所有像素共享所有相关计算。与通过窗口的相干视线相对应的像素的矩形图块(tile)，可以对应于在同一流处理器中以锁步方式运行的线程组。假定落在三角形边缘之间的所有像素都是运行相同着色器并从相同纹理中提取相邻纹理像素组的相同材料。相反，在光线追踪中，光线可能在公共点(光源或虚拟摄相机镜头)处开始或结束，但是当它们在整个场景中传播并与不同的材料交互时，它们会迅速发散。例如，每条光线执行搜索以找到最近的对象。可以执行一些结果的高速缓存和共享，但是由于每条光线都可能撞击不同的对象，因此不存在与纹理映射的阴影三角形相关的GPU传统上利用的那种相干性(例如，共同的有利点、窗口和图像平面没有用于光线追踪)。与其他图形方法相比，这使光线追踪在计算上更具挑战性，因此在交互基础上执行起来要困难得多。

在2010年，NVIDIA利用NVIDIA GPU和其他高度并行架构的高度并行性来开发OptiX^TM光线追踪引擎。参见Parker等人的“OptiX：通用光线追踪引擎”(图形ACM事务，第29卷，第4期，第66条，2010年7月)。除了对API(应用程序编程接口)的改进之外，OptiX^TM提供的一项进步是改进了用于查找光线与场景几何形状之间的相交的加速度数据结构。这样的加速度数据结构通常是光线追踪遍历算法使用的空间或对象层次结构，以有效地搜索可能与给定光线相交的图元。OptiX^TM提供了应用程序可以从中选择的许多不同的加速度结构类型。节点图中的每个加速度结构可以是不同的类型，从而可以将高质量的静态结构与动态更新的结构组合在一起。

OptiX^TM可编程光线追踪管线提供了显著的进步，但是通常仍然不能单独针对相对便宜的用于复杂3D场景的计算平台上的用户输入提供实时交互响应。从那时起，NVIDIA一直在开发用于光线追踪的硬件加速能力。参见，例如，US9,582,607；US9,569,559；US20160070820；US20160070767；以及以上引用的其他美国专利和专利申请。

大多数光线追踪器的基本任务是针对场景中的所有图元(在一个实施例中通常为三角形)测试光线，并报告最接近的命中(根据沿光线测量的距离)或仅遇到的第一命中(不一定最接近)，具体取决于用例。天真的算法将是O(n)蛮力搜索。但是，由于任意复杂度的3D场景中有大量的图元，因此对于光线追踪器而言，测试场景中的每个几何图元与给定光线的相交通常是无效或不可行的。

然而，通过预处理场景几何形状并预先建立合适的加速度数据结构，可以将平均情况的复杂度降低到O(log n)。加速数据结构(例如，包围体层次结构或BVH)可以快速确定哪些包围体可以忽略，哪些包围体可以包含相交的几何图元，以及哪些相交的几何图元对于可视化很重要，而哪些则不重要。使用简单的体积(例如，盒子)包含更复杂的对象可提供计算和存储效率，有助于使光线追踪实时进行。

图1A-图1C示出了在包括几何网格20的包围体中的光线追踪相交测试。图1A显示了在包括包围体10和15的虚拟空间中的光线102。为了确定光线102是否与网格20中的几何形状相交，可以直接针对光线102测试每个几何图元(例如，三角形)。但是，为了加速该过程(因为对象可能包含成千上万的几何图元)，首先针对包围体10和15测试光线102。如果光线102没有与包围体相交，则它不与包围体内的任何几何形状相交，并且对于该光线而言，可以忽略包围体内的所有几何形状。因为在图1A中，光线102错过了包围体10，所以不需要测试该包围体内的网格20的任何几何形状是否相交。虽然包围体15与光线102相交，但是包围体15不包含任何几何形状，因此不需要进一步的测试。

另一方面，如果诸如图1B中所示的光线104之类的光线与包括几何形状的包围体10相交，则该光线可能会或可能不会与包围体内部的几何形状相交，因此需要在几何形状本身上执行进一步测试以查找可能的相交。因为图1B和图1C中的光线104、106与包括几何形状的包围体10相交，所以需要执行进一步测试以确定包围体内部的任何(和哪些)图元是否相交。在图1B中，对与图元相交的进一步测试将表明，即使光线104通过包围体10，它也不会与包围体所包围的任何几何形状相交(或者，如上所述，包围体10可以进一步按体积细分，以便可以使用包围体相交测试来揭示光线不与任何几何形状相交，或更具体地，光线可以与哪些几何图元相交。

图1C示出了光线与包围体10相交并且包括光线306相交的几何形状的情况。为了执行实时光线追踪，相交测试器测试相交的包围体10内的每个几何图元，以确定光线是否与该几何图元相交。

现代光线追踪器最常使用的加速度数据结构是包围体层次结构(BVH)，其包括嵌套的轴对齐的包围盒(AABB)。BVH的叶节点包含要被测试相交的图元(例如，三角形)。BVH通常由图形或树结构数据表示形式表示。在光线追踪中，当使用这样的加速度数据结构时，查找光线的最近(或阴影，任何)相交点的时间通常是n个对象的O(log n)阶。例如，通常用于现代光线追踪加速数据结构的AABB包围体层次结构(BVH)通常具有O(log n)搜索行为。

BVH加速度数据结构以有助于帮助快速确定特定光线可能与对象的哪一部分相交并快速拒绝光线不会与其相交的场景的大部分的方式，来表示和/或引用对象或场景的3D模型。BVH数据结构表示具有包围体的场景或对象，并将包围体细分为越来越小的包围体，这些包围体终止于包含几何图元的叶节点。包围体是分层的，这意味着最上层将其下的层包围起来，该下层将其下的层包围起来，依此类推。在一个实施例中，叶节点可以潜在地与包围体层次结构中的其他叶节点重叠。

NVIDIA的RTX平台包括光线追踪技术，该技术可为内容创作者和游戏开发商带来实时的电影品质的渲染。请参阅https://developer.nvidia.com/rtx/raytracing。在包括NVIDIA RT核心在内的许多或大部分实施方案中，如在图1A-图1C中所示的包围体使用轴对齐的包围盒(“AABB”)，该包围盒可以紧凑地存储并易于进行光线相交测试。如果光线与几何形状的包围盒相交，则也对基础几何形状进行测试。但是，如果光线不与几何形状的包围盒相交，则不需要测试该基础几何形状。如图1A-图1C所示，创建了AABB的层次结构以提高单个AABB包围盒测试的剔除效果。这样可以进行有效遍历并快速缩小感兴趣的几何形状。

鉴于通过提高处理速度或能够通过使用大量图元来增加场景复杂性来改善实时光线追踪图形处理系统以渲染高质量图像的巨大潜力，因此进一步的工作是可能的并且是期望的。特别地，非常需要通过增加光线追踪硬件中的光线相交请求的吞吐量来加速对光线相交的测试。

附图说明

图1A-图1C示出了示例简化的光线追踪测试，以确定光线是否穿过包含几何形状的包围体以及光线是否与包围体内的几何形状相交。

图2示出了用于构造合适的包围体层次结构的示例过程。

图3A和图3B示出了示例包围体层次结构表示。

图4示出了示例非限制性光线追踪图形系统。

图5是示例非限制性光线追踪图形管线的流程图。

图6是示例非限制性基于硬件的光线追踪操作的流程图。

图7示出了包括树遍历单元(TTU)的简化示例非限制性遍历协处理器。

图8A和图8B示出了根据一些示例实施例的从TTU输出的结果，该结果针对用于整个组并且在子组中返回给多处理器寄存器的线程组。

图9示出了根据示例实施例的包括在多处理器和TTU之间的接口的系统。

图10A-图10D示出了根据一些示例实施例的可以返回到多处理器的数据的示例。

图11示出了可以由多处理器为线程提供的光线信息的示例。

图12A示出可以由相交管理单元提供以指示命中并提供相交信息的数据的示例。

图12B示出了可以由接口生成以指示命中但未提供有关命中的细节的数据的示例。

图12C示出了可以由相交管理单元提供以指示节点命中的数据的示例。

图12D示出了可以由相交管理单元提供以指示三角形范围命中的数据的示例。

图12E示出了可以由相交管理单元提供以指示项目范围命中的数据的示例。

图12F示出了可以由相交管理单元提供以指示实例节点命中的数据的示例。

图12G示出了可以由相交管理单元提供以指示执行光线相交测试中的错误的数据的示例。

图12H示出了可以由接口生成以指示未命中的数据的示例。

图13A示出了根据示例实施例的可以由接口跟踪的数据表。

图13B示出了根据示例实施例的TTU时隙(slot)与光线管理单元、相交管理单元与堆栈管理单元时隙之间的映射。

图14示出了用于确定数据结构和图元之间的相交的示例非限制性方法的流程图。

图15A和图15B示出了更详细的光线追踪管线。

图16是生成图像的示例过程的流程图。

具体实施方式

为了实现实时光线追踪，光线追踪硬件被设计为非常高效且快速地执行光线相交测试，即测试光线包围体和/或光线图元相交。为了实现这一点，光线追踪硬件从处理器接收一组光线相交测试查询，处理查询并将结果返回给处理器。由于组中的查询可能花费不同的时间来完成，因此将存储已完成查询的结果，直到组中的其他查询被处理并将该组的结果返回给处理器为止。光线追踪硬件的吞吐量受用于存储查询结果直到报告结果的资源消耗的限制。为了进一步提高查询的吞吐量，可以增加用于存储结果直到报告结果的存储器。然而，存储器是昂贵的并且芯片上的资源是有限的。

示例非限制性技术为光线追踪遍历工作负载提供了更好的资源利用率和性能。示例实施例基于光线遍历结果利用显着的存储压缩。存储压缩允许硬件资源被早期释放，这些硬件资源通常会存储结果数据，直到结果被返回到多处理器为止。资源的早期释放允许将资源指派给其他等待被调度以处理的查询。

示例非限制性技术提供了基于硬件的能力，该能力有效地加速了光线相交测试。

建立包围体层次结构以进行更有效的相交测试

如上所述，通过使用加速度数据结构使光线对象相交测试更加有效。如上所述，加速度数据结构包括包围体的层次结构(包围体层次结构或BVH)，该层次结构递归地封装越来越小的包围体细分。最大的体积包围体可以被称为“根节点”。这种包围体层次结构(“叶节点”)的最小细分包含项目。这些项目可以是定义对象表面的图元(例如，诸如三角形之类的多边形)。或者，项目可能是包含作为项目存在的全新世界级的球体，因为它还没有被添加到BVH中(想想《黑衣人》中猫的项圈饰物，里面包括整个微型银河系)。如果该项目包含图元，则遍历协处理器在到达相交的叶节点时，将针对与叶节点相关联的图元测试光线，以确定光线相交的对象表面以及沿光线可见的对象表面。

建立BVH可以分为两个部分：静态和动态。在许多应用中，对复杂的场景进行预处理，并且基于场景的静态几何形状创建BVH。然后，使用包括动态创建和操纵的运动对象在内的交互式图形生成，BVH的另一部分(或其他链接的一个或更多个BVH)可以由在实时交互式图形系统上运行的驱动程序或其他软件实时(例如，在每个帧中)构建。BVH的构建不需要硬件加速(尽管在某些非限制性实施例中可以)，但可以使用运行在SM132和/或CPU 120和/或其他开发系统上的高度优化的软件例程来实现，例如，在应用程序开发期间。

BVH加速结构构建的第一阶段获取参考几何形状的包围盒(图2，204)。这是通过为对象中的每个几何图元执行包围盒过程来完成的，该过程为其输入图元返回保守的轴对齐包围盒(AABB)。将包围盒与几何形状的相关坐标系的轴对齐，与例如定向包围盒(OBB)、包围球或其他方法相比，可以提高实时几何操作(例如，相交测试和坐标转换)的效率。然而，本领域技术人员将理解，本文的示例性非限制性方法也可以应用于更昂贵的包围构造，例如OBB、包围球和其他包围体技术。

已经细分的包围体(其确实包括场景中的几何形状的至少一部分)可以进一步递归细分-就像从苏斯博士(Dr.Seuss)的《帽子里的猫回来了》(1958)的帽子中出现的一系列越来越小的猫一样。递归细分的数量和配置将取决于要建模的3D对象的复杂性和配置以及其他因素，例如所需的分辨率、对象与视点的距离等。一种示例性的细分方案是所谓的8元(8-ary)细分或“八叉树(octree)”，其中将每个体细分为八个较小的统一大小的体，但是已知许多其他空间层次结构和细分方案，例如二叉树、四元树、k-d树、二进制空间分区(BSP)树和包围体层次结构(BVH)树。参见，例如，USP 9,582,607。

在细分的某个级别(对于BVH的不同部分可以是不同的级别)，BVH构造过程遇到构成被建模的封装对象的几何形状。用树的类比，连续的体细分是树干、分支(branch)、大树枝(bough)和小树枝(twig)，并且几何形状最终在树的最顶端(即叶子)处显现出来。此时，例如本文的非限制性实施例的BVH构建过程在此阶段执行优化，以使用启发式或其他分析技术(在一些实施例中可能包括人工智能和/或神经网络)找出那些相对于它们所包含的几何形状而言拟合性较差的叶节点(图2，206)。

继续该过程，直到包含几何形状的所有包围体被充分细分以为每个包围盒提供合理数量的几何图元为止(图2，210)。使用BVH的实时光线追踪器将通过比较每个图元的顶点的空间xyz坐标与光线的xyz坐标以确定光线图元相交，从而确定光线和该图元定义的曲面是否占据相同的空间。光线图元相交测试可能需要大量计算，因为可能要测试许多三角形。在许多情况下，进一步按体积细分可能会更有效，从而将任何“叶节点”中的图元数量限制为16个或更少。

将包括压缩小树(treelet)的结果压缩树写出到存储器中的数据结构中，以供后续由图形处理硬件/软件在例如包括实时光线追踪的实时图形处理期间使用(图2，212)。

图3A和图3B示出了3D场景的递归细分包围体(图3A)和光线追踪器可以访问并用于硬件加速操作的对应的树数据结构(图3B)。树数据结构可以被存储在存储器中，并且可以基于查询按需检索。

包围体的划分可以在分层树数据结构中表示，其中由父节点包含的大的包围体由树的父节点表示，并且较小的包围体由树的子节点表示。最小包围体表示为树中的叶节点，并标识这些最小包围体中包含的一个或更多个几何图元。

树数据结构包括以层次结构布置的多个节点。树结构的根节点N1对应于包围所有图元O1-O8的包围体N1。根节点N1可以标识包围体N1的顶点和根节点的子节点。

在图3A中，将包围体N1细分为包围体N2和N3。图3B的树结构的子节点N2和N3对应于并表示图3A所示的包围体N2和N3。树数据结构中的子节点N2和N3标识空间中各个包围体N2和N3的顶点。在该特定示例中，包围体N2和N3中的每一个被进一步细分。包围体N2被细分为包含的包围体N4和N5。包围体N3被细分为包含的包围体N6和N7。包围体N7包括两个包围体N8和N9。包围体N8包括三角形O7和O8，并且包围体N9包括叶包围体N10和N11作为其子包围体。叶包围体N10包括图元范围(例如，三角形范围)O10，并且叶包围体N11包括项目范围O9。图3B树结构的各个子节点N4、N5、N6、N8、N10和N11对应于并表示图3A在空间中的包围体N4、N5、N6、N8、N10和N11。

在此特定示例中的图3B树只有三到六层深，因此体N4、N5、N6、N8、N10和N11构成“叶节点”-也就是说，树中没有子节点的节点。图3A示出了叶节点包围体N4、N6和N8各自包含场景中几何形状的两个三角形。例如，体细分N4包含三角形O1和O2；体细分N6包含试验O5和O6；以及体细分N8包含三角形O7和O8。图3A进一步示出了叶节点包围体N5包含单个圆柱体O3，该圆柱体O3不能很好地拟合虚线所示的AABB包围体N5。因此，在本文的示例性非限制性实施例中，不是将较大的AABB包围体N5用于光线包围体相交测试，而是TTU 138针对多个较小的AABB包围体来测试光线，这些AABB包围体被布置、定位、维度和定向以更紧密地配合圆柱体O3。

图3B中所示的树结构通过将这些叶节点N4、N5、N6和N7与场景几何形状的图元O1-O8中的适当叶节点相关联来表示它们。为了访问该场景几何形状，TTU 138遍历图3B的树数据结构到叶节点。通常，树的不同部分可以并且将具有不同的深度，并且包含不同数量的图元。与不包含几何形状的体细分相关联的叶节点无需在树数据结构中明确表示(即，树被“修剪(trim)”)。

根据一些实施例，以N7为根的子树可以表示一组包围体或BVH，其被定义在与对应于节点N1-N3的包围体不同的坐标空间中。当包围体N7与其父包围体N3在不同的坐标空间中时，提供遍历以N7为根的子树所必需的光线转换的实例节点N7’可以将树的其余部分连接到以N7为根的子树。实例节点N7’通过定义从N1-N3的坐标空间(例如，世界空间)到N7等的坐标空间(例如，对象空间)的转换，将对应于节点N1-N3的包围体或BVH与对应于节点N7等的包围体或BVH连接起来。

如上所述构造的加速度结构可以通过在常规通用计算机上运行的基于软件的图形管线处理来有利地使用。然而，当前公开的非限制性实施例在基于硬件的图形处理单元的上下文中有利地实现上述技术，所述基于硬件的图形处理单元包括诸如一个或更多个流式多处理器(“SM”)的高性能处理器和一个或更多个遍历协处理器或“树遍历单元”(“TTU”)-3D图形处理管线的一个或一组流式多处理器SM的子单元。以下描述了诸如包括TTU 138的系统的整体结构和操作，该TTU 138加速了支持交互式光线追踪的某些过程，交互式光线追踪包括光线包围体相交测试、光线图元相交测试以及用于实时光线追踪的光线“实例”转换以及其他应用程序。

示例系统框图

图4示出了示例实时光线交互式追踪图形系统100，该示例实时光线交互式追踪图形系统100使用包括如上所述构造的加速度数据结构的场景或一个或更多个对象的三维(3D)数据来生成图像。

系统100包括输入设备110、一个或更多个处理器120、一个或更多个图形处理单元(GPU)130、存储器140和一个或更多个显示器150。图4所示的系统可以采用任何形式，包括但不限于个人计算机、智能手机或其他智能设备、视频游戏系统、可穿戴虚拟或增强现实系统、基于云的计算系统、车载图形系统、片上系统(SoC)等。

处理器120可以是多核中央处理单元(CPU)，其可操作为对输入设备110进行实时交互响应，以执行应用程序，输入的输出包括要在显示器150上显示的图像。显示器150可以是任何种类的显示器，例如固定显示器、头戴式显示器(例如，显示器眼镜或护目镜)、其他类型的可穿戴显示器、手持显示器、车载显示器等。例如，处理器120可以基于从输入设备110(例如，操纵杆、惯性传感器、环境光传感器等)接收的输入来执行应用程序，并且指示GPU 130生成显示应用程序进度的图像，用于在显示器150上显示。

基于处理器120上应用程序的执行，处理器可以发布指令以供GPU 130使用存储在存储器140中的3D数据生成图像。GPU 130包括专用硬件，其用于实时加速图像生成。例如，由于GPU的执行重复性和高度并行的特殊计算任务(例如，多边形扫描转换)的能力比传统软件驱动的CPU快得多，因此GPU 130能够实时处理数千或数百万个图形图元(多边形)的信息。例如，与处理器120不同，处理器120可能具有多个核心，其中多个核心具有一次可以处理几个软件线程的大量高速缓存存储器，GPU 130可以包括成百上千个正并行运行的处理核心或“流式多处理器”(SM)132。

在一个示例实施例中，GPU 130包括多个可编程高性能处理器(其可以被称为“流式多处理器”(“SM”)132)以及基于硬件的图形管线(其包括图形图元引擎134和光栅引擎136)。GPU 130的这些组件被配置为使用被称为“扫描转换光栅化”的技术执行实时图像渲染，以在二维显示器150上显示三维场景。在光栅化中，将3D场景的几何构造块(例如，点、线、三角形、四边形、网格等)映射到显示器的像素(通常经由帧缓冲存储器)。

GPU 130将3D模型的几何构造块(即，诸如三角形之类的多边形图元)转换为2D图像的像素，并为每个像素指派初始颜色值。图形管线可以通过定义或调整像素的颜色值，将阴影、透明度、纹理和/或颜色效果应用于图像的某些部分。最终像素值可以进行抗锯齿(anti-aliased)、滤波并被提供给显示器150进行显示。多年来，许多软件和硬件的进步已经使用光栅技术以实时图形所需的帧速率(即，每秒30至60帧)在一个或更多个显示器150上以高显示分辨率(例如，4096x 2160像素或更高)来改善主观图像质量。

为了使GPU 130能够以有效的方式实时地进行光线追踪，GPU提供了一个或更多个耦合到一个或更多个SM 132的“TTU”138。TTU 138包括被配置为执行(或加速)在光线追踪算法中常用的操作的硬件组件。TTU 138的目标是将光线追踪中使用的操作加速到一定程度，以使光线追踪的能力应用于实时图形应用程序(例如，游戏)，从而实现高质量的阴影、反射和全局照明。由TTU 138产生的结果可以与在GPU 130中执行的其他与图形有关的操作一起使用或作为其替代。

更具体地，SM 132和TTU 138可以协作以将光线投射到3D模型中，并确定该光线是否以及在何处与模型的几何形状相交。光线追踪直接模拟在虚拟环境或场景中传播的光线。光线相交的结果与表面纹理、观察方向和/或照明条件一起用于确定像素颜色值。由与TTU 138一起工作的SM 132执行的光线追踪允许计算机生成的图像以与真实世界的照片或视频无法区分开的方式捕获阴影、反射和折射。部分地因为需要跟踪大量的光线，因此光线追踪技术比光栅化在计算上更加密集，因此TTU 138能够在硬件中加速该过程中某些计算更加密集的方面。

给定如上所述构造的BVH，TTU 138执行树搜索，其中光线访问的树中的每个节点对于每个后代分支或叶子都有包围体，并且光线只访问与其相交的相应包围体的后代分支或叶子。以这种方式，TTU 138只显式地测试用于相交的少量图元，即驻留在与光线相交的叶节点中的图元。在示例非限制性实施例中，TTU 138加速树遍历(包括光线体测试)和光线图元测试。作为遍历的一部分，它还可以处理至少一级实例变换，将光线从世界空间坐标转换为实例网格的坐标系。在示例性非限制性实施例中，TTU 138以MIMD方式进行所有这些操作，这意味着一旦在TTU内部就独立地处理光线。

在示例性非限制性实施例中，TTU 138作为SM(流式多处理器)132的服务方(协处理器)运行。换句话说，示例性非限制性实施例中的TTU 138并非独立运行，而是遵循SM 132的命令以比SM 132本身执行更有效地执行某些计算密集的光线追踪相关的任务。在其他实施例或体系架构中，TTU 138可以具有更多或更少的自治权。

在所示的示例中，TTU 138经由SM 132指令接收命令，并将结果写回到SM寄存器文件。对于许多常见用例(例如，具有最多一级实例化的不透明三角形)，TTU 138可以为光线追踪查询提供服务，而无需与SM 132进行进一步交互。更复杂的查询(例如，涉及经过阿尔法测试(alpha-tested)的三角形、三角形以外的图元或多级实例)可能需要多次往返(尽管本文中的技术通过为TTU 138提供增强的功能来减少对某些类型的几何形状的这种“往返(round trips)”的需要，从而无需请求呼叫SM的帮助以自动执行光线包围体相交测试)。除了追踪光线，TTU 138还能执行更一般的空间查询，其中AABB或两个AABB之间的挤压体(extruded volume)(我们称为“光束(beam)”)代替了光线。因此，尽管TTU 138特别适于加速与光线追踪相关的任务，但是它也可以用于执行除光线追踪之外的任务。

因此，TTU 138针对宽范围的包围体自主地对每个光线执行测试，并且可以剔除不与该光线相交的任何包围体。从包围场景中所有内容的根节点开始，遍历协处理器针对较小的(可能重叠的)子包围体对每条光线进行测试，这些子包围体又包围了BVH的后代分支。光线跟随光线指向其他节点的包围体的子指针，直到到达BVH的叶或终端节点(体)为止。

一旦TTU 138遍历加速度数据结构以到达与光线相交并包含几何图元的终端或“叶”节点(其可以由一个或更多个边界体表示)，则其执行加速的光线图元相交测试，以确定光线是否与该图元相交(并因此与该图元定义的物体表面相交)。光线图元测试可以提供有关与光线相交的图元的其他信息，这些信息可用于确定阴影和可视化所需的表面的材料属性。通过加速度数据结构的递归遍历使遍历协处理器能够发现与光线相交的所有对象图元，或者发现与光线相交的最接近(从视点角度来看)的图元(在某些情况下，这是沿光线从视点可见的唯一图元)。参见例如Lefrancois等人的NVIDIA Vulkan光线追踪教程，2019年12月，https：//developer.nvidia.com/rtx/raytracing/vkray。

如上所述，TTU 138还加速了从世界空间到对象空间的每条光线的转换，以获得图元越来越细的包围盒封装，并减少了在场景中这些图元的重复。如上所述，在场景中以不同的位置、方位和比例多次复制的对象可以在场景中表示为实例节点，这些实例节点将世界空间BVH中的包围盒和叶节点与可以应用于世界空间光线的变换相关联将其转换为对象坐标空间，以及指向对象空间BVH的指针。这避免了在世界空间中多次复制对象空间BVH数据，从而节省了存储器和相关联的存储器访问。实例变换通过将光线转换为对象空间而不是要求将几何形状或包围体层次结构转换为世界(光线)空间来提高效率，并且其还与图形处理执行以可视化图元的其他常规光栅化过程兼容。

示例光线追踪过程

图5示出了可以由SM 132执行并且由TTU 138加速的示例性光线追踪阴影管线500。光线追踪阴影管线500由SM 132调用光线生成510并且向TTU 138发出相应的光线追踪请求来开始。光线追踪请求标识投射到场景中的单条光线，并要求TTU 138搜索具有SM 132也指定的加速度数据结构的相交。TTU 138遍历(图5的框520)加速度数据结构以确定光线与体细分以及加速度数据结构所表示的相关联的三角形之间的相交或潜在相交。潜在相交可以通过在加速数据结构中找到与光线相交的包围体来识别。不需要检查非相交的包围体的后代。

对于相交的包围体内的三角形，TTU 138光线图元测试块720执行相交530过程以确定光线是否与图元相交。

SM 132可以例如指示TTU 138仅报告光线与指定几何形状的“最接近命中”相交，或者它可以指示TTU 138还报告光线与指定几何形状的“任何命中”相交，而不考虑顺序。在后一种情况下，中间遍历(mid-traversal)TTU 138可以将相交信息返回给SM 132，SM 132可以响应于确定是否已经发生实际相交而执行“任何命中”着色操作540。例如，SM 132可以执行(或让其他硬件执行)相交的图元的纹理查找，并基于适当的纹理像素值确定是发生了实际命中还是半透明材料的不透明度，并且可以在TTU 138上完成遍历或恢复遍历(如果光线以非空堆栈返回)作为“任何命中”阴影值的函数。由于TTU 138可以按任意顺序返回场景中具有不同几何形状的多个相交点，并且必须按顺序合成半透明材料，因此SM 132可以选择性地跟踪此类结果。

当遍历完成时，TTU 138将查询结果返回给SM 132。对于与图元相交的光线，TTU138返回关于相交的图元的信息，例如，在相交的三角形的情况下，SM 132可以用三角形_id和重心坐标来识别和调用“最接近命中”着色功能570。对于没有与图元相交的光线，SM 132返回标识符，该标识符指示什么都没有命中，因此SM 132可以执行调用先前指定的未命中着色器560的“未命中”着色操作。

图6是概述了如上所述的TTU 138与一个或更多个SM 132协同执行的示例光线追踪操作的流程图。图6操作由TTU 138协同其与SM 132的交互来执行。TTU 138可因此从SM132接收光线的标识并且遍历状态，该遍历状态枚举该光线必须遍历的一个或更多个BVH中的一个或更多个节点。TTU 138确定光线与BVH数据结构的哪个包围体相交(“光线压缩树(ray-complet)”测试612)。TTU 138随后还可以确定光线是否与相交的包围体中的一个或更多个图元相交以及哪些三角形是相交的(“光线图元测试”620)-或如果TTU自身执行起来很复杂，SM 132可以在软件中执行此测试。在示例性非限制性实施例中，压缩树指定包围体层次结构的根或内部节点(即，体)，其具有作为其他压缩树的子级或每个压缩树的单一类型的叶节点。

首先，TTU 138检查光线的遍历状态。如果TTU 138为光线保持的堆栈是空的，则遍历完成。如果在堆栈的顶部有条目，则遍历协处理器138向存储器子系统发出请求以检索该节点。然后，遍历协处理器138执行包围盒测试612以确定BVH数据结构的包围体是否与SM132指定的特定光线相交(步骤612、614)。如果包围盒测试确定包围体未与光线相交(步骤614中为“否”)，则无需执行任何进一步的可视化测试，并且TTU 138可以将此结果返回给请求SM 132。这是因为，如果光线未命中包围体(如关于包围体10的图1A中所示)，则光线将未命中被测试的包围体内的所有其他较小的包围体以及包围体包含的所有图元。

如果由TTU 138执行的包围盒测试揭示了包围体与光线相交(步骤614中为“是”)，则TTU确定是否可以将包围体细分为较小的包围体(步骤618)。在一个示例实施例中，TTU138本身不一定执行任何细分。而是，BVH中的每个节点都有一个或更多个子代(其中每个子代是BVH中的叶或分支)。对于每个子代，都有一个或更多个包围盒和指向分支或叶节点的指针。当光线使用TTU 138处理节点时，它正在针对该节点的子代的包围体进行自我测试。光线只将命中代表性包围体的那些分支或叶的堆栈条目推入其堆栈。在示例实施例中，当光线提取节点时，它不会针对该节点的包围体进行测试-而是针对该节点的子代的包围体进行测试。TTU 138将其包围体被光线命中的节点按光线配置确定的顺序推入到光线的遍历堆栈上。例如，可以按节点在存储器中出现的顺序或它们沿着光线的长度出现的顺序或某些其他顺序，将节点推入到遍历堆栈上。如果存在包围体的进一步细分(步骤618中为“是”)，则访问包围体的那些进一步细分，并对结果细分包围体中的每一个执行包围盒测试，以确定哪些细分包围体是与光线相交而哪些不与光线相交。在该递归过程中，一些包围体可以通过测试614消除，而其他包围体可以导致通过TTU 138递归地应用步骤612-618来测试进一步和进一步的细分的相交。

一旦TTU 138确定与光线相交的包围体是叶节点(步骤518中为“否”)，则TTU 138和/或SM 132执行图元(例如，三角形)相交测试620以确定光线是否与相交的包围体中的图元相交，并且光线与哪些图元相交。因此，TTU 138执行相交的后代分支节点的深度优先遍历，直到到达叶节点为止。TTU 138处理叶节点。如果叶节点是图元范围，则TTU 138或SM132将相对于光线对它们进行测试。如果叶节点是实例节点，则TTU 138或SM 132应用实例转换。如果叶节点是项目范围，则TTU 138将它们返回给请求SM 132。在示例性非限制性实施例中，SM 132可以命令TTU 138执行不同种类的光线图元相交测试并根据来自应用程序(或运行该应用程序的软件堆栈)的操作来报告不同的结果并由SM中继到TTU。例如，SM 132可以命令TTU 138报告相交测试揭示的最近的可见图元，或者报告与光线相交的所有图元而不管它们是否是最近的可见图元。SM 132可以将这些不同的结果用于不同种类的可视化。或者，一旦TTU 138报告了光线压缩树测试结果，SM 132即可自行执行光线图元相交测试。一旦TTU 138处理完叶节点以后，可能会有其他分支节点(较早推入到光线的堆栈上)进行测试。

示例非限制性TTU 138硬件实现

图7示出了TTU 138的示例简化框图，该TTU 138包括被配置为执行如上所述的加速遍历操作的硬件。在一些实施例中，TTU 138可以使用具有支持的叶节点图元的相交测试的短堆栈遍历以及阿尔法(alpha)图元和不被支持的叶节点图元(条目)的中间遍历返回，来执行包围体层次结构的深度优先遍历。TTU 138包括确定光线是否与包围体相交的专用硬件，以及确定光线是否与树数据结构的图元相交的专用硬件。

TTU 138可以包括在SM 132和TTU执行单元之间的接口160。接口160通过调度接收到的查询并返回查询结果，使得SM 132能够有效地且鲁棒地在TTU 138上运行加速度结构遍历，从而有效地向TTU 138中的执行单元提供用于处理的数据。在一些示例中，可以在TTU138的外部提供接口160或接口160的一个或更多个组件。

更详细地，TTU 138包括相交管理块722、光线管理块730和堆栈管理块740。这些块中的每一个(以及图7中的所有其他块)可以构成由逻辑门、寄存器、硬件嵌入式查找表或其他组合逻辑等实现的专用硬件。

光线管理块730负责管理关于由SM 132向光线管理块指定的光线的信息并执行关于由SM 132向光线管理块指定的光线的操作。堆栈管理块740与遍历逻辑712一起工作以管理关于BVH加速度数据结构的遍历的信息并执行关于BVH加速度数据结构的遍历的操作。遍历逻辑712由光线压缩树测试块710的结果指导，该光线压缩树测试块710使用需要的实例转换来测试由光线管理块730指示的光线与由BVH表示的体细分之间的相交点。光线压缩树测试块710经由作为TTU 138的一部分的L0压缩树高速缓存752从存储器140检索关于BVH的附加信息。光线压缩树测试块710的结果通知遍历逻辑712是否需要进一步递归遍历。堆栈管理块740维护堆栈以在遍历逻辑712从BVH的一个层级遍历到另一层级时跟踪状态信息，其中当遍历逻辑遍历至BVH的较深处时，堆栈管理块740将条目推入到堆栈，当遍历逻辑在BVH中向上遍历时，堆栈管理块740将所有条目从堆栈中弹出。堆栈管理块740能够在SM请求的任何时间向请求SM 132提供状态信息(例如，中间或最终结果)。

相交管理块722使用需要的实例转换来管理关于光线和图元之间的相交点的信息并执行关于光线和图元之间的相交点的操作。光线图元测试块720根据需要经由作为TTU138的一部分的L0图元高速缓存754从存储器140中检索关于几何形状的信息。通过光线图元测试以及转换块720执行的相交测试结果通知相交管理块722。因此，光线图元测试和转换块720将相交结果提供给相交管理块722，相交管理块722向请求SM 132报告几何形状命中和相交。

堆栈管理单元740检查遍历状态以确定需要检索什么类型的数据以及哪个数据路径(压缩树或图元)将消耗它。在包括一个或更多个光线压缩树测试块710和一个或更多个遍历逻辑块712的TTU 138的光线压缩树测试路径中确定包围体的相交点。压缩树指定包围体的根节点或内部节点。因此，压缩树可以为光线压缩树测试定义一个或更多个包围体。在本文的示例实施例中，压缩树可以定义多个“子代”包围体(无论它们是否表示叶节点)，它们不一定各自具有后代，但是TTU将并行测试这些后代的光线包围体相交，以确定与多个包围体相关联的几何图元是否需要测试相交。

TTU 138的光线压缩树测试路径标识光线与哪些包围体相交。与光线相交的包围体需要被进一步处理，以确定与相交的包围体相关联的图元是否相交。在包括一个或更多个光线图元测试和转换块720以及一个或更多个相交管理块722的光线图元测试路径中确定图元的相交。

TTU 138从一个或更多个SM 132接收查询以执行树遍历操作。该查询可以请求光线是否与BVH数据结构中的包围体和/或图元相交。该查询可以标识光线(例如，光线的原点、方向和长度)以及BVH数据结构以及遍历状态(短堆栈)，其包括引用了光线要访问的一个或更多个包围体层次结构中的节点的一个或更多个条目。该查询还可以包括关于在遍历期间光线如何处理特定类型的相交的信息。可以将光线信息存储在光线管理块730中。可以基于光线图元测试的结果来更新存储的光线信息(例如，光线长度)。

TTU 138可以请求从TTU 138外部的存储器中检索在查询中标识的BVH数据结构。BVH数据结构的检索的部分可以被高速缓存在TTU 138内的零级(L0)高速缓存750中。因此该信息可用于其他时间相关的TTU操作，从而减少了存储器140的访问。光线压缩树测试所需的BVH数据结构的部分可被存储在L0压缩树高速缓存752中，并且光线图元测试所需的BVH数据结构的部分可被存储在L0图元高速缓存754中。

在压缩树高速缓存752中提供了请求的遍历步骤所需的压缩树信息之后，光线压缩树测试块710确定与光线相交的包围体。在执行此测试时，可以将光线从包围体层次结构的坐标空间转换为相对于压缩树而定义的坐标空间。针对与压缩树的子节点相关联的包围盒测试光线。在示例非限制性实施例中，未针对压缩树自身的包围盒测试光线，因为(1)TTU138先前在测试引用了此压缩树的父包围盒子代时针对类似的包围盒测试了光线，并且(2)压缩树包围盒的目的是定义子包围盒可以在其中以压缩形式表示的局部坐标系。如果光线与任何子包围盒相交，则将结果推入遍历逻辑，以确定将相应的子指针推入遍历堆栈的顺序(进一步的测试可能需要遍历逻辑712向下遍历到BVH的下一层级)。递归重复这些步骤直到遇到BVH的相交的叶节点为止

光线压缩树测试块710可以向遍历逻辑712提供光线压缩树相交。使用光线压缩树测试的结果，遍历逻辑712创建要被推入到堆栈管理块740的堆栈条目。堆栈条目可以指示需要由光线压缩树测试块710进一步测试的光线相交的内部节点(即，包括一个或更多个子节点的节点)和/或需要由光线图元测试和转换模块720测试的光线相交的在相交的叶节点中标识的三角形。光线压缩树测试块710可以在堆栈中标识的内部节点上重复遍历，以确定与光线相交的BVH中的所有叶节点。在示例非限制性实施例中，光线压缩树测试块710执行的精确测试将由模式位(mode bits)、光线操作(参见下文)和命中剔除来确定，并且TTU138可以将中间以及最终结果返回至SM 132。

光线图元相交测试

再次参考图7，TTU 138还具有加速相交测试的能力，以确定光线是否与特定几何形状或图元相交。对于某些情况，几何形状足够复杂(例如，由曲线或其他抽象构造所定义，而不是由例如顶点所定义)，以致在某些实施例中，TTU 138可能无法帮助进行光线图元相交测试。在这种情况下，TTU 138简单地将光线压缩树相交测试结果报告给SM 132，并且SM132自身执行光线图元相交测试。在其他情况下(例如，三角形)，TTU 138自身可以执行光线三角形相交测试，从而进一步提高了整个光线追踪过程的性能。为了完整起见，下面描述TTU 138如何执行或加速光线图元相交测试。

如上所述，被发现与光线相交的叶节点标识(包围)可能与光线相交或可能不与光线相交的图元。TTU 138的一种选择是向SM 132提供在相交的叶节点中识别出的例如一系列几何形状以进行进一步处理。例如，SM 132自身可以基于TTU 138提供作为TTU遍历BVH的结果的信息，来确定标识的图元是否与光线相交。为了从SM 132卸载该处理并从而使用TTU138的硬件来加速它，堆栈管理块740可以发出对光线图元和转换块720的请求，以对TTU的光线压缩树测试块710标识的相交的叶节点内的图元执行光线图元测试。在一些实施例中，SM 132可以发出对光线图元测试的请求以测试特定范围的图元和转换块720，而与如何标识该几何形状范围无关。

在确保请求的光线图元测试所需的图元数据在图元高速缓存754中可用之后，光线图元和转换块720可使用存储在光线管理块730中的光线信息确定与光线相交的图元。光线图元测试块720将确定要与光线相交的图元的标识提供给相交管理块722。

相交管理块722可以将光线图元测试的结果返回给SM 132。光线图元测试的结果可以包括相交的图元的标识符、与光线原点的相交点的距离以及与相交的图元基元的属性相关的其他信息。在一些实施例中，相交管理块722可以基于来自光线图元和转换块720的先前的相交结果来修改现有的光线图元测试(例如，通过修改光线的长度)。

相交管理块722还可以跟踪不同类型的图元。例如，不同类型的三角形包括在相交时将阻挡光线的不透明三角形，以及在相交时可能会或可能不会阻挡光线或可能需要SM进行其他处理的阿尔法(alpha)三角形。光线是否被透明三角形阻挡可能例如取决于映射到三角形上的一个或更多个纹理、纹理所占据的三角形区域以及纹理修改三角形的方式。例如，在一些实施例中，透明度(例如，彩色玻璃)要求SM 132跟踪透明对象命中，以便可以按照光线参数顺序对其进行分类和着色，并且通常不会实际阻挡光线。同时，阿尔法“修剪”允许基于映射到图元上的纹理的形状来修剪图元的形状-例如，将从三角形剪出叶形。(请注意，在光栅图形中，透明度通常被称为“阿尔法混合”，而修剪则被称为“阿尔法测试”)。在其他实施例中，TTU 138可以将透明命中推入到存储器中的队列以供SM 132稍后处理，并且可以通过向纹理单元发送请求来直接处理修剪后的三角形。每个三角形可包括指示符，以指示三角形的类型。相交管理块722被配置为维持用于跟踪不同类型的相交的三角形的结果队列。例如，结果队列可以在一个队列中存储一个或更多个相交的不透明三角形标识符，并在另一队列中存储一个或更多个透明三角形标识符。

对于不透明三角形，可以在TTU 138中完全确定不太复杂的几何形状的光线相交，因为不透明三角形的区域阻挡了光线穿过三角形的表面。对于透明三角形，在某些实施例中无法在TTU 138中完全确定光线相交，因为TTU 138基于三角形的几何形状执行相交测试，并且可能无法访问三角形的纹理和/或纹理所占据三角形区域(在其他实施例中，可以通过图形管线的纹理映射块向TTU提供纹理信息)。为了完全确定三角形是否相交，可以将关光线图元和转换块720确定的相交的透明三角形的信息发送到SM 132，以使SM完全确定该三角形是否影响沿光线的可见性。

SM 132可以确定光线是否与关联于透明三角形的纹理相交和/或光线是否将被该纹理阻挡。在一些情况下，SM 132可以基于该确定将修改的查询发送到TTU 138(例如，如果光线被纹理阻挡则缩短光线)。在一个实施例中，TTU 138可以被配置为将确定为与光线相交的所有三角形返回给SM 132以进行进一步处理。因为就接口和线程同步而言，将每个三角形相交点返回到SM 132以进行进一步处理是昂贵的，所以TTU 138可被配置为隐藏相交的但可证明能够被隐藏而对结果场景没有功能影响的三角形。例如，因为向TTU 138提供了三角形类型信息(例如，三角形是不透明还是透明)，所以TTU 138可以使用三角形类型信息来确定沿着光线被另一个相交的不透明三角形遮挡的相交的三角形，并且因此不需要将其包含在结果中，因为它们不会影响沿光线的可见性。如果TTU 138知道三角形被不透明三角形沿光线遮挡，则可以从结果中隐藏遮挡的三角形，而不会影响结果场景的可视化。

相交管理块722可以包括结果队列，该结果队列用于存储与三角形ID以及与光线命中三角形的点有关的信息相关联的命中。当确定光线与不透明三角形相交时，可以将三角形的标识和相交点到光线原点的距离存储在结果队列中。如果确定光线与另一个不透明三角形相交，则如果相交点到光线原点的距离大于已存储在结果队列中的相交的不透明三角形的距离，则可以从结果中省略另一个相交的不透明三角形。如果相交点到光线原点的距离小于已存储在结果队列中的相交不透明三角形的距离，则另一个相交的不透明三角形可以替换结果队列中存储的不透明三角形。在测试了所有查询的三角形之后，可以将存储在结果队列中的不透明三角形信息和相交信息发送到SM 132。

在一些实施例中，一旦标识出不透明三角形相交，则相交管理块722可以缩短存储在光线管理块730中的光线，以使得在相交的不透明三角形(沿着光线)之后的包围体(其可以包括三角形)将不会被标识为与光线相交。

相交管理块722可以将关于相交的透明三角形的信息存储在单独的队列中。关于相交的透明三角形的存储的信息可以被发送到SM 132，以用于SM来确定光线是否与关联于三角形的纹理相交和/或该纹理是否阻挡光线。SM可以基于确定将确定的结果返回给TTU138和/或修改查询(例如，如果该光线被纹理阻挡，则缩短该光线)。

如上所述，TTU 138允许快速遍历加速度数据结构(例如，BVH)，以确定数据结构中的哪些图元(例如，用于生成场景的三角形)与查询数据结构(例如，光线)相交。例如，TTU138可以确定加速度数据结构中的哪些三角形与光线相交并将结果返回给SM 132。但是，就接口和线程同步而言，将每个三角形相交点的结果返回给SM 132的成本很高。TTU 138提供硬件逻辑，该硬件逻辑被配置为隐藏那些被证明能够被隐藏而对结果场景没有功能影响的项目或三角形。结果返回给SM的减少和线程之间的同步步骤大大提高了遍历的整体性能。在本申请中公开的TTU 138的示例非限制性实施例提供了在没有SM 132干预的情况下在TTU 138内丢弃某些相交点，使得更少的相交点被返回到SM 132并且SM 132不必检查所有相交的三角形或项目范围。

TTU资源的早期释放

如上所述，TTU 138处理由SM 132发出的光线可见性查询。TTU 138代表线程束执行光线可见性查询。每个线程束包括一组线程(例如，线程束中的32个线程)，每个线程都可以启动独立的光线查询。在TTU 138中，向线程束指派票证，并且为每个线程分配TTU 138上的资源。TTU 138资源可以包括用于存储中间和/或最终测试结果的执行槽(被称为光线槽(ray slots)，其可以是存储器或寄存器)。光线槽可以包括分布在TTU 138的不同处理单元上的组件。TTU 138可以以任何顺序自由地在分配的资源上进行操作。将结果返回到SM 132进行票证同步。

出现的性能问题是，光线查询的复杂度差异很大，有些光线查询很短，而另一些光线查询要花更长的时间才能完成。例如，一个光线查询可能需要更长的时间才能完成，因为查询所需的数据需要从TTU 138外部的存储器中检索，而另一个查询所需的数据位于TTU138的零级(L0)高速缓存750中。在另一个示例中，每个查询中需要测试和检索的图元数量可能不同。在其他示例中，为光线设置的定义应返回哪些测试结果的参数将影响查询完成所需的时间。

由于票证的结果按组返回，因此票证内的任何短遍历都必须等待最长的遍历完成。在等待期间，这些光线正在消耗TTU 138存储资源(例如，光线槽)，这些存储资源随后不用于主动遍历。如果增加光线槽的数量，则可以提高性能，但是光线槽在TTU 138中是昂贵的资源，因为它们占据了芯片上的面积。因此，需要在有效利用可用的光线槽的同时使TTU中的光线槽的数量最小化。

早的光线返回允许在整个线程束准备返回之前返回光线结果，同时释放TTU 138中的光线槽。在标题为“健壮、高效的多处理器协处理器接口”的共同未决的美国申请号16/101,247中描述了提供早的光线返回的处理器和协处理器系统的示例，该申请的全部内容通过引用合并于此。图8A和图8B示出了从TTU 138(协处理器)输出16个线程组的线程的结果，这些线程是针对整个组返回的，并以4个线程为一组返回到SM寄存器，从而当针对每个线程的光线相交测试完成时，释放在TTU 138上为线程组中的相应线程保留的各个执行时隙。如图8A所示，当整个16个线程的组同时将结果写入多处理器寄存器时，由16个线程中的每个线程使用的TTU资源(例如，光线槽)仍被占用，并且多处理器中的所有寄存器文件，即使分配，也保持空闲状态。相反，图8B所示，允许16个线程的组以4个线程的组的形式将结果返回到SM寄存器。当线程的每个子组完成对TTU 138的处理时，结果的时间错开返回，提高了SM 132中已分配的寄存器的利用率，同时当线程的各个子组完成其各自对TTU 138的使用时，可以更快地释放宝贵的TTU 138资源。早的光线返回的粒度是可编程的。早的TTU资源释放允许由其他查询更早地使用光线槽，从而提高了TTU 138的整体利用率。

然而，结果的每次返回都消耗整个线程束的寄存器文件(RF)带宽。这意味着要在释放TTU 138中的光线槽和消耗RF带宽之间进行权衡，以防止两者成为瓶颈。平衡所在的位置会有所不同(例如，针对发出的特定查询)，但在某些示例中，通常会采用较大的粒度，例如16个(完整线程束的一半)或8个(完整线程束的四分之一)。不可能一直处于单线程极端状态。即使在8个或16个较小的组中，遍历长度仍然存在差异，这可能导致较短的光线消耗比所需时间更长的光线槽资源。

本公开的示例提供了在等待其他查询完成的同时进一步释放TTU 138中的执行资源的系统和方法。在一些示例中，本公开可以进一步释放TTU 138中的执行资源，而无需进一步减小早的光线返回的粒度。因此，在一些示例中，可以维持或增加早的光线返回的粒度(例如，16个(完全线程束的一半)或8个(完全线程束的四分之一)的粒度)以限制消耗RF带宽。本公开的示例提供SM 132和TTU 138之间的接口，该接口被配置为释放TTU 132中的执行资源，从而允许SM 132和TTU 138处理大量光线的相交测试。该接口提供以压缩格式存储至少一些查询结果，并在报告查询结果时基于压缩数据生成查询结果。

示例多处理器/TTU接口

图9示出了系统900，该系统900包括SM 132和TTU 138之间的接口160。在一些示例中，SM 132可以是另一个处理器，而TTU 138可以是另一个协处理器。尽管接口160被示为是TTU 138的一部分，但是在一些示例中，可以在TTU 138的外部提供接口160或接口160的一个或更多个组件。

SM 132和TTU 138可以经由接口160通信，并且两者都可以访问共享存储器140。共享存储器140尽管被示为位于SM 132和TTU 138的外部，但是不限于此。在一些实施例中，共享存储器140可以是高速缓存存储器(例如，诸如TTU 138的L0/L1高速缓存)或TTU 138仅对其具有读访问权的其他存储器。共享存储器140可以包括用于在SM 132和TTU 138之间交换数据的存储器位置。

SM 132被配置为同时执行多个线程，并且可以进一步被配置为命令TTU 138执行一个或更多个TTU操作，以加速对被调度为并发执行的多个线程中的一个或一组的处理。SM132可以发出线程束以用于针对场景的光线的可见性测试。线程束的每个线程可以包括不同的光线相交查询。

当TTU 138接收到线程束请求时，接口160中的调度器确定资源是否可用于处理线程束中的线程查询。处理查询所需的资源包括用于存储光线信息以及中间和/或最终测试结果的光线槽(存储器或寄存器)。如果线程束包括32个线程，每个线程包括光线相交查询，则TTU 138将需要分配32个光线槽。调度器160发出线程束的票证，并且在光线槽变得可用于包括查询的每个线程之后开始查询。如果光线槽不可用，则TTU 138等待直到其他查询完成并且光线槽可用于线程束为止。

在TTU 138针对线程束中的每个查询均获得相交测试结果之后，将测试结果返回到SM 132中的寄存器文件中。如上所述，因为某些查询可能需要更长的时间才能完成，接口160可以被配置为在整个线程束准备返回之前返回早的光线相交结果。较早返回光线相交结果会释放TTU 138中的光线槽，以便较早(即，在完成整个线程束之前)供其他线程束使用，但会在部分返回期间消耗整个线程束的RF带宽。随着光线相交结果的早返回，线程束的票证继续进行，直到对票证的所有查询都完成了为止。当有足够的光线槽可用于下一个线程束时，调度器将为下一个线程束中的查询发出另一张票证。

当目标操作(例如，完全线程束或部分线程束)完成其结果输出并将结果写入分配给线程束的SM寄存器时，记分板用于通知SM 132。记分板跟踪返回的结果，并在其他指令可以安全使用返回的结果时向SM 132指示。在标题为“健壮、高效的多处理器协处理器接口”的共同未决的美国专利申请号16/101,247中描述了利用记分板来跟踪返回结果的示例，该申请的全部内容通过引用合并于此。

本公开的实施例提供了较早释放光线槽的技术(例如，在将其他结果报告给SM132之前)，以便一旦下一个票据的光线槽可用，就可以开始其他票据和查询。用于释放光线槽的示例实施例允许TTU 138最大化在TTU 138中正在进行的查询的数量。

返回到SM 132的结果中的信息取决于查询中请求的信息(例如，描述查询细节的各种光线标记)。查询设置的一部分是确定需要返回哪些信息。返回的结果可以包括命中信息、指向被命中的任何对象的指针、有关在其下被命中的实例的信息、其他光线信息以及遍历堆栈，以便在需要时继续遍历。

通常，到SM 132的返回涉及从相交管理单元722、光线管理单元730和/或堆栈管理单元740中的RAM中读取数据，以填充返回数据的字段。尽管在图9中示出了单个相交管理单元722、光线管理单元730和堆栈管理单元740，但是本公开的示例不限于此，并且可以包括这些单元中的一个或更多个中的多个。因此，到SM 132的返回可以包括从单个或多个相交管理单元、光线管理单元和/或堆栈管理单元读取结果。

图9示出了相交管理单元722、光线管理单元730和堆栈管理单元740，其包括与各个处理单元相关联的光线槽。在一些示例中，每个处理单元可以具有可以分配给查询的其自己的专用存储器。在其他示例中，可以分割相同的存储器以将相应的光线槽提供给每个处理单元。在一些示例中，可以在公共高速缓存中提供光线槽。

在处理完查询之后，接口160被配置为接收测试结果的信息(例如，命中信息、指向被命中的任何对象的指针、有关在其下被命中的实例的信息、其他光线信息以及遍历堆栈，以便在需要时继续遍历)以从TTU 138中的不同位置，并将信息提供给SM 132。在将结果返回给SM 132时，将从TTU 138中的不同位置接收信息。例如，用于测试结果的信息可以被存储在相交口管理单元722、光线管理单元730和/或堆栈管理单元740中。在将信息返回给SM132之前，将信息存储TTU 138中的不同位置。如上所述，基于相同线程束的其他查询(例如，对预定数量的线程的查询)的完成，返回测试结果数据。

图10A-图10D示出了可以被返回到SM 132的数据的示例。命中数据(下面参考图12A-图12H进行更详细的讨论)可以是从相交管理单元722、堆栈管理单元740返回的或由接口160生成的数据。命中三角形参数和命中实例数据(图10A所示)从相交管理单元722返回。堆栈数据(图10B所示)从堆栈管理单元740返回。转换的光线数据(图10C中所示)和trifetch(三角形取回)0-2数据(图10D中所示)从光线管理单元730返回。指示查询位于获取三角形的遍历中的何处的trifetch 3数据(图10D中所示)从堆栈管理单元740返回。

存储在TTU 138的不同单元中的结果数据将占用每个相应单元中的存储器，直到该数据被返回到SM132。在一个示例中，光线管理单元730、堆栈管理单元740和相交管理单元722中的每一个可以具有为每个查询分配不同的预定数目的比特。

早期资源释放而不向SM报告

本公开的示例通过存储结果的压缩版本(例如，在接口160中)，提供了在将数据返回给SM 132之前释放在TTU 138的不同单元中分配的光线槽直到结果被返回给SM132。当数据被返回给SM 132时，接口160基于压缩的信息生成结果。在要返回的数据指示特定结果的情况下，这是可能的。下面讨论何时可以释放TTU 138中的资源而不将结果返回给SM 132的示例。

在否定查询的情况下，确定没有任何东西与光线相交，所有信息的返回值都是先验已知的。例如，当确定光线不与查询中的任何东西相交时，命中信息、指向被命中的任何对象的指针、有关在其下被命中实例的信息以及其他光线信息都是已知的。这意味着当光线既返回未命中又被终止时，为该光线存储在TTU 138上的位置中并被读取以形成返回分组的值(图10A-图10D中所示的数据)是确定的。术语“已终止”在这里表示不再对该光线采取任何操作，这由空的遍历堆栈表示。

当查询中没有任何东西与光线相交时，接口160可以存储指示查询未命中的信息(其可以由单个位指示)，并且可以释放TTU 138上用于查询的分配的资源供其他票证和查询使用。当结果返回给SM 132时，接口160基于接口160中指示查询未命中的信息来生成已经从TTU 138上的资源中读取的数据。因为SM 132期望SM中的寄存器被结果数据填充，所以该信息需要被生成并被返回给SM 132。

早期光线释放机制从根本上讲是一种压缩方案，其中在某些特定情况下，所有光线存储都被压缩到单个位。可以将每个线程的那个单个位存储在票证中，以指示在返回结果之前是否释放了光线槽。将返回未命中并终止的任何光线槽将立即释放，并且将为票证中的该线程设置该位。后来，当返回该票证的结果时，将重建适当的值。重建可以由接口160执行。未压缩的存储消耗可能在光线管理单元730、堆栈管理单元740和相交管理单元722中消耗超过1000位。这给出的压缩比大于1000：1。

在早期光线槽释放的情况下，接口160将不会从RMU、IMU或SMU中读取。相反，它会为每个请求的返回本身生成正确的值。在一些示例中，生成的数据可以是由接口160预先存储的数据，和/或接口160中的逻辑可以基于结果的压缩版本来生成数据。

用于释放TTU资源而不将结果返回给SM 132的特征不仅被隔离以错过查询，而且可以在返回值是先验已知时使用。这些情况中的某些情况取决于查询参数，例如光线的光线标记或模式标记。

作为示例，一些可见性测试仅关心是否有东西被击中，而不是具体击中了什么。这些类型的查询可以被称为任何命中光线。一个示例应用程序是阴影光线，它可以测试空间中的点是处于特定光源的阴影中还是在光中。在该测试中，查询不是试图标识最接近的相交的图元，而是是否存在至少一个图元相交，而不考虑相交位置(例如，相交的参数长度)或确定什么图元与光线相交。

这些类型的返回还可以具有先验已知的返回值。在一个可能的实现中，TerminateOnAnyHit(终止任意命中)标记可能会控制此行为，但是它仍然返回导致终止的命中的任何三角形。尽管该命中不一定是最接近的三角形，但在某些算法中它仍可用作近似值。

在不需要击中哪个三角形的情况下，本公开的示例添加了新的光线标记位“tu”，其允许相同的终止任何命中(terminate-on-any-hit)行为，但不返回击中的任何东西。图11示出了可以由SM 132为线程提供的光线信息的示例。光线信息可以包括如何执行遍历以及如何处理命中信息。光线信息可以包括“t”位以终止任何命中，并且“tu”位终止任何命中行为但不返回任何命中。当光线标记位“tu”被设置时，当在测试了查询中标识的每个图元之后确定无命中(no hit)时或者当标识第一命中时，查询可以终止。这些结果中的任何一个的返回数据都是先验已知的，并且可以在结果被返回到SM132时由接口160生成。因此，当设置了光线标记位“tu”时，在测试了查询中的每个图元之后确定无命中或者标识了第一命中时，则将释放为查询分配的资源。可以在票证中存储另一位，以指示早期光线释放阴影命中与早期光先释放未命中。

用于不同命中类型的数据结构

图12A-图12H示出了命中类型数据的示例，其可以基于指示查询结果的压缩数据(例如，任何类型的无命中或命中)从IMU 722检索或由接口160生成。可以将命中类型数据作为图10所示的“命中”数据的一部分来提供。当将线程束结果返回到SM 132时，将命中类型数据提供给SM 132。在一些示例中，图12A-图12H中所示的每个数据块的尺寸可以相同。

图12A示出了可以由IMU 722提供以指示命中并提供相交信息的数据的示例。该信息包括三角形id、相交信息(例如，参数长度和/或相交的重心坐标)、三角形是正面还是背面，以及三角形是不透明三角形还是阿尔法三角形。

图12B示出了可以由接口160生成以指示命中但未提供有关命中的细节的数据的示例。可以为阴影命中查询生成该数据结构。当数据返回到SM 132时，包括HitTrianglePtr和HitInstance在内的所有其他字段可以被零填充。

图12C示出了可以由IMU 722提供以指示节点命中的数据的示例。

图12D示出了可以由IMU 722提供以指示三角形范围命中的数据的示例。

图12E示出了可以由IMU 722提供以指示条目范围命中的数据的示例。

图12F示出了可以由IMU 722提供以指示实例节点命中的数据的示例。

图12G示出了可以由IMU 722提供以指示执行光线相交测试中的错误的数据的示例。

图12H示出了可以由接口160生成以指示未命中的数据的示例。在一个示例中，图12H中的命中类型可以被提供1111，使得针对“命中类型无”返回的所有数据都是一个。在另一示例中，图12H中所示的用于“命中类型无”的所有数据可以用零而不是1来填充。当数据被返回到SM 132时，所有其他字段可以被零填充。

如图12A-图12H所示，每个不同的命中类型包括指示正在被返回的命中类型的类型指示符。命中类型可以由一个或更多个位指示。在一个示例中，可以为图12A-图12H所示的多个不同命中类型的类型指示符分配相同数量的位。当SM 132接收到每个线程的查询结果时，命中类型信息可以用于确定如何使用返回的数据以及可以忽略查询的返回数据的哪一部分。

部分TTU资源释放(deallocation)

示例实施例将TTU 138中的光线槽分解为独立分配和释放的单独组件。

如上所述，查询结果可以被存储在TTU 138中的不同位置。在图9中，查询结果可以被存储在IMU 722、RMU 730和/或SMU 740中。在上述示例中，当存储在IMU 722、RMU 730和SMU 740中的查询结果被释放并以压缩格式存储(例如，用于报告未命中的查询)在接口160中时，相关联的光线槽的每个单独组件被释放，以便其他票证和查询可以使用光线槽。在下面讨论的示例中，仅释放光线槽的一部分(例如，一个或更多个)组件，而一个或更多个其他组件继续存储光线测试结果，直到查询结果被返回到SM 132为止。在本示例中，将结果的一部分以压缩格式存储在接口160中，并将结果的一部分存储在光线槽的组件中(无压缩)，直到将结果返回到SM 132为止。

例如，对于终止遍历的光线，没有实际的遍历堆栈内容要返回，因此可以释放光线槽的SMU 740部分。在释放SMU 740中的光线槽的组件的同时，可以保持IMU 722和RMU 730中的光线槽的组件，直到查询结果被返回到SM 132为止。当查询结果与其他查询结果一起被返回到SM 132时，接口160从IMU 722和RMU 730中的光线槽的组件中读取结果，并生成否则将从SMU 740读取的结果。在一些示例中，接口160可以将本来应该从SMU 740中检索到的字段全部填充为零。

在另一示例中，在不需要来自RMU 730的结果的情况下(即，无三角获取或转换的光线返回)，可以释放光线槽的RMU 730部分。在另一个示例中，堆栈或RMU 730中的命中仅不需要IMU 722存储，可以将其释放。

独立地释放任何这些资源需要分离它们的分配。所有光线分配均始于RMU 730、IMU 722和SMU 740中的所有组成组件。在每个那些单元中添加了一个重映射表，以将接口起源的光线槽ID与每个那些单元中的物理光线槽进行映射。在分配时，接口160更新那些表中的每一个。在RMU 730、IMU 722或SMU 740中访问时(例如，当相交结果被返回到SM 132时)，将访问重映射表以确定所需的物理位置。在一些实施例中，可以在接口160中管理存储在重映射表中的信息。

由于为每个光线分配了要启动的所有组件，因此释放这些资源的目的在于减小任何那些单元(例如，RMU 730、IMU 722和/或SMU 740)的大小。如果大小都相同，则无需进一步减小它们。例如，如果期望很少的返回需要RMU 730存储，则可以减少RMU 730的存储，以不覆盖光线完成与该光线返回SM 132之间的延迟。或者例如，如果期望大多数查询在不继续遍历的情况下终止并且也不需要返回有关RMU 730中的光线信息，那么SMU 740和RMU730二者的大小都可以较小，以不覆盖整个未决返回延迟。

将光线槽分解成用于单独分配和释放的组件，意味着接口160被扩展以分别跟踪独立资源，并且还在RMU 730、IMU 722和SMU 740中提供了重映射表。那些组件的附加区域通过在RMU 730、IMU 722和/或SMU 740中的减少的缓冲区中的区域节省来抵消。

如上所述，接口160接收线程束，发出票证并跟踪光线相交测试、结果的存储并将结果返回给SM 132。图13A示出了可以由接口160可以跟踪的数据的示例表。对于线程束中的每个线程，接口160线程可以跟踪每个线程是否处于活动状态、线程的结果存储在哪里以及完成的查询是否指示无命中或任何命中。

如图13A所示，活动线程23和活动线程16可具有分配并映射到RMU、IMU和SMU中的槽的TTU槽(即，光线槽)。当针对线程的查询完成时(基于光线的参数设置)，接口160可以为完成的查询更新表中的信息。

对于非活动线程5，该表存储有关RMU、IMU和SMU中结果位置的信息。当线程5的结果被返回到SM 132时，接口160可以从标识的位置中读取线程ID 5的查询结果。

对于非活动线程16，测试结果表明无命中。因为无命中，所以在接口160中为线程16设置了无命中位，并且释放了先前为线程16查询分配的时隙，以供其他查询使用。当线程16的结果被返回到SM 132时，接口160不会从先前为线程16分配的时隙中读取，而是会生成返回到SM 132寄存器的数据。类似地，接口160生成要返回至线程8的SM 132的数据，因为线程8的查询结果表明存在某些命中。

图13A还示出了线程4的部分结果被存储在RMU和IMU的特定槽中，但是当线程4的结果被返回给SM时，会生成将从SMU检索的数据。已存储结果的SMU的槽被释放以供其他查询使用。

可以在存储在图9中所示的各个单元中的每个的重映射表中提供指派给线程的TTU槽与RMU、IMU和SMU中的槽之间的映射。图13B示出了TTU槽与RMU、IMU和SMU槽之间的示例映射。如果在TTU 138的各个单元中提供了重映射表，则该映射不需要包括在图13A所示的表中。

确定查询是否需要资源分配的接口

在一些实施例中，接口160可以包括被配置为确定是否不需要为特定查询分配TTU138中的某些资源的电路。在该示例中，接口160可以基于查询中的信息(例如，光线的参数或遍历的类型)来确定不需要为该查询分配光线槽的一个或更多个组件。作为示例，如果查询包括要测试的单个图元，则接口160可以确定不需要分配堆栈管理单元中的资源。在分配资源之前或之时做出该确定的接口160可以允许更早地发出票证以用于线程束执行。

示例光线三角遍历实现

图14示出了用于确定数据结构(例如，光线)与图元之间的相交的示例非限制性方法的流程图。参考图14讨论的一个或更多个操作可以由本申请中公开的TTU 138执行，但是示例实施方式不限于此。

该方法包括接收对查询数据结构和图元范围之间的一个或更多个相交的请求(例如，查询)(步骤1110)。可以从SM 132接收该请求。可以将该请求作为包括多个线程的线程束的一部分来接收，其中每个线程包括对于光线相交测试的请求。该请求可以请求图元范围内的任何命中、最接近的相交或每个相交。在一些实施例中，查询数据结构可以是由其三坐标原点、三坐标方向以及沿光线(例如，代表沿光线的当前感兴趣的分段)的参数间隔(t-parameter)的最小值和最大值(tmin，tmax)给出的光线。在一些实施例中，查询可以包括用于定义查询数据结构(例如，光线)的信息，该查询数据结构可以被TTU 138用来生成一个或更多个光线参数以测试与光线的图元相交。可以在TTU 138中的堆栈管理块的一个或更多个堆栈条目中标识该请求的图元范围。可以基于在TTU 138的光线压缩树测试路径中找到BVH的相交的叶节点的结果来创建堆栈条目。

当TTU 138中的资源可用于执行线程束中的请求时，接口160调度该请求(步骤1112)。调度请求可以包括为请求分配TTU资源。如上所述，可以将光线槽指派给请求。

从存储器中检索图元范围(步骤1114)。可以从TTU存储器(例如，L0高速缓存750的三角形高速缓存754)或TTU 138外部的存储器中检索图元范围。例如，可以在连续的一组高速缓存行大小的(cacheline-sized)块中提供图元范围。每个高速缓存行大小的块可以包括头部，该头部标识在该块内表达的几何形状的类型以及该块中每个图元的图元类型。例如，头部可以标识该块包括三角形，并且可以指示每个三角形是阿尔法图元还是不透明图元。头部可包括用于每个图元的阿尔法位，以指定相应图元是阿尔法图元还是不透明图元。

该方法包括转换光线和/或图元(步骤1116)。光线和/或图元经过转换以简化3D相交问题并减少TTU硬件执行相交测试所需的浮点资源。

使用转换的光线和/或图元，确定光线与哪些图元相交(步骤1118)。应用于光线和图元的转换使用简化的平面坐标(例如，2D光线相对坐标)简化了从3D空间到2D空间的相交问题。在2D空间中，相交测试将确定光线相交是否在图元的内部边缘(例如，三角形边缘)。

如果TTU确定了相交点，那么它也可以确定该相交点的坐标。相交点坐标可以例如由重心坐标提供，以供SM 132或者在一些其他(例如，将来的)实现中由TTU内的硬件进行进一步处理(例如，纹理坐标的计算)。

相交结果被存储(步骤1120)在TTU 138中。该结果可以指示光线是否与任何图元、遍历堆栈状态、光线信息等相交。结果可以被存储在为各个处理单元的查询分配的时隙中。一些结果可以以压缩格式(例如，具有单个位)存储在接口160中。当全部或部分结果被存储在接口160中时，可以释放分配给查询的一个或更多个时隙以由其他查询使用。

用于查询的相交测试结果被返回到SM 132(步骤1122)。在一个示例中，TTU 138将最接近的命中图元返回到SM 132。在一个示例性实施例中，对于每个相交的图元，返回给SM132的结果可包括参数长度(其指定沿着光线命中的点发生和命中的属性，例如实例ID、材质ID)或SM可以使用以选择特定材料着色器和一组资源绑定的参数长度，以及在着色期间可以由SM 132使用以检索和内插属性或样本纹理的图元ID和(u，v)坐标。在一些示例中，相交测试结果表明，没有任何东西被确定为与光线相交，或者某些东西与光线相交而没有标识出被相交的东西。

如果需要进行SM干预(例如，如果在单个三角形范围内找到的阿尔法命中次数超过了结果队列中的阿尔法命中的存储容量)，则当请求完成或中间遍历时，TTU 138可以将结果返回给SM 132。如果请求中的所有图元都是不透明的，则TTU 138可以只将最接近的不透明图元返回给SM 132。但是，如果图元包括不透明图元和阿尔法图元的混合，则多个阿尔法图元可以与光线相交。可以将每个相交的阿尔法图元返回到SM 132以进行进一步处理(例如，基于与阿尔法图元相关联的纹理信息来确定是否存在命中)。SM 132可以使用结果来构建场景、向TTU 138发出附加查询、和/或修改先前向TTU 138发出的查询。

将结果返回到SM 132可以包括在返回结果之前等待线程束中的每个请求完成。在其他示例中，当完成线程束中的预定数量的请求(例如8个或16个请求)时，可以返回结果。

将请求的结果返回给SM 132可以包括接口160请求TTU上存储的结果数据和/或基于接口160中先前存储的结果(例如，作为压缩的结果数据)生成结果数据。如上所述，将结果作为的压缩数据存储在接口160中，允许释放分配的TTU资源(例如，光线槽)以供其他线程束或查询使用这些资源。

由TTU 138和SM 132实例化管道实现的示例

为了完整性，下面描述示例实施例中的TTU 138如何执行实例化和相关联的转换。

图15A的光线追踪管道流程图的更详细的图示出了典型用例的数据流和组件之间的交互：针对包含几何图元的场景追踪光线，并在硬件中处理实例转换。在一个示例非限制性实施例中，图15A的光线追踪管线本质上是软件定义的(在示例实施例中，这是由SM 132确定的)，但是广泛使用了TTU 138进行的硬件加速。关键组件包括SM 132(以及其余的计算管线)、TTU 138(充当SM的协处理器)以及L1高速缓存和下游存储器系统，TTU从中获取BVH和三角形数据。

图15A中所示的管线示出了可以由开发系统提前执行包围体层次结构创建1802。在示例实施例中还示出了，作为阴影(其可以包括光和纹理)，由SM 132或其他软件执行或控制的光线创建和分配1804。示例管线包括分别由TTU 138执行的“顶层”BVH树遍历1806、光线转换1814、“底层”BVH树遍历1818和光线/三角形(或其他图元)相交1826。由于TTU 138和SM 132之间的握手确定了TTU 138做什么以及以什么顺序进行，所以不必按照所示的顺序执行。

SM 132一次向TTU 138呈现一条或更多条光线。SM 132呈现给TTU 138进行遍历的每条光线可以包括光线的几何参数、遍历状态以及光线的光线标记、模式标记和光线操作信息。在示例实施例中，光线操作(RayOp)提供或包括辅助算术和/或逻辑测试，以抑制、覆盖和/或允许相交点的存储。遍历堆栈也可以由SM 132使用，以将某些状态信息传递给TTU138，以用于遍历。新的光线查询可以从显式遍历堆栈开始。但是，对于某些查询，可以提供少量的堆栈初始值设定项(initializer)以开始给定类型的新查询，例如：诸如从压缩树开始的遍历；光线与一系列三角形的相交；光线与一系列三角形的相交，然后从压缩树开始进行遍历；从三角形缓冲区中获取给定三角形的顶点，等。在一些实施例中，使用堆栈初始值设定项代替显式堆栈初始化可提高性能，因为堆栈初始值设定项需要较少的流处理器寄存器并减少了需要从流处理器传输到TTU的参数的数量。

在示例实施例中，当查询与特定类型的包围体相交或与特定图元类型的图元相交时，SM 132随每个查询(例如，光线)呈现的一组模式标记可以至少部分地控制TTU 138将如何处理查询。SM 132提供给TTU 138的模式标记使SM和/或应用能够例如通过RayOp指定辅助算术或逻辑测试，以抑制、覆盖或允许存储相交点的能力。模式标记可以例如使得能够根据例如诸如与每个包围体和/或图元相关联的深度(或距离)、与原点或光线的距离有光的包围体或图元的大小、对象的特定示例等方面来改变遍历行为。应用程序可以使用此功能来动态和/或选择性地启用/禁用对象集以进行相交测试，而不是特定的查询集或查询组，例如，以允许在应用程序状态更改时(例如，当门打开或关闭时)使用不同版本的模型或提供不同版本的模型，这些模型的选择取决于光线的长度，以实现某种形式的几何细节水平，或允许某些类别的光线中的特定对象集以使某些层在特定视图中可见或不可见。

除了可以分别为光线压缩树相交和光线图元交集指定的模式标记集之外，光线数据结构还可以指定与RayOp测试相关的其他参数，例如光线标记、光线参数和RayOp测试。光线标记可以由TTU 138用于控制遍历行为、背面剔除和各种子节点类型处理的各个方面，并取决于可选RayOp测试的通过/失败状态。RayOp测试以一定的复杂性为代价，为TTU 138的功能增加了灵活性。TTU 138为其正在处理的每个活动光线保留“光线槽”，并且可以在遍历期间将光线标记、模式标记和/或RayOp信息存储在TTU内的相应的光线槽缓冲区中。

在图15A所示的示例中，TTU 138执行顶层树遍历1806和底层树遍历1818。在示例实施例中，BVH的二级遍历使得能够对动态场景变化做出快速光线追踪响应。

在一些实施例中，在进入顶层树遍历时，或在顶层树遍历中，在BVH中遇到指定顶层转换的实例节点1805。实例节点1805向TTU指示以实例节点1805为根的子树与替代世界空间坐标系对齐，在实例节点1805中为其定义了来自世界空间的转换。

响应于遍历实例节点1805，TTU将从SM接收到的光线(或多个光线)从世界空间转换为替代世界空间。

光线转换1814通过转换可以在第一坐标空间(例如，世界空间)中的顶层遍历中使用的光线，提供从顶层树遍历1806到底层树遍历1818的适当过渡，到底层遍历的BVH的不同坐标空间(例如，对象空间)。在先前的文献中描述了使用两层遍历的示例BVH遍历技术，例如，参见Woop的“用于动态场景的光线追踪硬件架构”，萨尔兰德大学，2004，但是实施例不限于此。

示例顶层树遍历

TTU 138对顶层树遍历1806从L1高速缓存1812接收压缩树，并向光线转换1814提供实例以进行转换，或者向SM 132提供未命中/结束输出1813以由SM处理最接近命中着色器1815(此块还可以基于非叶节点/无命中条件来递归地操作)。在顶层树遍历1806中，下一个压缩树获取步骤1808从存储器和/或高速缓存层次结构中获取用于在步骤181中要用于光线相交测试的下一个压缩树，并且在获取的压缩树中的对包围体上完成光线包围体测试。

如上所述，实例节点将一个BVH连接到处于不同坐标系中的另一个BVH。当相交的包围体的子代是实例节点时，光线转换1814能够从L1高速缓存1816中检索适当的转换矩阵。TTU 138使用适当的转换矩阵将光线转换为子代BVH的坐标系。已经通过引用并入的美国专利申请号14/697,480描述了将树中的第一组节点连接到第二组节点的转换节点，其中第一组节点和第二组节点处于不同的坐标系中。示例实施例中的实例节点可以类似于美国专利申请号14/697,480中的转换节点。在图15B中所示的TTU 138的替代的非实例化模式中，TTU不执行“底”层树遍历1818，并且非实例树BVH遍历由框1808、1810例如仅使用一个堆栈来执行。TTU 138可以基于从BVH和/或查询类型中读取的内容在图15A实例化操作和图15B非实例化操作之间切换。例如，特定的查询类型可能会限制TTU仅使用非实例化操作。在这种查询中，任何相交的实例节点都将返回给SM。

在一些非限制性实施例中，在提取下一个压缩树之前，对提取的压缩树中的每个包围体执行步骤1810中的光线包围体相交测试。其他实施例可以使用其他技术，例如，诸如以深度优先的方式遍历顶层遍历BVH。已经通过引用并入的美国专利号9,582,607描述了可以在示例实施例中使用的一个或更多个压缩树的结构和内容。美国专利号9,582,607也描述了压缩树的实例遍历。

当确定包围体与光线相交时，相交的包围体的子包围体(或对其的引用)被跟踪，以用于随后的与光线的相交和遍历的测试。在示例实施例中，一个或更多个堆栈数据结构用于跟踪要随后测试与光线相交的子包围体。在一些示例实施例中，可以使用小尺寸的遍历堆栈来跟踪将通过顶层树遍历1806的操作来遍历的压缩树，以及要测试相交的图元，并且可以使用较大的局部堆栈数据结构来跟踪在底层树遍历1818中的遍历状态。

底层树遍历的示例

在底层树遍历1818中，下一个压缩树提取步骤1822在步骤1824中从存储器和/或高速缓存层次结构1820中提取要测试的光线相交的下一个压缩树，并且在提取的压缩树中的包围体上进行光线包围体相交测。如上所述，底层树遍历可以包括具有与在高层树遍历中遍历的包围体不同的坐标系中的包围体的压缩树。底层树遍历还从L1高速缓存中接收压缩树，并且可以基于非叶子/无命中条件在自身内进行递归或迭代操作，并且还可以基于未命中/结束检测在顶层树遍历1806内进行递归或迭代操作。光线与较低层BVH中的包围体的相交点可以通过将光线转换为获取的较低层压缩树的坐标系来确定。然后，将在较低层的树遍历中发现的与光线相交的叶包围体提供给光线/三角形相交1826。

底层树遍历1818的叶输出被提供给光线/三角形相交1826(其具有L0高速缓存访问以及经由L1高速缓存1828检索三角形的能力)。L0压缩树和三角形高速缓存可以是TTU138内部的小型只读高速缓存。当到达某些叶节点而没有遍历实例BVH时，光线/三角形相交1826也可以从顶层树遍历1806接收叶输出。

在处理完图元范围内的所有图元之后，相交管理单元检查结果队列的状态，并制作分组以发送到堆栈管理单元和/或光线管理单元以更新光线的属性和遍历状态，设置光线的下一个遍历步骤，和/或将光线返回到SM 132(如有必要)。如果结果队列中包含在图元范围处理期间发现的不透明或阿尔法交点，则相交管理单元将结果队列中最近的不透明相交的参数长度(t)通知给光线管理单元，以记录为光线的tmax以缩短光线。为了更新遍历状态以设置光线的下一个遍历步骤，相交管理单元会向堆栈管理单元发送信号，通知结果队列中是否存在来自图元范围的不透明相交，结果队列中是否存在一个或更多个阿尔法相交，结果队列是否已满，是否在图元范围内找到尚未返回到SM且在结果队列中不存在的其他阿尔法相交，以及要测试的光线在图元范围内的下一个阿尔法图元的索引在SM消耗结果队列的内容之后(结果队列中当前图元范围内的最高存储顺序的alpha图元之后的范围内的下一个图元的索引)。

当堆栈管理单元740从相交管理单元722接收到分组时，堆栈管理单元740检查该分组以确定完成遍历步骤并开始下一个所需的下一动作。如果来自相交管理单元722的分组指示在图元范围内发现了不透明相交，并且光线模式位指示一旦找到任何相交，光线将完成遍历，则堆栈管理单元740将光线及其结果队列返回到具有遍历状态的SM，该遍历状态指示遍历已完成(已设置完成标记和/或空顶层堆栈和底层堆栈)。如果来自相交管理单元722的分组指示结果队列中存在不透明或阿尔法相交，并且结果队列中不存在图元范围中的剩余的阿尔法相交，这些相交由光线在图元范围的处理期间相遇且尚未返回到SM，则堆栈管理单元740将光线和结果队列返回到SM，并且将修改遍历状态以设置剔除不透明位，以防止对图元范围内的不透明图元的进一步处理，并且在最高阿尔法图元相交从图元范围返回到光线结果队列中的SM之后，图元范围起始索引前进到第一阿尔法图元。如果当光线处理图元范围时，来自相交管理单元722的分组指示未发现不透明或阿尔法相交，则堆栈管理单元740从活动遍历堆栈弹出堆栈条目的顶部(对应于完成的图元范围)。如果来自堆栈管理单元740的分组指示结果队列中存在不透明相交，并且光线模式位不指示一旦找到任何相交和/或结果队列中存在阿尔法相交，则光线将完成遍历，但是在尚未返回给SM的结果队列中不存在的图元范围中未找到剩余的阿尔法相交，则堆栈管理单元740从活动遍历堆栈弹出堆栈条目的顶部(对应于完成的图元范围)并修改结果队列的内容，以指示结果队列中存在的所有相交都来自完成处理的图元范围。

如果活动堆栈是底部堆栈，并且底部堆栈为空，则堆栈管理单元740将活动堆栈设置为顶部堆栈。如果顶部堆栈是活动堆栈，并且活动堆栈为空，则堆栈管理单元740将光线及其结果队列返回到具有遍历状态的SM，该遍历状态指示遍历已完成(已设置完成标记和/或为空顶层堆栈和底层堆栈)。如果活动堆栈包含一个或更多个堆栈条目，则堆栈管理单元740检查顶部堆栈条目并开始下一遍历步骤。与光线相交的图元和/或图元范围的测试以及将结果返回到SM 132的说明，参见标题为“保守的水密光线三角形相交点”的共同未决的美国专利申请号16/101,148，以及标题为“处理乱序的不透明和Alpha(阿尔法)光线/图元相交点的方法”的美国专利申请号16/101,196，通过引用将其全部内容合并于此。

包括光线追踪的示例图像生成管线

尽管以上公开内容是在计算机图形和可视化的特定上下文中进行构架的，但是光线追踪和所公开的TTU可以用于图形和可视化之外的多种应用。非限制性示例包括用于真实声音合成的声传播、声纳系统的模拟、光学元件和系统的设计、粒子传输模拟(例如，用于医学物理学或实验性高能物理)、一般的波传播模拟，用于例如机器人或车辆定位目的的与LIDAR数据的比较以及其他。过去，OptiX^TM已用于其中一些应用领域。

例如，可以以各种方式使用上述的光线追踪和其他能力。例如，除了用于使用光线追踪渲染场景外，它们还可以与扫描转换技术结合使用，例如在对3D模型的几何构造块(即，诸如三角形之类的多边形图元)进行扫描转换的上下文中用以生成用于显示(例如，在图4所示的显示器150上)的图像。

然而，同时，当用于产生用于虚拟现实、增强现实、混合现实、视频游戏、运动和静止图片生成以及其他可视化应用的图像时，本文的技术提供了优点。图16示出了根据一个实施例的用于处理图元以提供图像的图像像素值的示例流程图。如图16所示，可以响应于接收到用户输入来生成3D模型的图像(步骤1952)。用户输入可以是显示图像或图像序列的请求，例如在与应用程序(例如，游戏应用程序)交互期间执行的输入操作。响应于用户输入，系统使用常规的GPU 3D图形管线执行场景的3D模型几何图元的扫描转换和光栅化(步骤1954)。几何图元的扫描转换和光栅化可包括例如使用本领域技术人员众所周知的常规技术(例如，照明、转换、纹理映射、光栅化等)处理3D模型的图元以确定图像像素值。生成的像素数据可以被写入帧缓冲区。

在步骤1956中，可以使用TTU硬件加速从光栅化图元上的一个或更多个点追踪一条或更多条光线。可以根据本申请中公开的一种或更多种光线追踪能力来追踪光线。根据光线追踪的结果，可以修改存储在缓冲区中的像素值(步骤1958)。在某些应用中，修改像素值可能会例如通过例如应用更真实的反射和/或阴影来提高图像质量。使用存储在缓冲区中的修改的像素值来显示图像(步骤1960)。

在一个示例中，可以使用上述处理系统来实现几何图元的扫描转换和光栅化，并且可以由SM 132使用关于图7描述的TTU架构来实现光线追踪，以添加更多的可视化特征(例如，镜面反射、阴影等)。图16仅是非限制性示例-SM 132可以自行使用所描述的TTU，而无需进行纹理处理或其他常规3D图形处理来产生图像，或者SM可以采用纹理处理和其他常规3D图形处理而无需进行所描述的TTU来产生图像。SM还可根据应用程序在软件中实现任何所需的图像生成或其他功能，以提供任何所需的可编程功能，这些功能不受纹理映射硬件、树遍历硬件或其他图形管线硬件提供的硬件加速功能的约束。

在一些实施例中，TTU 138是无状态的，这意味着在查询之间的TTU中没有维护架构状态。同时，对于SM 1840上运行的软件来说，请求继续先前的查询通常很有用，这意味着相关状态应由TTU 138写入寄存器，并且然后传递回寄存器中的TTU(通常在位(in-place))继续。该状态可以采用遍历堆栈的形式，该遍历堆栈跟踪BVH遍历的进度。

还可以提供少量的堆栈初始值设定项以开始给定类型的新查询，例如：

●从压缩树开始遍历

●光线与一系列三角形的相交

●光线与一系列三角形的相交，然后从压缩树开始遍历

●从三角形缓冲区中获取给定三角形的顶点

●在“从压缩树开始遍历”和“光线与一系列三角形的相交”前面进行实例转换的可选支持。

顶点提取是简单的查询，其可以用包含堆栈初始值设定项而不包含其他内容的请求数据来指定。其他查询类型可能需要指定光线、光束或其他几何对象，以及堆栈或堆栈初始值设定项以及描述查询详细信息的各种光线标记。光线由其三坐标原点、三坐标方向以及沿光线的t参数的最小值和最大值给出。光束还由第二原点和方向给出。

各种光线标记可用于控制遍历行为、背面剔除和各种子节点类型的处理的各个方面，这取决于可选rayOp测试的通过/失败状态。RayOp为TTU的功能增加了相当大的灵活性。在一些示例实施例中，RayOp部分引入了两个光线标记版本，其可以基于对与光线一起传输的数据和存储在压缩树中的数据的指定操作来动态选择两个光线标记版本。要探索此类标记，这首先有助于了解BVH中允许的子节点的不同类型以及TTU 138可以返回给SM的各种命中类型。示例节点类型为：

■子压缩树(即，内部节点)

默认情况下，TTU 138通过下降到子压缩树继续遍历。

■三角形范围，对应于三角形缓冲区中的一组连续三角形

(1)默认情况下，光线遇到的三角形范围由TTU 138通过测试三角形的相交并相应地缩短光线来本地处理。如果遍历完成并且命中了三角形，则默认行为是将三角形ID以及相交的t值和重心坐标返回给SM 1840。这是“三角形”命中类型。

(2)默认情况下，即使遍历尚未完成，设置了阿尔法位的相交的三角形会被返回到SM 1840。如果软件确定三角形实际上是透明的，则返回的遍历堆栈包含继续遍历所需的状态。

(3)在某些实施例中，光束不支持三角形相交，因此默认情况下将遇到的三角形范围作为“TriRange”命中类型返回到SM 1840，其中包括指向与该范围重叠的第一三角形块的指针，参数指定了范围，以及与叶包围盒相交的t值。

■条目范围，由索引(从压缩树中存储的用户提供的“条目范围库”中得出)和条目计数组成。

默认情况下，条目范围作为“ItemRange”命中类型被返回到SM 1840，其由例如索引、计数和与叶包围盒相交的t值组成。

■实例节点。

在一些实施例中，TTU 138可以通过将光线转换成BVH实例的坐标系来本地处理一个实例化级别。其他级别的实例化(或实例化的每个其他级别，取决于策略)可以在软件中被处理(或在其他实施例中，TTU 138硬件可以处理两个、三个或更多级别的实例化)。为此提供了“实例节点(InstanceNode)”命中类型，由指向实例节点的指针和与叶包围盒相交的t值组成。在其他实施方式中，硬件可以处理两个、三个或更多级别的实例化。

除了特定于节点的命中类型之外，还提供了通用的“节点参考(NodeRef)”命中类型，其由指向父压缩树本身的指针以及指示哪个子代相交的ID和与该子代的包围盒相交的t值组成。

对于查询或BVH格式不正确或遍历期间遍历遇到问题的情况，可以提供“错误”命中类型。

对于光线或光束未命中场景中所有几何形状的情况，可以提供“无”命中类型。

TTU如何处理四种可能的节点类型中的每一个，是由一组特定于节点的模式标记确定的，该标记设置为给定光线的查询的一部分。上面提到的“默认”行为对应于将模式标记设置为全零的情况。

标记的替代值允许剔除给定类型的所有节点，将给定类型的节点作为NodeRef命中类型返回给SM，或者使用其对应的命中类型将三角形范围或实例节点返回给SM，而不是在TTU 138中本地处理它们。

可以提供替代的模式标记，以控制阿尔法三角形。

应用本文公开的一种或更多种技术生成的图像可以显示在监视器或其他显示设备上。在一些实施例中，显示设备可以直接耦合到生成或渲染图像的系统或处理器。在其他实施例中，显示设备可以例如经由网络间接地耦合到系统或处理器。此类网络的示例包括因特网、移动电信网络、WIFI网络以及任何其他有线和/或无线联网系统。当显示设备间接耦合时，由系统或处理器生成的图像可以通过网络流传输到显示设备。这种流传输允许例如在服务器上或在数据中心中执行渲染图像的视频游戏或其他应用程序，并且渲染的图像可以在与服务器或数据中心物理上分开的一个或更多个用户设备(例如，计算机、游戏控制台、智能手机、其他移动设备等)上传输和显示。因此，本文公开的技术可以应用于增强流传输的图像并增强流传输图像的服务，例如NVIDIA GeForce Now(GFN)、Google Stadia等。

此外，应用本文公开的一种或更多种技术生成的图像可以用于训练、测试或认证用于识别现实世界中的对象和环境的深度神经网络(DNN)。这样的图像可以包括道路、工厂、建筑物、城市环境、农村环境、人类、动物以及任何其他物理对象或真实环境的场景。这样的图像可以用于训练、测试或认证在机器或机器人中使用的DNN，以操纵、处理或修改现实世界中的物理对象。此外，此类图像可用于训练、测试或认证在自动驾驶车辆中使用的DNN，以在现实世界中导航和移动车辆。另外，应用本文公开的一种或更多种技术生成的图像可以用于向这些机器、机器人和车辆的用户传达信息。

以上引用的所有专利和出版物均通过引用并入，如同明确提出一样。

尽管已经结合当前被认为是最实际和优选的实施例描述了本发明，但是应当理解，本发明不限于所公开的实施例，相反，其意图是涵盖所附权利要求的精神和范围内所包括的各种修改和等效布置。

Claims

1.一种光线追踪硬件方法，包括：

执行相交测试以提供相交测试结果；

基于所述相交测试结果，选择是使用从所述相交测试收集的数据还是使用在执行所述相交测试之前预定的数据，向协处理器报告所述相交测试；以及

针对使用从所述相交测试收集的数据和使用在执行所述相交测试之前预定的数据中的每一者，使用相同的报告格式表示。

2.根据权利要求1所述的光线追踪硬件方法，还包括：在基于所述相交测试结果确定将使用在执行所述相交测试之前预定的所述数据来报告所述相交测试结果时，选择性地释放用于从所述相交测试收集数据的片上存储器。

3.根据权利要求1所述的光线追踪硬件方法，其中每当所述相交测试结果为未命中时，所述选择选择使用在执行所述相交测试之前预定的数据。

4.一种耦合到处理器的协处理器，所述协处理器包括被配置为执行包括以下各项操作的电路：

从所述处理器接收多个线程请求，每个请求包括查询；

针对每个查询，分配用于存储查询结果的资源；

处理所述查询；

对于至少一个处理的查询，将查询结果存储在针对相应的查询所分配的资源中；

对于至少一个处理的查询，将查询结果存储在针对所述相应的查询所分配的资源之外，并针对所述相应的查询释放所分配的资源；以及

当完成预定数量的查询的处理时，并发地报告存储在所述至少一个处理的查询的所分配的资源中的所述查询结果和存储在针对所述至少一个查询所分配的资源之外的所述查询结果。

5.根据权利要求4所述的协处理器，其中所述查询的预定数量是所述多个线程请求中的线程的数量。

6.根据权利要求4所述的协处理器，其中所述查询的预定数量小于所述多个线程请求中的线程的数量。

7.根据权利要求4所述的协处理器，其中每个查询包括定义光线的信息以及用于测试与所述光线相交的图元的数据结构。

8.根据权利要求7所述的协处理器，其中存储在所分配的资源之外的所述查询结果指示确定所述光线被确定为不与所述数据结构中的任何图元相交。

9.根据权利要求4所述的协处理器，其中所述多个线程请求包括对任何命中查询的终止，所述任何命中查询包括定义光线的信息和用于测试与所述光线相交的多个图元，对任何命中查询的终止返回所述多个图元中的任何一个与所述光线相交的指示或者所述多个图元中没有一个与所述光线相交的指示。

10.根据权利要求9所述的协处理器，其中在完成对任何命中查询的终止后，释放对任何命中查询的终止所分配的资源，并且将对任何命中查询的终止的结果以压缩格式存储在对任何命中查询的终止所分配的资源之外，直到完成对预定数量的查询的处理为止。

11.根据权利要求4所述的协处理器，还包括接口，所述接口被配置为接收所述多个线程请求，控制所述资源的所述分配和释放，将压缩的查询结果的存储提供在所分配的资源之外，以及控制所述查询结果的所述报告至所述处理器。

12.一种光线追踪设备，其耦合到处理器并且包括被配置为执行包括以下各项操作的电路：

从所述处理器接收多个查询，每个查询包括定义光线的信息和测试与所述光线相交的图元的数据结构；

对于每个查询，分配用于存储光线相交结果的资源，接收包括多个图元的图元范围，确定所述光线是否与所述多个图元中的一个或更多个相交，当所述光线被确定为与所述多个图元中的至少一个相交时将所述相交结果存储在所分配的资源中，并且当所述光线被确定不与所述多个图元中的任何一个相交时，释放针对所述查询所分配的资源，并将所述相交结果的压缩表示存储在针对所述查询所分配的资源之外的存储器中；以及

向所述处理器报告存储在所分配的资源和/或所分配的资源之外的所述存储器中的相交结果。

13.根据权利要求12所述的光线追踪设备，其中在所述光线追踪设备处理预定数量的所述多个查询之后，将所述相交结果报告给所述处理器，其中所述预定数量大于一个且小于所述多个查询的数量。

14.根据权利要求12所述的光线追踪设备，其中在所述光线追踪设备处理所述多个查询的一半之后，将所述相交结果报告给所述处理器。

15.根据权利要求12所述的光线追踪设备，其中针对每个查询所分配的资源包括多个存储位置，每个所述存储位置与所述光线追踪设备的不同处理电路相关联。

16.根据权利要求12所述的光线追踪设备，其中所述光线被确定为不与所述多个图元中的任何一个相交时，单比特位用于表示针对所述查询所分配的资源之外的存储器中的所述相交结果。

17.根据权利要求12所述的光线追踪设备，其中报告所述光线不与所述多个图元中的任何一个相交的查询的结果包括：基于存储在所分配的资源之外的所述存储器中的所述相交结果的所述压缩表示来生成数据。

18.根据权利要求12所述的光线追踪设备，其中报告所述光线不与所述多个图元中的任何一个相交的查询的结果包括：当所述多个查询的所述相交结果被并发地返回到所述处理器时，基于存储在所分配的资源之外的所述存储器中的所述相交结果的所述压缩表示来生成数据。

19.一种由协处理器执行的方法，所述协处理器可通信地耦合处理器，所述方法包括：

从所述处理器接收多个线程请求，每个请求包括查询；

针对每个查询，分配用于存储查询结果的资源；

处理所述查询；

并发地报告存储在所述至少一个处理的查询的所分配的资源中的所述查询结果和存储在所述至少一个查询的所分配资源之外的所述查询结果。

20.根据权利要求19所述的方法，其中当完成预定数量的查询的处理时，报告所述查询结果。

21.根据权利要求20所述的方法，其中所述查询的预定数量是所述多个线程请求中的线程的数量。

22.根据权利要求20所述的方法，其中所述查询的预定数量小于所述多个线程请求中的线程的数量。

23.根据权利要求19所述的方法，其中每个查询包括定义光线的信息和用于测试与所述光线相交的图元的数据结构。

24.根据权利要求23所述的方法，其中存储在所分配的资源之外的所述查询结果指示所述光线被确定为不与所述数据结构中的任何图元相交。

25.根据权利要求19所述的方法，其中所述多个线程请求包括对任何命中查询的终止，所述任何命中查询包括定义光线的信息和用于测试与所述光线相交的多个图元，在对任何命中查询的终止返回所述多个图元中的任何一个与所述光线相交的指示或者所述多个图元中没有一个与所述光线相交的指示，在完成对任何命中查询的终止时，释放对任何命中查询的终止所分配的资源，并且将对任何命中查询的终止的结果以压缩格式存储在所分配的资源之外，直到完成对所述多个线程请求中的每个线程请求的处理为止。

26.根据权利要求19所述的方法，其中在服务器上或在数据中心中执行所述接收、所述分配、处理所述查询、将所述查询结果存储在所分配的资源中和/或存储在所分配的资源之外、以及报告，以生成图像，并将所述图像流传输到用户设备。

27.根据权利要求19所述的方法，其中执行所述接收、分配、处理所述查询、将所述查询结果存储在所分配的资源中和/或在所分配的资源之外以及报告，来生成以用于训练、测试或证明在机器、机器人或自动驾驶车辆中所使用的神经网络。

28.根据权利要求12所述的光线追踪设备，其中所述电路是用于生成图像的服务器或数据中心的一部分，并且所述图像被流传输到用户设备。

29.根据权利要求12所述的光线追踪设备，其中所述电路用于生成图像，并且所述图像用于训练、测试或证明在机器、机器人或自动驾驶车辆中所使用的神经网络。