CN114028804A - 流式传输压缩光场 - Google Patents

Abstract

公开了流式传输压缩光场。远程设备利用光线追踪来计算要渲染的场景的光场，其中所述光场包括关于从所述场景内的表面反射出的光的信息。接着利用实现时间复用的一个或更多个视频压缩技术来压缩此光场，使得仅压缩场景的光场与先前场景的光场之间的差异。随后将压缩后的光场数据发送到客户端设备，所述客户端设备解压缩该光场数据并且在客户端设备处使用此数据来获得该场景的光场。接着此光场由客户端设备使用以计算场景的全局照明。全局照明可用于在移动设备处准确地渲染场景，从而产生由移动设备呈现的逼真场景。

Description

流式传输压缩光场

要求优先权

本申请要求于2020年7月21日提交的美国临时申请No.63/054681的权益，该申请的全部内容在此通过引用合并。

技术领域

本发明涉及图像渲染，并且更具体地，涉及对场景执行全局照明。

背景技术

今天的用于游戏的高性能图形系统包括多个GPU、硬件加速的光线追踪以及高效算法，并且可以使用光线追踪的全局照明实时地接近影片效果的渲染质量，同时提供测量的数毫秒的交互延迟。这些高端系统设置当前难以在由热限制、电池功率和受限的GPU特征集约束的较低端消费者平台上满足的期望。

当前的基于云的图形解决方案将全部内容作为完全渲染的图像从远程服务器流式传输到客户端。在客户端上，视频流被解压缩并在显示器上显示。然而，网络延迟、带宽限制、以及增加的屏幕分辨率和帧率威胁了这种方法在未来的可行性。因此，需要实现具有减少的带宽和延迟特性的分布式渲染系统。

附图说明

图1示出了根据一个实施例的用于流式传输压缩的光场的方法的流程图。

图2示出了根据一个实施例的并行处理单元。

图3A示出了根据一个实施例的图2的并行处理单元内的通用处理集群。

图3B示出了根据一个实施例的图2的并行处理单元的存储器分区单元。

图4A示出了根据一个实施例的图3A的流式多处理器。

图4B是根据一个实施例的使用图2的PPU实现的处理系统的概念图。

图4C示出了可以在其中实现各种先前实施例的各种架构和/或功能的示例性系统。

图5是根据一个实施例的由图2的PPU实现的图形处理管线的概念图。

图6是适合用于实现本公开的一些实施例的示例游戏流式传输系统的框图。

图7是适合用于实现本公开的一些实施例的示例计算设备的框图。

图8示出了根据一个实施例的示例性分布式渲染系统。

图9示出了根据一个实施例的示例性数据流。

具体实施方式

远程设备(诸如服务器或一个或更多个分布式计算节点)利用光线追踪来计算要渲染的场景的光场，其中光场包括关于从场景内的表面反射出的光的信息。然后，利用实现时间复用(temporal reuse)的一个或更多个视频压缩技术以有效的方式压缩该光场，使得仅压缩该场景的光场与先前场景的光场之间的差异。这最小化了要发送的数据的量。压缩的光场数据然后被发送到客户端设备(诸如移动计算设备)，客户端设备解压缩光场数据并且在客户端设备处使用这样的数据来获得场景的光场。该光场接着由客户端设备使用以计算场景的全局照明。全局照明可用于在移动设备处准确地渲染场景，从而导致由移动设备向一个或更多个用户呈现的逼真场景。

图1示出了根据一个实施例的用于流式传输压缩的光场的方法100的流程图。尽管在处理单元的上下文中描述了方法100，但方法100还可由程序、定制电路或由定制电路与程序的组合执行。例如，方法100可以由GPU(图形处理单元)、CPU(中央处理单元)或能够通过散列执行并行路径空间滤波的任何处理器执行。此外，本领域普通技术人员将理解，执行方法100的任何系统都在本发明的实施例的范围和精神内。

应理解的是，在此描述的这种和其他布置仅作为示例被阐述。除了所示的那些布置和元件之外或代替所示的那些布置和元件，可以使用其他布置和元件(例如，机器、接口、功能、顺序、功能分组等)，并且一些元件可以一起省略。进一步，本文描述的许多元件是可被实现为分立或分布式组件或结合其他组件、和在任何合适的组合和位置中实现的功能实体。本文中描述为由实体执行的不同功能可由硬件、固件和/或软件执行。例如，不同功能可由执行存储在存储器中的指令的处理器执行。

如操作102中所示，在远程设备处标识要渲染的场景。在一个实施例中，场景可包括静止图像、视频内的帧、视频游戏内的帧等。在另一个实施例中，远程设备可以包括分布式计算系统内的计算节点、基于云的计算环境内的一个或更多个节点、服务器计算设备等。在又一个实施例中，远程设备可以与客户端设备在物理上分离。

例如，客户端设备可将所渲染的场景显示给一个或更多个用户(例如，使用一个或更多个显示器等)。在另一示例中，远程设备和客户端设备可以经由一个或更多个有线和/或无线通信网络(例如，无线互联网连接、蜂窝通信网络等)进行通信。

此外，如操作104中所示，在远程设备处利用光线追踪来计算场景的光场。在一个实施例中，远程设备可在场景内执行光线追踪以确定场景的光场。例如，光线追踪可以包括作为图像平面内的像素来追踪光路径并且模拟其与场景内的对象相遇的效果。

进一步地，在一个实施例中，可以实时执行光线追踪。在一个实施例中，场景的光场可包括描述沿一个或更多个方向流动通过场景内的空间中的一个或更多个点的光的量的一个或更多个向量。例如，场景的光场可包括向量函数，其描述在每一方向上流动通过场景内的空间中的每一点的光的量。在另一个实施例中，光场可以包括多个光探针。在又一实施例中，光场内的每一光探针可存储关于从场景内的表面反射出的光的信息。在又一实施例中，光场可包括表示光探针的块(例如，多个纹素像素块)的阵列。

更进一步，在一个实施例中，阵列内的每个块可以包括颜色纹理信息和可见性纹理信息。例如，颜色纹理信息可包括块内的照明颜色信息。在另一示例中，可见性纹理信息可包括距离信息(例如，到块内的最接近对象/表面的距离)。在另一实施例中，可利用处理器(例如，图形处理单元(GPU)等)计算光场。

而且，如操作106中所示，在远程设备处压缩光场以创建场景的压缩的光场数据。在一个实施例中，远程设备可使用视频编码和/或视频压缩单元压缩光场。例如，所述单元可位于GPU内。

另外，在一个实施例中，可使用一个或更多个视频压缩算法/技术来压缩光场。例如，可使用经由预定的视频译码/压缩标准实现的GPU加速的高动态范围(HDR)视频压缩来压缩光场。在另一实施例中，时间复用可在光场的压缩期间实现。例如，来自先前渲染的场景的压缩的信息可在当前场景的压缩期间使用。在另一实例中，可仅压缩/发送场景的光场与先前场景的光场之间的差异为光场数据。

以此方式，可利用连续场景之间的时间依赖性来减少需要压缩的数据量。这可以提高压缩性能(例如，通过减少压缩光场所需的时间)并且当与不利用时间依赖性的当前压缩实现方法相比时可以减少通过网络发送到客户端设备的数据量。

此外，在一个实施例中，压缩可以考虑场景内的当前用户视图。例如，可从客户端设备接收当前用户视图。在另一示例中，可以仅计算光场的在当前用户视图内的部分。在又一示例中，可仅压缩在可能可见的当前用户视图内的所计算光场的部分以创建压缩的光场数据。这可以减少正被压缩的数据量，这可以进一步提高执行压缩的系统的性能，并且可以进一步减少通过网络发送到客户端设备的压缩数据的量。

更进一步，如操作108中所示，压缩的光场数据从远程设备被发送到客户端设备。在一个实施例中，压缩的光场数据可经由一个或更多个有线和/或无线通信网络(例如，无线互联网连接、蜂窝通信网络等)从远程设备发送(例如，流式传输等)到客户端设备。

以此方式，可远程地计算压缩的光场数据，且可将所述压缩的光场数据提供给客户端设备，其中所述客户端设备可解压缩所述压缩的光场数据以获得所述场景的解压缩的光场。此解压缩的光场可由客户端设备使用以在客户端设备处执行场景的全局照明。在光场的压缩期间实现时间复用可减少在通信网络上发送的数据/使用的带宽的量，这可改善在这样的网络上实现通信的计算设备的性能。此复用还可导致压缩的光场数据的创建和发送两者的减少的延迟。进一步，当计算场景的光场时，可动态地计算照明计算且照明计算可不依赖于静态场景或静态照明。这可有效地考虑场景几何形状和光照的动态改变，且可改进所渲染结果的质量。

同样，如操作110中所示，在客户端设备处接收场景的压缩的光场数据。在一个实施例中，压缩的光场数据可在客户端设备处经由一个或更多个有线和/或无线通信网络(例如，无线互联网连接、蜂窝通信网络等)从远程设备接收。

此外，在一个实施例中，客户端设备可以包括用于至少部分地渲染场景并显示所渲染的场景的设备。在另一实施例中，客户端设备可以包括移动设备(例如，智能电话、平板设备等)、便携式游戏平台、虚拟现实(VR)头戴式显示器等。

进一步地，如操作112中所示，在客户端设备处对压缩的光场数据进行解压缩以获得场景的光场。在一个实施例中，所述客户端设备可使用视频解码器和/或视频解压缩单元来解压缩所述压缩的光场数据。在另一实施例中，视频解码器和/或视频解压缩单元可包括客户端设备内的专用硬件单元。在又一实施例中，视频解码器和/或视频解压缩单元可位于客户端设备的GPU内。在另一实施例中，先前场景的光场数据可与解压缩的光场数据组合以获得当前场景的光场。

更进一步，如操作114中所示，使用场景的光场在客户端设备处计算场景的全局照明。在一个实施例中，在计算全局照明时，客户端设备可在光场内执行查找(例如，代替执行光线追踪或其他资源密集型动作等)。在另一实施例中，执行全局照明可包括建模间接光(例如，光如何从表面反射到场景内的其他表面上)以及直接光(例如，直接从光源命中表面的光)。

此外，在一个实施例中，所计算的全局照明可以用于在客户端设备处渲染场景。在另一实施例中，渲染的场景可由客户端设备显示(例如，利用客户端设备的显示器等)。

以此方式，场景的全局照明的性能可改进如由客户端设备显示的场景的逼真性。另外，可以利用光场查找以更高效的方式执行全局照明，这可以减少在客户端设备处必需的处理量。这可改善客户端设备在渲染场景时的性能，并且可导致具有低带宽使用的高质量、动态渲染的图像。

在又另一个实施例中，可以利用并行处理单元(PPU)(如图2中所示的PPU 200)来执行光场计算和压缩的一个或更多个部分。

现在将根据用户的期望，阐述关于可以采用其实现前述框架的各种可选架构和特征的更多说明性信息。应该特别注意的是，出于说明性目的阐述了以下信息，并且不应该被解释为以任何方式进行限制。任选的以下特征可以任选地并入或不排除所描述的其他特征。

并行处理架构

图2示出了根据一个实施例的并行处理单元(PPU)200。在一个实施例中，PPU 200是在一个或更多个集成电路器件上实现的多线程处理器。PPU 200是设计用于并行处理许多线程的延迟隐藏体系架构。线程(即，执行线程)是被配置为由PPU 200执行的指令集的实例。在一个实施例中，PPU 200是图形处理单元(GPU)，其被配置为实现用于处理三维(3D)图形数据的图形渲染管线，以便生成用于在显示设备(诸如液晶显示(LCD)设备)上显示的二维(2D)图像数据。在其他实施例中，PPU 200可以用于执行通用计算。尽管为了说明的目的本文提供了一个示例性并行处理器，但应特别指出的是，该处理器仅出于说明目的进行阐述，并且可使用任何处理器来补充和/或替代该处理器。

一个或更多个PPU 200可以被配置为加速数千个高性能计算(HPC)、数据中心和机器学习应用。PPU 200可被配置为加速众多深度学习系统和应用，包括自动驾驶汽车平台、深度学习、高精度语音、图像和文本识别系统、智能视频分析、分子模拟、药物研发、疾病诊断、天气预报、大数据分析、天文学、分子动力学模拟、金融建模、机器人技术、工厂自动化、实时语言翻译、在线搜索优化和个性化用户推荐，等等。

如图2所示，PPU 200包括输入/输出(I/O)单元205、前端单元215、调度器单元220、工作分配单元225、集线器230、交叉开关(Xbar)270、一个或更多个通用处理集群(GPC)250以及一个或更多个分区单元280。PPU 200可以经由一个或更多个高速NVLink 210互连连接到主机处理器或其他PPU 200。PPU 200可以经由互连202连接到主机处理器或其他外围设备。PPU 200还可以连接到包括多个存储器设备204的本地存储器。在一个实施例中，本地存储器可以包括多个动态随机存取存储器(DRAM)设备。DRAM设备可以被配置为高带宽存储器(HBM)子系统，其中多个DRAM管芯(die)堆叠在每个设备内。

NVLink 210互连使得系统能够扩展并且包括与一个或更多个CPU结合的一个或更多个PPU 200，支持PPU 200和CPU之间的高速缓存一致性，以及CPU主控。数据和/或命令可以由NVLink 210通过集线器230发送到PPU 200的其他单元或从其发送，例如一个或更多个复制引擎、视频编码器、视频解码器、电源管理单元等(未明确示出)。结合图4B更详细地描述NVLink 210。

I/O单元205被配置为通过互连202从主机处理器(未示出)发送和接收通信(即，命令、数据等)。I/O单元205可以经由互连202直接与主机处理器通信，或通过一个或更多个中间设备(诸如内存桥)与主机处理器通信。在一个实施例中，I/O单元205可以经由互连202与一个或更多个其他处理器(例如，一个或更多个PPU 200)通信。在一个实施例中，I/O单元205实现外围组件互连高速(PCIe)接口，用于通过PCIe总线进行通信，并且互连202是PCIe总线。在替代的实施例中，I/O单元205可以实现其他类型的已知接口，用于与外部设备进行通信。

I/O单元205对经由互连202接收的数据包进行解码。在一个实施例中，数据包表示被配置为使PPU 200执行各种操作的命令。I/O单元205按照命令指定将解码的命令发送到PPU 200的各种其他单元。例如，一些命令可以被发送到前端单元215。其他命令可以被发送到集线器230或PPU200的其他单元，诸如一个或更多个复制引擎、视频编码器、视频解码器、电源管理单元等(未明确示出)。换句话说，I/O单元205被配置为在PPU200的各种逻辑单元之间和之中路由通信。

在一个实施例中，由主机处理器执行的程序在缓冲区中对命令流进行编码，该缓冲区向PPU 200提供工作量用于处理。工作量可以包括要由那些指令处理的许多指令和数据。缓冲区是存储器中可由主机处理器和PPU200两者访问(即，读/写)的区域。例如，I/O单元205可以被配置为经由通过互连202传输的存储器请求访问连接到互连202的系统存储器中的缓冲区。在一个实施例中，主机处理器将命令流写入缓冲区，然后向PPU200发送指向命令流开始的指针。前端单元215接收指向一个或更多个命令流的指针。前端单元215管理一个或更多个流，从流读取命令并将命令转发到PPU 200的各个单元。

前端单元215耦合到调度器单元220，其配置各种GPC 250以处理由一个或更多个流定义的任务。调度器单元220被配置为追踪与由调度器单元220管理的各种任务相关的状态信息。状态可以指示任务被指派给哪个GPC 250，该任务是活动的还是不活动的，与该任务相关联的优先级等等。调度器单元220管理一个或更多个GPC 250上的多个任务的执行。

调度器单元220耦合到工作分配单元225，其被配置为分派任务以在GPC 250上执行。工作分配单元225可以追踪从调度器单元220接收到的若干调度的任务。在一个实施例中，工作分配单元225为每个GPC 250管理待处理(pending)任务池和活动任务池。待处理任务池可以包括若干时隙(例如，32个时隙)，其包括被指派为由特定GPC 250处理的任务。活动任务池可以包括若干时隙(例如，4个时隙)，用于正在由GPC 250主动处理的任务。当GPC250完成任务的执行时，该任务从GPC 250的活动任务池中逐出，并且来自待处理任务池的其他任务之一被选择和调度以在GPC 250上执行。如果GPC 250上的活动任务已经空闲，例如在等待数据依赖性被解决时，那么活动任务可以从GPC 250中逐出并返回到待处理任务池，而待处理任务池中的另一个任务被选择并调度以在GPC 250上执行。

工作分配单元225经由XBar(交叉开关)270与一个或更多个GPC 250通信。XBar270是将PPU 200的许多单元耦合到PPU 200的其他单元的互连网络。例如，XBar 270可以被配置为将工作分配单元225耦合到特定的GPC 250。虽然没有明确示出，但PPU 200的一个或更多个其他单元也可以经由集线器230连接到XBar 270。

任务由调度器单元220管理并由工作分配单元225分派给GPC 250。GPC 250被配置为处理任务并生成结果。结果可以由GPC 250内的其他任务消耗，经由XBar 270路由到不同的GPC 250，或者存储在存储器204中。结果可以经由分区单元280写入存储器204，分区单元280实现用于从存储器204读取数据和向存储器204写入数据的存储器接口。结果可以通过NVLink 210发送到另一个PPU 200或CPU。在一个实施例中，PPU 200包括数目为U的分区单元280，其等于耦合到PPU 200的独立且不同的存储器设备204的数目。下面将结合图3B更详细地描述分区单元280。

在一个实施例中，主机处理器执行实现应用程序编程接口(API)的驱动程序内核，其使得能够在主机处理器上执行一个或更多个应用程序以调度操作用于在PPU 200上执行。在一个实施例中，多个计算应用由PPU200同时执行，并且PPU 200为多个计算应用程序提供隔离、服务质量(QoS)和独立地址空间。应用程序可以生成指令(例如，API调用)，其使得驱动程序内核生成一个或更多个任务以由PPU 200执行。驱动程序内核将任务输出到正在由PPU 200处理的一个或更多个流。每个任务可以包括一个或更多个相关线程组，本文称为线程束(warp)。在一个实施例中，线程束包括可以并行执行的32个相关线程。协作线程可以指代包括执行任务的指令并且可以通过共享存储器交换数据的多个线程。结合图4A更详细地描述线程和协作线程。

图3A示出了根据一个实施例的图2的PPU 200的GPC 250。如图3A所示，每个GPC250包括用于处理任务的多个硬件单元。在一个实施例中，每个GPC 250包括管线管理器310、预光栅操作单元(PROP)315、光栅引擎325、工作分配交叉开关(WDX)380、存储器管理单元(MMU)390以及一个或更多个数据处理集群(DPC)320。应当理解，图3A的GPC 250可以包括代替图3A中所示单元的其他硬件单元或除图3A中所示单元之外的其他硬件单元。

在一个实施例中，GPC 250的操作由管线管理器310控制。管线管理器310管理用于处理分配给GPC 250的任务的一个或更多个DPC 320的配置。在一个实施例中，管线管理器310可以配置一个或更多个DPC 320中的至少一个来实现图形渲染管线的至少一部分。例如，DPC 320可以被配置为在可编程流式多处理器(SM)340上执行顶点着色程序。管线管理器310还可以被配置为将从工作分配单元225接收的数据包路由到GPC 250中适当的逻辑单元。例如，一些数据包可以被路由到PROP 315和/或光栅引擎325中的固定功能硬件单元，而其他数据包可以被路由到DPC 320以供图元引擎335或SM 340处理。在一个实施例中，管线管理器310可以配置一个或更多个DPC 320中的至少一个以实现神经网络模型和/或计算管线。

PROP单元315被配置为将由光栅引擎325和DPC 320生成的数据路由到光栅操作(ROP)单元，结合图3B更详细地描述。PROP单元315还可以被配置为执行颜色混合的优化，组织像素数据，执行地址转换等。

光栅引擎325包括被配置为执行各种光栅操作的若干固定功能硬件单元。在一个实施例中，光栅引擎325包括设置引擎、粗光栅引擎、剔除引擎、裁剪引擎、精细光栅引擎和图块聚合引擎。设置引擎接收变换后的顶点并生成与由顶点定义的几何图元关联的平面方程。平面方程被发送到粗光栅引擎以生成图元的覆盖信息(例如，图块的x、y覆盖掩码)。粗光栅引擎的输出被发送到剔除引擎，其中与未通过z-测试的图元相关联的片段被剔除，并且被发送到裁剪引擎，其中位于视见平截头体之外的片段被裁剪掉。那些经过裁剪和剔除后留下来的片段可以被传递到精细光栅引擎，以基于由设置引擎生成的平面方程生成像素片段的属性。光栅引擎325的输出包括例如要由在DPC 320内实现的片段着色器处理的片段。

包括在GPC 250中的每个DPC 320包括M管道控制器(MPC)330、图元引擎335和一个或更多个SM 340。MPC 330控制DPC 320的操作，将从管线管理器310接收到的数据包路由到DPC 320中的适当单元。例如，与顶点相关联的数据包可以被路由到图元引擎335，图元引擎335被配置为从存储器204提取与顶点相关联的顶点属性。相反，与着色程序相关联的数据包可以被发送到SM 340。

SM 340包括被配置为处理由多个线程表示的任务的可编程流式处理器。每个SM340是多线程的并且被配置为同时执行来自特定线程组的多个线程(例如，32个线程)。在一个实施例中，SM 340实现SIMD(单指令、多数据)体系架构，其中线程组(即，线程束)中的每个线程被配置为基于相同的指令集来处理不同的数据集。线程组中的所有线程都执行相同的指令。在另一个实施例中，SM 340实现SIMT(单指令、多线程)体系架构，其中线程组中的每个线程被配置为基于相同的指令集处理不同的数据集，但是其中线程组中的各个线程在执行期间被允许发散。在一个实施例中，为每个线程束维护程序计数器、调用栈和执行状态，当线程束内的线程发散时，使能线程束之间的并发和线程束内的串行执行。在另一个实施例中，为每个个体线程维护程序计数器、调用栈和执行状态，从而在线程束内和线程束之间的所有线程之间实现相等的并发。当为每个个体线程维护执行状态时，执行相同指令的线程可以被收敛并且并行执行以获得最大效率。下面结合图4A更详细地描述SM 340。

MMU 390提供GPC 250和分区单元280之间的接口。MMU 390可以提供虚拟地址到物理地址的转换、存储器保护以及存储器请求的仲裁。在一个实施例中，MMU 390提供用于执行从虚拟地址到存储器204中的物理地址的转换的一个或更多个转换后备缓冲器(TLB)。

图3B示出了根据一个实施例的图2的PPU 200的存储器分区单元280。如图3B所示，存储器分区单元280包括光栅操作(ROP)单元350、二级(L2)高速缓存360和存储器接口370。存储器接口370耦合到存储器204。存储器接口370可以实现用于高速数据传输的32、64、128、1024位数据总线等。在一个实施例中，PPU 200合并了U个存储器接口370，每对分区单元280有一个存储器接口370，其中每对分区单元280连接到对应的存储器设备204。例如，PPU 200可以连接到多达Y个存储器设备204，诸如高带宽存储器堆叠或图形双数据速率版本5的同步动态随机存取存储器或其他类型的持久存储器。

在一个实施例中，存储器接口370实现HBM2存储器接口，并且Y等于U的一半。在一个实施例中，HBM2存储器堆叠位于与PPU 200相同的物理封装上，提供与常规GDDR5 SDRAM系统相比显著的功率高和面积节约。在一个实施例中，每个HBM2堆叠包括四个存储器管芯并且Y等于4，其中HBM2堆叠包括每个管芯两个128位通道，总共8个通道和1024位的数据总线宽度。

在一个实施例中，存储器204支持单错校正双错检测(SECDED)纠错码(ECC)以保护数据。对于对数据损毁敏感的计算应用程序，ECC提供了更高的可靠性。在大型集群计算环境中，PPU 200处理非常大的数据集和/或长时间运行应用程序，可靠性尤其重要。

在一个实施例中，PPU 200实现多级存储器层次。在一个实施例中，存储器分区单元280支持统一存储器以为CPU和PPU 200存储器提供单个统一的虚拟地址空间，使得虚拟存储器系统之间的数据能够共享。在一个实施例中，追踪PPU 200对位于其他处理器上的存储器的访问频率，以确保存储器页面被移动到更频繁地访问该页面的PPU 200的物理存储器。在一个实施例中，NVLink 210支持地址转换服务，其允许PPU 200直接访问CPU的页表并且提供由PPU 200对CPU存储器的完全访问。

在一个实施例中，复制引擎在多个PPU 200之间或在PPU 200与CPU之间传输数据。复制引擎可以为未映射到页表的地址生成页面错误。然后，存储器分区单元280可以服务页面错误，将地址映射到页表中，之后复制引擎可以执行传输。在常规系统中，针对多个处理器之间的多个复制引擎操作固定存储器(即，不可分页)，其显著减少了可用存储器。由于硬件分页错误，地址可以传递到复制引擎而不用担心存储器页面是否驻留，并且复制过程是否透明。

来自存储器204或其他系统存储器的数据可以由存储器分区单元280取回并存储在L2高速缓存360中，L2高速缓存360位于芯片上并且在各个GPC 250之间共享。如图所示，每个存储器分区单元280包括与对应的存储器设备204相关联的L2高速缓存360的一部分。然后可以在GPC 250内的多个单元中实现较低级高速缓存。例如，每个SM 340可以实现一级(L1)高速缓存。L1高速缓存是专用于特定SM 340的专用存储器。来自L2高速缓存360的数据可以被获取并存储在每个L1高速缓存中，以在SM340的功能单元中进行处理。L2高速缓存360被耦合到存储器接口370和XBar 270。

ROP单元350执行与诸如颜色压缩、像素混合等像素颜色相关的图形光栅操作。ROP单元350还与光栅引擎325一起实现深度测试，从光栅引擎325的剔除引擎接收与像素片段相关联的样本位置的深度。测试与片段关联的样本位置相对于深度缓冲区中的对应深度的深度。如果片段通过样本位置的深度测试，则ROP单元350更新深度缓冲区并将深度测试的结果发送给光栅引擎325。将理解的是，分区单元280的数量可以不同于GPC250的数量，并且因此每个ROP单元350可以耦合到每个GPC 250。ROP单元350追踪从不同GPC 250接收到的数据包并且确定由ROP单元350生成的结果通过Xbar 270被路由到哪个GPC 250。尽管在图3B中ROP单元350被包括在存储器分区单元280内，但是在其他实施例中，ROP单元350可以在存储器分区单元280之外。例如，ROP单元350可以驻留在GPC250或另一个单元中。

图4A示出了根据一个实施例的图3A的流式多处理器340。如图4A所示，SM 340包括指令高速缓存405、一个或更多个调度器单元410(K)、寄存器文件420、一个或更多个处理核心450、一个或更多个特殊功能单元(SFU)452、一个或更多个加载/存储单元(LSU)454、互连网络480、共享存储器/L1高速缓存470。

如上所述，工作分配单元225调度任务以在PPU 200的GPC 250上执行。任务被分配给GPC 250内的特定DPC 320，并且如果该任务与着色器程序相关联，则该任务可以被分配给SM 340。调度器单元410(K)接收来自工作分配单元225的任务并且管理指派给SM 340的一个或更多个线程块的指令调度。调度器单元410(K)调度线程块以作为并行线程的线程束执行，其中每个线程块被分配至少一个线程束。在一个实施例中，每个线程束执行32个线程。调度器单元410(K)可以管理多个不同的线程块，将线程束分配给不同的线程块，然后在每个时钟周期期间将来自多个不同的协作组的指令分派到各个功能单元(即，核心450、SFU452和LSU 454)。

协作组是用于组织通信线程组的编程模型，其允许开发者表达线程正在进行通信所采用的粒度，使得能够表达更丰富、更高效的并行分解。协作启动API支持线程块之间的同步性，以执行并行算法。常规的编程模型为同步协作线程提供了单一的简单结构：跨线程块的所有线程的栅栏(barrier)(即，syncthreads()函数)。然而，程序员通常希望以小于线程块粒度的粒度定义线程组，并在所定义的组内同步，以集体的全组功能接口(collective group-wide function interface)的形式使能更高的性能、设计灵活性和软件重用。

协作组使得程序员能够在子块(即，像单个线程一样小)和多块粒度处明确定义线程组并且执行集体操作，诸如协作组中的线程上的同步性。编程模型支持跨软件边界的干净组合，以便库和效用函数可以在他们本地环境中安全地同步，而无需对收敛进行假设。协作组图元启用合作并行的新模式，包括生产者-消费者并行、机会主义并行以及跨整个线程块网格的全局同步。

分派单元415被配置为向一个或更多个功能单元传送指令。在该实施例中，调度器单元410(K)包括两个分派单元415，其使得能够在每个时钟周期期间调度来自相同线程束的两个不同指令。在替代实施例中，每个调度器单元410(K)可以包括单个分派单元415或附加分派单元415。

每个SM 340包括寄存器文件420，其提供用于SM 340的功能单元的一组寄存器。在一个实施例中，寄存器文件420在每个功能单元之间被划分，使得每个功能单元被分配寄存器文件420的专用部分。在另一个实施例中，寄存器文件420在由SM 340执行的不同线程束之间被划分。寄存器文件420为连接到功能单元的数据路径的操作数提供临时存储器。

每个SM 340包括L个处理核心450。在一个实施例中，SM 340包括大量(例如128个等)不同的处理核心450。每个核心450可以包括完全管线化的、单精度、双精度和/或混合精度处理单元，其包括浮点运算逻辑单元和整数运算逻辑单元。在一个实施例中，浮点运算逻辑单元实现用于浮点运算的IEEE 754-2008标准。在一个实施例中，核心450包括64个单精度(32位)浮点核心、64个整数核心、32个双精度(64位)浮点核心和8个张量核心(tensorcore)。

张量核心被配置为执行矩阵运算，并且在一个实施例中，一个或更多个张量核心被包括在核心450中。具体地，张量核心被配置为执行深度学习矩阵运算，诸如用于神经网络训练和推理的卷积运算。在一个实施例中，每个张量核心在4×4矩阵上运算并且执行矩阵乘法和累加运算D＝A×B+C，其中A、B、C和D是4×4矩阵。

在一个实施例中，矩阵乘法输入A和B是16位浮点矩阵，而累加矩阵C和D可以是16位浮点或32位浮点矩阵。张量核心在16位浮点输入数据以及32位浮点累加上运算。16位浮点乘法需要64次运算，产生全精度的积，然后使用32位浮点与4×4×4矩阵乘法的其他中间积相加来累加。在实践中，张量核心用于执行由这些较小的元件建立的更大的二维或更高维的矩阵运算。API(诸如CUDA 9C++API)公开了专门的矩阵加载、矩阵乘法和累加以及矩阵存储运算，以便有效地使用来自CUDA-C++程序的张量核心。在CUDA层面，线程束级接口假定16×16尺寸矩阵跨越线程束的全部32个线程。

每个SM 340还包括执行特殊函数(例如，属性评估、倒数平方根等)的M个SFU 452。在一个实施例中，SFU 452可以包括树遍历单元，其被配置为遍历分层树数据结构。在一个实施例中，SFU 452可以包括被配置为执行纹理图过滤操作的纹理单元。在一个实施例中，纹理单元被配置为从存储器204加载纹理图(例如，纹理像素的2D阵列)并且对纹理图进行采样以产生经采样的纹理值，用于在由SM 340执行的着色器程序中使用。在一个实施例中，纹理图被存储在共享存储器/L1高速缓存370中。纹理单元实现纹理操作，诸如使用mip图(即，不同细节层次的纹理图)的过滤操作。在一个实施例中，每个SM 340包括两个纹理单元。

每个SM 340还包括N个LSU 454，其实现共享存储器/L1高速缓存470和寄存器文件420之间的加载和存储操作。每个SM 340包括将每个功能单元连接到寄存器文件420以及将LSU 454连接到寄存器文件420、共享存储器/L1高速缓存470的互连网络480。在一个实施例中，互连网络480是交叉开关，其可以被配置为将任何功能单元连接到寄存器文件420中的任何寄存器，以及将LSU 454连接到寄存器文件和共享存储器/L1高速缓存470中的存储器位置。

共享存储器/L1高速缓存470是片上存储器阵列，其允许数据存储和SM 340与图元引擎335之间以及SM 340中的线程之间的通信。在一个实施例中，共享存储器/L1高速缓存470包括128KB的存储容量并且在从SM 340到分区单元280的路径中。共享存储器/L1高速缓存470可以用于高速缓存读取和写入。共享存储器/L1高速缓存470、L2高速缓存360和存储器204中的一个或更多个是后备存储。

将数据高速缓存和共享存储器功能组合成单个存储器块为两种类型的存储器访问提供最佳的总体性能。该容量可由程序用作不使用共享存储器的高速缓存。例如，如果将共享存储器配置为使用一半容量，则纹理和加载/存储操作可以使用剩余容量。在共享存储器/L1高速缓存470内的集成使共享存储器/L1高速缓存470起到用于流式传输数据的高吞吐量管线的作用，并且同时提供对频繁重用数据的高带宽和低延迟的访问。

当被配置用于通用并行计算时，与图形处理相比，可以使用更简单的配置。具体地，图2所示的固定功能图形处理单元被绕过，创建了更简单的编程模型。在通用并行计算配置中，工作分配单元225将线程块直接指派并分配给DPC 320。块中的线程执行相同的程序，使用计算中的唯一线程ID来确保每个线程生成唯一结果，使用SM 340执行程序并执行计算，使用共享存储器/L1高速缓存470以在线程之间通信，以及使用LSU 454通过共享存储器/L1高速缓存470和存储器分区单元280读取和写入全局存储器。当被配置用于通用并行计算时，SM 340还可以写入调度器单元220可用来在DPC 320上启动新工作的命令。

PPU 200可以被包括在台式计算机、膝上型计算机、平板电脑、服务器、超级计算机、智能电话(例如，无线、手持设备)、个人数字助理(PDA)、数码相机、运载工具、头戴式显示器、手持式电子设备等中。在一个实施例中，PPU 200包括在单个半导体衬底上。在另一个实施例中，PPU 200与一个或更多个其他器件(诸如附加PPU 200、存储器204、精简指令集计算机(RISC)CPU、存储器管理单元(MMU)、数字-模拟转换器(DAC)等)一起被包括在片上系统(SoC)上。

在一个实施例中，PPU 200可以被包括在图形卡上，图形卡包括一个或更多个存储器设备204。图形卡可以被配置为与台式计算机的主板上的PCIe插槽接口。在又一个实施例中，PPU 200可以是包括在主板的芯片集中的集成图形处理单元(iGPU)或并行处理器。

示例性计算系统

具有多个GPU和CPU的系统被用于各种行业，因为开发者在应用(诸如人工智能计算)中暴露和利用更多的并行性。在数据中心、研究机构和超级计算机中部署具有数十至数千个计算节点的高性能GPU加速系统，以解决更大的问题。随着高性能系统内处理设备数量的增加，通信和数据传输机制需要扩展以支持该增加带宽。

图4B是根据一个实施例的使用图2的PPU 200实现的处理系统400的概念图。示例性系统400可以被配置为实现图1中所示的方法100。处理系统400包括CPU 430、交换机410和多个PPU 200中的每一个以及相应的存储器204。NVLink 210提供每个PPU 200之间的高速通信链路。尽管图4B中示出了特定数量的NVLink 210和互连202连接，但是连接到每个PPU 200和CPU 430的连接的数量可以改变。交换机410在互连202和CPU 430之间接口。PPU200、存储器204和NVLink 210可以位于单个半导体平台上以形成并行处理模块425。在一个实施例中，交换机410支持两个或更多个在各种不同连接和/或链路之间接口的协议。

在另一个实施例(未示出)中，NVLink 210在每个PPU 200和CPU 430之间提供一个或更多个高速通信链路，并且交换机410在互连202和每个PPU 200之间进行接口。PPU 200、存储器204和互连202可以位于单个半导体平台上以形成并行处理模块425。在又一个实施例(未示出)中，互连202在每个PPU 200和CPU 430之间提供一个或更多个通信链路，并且交换机410使用NVLink 210在每个PPU 200之间进行接口，以在PPU 200之间提供一个或更多个高速通信链路。在另一个实施例(未示出)中，NVLink 210在PPU 200和CPU 430之间通过交换机410提供一个或更多个高速通信链路。在又一个实施例(未示出)中，互连202在每个PPU 200之间直接地提供一个或更多个通信链路。可以使用与NVLink 210相同的协议将一个或更多个NVLink 210高速通信链路实现为物理NVLink互连或者片上或管芯上互连。

在本说明书的上下文中，单个半导体平台可以指在管芯或芯片上制造的唯一的单一的基于半导体的集成电路。应该注意的是，术语单个半导体平台也可以指具有增加的连接的多芯片模块，其模拟片上操作并通过利用常规总线实现方式进行实质性改进。当然，根据用户的需要，各种电路或器件还可以分开放置或以半导体平台的各种组合来放置。可选地，并行处理模块425可以被实现为电路板衬底，并且PPU 200和/或存储器204中的每一个可以是封装器件。在一个实施例中，CPU 430、交换机410和并行处理模块425位于单个半导体平台上。

在一个实施例中，每个NVLink 210的信令速率是20到25千兆位/秒，并且每个PPU200包括六个NVLink 210接口(如图4B所示，每个PPU 200包括五个NVLink 210接口)。每个NVLink 210在每个方向上提供25千兆位/秒的数据传输速率，其中六条链路提供300千兆位/秒。当CPU 430还包括一个或更多个NVLink 210接口时，NVLink 210可专门用于如图4B所示的PPU到PPU通信，或者PPU到PPU以及PPU到CPU的某种组合。

在一个实施例中，NVLink 210允许从CPU 430到每个PPU 200的存储器204的直接加载/存储/原子访问。在一个实施例中，NVLink 210支持一致性操作，允许从存储器204读取的数据被存储在CPU 430的高速缓存分层结构中，减少了CPU 430的高速缓存访问延迟。在一个实施例中，NVLink 210包括对地址转换服务(ATS)的支持，允许PPU 200直接访问CPU430内的页表。一个或更多个NVLink 210还可以被配置为以低功率模式操作。

图4C示出了示例性系统465，其中可以实现各种先前实施例的各种体系架构和/或功能。示例性系统465可被配置为实现图1中所示的方法100。

如图所示，提供系统465，其包括连接到通信总线475的至少一个中央处理单元430。通信总线475可以使用任何合适的协议来实现，诸如PCI(外围组件互连)、PCI-Express、AGP(加速图形端口)、超传输或任何其他总线或一个或更多个点对点通信协议。系统465还包括主存储器440。控制逻辑(软件)和数据被存储在主存储器440中，主存储器440可以采取随机存取存储器(RAM)的形式。

系统465还包括输入设备460、并行处理系统425和显示设备445，即常规CRT(阴极射线管)、LCD(液晶显示器)、LED(发光二极管)、等离子显示器等。可以从输入设备460(例如键盘、鼠标、触摸板、麦克风等)接收用户输入。前述模块和/或设备中的每一个甚至可以位于单个半导体平台上以形成系统465。可选地，根据用户的需要，各个模块还可以分开放置或以半导体平台的各种组合来放置。

此外，系统465可以出于通信目的通过网络接口435耦合到网络(例如，电信网络、局域网(LAN)、无线网络、广域网(WAN)(诸如因特网)、对等网络、电缆网络等)。

系统465还可以包括辅助存储(未示出)。辅助存储包括例如硬盘驱动器和/或可移除存储驱动器、代表软盘驱动器、磁带驱动器、光盘驱动器、数字多功能盘(DVD)驱动器、记录设备、通用串行总线(USB)闪存。可移除存储驱动器以众所周知的方式从可移除存储单元读取和/或写入可移除存储单元。

计算机程序或计算机控制逻辑算法可以存储在主存储器440和/或辅助存储中。这些计算机程序在被执行时使得系统465能够执行各种功能。存储器440、存储和/或任何其他存储是计算机可读介质的可能示例。

各种在先附图的体系架构和/或功能可以在通用计算机系统、电路板系统、专用于娱乐目的的游戏控制台系统、专用系统和/或任何其他所需的系统的上下文中实现。例如，系统465可以采取台式计算机、膝上型计算机、平板电脑、服务器、超级计算机、智能电话(例如，无线、手持设备)、个人数字助理(PDA)、数字相机、运载工具、头戴式显示器、手持式电子设备、移动电话设备、电视机、工作站、游戏控制台、嵌入式系统和/或任何其他类型的逻辑的形式。

虽然上面已经描述了各种实施例，但是应该理解，它们仅以示例的方式呈现，而不是限制。因此，优选实施例的宽度和范围不应受任何上述示例性实施例的限制，而应仅根据所附权利要求及其等同物来限定。

图形处理管线

在一个实施例中，PPU 200包括图形处理单元(GPU)。PPU 200被配置为接收指定用于处理图形数据的着色程序的命令。图形数据可以被定义为一组图元，例如点、线、三角形、四边形、三角形带等。典型地，图元包括指定图元的多个顶点(例如，在模型空间坐标系中)的数据以及与图元的每个顶点相关联的属性。PPU 200可以被配置为处理图元以生成帧缓冲区(即，用于显示器的像素中的每一个的像素数据)。

应用程序将场景的模型数据(例如，顶点和属性的集合)写入存储器(诸如系统存储器或存储器204)。模型数据定义可能在显示器上可见的对象中的每一个。然后应用程序对驱动程序内核进行API调用，其请求要被渲染和显示的模型数据。驱动程序内核读取模型数据并将命令写入一个或更多个流以执行操作来处理模型数据。这些命令可以参考要在PPU 200的SM 340上实现的不同着色程序，包括顶点着色、外壳着色、域着色、几何着色和像素着色中的一个或更多个。例如，SM 340中的一个或更多个可以被配置为执行顶点着色程序，其处理由模型数据定义的多个顶点。在一个实施例中，不同的SM 340可以被配置为同时执行不同的着色程序。例如，SM 340的第一子集可以被配置为执行顶点着色程序，而SM 340的第二子集可以被配置为执行像素着色程序。SM 340的第一子集处理顶点数据以产生经处理的顶点数据，并将经处理的顶点数据写入L2高速缓存360和/或存储器204。在经处理的顶点数据被光栅化(例如，从三维数据转换成屏幕空间中的二维数据)以产生片段数据之后，SM 340的第二子集执行像素着色以产生经处理的片段数据，然后将其与其他经处理的片段数据混合并被写入存储器204中的帧缓冲区。顶点着色程序和像素着色程序可以同时执行，以管线方式处理来自同一场景的不同数据，直到该场景的所有模型数据已经被渲染到帧缓冲区。然后，帧缓冲区的内容被传送到显示控制器以在显示设备上显示。

图5是根据一个实施例的由图2的PPU 200实现的图形处理管线500的概念图。图形处理管线500是被实现以从3D几何数据生成2D计算机生成图像的处理步骤的抽象流程图。众所周知，管线架构可以通过将操作分成多个阶段来更高效地执行长延迟操作，其中每个阶段的输出耦合到下一个连续阶段的输入。因此，图形处理管线500接收从图形处理管线500的一个阶段传送到下一阶段的输入数据501，以生成输出数据502。在一个实施例中，图形处理管线500可表示由

API定义的图形处理管线。作为选择，图形处理管线500可以在先前附图和/或一个或更多个任何后续附图的功能和架构的上下文中实现。

如图5所示，图形处理管线500包括包括多个阶段的管线架构。这些阶段包括但不限于数据组装阶段510、顶点着色阶段520、图元组装阶段530、几何着色阶段540、视口缩放、剔除和裁剪(viewport scale,cull,and clip，VSCC)阶段550、光栅化阶段560、片段着色阶段570和光栅操作阶段580。在一个实施例中，输入数据501包括命令，其配置处理单元以实现图形处理管线500的阶段，并配置几何图元(例如，点、线、三角形、四边形、三角形带或扇形等)以由这些阶段处理。输出数据502可以包括像素数据(即，颜色数据)，其被复制到存储器中的帧缓冲区或其他类型的表面数据结构中。

数据组装阶段510接收输入数据501，其指定用于高阶表面、图元等的顶点数据。数据组装阶段510收集临时存储或队列中的顶点数据，诸如通过从主机处理器接收包括指向存储器中的缓冲区的指针的命令并从该缓冲区读取顶点数据。顶点数据然后被传送到顶点着色阶段520以进行处理。

顶点着色阶段520通过对顶点中的每一个执行一次一组操作(即，顶点着色器或程序)来处理顶点数据。顶点可以例如被指定为与一个或更多个顶点属性(例如，颜色、纹理坐标、表面法线等)相关联的4坐标向量(即，<x，y，z，w>)。顶点着色阶段520可以操纵各个顶点属性，诸如位置、颜色、纹理坐标等。换句话说，顶点着色阶段520对与顶点相关联的顶点坐标或其他顶点属性执行操作。这些操作通常包括光照操作(即，修改顶点的颜色属性)和变换操作(即，修改顶点的坐标空间)。例如，可以使用对象坐标空间中的坐标来指定顶点，其通过将坐标乘以矩阵进行变换，该矩阵将坐标从对象坐标空间转换到世界空间或归一化设备坐标(normalized-device-coordinate，NCD)空间。顶点着色阶段520生成被传送到图元组装阶段530的经变换的顶点数据。

图元组装阶段530收集由顶点着色阶段520输出的顶点并且将顶点分组成几何图元以由几何着色阶段540处理。例如，图元组装阶段530可以被配置为将每三个连续顶点分组为用于传送到几何着色阶段540的几何图元(即，三角形)。在一些实施例中，特定顶点可以被重新用于连续几何图元(例如，三角形带中的两个连续三角形可以共享两个顶点)。图元组装阶段530将几何图元(即，相关联的顶点的集合)传送到几何着色阶段540。

几何着色阶段540通过对几何图元执行一组操作(即，几何着色器或程序)来处理几何图元。曲面细分(tessellation)操作可以从每个几何图元生成一个或更多个几何图元。换言之，几何着色阶段540可以将每个几何图元细分为两个或更多个几何图元的更精细的网格，以由图形处理管线500的其余部分进行处理。几何着色阶段540将几何图元传送到视口SCC阶段550。

在一个实施例中，图形处理管线500可以在流式多处理器和顶点着色阶段520、图元组装阶段530、几何着色阶段540、片段着色阶段570和/或与其相关联的硬件/软件内操作，可顺序地执行处理操作。一旦顺序处理操作完成，在一个实施例中，视口SCC阶段550可以利用数据。在一个实施例中，由图形处理管线500中的阶段的一个或更多个处理的图元数据可以被写入高速缓存(例如，L1高速缓存、顶点高速缓存等)中。在这种情况下，在一个实施例中，视口SCC阶段550可以访问高速缓存中的数据。在一个实施例中，视口SCC阶段550和光栅化阶段560被实现为固定功能电路。

视口SCC阶段550执行几何图元的视口缩放、剔除和裁剪。正被渲染的每个表面都与抽象相机位置相关联。相机位置表示正观看该场景的观看者的位置并定义了包围该场景的对象的视见平截头体。视见平截头体可以包括观看平面、后平面和四个裁剪平面。完全位于视见平截头体之外的任何几何图元都可被剔除(即，被丢弃)，因为这些几何图元将不会对最终渲染的场景做出贡献。部分位于视见平截头体内并且部分位于视见平截头体外的任何几何图元可以被裁剪(即，转换为被包围在视见平截头体内的新的几何图元)。此外，可以基于视见平截头体的深度来对每个几何图元进行缩放。然后将所有可能可见的几何图元传送到光栅化阶段560。

光栅化阶段560将3D几何图元转换成2D片段(例如，能够用于显示等)。光栅化阶段560可以被配置为利用几何图元的顶点来设置一组平面方程，从中可以内插各种属性。光栅化阶段560还可以计算多个像素的覆盖掩码，其指示像素的一个或更多个样本位置是否拦截几何图元。在一个实施例中，还可以执行z测试以确定几何图元是否被已经被光栅化的其他几何图元遮挡。光栅化阶段560生成片段数据(即，与每个被覆盖像素的特定样本位置相关联的内插顶点属性)，其被传送到片段着色阶段570。

片段着色阶段570通过对片段中的每一个执行一组操作(即，片段着色器或程序)来处理片段数据。片段着色阶段570可以生成片段的像素数据(即，颜色值)，诸如通过使用片段的内插纹理坐标执行光照操作或采样纹理图。片段着色阶段570生成像素数据，其被发送到光栅操作阶段580。

光栅操作阶段580可对像素数据执行各种操作，诸如执行阿尔法测试、模板测试(stencil test)以及将像素数据与对应于与像素相关联的其他片段的其他像素数据混合。当光栅操作阶段580已经完成对像素数据(即，输出数据502)的处理时，可以将像素数据写入渲染目标，诸如帧缓冲区、颜色缓冲区等。

应当领会，除上述阶段中的一个或更多个以外或代替上述阶段中的一个或更多个，一个或更多个额外的阶段可以被包括在图形处理管线500中。抽象图形处理管线的各种实现方式可以实现不同的阶段。此外，在一些实施例中，上述阶段中的一个或更多个可以从图形处理管线中排除(诸如几何着色阶段540)。其他类型的图形处理管线被认为是在本公开的范围内所构想的。此外，图形处理管线500的任何阶段可以由图形处理器(诸如PPU200)内的一个或更多个专用硬件单元来实现。图形处理管线500的其他阶段可以由可编程硬件单元(诸如PPU 200的SM 340)来实现。

图形处理管线500可以经由由主机处理器(诸如CPU)执行的应用程序来实现。在一个实施例中，设备驱动程序可以实现应用程序编程接口(API)，其定义可以被应用程序利用以生成用于显示的图形数据的各种功能。设备驱动程序是软件程序，其包括控制PPU 200的操作的多个指令。API为程序员提供抽象，其允许程序员利用专用图形硬件(诸如PPU 200)来生成图形数据而不要求程序员利用PPU 200的特定指令集。应用程序可以包括被路由到PPU 200的设备驱动程序的API调用。设备驱动程序解释API调用并执行各种操作以响应API调用。在一些情况下，设备驱动程序可以通过在CPU上执行指令来执行操作。在其他情况下，设备驱动程序可以至少部分地通过利用CPU和PPU 200之间的输入/输出接口在PPU 200上启动操作来执行操作。在一个实施例中，设备驱动程序被配置为利用PPU200的硬件来实现图形处理管线500。

可以在PPU 200内执行各种程序以便实现图形处理管线500的各个阶段。例如，设备驱动程序可以启动PPU 200上的内核以在一个SM 340(或多个SM 340)上执行顶点着色阶段520。设备驱动程序(或由PPU 300执行的初始内核)还可启动PPU 300上的其他内核以执行图形处理管线500的其他阶段，诸如几何着色阶段540和片段着色阶段570。另外，图形处理管线500的阶段中的一些可以在固定单元硬件(诸如在PPU 300内实现的光栅器或数据组装器)上实现。应当领会，在被SM 340上的后续内核处理之前，来自一个内核的结果可以由一个或更多个中间固定功能硬件单元处理。

示例游戏流式传输系统

现在参考图6，图6是根据本公开的一些实施例的游戏流式传输系统600的示例系统图。图6包括一个或更多个游戏服务器602(其可以包括与图7的示例计算设备700类似的组件、特征和/或功能)，一个或更多个客户端设备604(其可包括与图7的示例计算设备700相似的组件、特征和/或功能)和一个或更多个网络606(其可与本文的一个或更多个网络类似)。在本公开的一些实施例中，可以实现系统600。

在系统600中，对于游戏会话，一个或更多个客户端设备604可以响应于对一个或更多个输入设备的输入仅接收输入数据，将输入数据发送到一个或更多个游戏服务器602，从一个或更多个游戏服务器602接收编码的显示数据，并在显示器624上显示该显示数据。这样，计算强度更高的计算和处理被卸载到一个或更多个游戏服务器602(例如，针对游戏会话的图形输出的渲染(具体为光线或路径追踪)由一个或更多个游戏服务器602的一个或更多个GPU执行)。换句话说，游戏会话从一个或更多个游戏服务器602被流式传输到一个或更多个客户端设备604，从而降低了一个或更多个客户端设备604对图形处理和渲染的需求。

例如，参照游戏会话的实例化，客户端设备604可以基于从一个或更多个游戏服务器602接收到显示数据而在显示器624上显示游戏会话的帧。客户端设备604可以接收对一个或更多个输入设备之一的输入，并作为响应生成输入数据。客户端设备604可以经由一个或更多个通信接口620并且通过一个或更多个网络606(例如，因特网)将输入数据发送到一个或更多个游戏服务器602，并且一个或更多个游戏服务器602可以经由通信接口618接收输入数据。一个或更多个CPU可以接收输入数据，处理输入数据，并且将数据发送到一个或更多个GPU，从而使一个或更多个GPU生成游戏会话的渲染。例如，输入数据可以表示用户在游戏中的角色的移动，武器开火，重新加载，传球，车辆转弯等。渲染组件612可以渲染游戏会话(例如，表示输入数据的结果)，并且渲染捕获组件614可以将游戏会话的渲染捕获为显示数据(例如，作为捕获游戏会话的渲染帧的图像数据)。游戏会话的渲染可以包括使用一个或更多个并行处理单元(如GPU)计算的光线或路径追踪的照明和/或阴影效果，该一个或更多个并行处理单元可以进一步采用一个或更多个专用硬件加速器或处理核心来执行一个或更多个游戏服务器602的光线或路径追踪技术。然后，编码器616可以对显示数据进行编码以生成编码的显示数据，并且编码的显示数据可以经由通信接口618通过一个或更多个网络606被发送到客户端设备604。客户端设备604可以经由通信接口620接收编码的显示数据，并且解码器622可以将编码的显示数据进行解码以生成显示数据。然后，客户端设备604可以经由显示器624显示该显示数据。

示例计算设备

图7是适合用于实现本公开的一些实施例的一个或更多个示例计算设备700的框图。计算设备700可以包括直接或间接耦合以下设备的互连系统702：存储器704，一个或更多个中央处理单元(CPU)706，一个或更多个图形处理单元(GPU)708，通信接口710，输入/输出(I/O)端口712，输入/输出组件714，电源716，一个或更多个呈现组件718(例如，一个或更多个显示器)以及一个或更多个逻辑单元720。

尽管图7的各个框被示出为经由互连系统702与线路连接，但这不旨在是限制而仅是为了清楚。例如，在一些实施例中，呈现组件718(诸如显示设备)可以被认为是I/O组件714(例如，如果显示器是触摸屏)。作为另一个示例，CPU 706和/或GPU 708可以包括存储器(例如，除了GPU 708、CPU 706和/或其他组件的存储器之外，存储器704还可以表示存储设备)。换句话说，图7的计算设备仅是说明性的。在如“工作站”，“服务器”，“笔记本电脑”，“台式机”，“平板电脑”，“客户端设备”，“移动设备”，“手持设备”，“游戏机”，“电子控制单元(ECU)”，“虚拟现实系统”和/或其他设备或系统类型等类别之间未进行区分，均被考虑在图7的计算设备的范围内。

互连系统702可以表示一个或更多个链路或总线，例如地址总线，数据总线，控制总线或其组合。互连系统702可以包括一种或更多种总线或链路类型，例如工业标准架构(ISA)总线，扩展工业标准架构(EISA)总线，视频电子标准协会(VESA)总线，外围组件互连(PCI)总线，外围组件互连快速(PCIe)总线和/或另一种类型的总线或链路。在一些实施例中，组件之间存在直接连接。作为示例，CPU 706可直接连接到存储器704。进一步，CPU 706可直接连接到GPU 708。在组件之间存在直接连接或点对点连接的情况下，互连系统702可以包括PCIe链路以执行连接。在这些示例中，PCI总线不需要被包括在计算设备700中。

存储器704可以包括各种计算机可读介质中的任何一种。计算机可读介质可以是计算设备700可以访问的任何可用介质。计算机可读介质可以包括易失性和非易失性介质以及可移除和不可移除介质。作为示例而非限制，计算机可读介质可以包括计算机存储介质和通信介质。

计算机存储介质可以包括以用于存储信息(例如计算机可读指令，数据结构，程序模块和/或其他数据类型)的任何方法或技术实现的易失性和非易失性介质和/或可移除和不可移除介质。例如，存储器704可以存储计算机可读指令(例如，其表示一个或更多个程序和/或一个或更多个程序元件，诸如操作系统)。计算机存储介质可以包括但不限于RAM，ROM，EEPROM，闪存或其他存储技术，CD-ROM，数字多功能盘(DVD)或其他光盘存储设备，盒式磁带，磁带，磁盘存储设备或其他磁存储设备，或可以用于存储期望的信息并且可以由计算设备700访问的任何其他介质。如本文所使用的，计算机存储介质本身不包括信号。

计算机存储介质可以在调制数据信号(诸如载波或其他传输机制)中包括计算机可读指令，数据结构，程序模块和/或其他数据类型，并且包括任何信息传递介质。术语“调制数据信号”可以指具有以将信息编码到信号中的方式设置或改变的一个或更多个特征的信号。作为示例而非限制，计算机存储介质可以包括有线介质(诸如有线网络或直接有线连接)，以及无线介质(诸如声学，RF，红外和其他无线介质)。以上任何内容的组合也应包括在计算机可读介质的范围内。

一个或更多个CPU 706可以被配置为执行至少一些计算机可读指令以控制计算设备700的一个或更多个组件执行本文描述的方法和/或过程中的一个或更多个。一个或更多个CPU 706的每一个可以包括能够同时处理众多软件线程的一个或更多个核心(例如，一个，两个，四个，八个，二十八个，七十二个等等)。一个或更多个CPU 706可以包括任何类型的处理器，并且取决于所实现的计算设备700的类型可以包括不同类型的处理器(例如，用于移动设备的具有较少核心的处理器以及用于服务器的具有更多核心的处理器)。例如，取决于计算设备700的类型，处理器可以是使用精简指令集计算(RISC)实现的高级RISC机器(ARM)处理器或使用复杂指令集计算(CISC)实现的x86处理器。除了一个或更多个微处理器或辅助协处理器(例如数学协处理器)之外，计算设备700还可包括一个或更多个CPU 706。

除了一个或更多个CPU 706之外或替代一个或更多个CPU 706，一个或更多个GPU708可以被配置成执行计算机可读指令中的至少一些，以控制计算设备700的一个或更多个组件执行在此描述的方法和/或过程中的一个或更多个。GPU 708中的一个或更多个可以为集成GPU(例如，与CPU 706中的一个或更多个集成和/或GPU 708中的一个或更多个可为离散GPU)。在实施例中，GPU 708中的一个或更多个可以是CPU 706中的一个或更多个的协处理器。GPU 708可由计算设备700使用以渲染图形(例如，3D图形)或执行通用计算。例如，GPU708可用于GPU上的通用计算(GPGPU)。一个或更多个GPU 708可以包括能够同时处理数百或数千个软件线程的数百或数千个核心。一个或更多个GPU 708可以响应于渲染命令(例如，经由主机接口从一个或更多个CPU 706接收的渲染命令)生成用于输出图像的像素数据。一个或更多个GPU 708可以包括用于存储像素数据或任何其他合适的数据(诸如GPGPU数据)的图形存储器，例如显示存储器。显示存储器可以被包括为存储器704的一部分。一个或更多个GPU 708可以包括并行操作的两个或更多个GPU(例如，经由链路)。链路可以直接连接GPU(例如，使用NVLINK)或可以通过交换机(例如，使用NVSwitch)连接GPU。当组合在一起时，每个GPU 708可以生成用于输出的不同部分或用于不同输出的像素数据或GPGPU数据(例如，用于第一图像的第一GPU和用于第二图像的第二GPU)。每个GPU可以包括自己的存储器，或可以与其他GPU共享存储器。

除了CPU 706和/或GPU 708之外或替代CPU 706和/或GPU 708，逻辑单元720可以被配置成执行计算机可读指令中的至少一些，以控制计算设备700的一个或更多个组件执行在此描述的方法和/或过程中的一个或更多个。在实施例中，CPU 706、GPU 708和/或逻辑单元720可以离散地或联合地执行方法、过程和/或其部分的任何组合。逻辑单元720中的一个或更多个可以为CPU 706和/或GPU 708中的一个或更多个的一部分和/或集成于CPU 706和/或GPU 708中的一个或更多个和/或逻辑单元720中的一个或更多个可以为离散组件或以其他方式在CPU 706和/或GPU 708外部。在实施例中，逻辑单元720中的一个或更多个可以是CPU 706中的一个或更多个和/或GPU 708中的一个或更多个的协处理器。

逻辑单元720的示例包括一个或更多个处理核心和/或其组件，诸如张量核心(TC)、张量处理单元(TPU)、像素视觉核心(PVC)、视觉处理单元(VPU)、图形处理集群(GPC)、纹理处理集群(TPC)、流式多处理器(SM)、树遍历单元(TTU)、人工智能加速器(AIA)、深度学习加速器(DLA)、算术逻辑单元(ALU)、专用集成电路(ASIC)、浮点单元(FPU)、输入/输出(I/O)元件、外围组件互连(PCI)或快速外围组件互连(PCIe)元件等。

通信接口710可以包括使计算设备700能够经由电子通信网络(包括有线和/或无线通信)与其他计算设备进行通信的一个或更多个接收器、发送器和/或收发器。通信接口710可以包括组件和功能，以使得能够在多个不同网络中的任何一个上进行通信，例如无线网络(例如，Wi-Fi，Z-Wave，蓝牙，蓝牙LE，ZigBee等)，有线网络(例如，通过以太网或无线带宽通信)，低功耗广域网(例如LoRaWAN，SigFox等)和/或因特网。

I/O端口712可以使计算设备700能够逻辑地耦合到包括I/O组件714、一个或更多个呈现组件718和/或其他组件的其他设备，其中一些可以内置到(例如集成到)计算设备700。示例性I/O组件714包括麦克风，鼠标，键盘，操纵杆，游戏板，游戏控制器，碟形卫星天线，扫描仪，打印机，无线设备等。I/O组件714可以提供自然的用户界面(NUI)，其处理由用户产生的空中手势、语音或其他生理输入。在某些情况下，输入可以被发送到适当的网络元件以进行进一步处理。NUI可以实现以下项的任意组合：语音识别，手写笔识别，面部识别，生物特征识别，屏幕上以及邻近屏幕的手势识别，空中手势，头部和眼睛追踪以及与计算设备700的显示器相关联的触摸识别(如下更详细描述)。计算设备700可以包括用于姿势检测和识别的深度相机(例如立体相机)系统，红外相机系统，RGB相机系统，触摸屏技术以及这些的组合。另外，计算设备700可以包括使得能够检测运动的加速度计或陀螺仪(例如，作为惯性测量单元(IMU)的一部分)。在一些示例中，计算设备700可以使用加速度计或陀螺仪的输出来渲染沉浸式增强现实或虚拟现实。

电源716可以包括硬线电源、电池电源或它们的组合。电源716可以向计算设备700供电，以使计算设备700的组件能够运行。

一个或更多个呈现组件718可以包括显示器(例如，监视器、触摸屏、电视屏幕、平视显示器(HUD)、其他显示器类型或其组合)，扬声器，和/或其他呈现组件。一个或更多个呈现组件718可以从其他组件(例如，一个或更多个GPU 708，一个或更多个CPU 706等)接收数据，并且输出数据(例如，作为图像、视频、声音等)。

示例网络环境

适合用于实现本公开的实施例的网络环境可包括一个或更多个客户端设备、服务器、网络附加存储(NAS)、其他后端设备、和/或其他设备类型。客户端设备、服务器和/或其他设备类型(例如，每个设备)可以在图7的一个或更多个计算设备700的一个或更多个实例上实现—例如，每个设备可以包括一个或更多个计算设备700的类似的组件、特征和/或功能。

网络环境的组件可以经由一个或更多个网络彼此通信，所述网络可以是有线的、无线的或两者。网络可以包括多个网络或多个网络中的一个网络。例如，网络可包括一个或更多个广域网(WAN)、一个或更多个局域网(LAN)、一个或更多个公共网络(诸如互联网和/或公共交换电话网(PSTN))和/或一个或更多个私有网络。在网络包括无线电信网络的情况下，诸如基站、通信塔或者甚至接入点(以及其他组件)之类的组件可以提供无线连接。

兼容的网络环境可以包括一个或更多个对等网络环境(在这种情况下，服务器可以不包括在网络环境中)和一个或更多个客户端-服务器网络环境(在这种情况下，一个或更多个服务器可以包括在网络环境中)。在对等网络环境中，本文相对于服务器所描述的功能可在任何数量的客户端设备上实现。

在至少一个实施例中，网络环境可以包括一个或更多个基于云的网络环境、分布式计算环境、其组合等。基于云的网络环境可包括框架层、作业调度器、资源管理器和在一个或更多个服务器上实现的分布式文件系统，所述服务器可包括一个或更多个核心网服务器和/或边缘服务器。框架层可包括支持软件层的软件和/或应用层的一个或更多个应用的框架。所述软件或应用程序可分别包括基于网络的服务软件或应用程序。在实施例中，一个或更多个客户端设备可以使用基于web的服务软件或应用程序(例如，通过经由一个或更多个应用程序编程接口(API)访问服务软件和/或应用程序)。框架层可以是但不限于自由和开源软件web应用框架的类型，诸如可以使用分布式文件系统进行大规模数据处理(例如，“大数据”)。

基于云的网络环境可以提供执行在此描述的计算和/或数据存储功能(或其一个或更多个部分)的任何组合的云计算和/或云存储。这些不同功能中的任何功能可以分布在来自(例如，可以分布在州、地区、国家、地球等上的一个或更多个数据中心的)中央或核心服务器的多个位置上。如果与用户(例如，客户端设备)的连接相对靠近边缘服务器，则核心服务器可以将功能的至少一部分指定给边缘服务器。基于云的网络环境可以是私有的(例如，限于单个组织)，可以是公共的(例如，对许多组织可用)，和/或其组合(例如，混合云环境)。

客户端设备可以包括在此关于图7所描述的示例计算设备700的组件、特征和功能中的至少一些。作为示例而非限制，客户端设备可被实现为个人计算机(PC)、膝上型计算机、移动设备、智能电话、平板计算机、智能手表、可穿戴计算机、个人数字助理(PDA)、MP3播放器、虚拟现实头戴式显示器、全球定位系统(GPS)或设备、视频播放器、摄像机、监视设备或系统、车辆、船、飞船、虚拟机、无人机、机器人、手持式通信设备、医院设备、游戏设备或系统、娱乐系统、车辆计算机系统、嵌入式系统控制器、遥控器、家用电器、消费电子设备、工作站、边缘设备、这些描绘的设备的任何组合或任何其他合适的设备。

示例性分布式计算环境

图8示出了根据一个示例性实施例的示例性分布式渲染系统800。如图所示，客户端设备802通过通信网络806与远程设备804通信。在一个实施例中，通信网络806可以包括一个或更多个有线和/或无线通信网络。

此外，在一个实施例中，要渲染的场景可以由远程设备804接收。例如，该场景可以包括由用户在客户端设备处玩的视频游戏内的场景。在另一示例中，游戏信息(例如，游戏内的用户位置、游戏内的用户的视图等)可通过通信网络806从客户端设备802传送到远程设备804。

进一步地，在一个实施例中，远程设备804可利用光线追踪来计算场景的光场。另外，远程设备804可压缩场景的光场以创建场景的压缩的光场数据。例如，光场可由远程设备804使用实现时间复用的一个或更多个视频压缩算法/技术来压缩。在另一示例中，光场的计算和压缩可考虑从客户端设备802提供到远程设备804的场景内的当前可能可见的用户视图。

更进一步，在一个实施例中，远程设备804可以通过通信网络806向客户端设备802发送压缩的光场数据。然后客户端设备802可解压缩该压缩的光场数据，且可使用解压缩后的数据来获得场景的光场。客户端设备802可随后利用光场内的一个或更多个查找来计算场景的全局照明值。客户端设备可接着利用场景的所计算的全局照明值来渲染场景。

以此方式，可以在客户端设备802与远程设备804之间划分渲染职责，使得远程设备804执行更计算密集的渲染或光线追踪硬件相关的职责(例如，光线追踪、光场计算)，以便简化/减少在客户端设备处执行的渲染职责(例如，利用光场查找的全局照明)，或者简化/减少客户端设备处的光线追踪硬件依赖性。此外，通过利用一个或更多个视频压缩算法/技术和在压缩期间考虑场景内的当前用户视图，可以最小化得到的压缩数据，这可以减少通过通信网络806发送的数据量，并且可以减少系统800的总体延迟。

一种用于向瘦客户端无损流式传输动态光探针的分布式解耦系统

当今的具有多个GPU的游戏的高性能图形系统、硬件加速的光线追踪以及高效算法可以使用光线追踪的全局照明实时地接近影片效果的渲染质量并且提供以毫秒测量的交互延迟。这些高端系统设置了在热限制、电池功率和有限的GPU特征集约束的较低端消费者平台上不能满足的期望。

屏幕分辨率、刷新率和高动态范围(HDR)颜色深度正在增加，并且XR应用程序需要渲染多个视图。推进要求可能压倒在未经装订的设备中使用的当前移动处理器。

在一个实施例中，全局照明(GI)数据可以从云渲染服务器流式传输至瘦客户端。流式传输的数据在没有光线追踪能力的瘦客户端上以低计算成本实现动态、高质量、光线追踪的漫射GI。可使用有效的编码和解码硬件特征来实现具有低延迟的高压缩比。进一步，可使用可减少在GI更新内传送的数据量的启发式光探针更新方案。因此，在一个实施例中，单个服务器可以跨多个连接的瘦客户端每秒更新数千(数万)个光探针，从而分摊渲染成本。

示例性光探针流式传输管线可以包括以下4个步骤：

1.光场(光探针体)的服务器侧光线追踪

2.对针对每个客户端优化的光探针数据进行编码

3.将编码数据网络传输至客户端

4.对光探针数据进行解码并且在客户端上进行渲染

图9示出了根据一个实施例的示例性数据流900。客户端-服务器架构可以跨一个或更多个服务器和一个或更多个客户端分布图形管线，而不是流式传输全部视频帧。在一个实施例中，假定要处于数据中心中的服务器概念上由与高带宽链路互连的两个节点组成。第一节点充当游戏服务器902以可靠地接收来自客户端906的用户输入并相应地更新游戏状态908。这类似于标准的多玩家游戏服务器。第二节点充当GI服务器904，其执行光探针数据的光线追踪并对其进行编码以用于客户端输送。

假设由游戏服务器902以可忽略的延迟向GI服务器904报告任何场景变化。使用当前场景状态，GI服务器904计算视图无关的漫射光探针纹理数据。结果，该GI数据可用于多玩家游戏场景中的多个客户端，从而分摊渲染成本。在服务器上使用硬件加速的视频编码来压缩光探针数据。使用可靠的低延迟网络协议通过WiFi、5G和/或有线连接的组合将经编码的数据传送到客户端906。

在客户端906侧，硬件视频解码用于(当可用时)以低延迟对光探针数据进行解压缩。客户端渲染循环910接着使用未压缩的光探针纹理来以低计算成本添加动态和高质量漫射GI。GI纹理解码过程与渲染循环解耦，且可在完全不同的速率下发生。这允许客户端906以全帧率运行，从而导致对用户输入或移动的最小感知延迟。因此，避免了如传统云渲染解决方案中发生的输入延迟。

在一个实施例中，当在云中渲染GI数据时，GI数据提供特定益处：(1)漫射GI是视图无关的并且跨多个用户和可能的多个帧使用；(2)渲染GI数据是计算上昂贵的，瘦客户端硬件不足以用于渲染GI数据：以及(3)用户比视图依赖效应对延迟漫射照明更不敏感。

未压缩的光探针流式传输

流式传输探针颜色

在一个实施例中，可以使用动态漫射全局照明(DDGI)辐照体描述。每个探针可以使用10x10纹理像素阵列(每个纹理像素具有32位的颜色)来以八面体映射的形式对每个方向的颜色数据进行编码。因此，用于以速率R颜色(以Hz为单位)更新任何给定的N个探针颜色探针的所需网络吞吐量T颜色可如下所示：

T_color＝R_color×N_probes×3.125kb (1)

在一个示例中，16x8x16(2048)探针体具有未压缩的DDGI颜色纹理大小为6.25Mb(0.78MB)。在10Hz下更新2048个未压缩的颜色探针需要62.5Mbps的带宽。

流式传输探针可见性

在一个实施例中，DDGI存储每个探针的平均距离和平方距离。在着色期间，这些值用于使用切比雪夫(Chebyshev)统计测试来确定探针与着色点之间的可见性权重。平均距离/平方距离数据被称为“可见性数据”并且纹理本身被称为“可见性纹理。”可见性纹理包含被编码为一对半精度(16位)浮点值(32位/纹理像素)的每探针18x18个纹理像素。由此，R_visibility的可见性更新速率的所需吞吐量(T_visibility)可示出如下：

T_visibility＝R_visibility×N_probes×10.125kb (2)

对于如以上针对颜色分析的相同探针体(2048个探针)，可见性纹理的大小比颜色纹理的大小高3.24倍或20.3Mb(2.5MB)。以10Hz流式传输原始可见性纹理需要202.5Mbps的吞吐量。针对2048个探针以10Hz更新的未压缩颜色和可见性纹理的最小所需吞吐量是265Mbps。这些是当考虑公共当前无线网络中的多个瘦客户端设备时使用的示例性带宽限制。尽管这种朴素的、未压缩的方法是无损的并且维持完美的探针“一致性”，但是它要求不合理的高网络吞吐量，因为它发送了所有探针数据，而不管数据是未改变的还是可能在客户端上使用。然而，这种吞吐量可降低。

低延迟光探针压缩

在一个实施例中，使用预定的视频译码/压缩标准来实现GPU加速的高动态范围(HDR)视频压缩。在另一个实施例中，可以实现硬件加速的HDR10编码和解码。

编码颜色

在一个实施例中，一种方法压缩颜色数据如下。在A2RGB10F纹理中保存归一化的颜色值(针对每种颜色10位无符号小浮点，针对阿尔法为2个未使用位)。由于无符号小浮点被归一化，所以这些值可在无损失的情况下量化为范围[0，1023]中的10位无符号整数值。用于硬件编码器的一个示例性输入格式是在3个Y、U、V平面(线性Y-亮度、U、V色度)中组织的16位无符号整数。YUV444表面格式可被用于避免无损压缩的色度子采样。在一个实施例中，硬件编码器仅使用16位中的10位用于颜色编码。剩余的位被保留用于支持12位和16位颜色编码的编解码器的未来版本。因此，这些位可以被设置为零。YUV元组然后被重新排序到Y、U、V平面中，在其上应用硬件编码。为了解码，相反地执行该过程。

编码可见性

一种用于可见性的解决方案依赖于无损和低位深度视频编码。想法是将单个16位浮点值分布在两个相邻8位整数值上。由于光探针的可见性纹理保持两个通道(RG16F)，所以位分布在四个8位整数值上。如果所使用的硬件编码器不支持四通道图像，则三个RG16F值的序列可被打包成四个YUV值的序列，这四个YUV值的序列有效地将位分配到YUVY、UVYU、VYUV序列中。YUV纹理可被加宽以为可见性纹理分配足够的存储器。对于原始光探针可见性纹理宽度x，YUV纹理宽度可增加到

线程化客户端侧解码

为了使吞吐量最大化并且避免渲染更新与解码传入的纹理更新之间的CPU阻塞行为，纹理解码可以在客户端上的单独线程中发生。这在基于CPU的纹理解码或GPU解码分派期间解除阻挡游戏循环。

选择性光探针更新

作为优化每个GI更新的网络吞吐量消耗的下一个步骤，可以避免发送不包含与客户端侧着色相关的信息的探针。相关探针满足以下三个条件：

1.它被更新并且用于场景中的着色

2.其附属纹理像素自其最后向客户端发送更新以来已经显著改变

3.它是用户潜在可见的着色点

在服务器上，收集保持其前面三个条件的所有探针并将其发送至客户端。在每次发送时，所发送的探针数据被记录在服务器上并且与所渲染的探针数据进行比较，以确定在下一次发送中应当发送哪些探针。

光探针重新封装

与传输全部纹理(全局探针体更新)相反，可以通过移动到基于索引的探针更新系统(选择性的、迭代的)来从原始纹理中去除不活动探针。对于每一核心纹理像素阵列，在颜色和可见性纹理两者中，附加的减少是可能的。原始DDGI纹理包括用于纹理滤波的一个像素保护带(每个探针)，其包含来自核心纹理像素阵列的冗余信息。该数据可以在服务器上在打包步骤中被移除，并且在解包期间在客户端上不丢失的情况下被重建。该策略减小所传送的纹理的大小，从而导致独立于压缩方案(或未压缩的传输)的益处。然而，对于时间复用，如果可能的话，纹理中的探针位置可在多个帧上维持。

基于索引的更新方案允许以灵活的方式调整总数据包大小，因为可以指定迭代更新的探针的数量。这有效地引入‘旋钮’以基于每个客户端来调整吞吐量。

光探针更新纹理

以下描述了服务器和客户端上的选择性探针更新。

服务器为每个客户端存储永久客户端探针纹理以及临时选择性探针更新纹理。永久纹理表示探针存在于每个客户端上时的状态。每个更新步骤创建临时探针更新纹理并存储正被更新的探针信息。连同该纹理一起，客户端可被通知体中的哪些探针正被更新。此信息由探针索引缓冲区提供，所述探针索引缓冲区将探针更新纹理坐标映射到客户端的探针纹理中。与探针更新纹理相比，探针索引缓冲区的大小(被编码为每探针单个两字节无符号整数)非常小，并且通过增量(delta)编码进一步减小。

对于客户端，这个过程以相反的顺序发生。只有那些已经被发送到客户端的光探针在永久探针纹理中被更新。从更新纹理到永久光探针纹理的映射使用所接收和解压缩的探针索引缓冲区。假设剩余纹理像素从先前状态有效。由于纹理解压缩和更新步骤在并行线程中异步地发生，所以渲染循环不被阻塞并且可以以全帧率连续运行。

光探针变化阈值

为了保守地估计可能影响主客户端视图的所有探针，可以考虑自从它们上一次被发送以来值已经改变的所有探针。可以在服务器上维护每个连接的客户端的两个附加纹理，一个用于颜色，一个用于可见性，其存储每个探针在最后一次被发送时的状态。在发送时间，每个探针可以与其最后发送的状态相比较，并且仅在其值改变超过指定阈值的情况下可以被考虑进行传送。尽管更高的阈值可能在感知上是可容忍的，但是如果探针不是与其最后发送的状态相同的纹理像素对纹理像素，则探针可被标记为已改变。做出场景改变的服务器上的完全收敛的颜色可假定为探针结果中的唯一变化源。在发送每个探针之前，其数据可以被写入到相应的最后发送的纹理。

服务器侧客户端视图探针剔除

给定场景内的视点，可能对渲染的帧有贡献的探针纹理像素的子集仅是接近具有主要可见性的点的那些纹理像素。这可以表示全部数目的活动/更新探针从全部体的实质性减少。

通过将经更新的探针限制于那些有助于着色主可见性视椎体的探针，可以减少需要更新的探针的数量。依赖于游戏的客户端视图预测方案可以调整更新的探针的数目。这样的预测可以耦合到网络延迟和游戏内容。可以通过在服务器上估计探针的潜在可见集(PVS)(其通过从客户端的位置渲染球形视图而有助于客户端着色)来实现独立于应用的策略。从该PVS估计收集探针确保了相机旋转下的客户端视图的正确性。

虽然以上已经描述了不同实施例，但应理解的是，这些实施例仅通过示例而非限制的方式呈现。由此，优选实施例的宽度和范围不应受任何上述示例性实施例的限制，而应仅根据所附权利要求及其等同物来限定。

可以在计算机代码或机器可用指令的一般上下文中描述本公开，包括由计算机或其他机器(例如个人数据助手或其他手持式设备)执行的计算机可执行指令(例如程序模块)。通常，程序模块(包括例程，程序，对象，组件，数据结构等)是指执行特定任务或实现特定抽象数据类型的代码。本公开可以在包括手持设备、消费电子产品、通用计算机、更多专用计算设备等的各种系统配置中实践。本公开还可以在其中由通过通信网络链接的远程处理设备执行任务的分布式计算环境中实践。

如本文所使用的，对于两个或更多个元件的“和/或”的叙述应被解释为仅意味着一个元件或元件的组合。例如，“元件A，元件B和/或元件C”可以包括仅元件A，仅元件B，仅元件C，元件A和元件B，元件A和元件C，元件B和元件C，或元件A、B和C。另外，“元件A或元件B中的至少一个”可以包括元件A中的至少一个，元件B中的至少一个，或元件A中的至少一个和元件B中的至少一个。

本文具体描述了本公开的主题，以满足法定要求。然而，描述本身并不旨在限制本公开的范围。相反，发明人已经预料到，所要求保护的主题还可以结合其他当前或未来技术以其他方式体现，以包括与本文档中所描述的步骤不同的步骤或步骤的组合。此外，尽管本文中可以使用术语“步骤”和/或“框”来表示所采用方法的不同元件，但是这些术语不应解释为暗示本文所公开的各个步骤之中或之间的任何特定顺序，除非明确描述了各个步骤的顺序。

Claims (20)

1.一种方法，包括：

接收场景的压缩的光场数据；

解压缩所述压缩的光场数据以获得所述场景的光场；以及

使用所述场景的所述光场来计算所述场景的全局照明。

2.根据权利要求1所述的方法，其中在客户端设备处从远程设备接收所述压缩的光场数据，其中所述远程设备包括基于云的计算环境内的节点，并且所述客户端设备包括移动计算设备、便携式游戏平台和虚拟现实(VR)头戴式显示器中的一个或更多个。

3.根据权利要求1所述的方法，其中经由无线互联网连接和蜂窝通信网络中的一个或更多个接收所述压缩的光场数据。

4.根据权利要求1所述的方法，其中客户端设备使用视频解压缩单元来解压缩所述压缩的光场数据。

5.根据权利要求1所述的方法，其中在计算所述场景的全局照明时，客户端设备在所述场景的所述光场内执行查找，而不是执行光线追踪。

6.根据权利要求1所述的方法，还包括：使用所计算的全局照明在客户端设备处渲染所述场景。

7.根据权利要求6所述的方法，还包括：由所述客户端设备显示渲染的所述场景。

8.一种计算机可读存储介质，其存储指令，所述指令在由处理器执行时使所述处理器执行步骤，所述步骤包括：

接收场景的压缩的光场数据；

解压缩所述压缩的光场数据以获得所述场景的光场；以及

使用所述场景的所述光场来计算所述场景的全局照明。

9.根据权利要求8所述的计算机可读存储介质，其中在客户端设备处从远程设备接收所述压缩的光场数据，其中所述远程设备包括基于云的计算环境内的节点，并且所述客户端设备包括移动计算设备、便携式游戏平台和虚拟现实(VR)头戴式显示器中的一个或更多个。

10.根据权利要求8所述的计算机可读存储介质，其中经由无线互联网连接和蜂窝通信网络中的一个或更多个接收所述压缩的光场数据。

11.根据权利要求8所述的计算机可读存储介质，其中客户端设备使用视频解压缩单元来解压缩所述压缩的光场数据。

12.根据权利要求8所述的计算机可读存储介质，其中在计算所述场景的全局照明时，客户端设备在所述场景的所述光场内执行查找，而不是执行光线追踪。

13.根据权利要求8所述的计算机可读存储介质，其中所述步骤还包括：使用所计算的全局照明在客户端设备处渲染所述场景。

14.根据权利要求13所述的计算机可读存储介质，其中所述步骤还包括：由所述客户端设备显示渲染的所述场景。

15.一种方法，包括：

识别要渲染的场景；

利用光线追踪来计算所述场景的光场；

压缩所述光场以创建所述场景的压缩的光场数据；以及

将所述压缩的光场数据发送到客户端设备。

16.根据权利要求15所述的方法，其中所述识别、所述计算、所述压缩和所述发送是在与所述客户端设备物理分离的远程设备处执行的。

17.根据权利要求15所述的方法，其中：

所述光场包括块阵列，

每个块包括颜色纹理信息和可见性纹理信息，

所述颜色纹理信息包括所述块内的照明颜色信息，以及

所述可见性纹理信息包括到所述块内的最接近表面的距离。

18.根据权利要求15所述的方法，其中使用在压缩期间实现时间复用的一种或更多种视频压缩技术来压缩所述光场。

19.根据权利要求18所述的方法，其中仅压缩所述场景的所述光场与先前场景的光场之间的差异。

20.根据权利要求15所述的方法，其中所述压缩考虑所述场景内的当前用户视图，从而使得仅压缩所计算的光场的处于所述当前用户视图内的一部分。

Images