未来图形架构 -

2008年4月28日
第6卷，第2期

未来图形架构

GPU持续快速发展，但方向是什么？

WILLIAM MARK，英特尔和德克萨斯大学奥斯汀分校

图形架构正处于重大转型之中。过去，这些是专门的架构，旨在支持单一渲染算法：标准 Z 缓冲。实时 3D 图形现在已经发展到 Z 缓冲算法在生成下一代更高质量的视觉效果方面存在严重缺陷的程度，而这些效果正是游戏和其他交互式 3D 应用程序所需要的。人们还希望利用图形架构的高计算能力来支持碰撞检测、近似物理模拟、场景管理和简单的人工智能。为了应对这些力量，图形架构正在朝着通用并行编程模型演进，该模型将支持各种图像合成算法以及非图形任务。

这种架构转型既带来了机遇，也带来了挑战。对于硬件设计师来说，主要挑战是在对更高可编程性的需求与继续在传统图像合成算法上提供高性能的需求之间取得平衡。软件开发人员有机会摆脱硬件决定的图像合成算法的约束，从而可以实现几乎任何所需的算法，即使是那些与图形无关的算法。然而，随之而来的是编写高效、高性能并行软件以在新图形架构上运行的挑战。编写这样的软件比编写大多数开发人员习惯的单线程软件要困难得多，并且它要求程序员解决诸如算法并行化、负载平衡、同步和数据局部性管理等挑战。

图形硬件从专用架构到灵活的高吞吐量并行架构的转变，其影响将远远超出计算机图形领域。由于各种技术和商业原因，图形架构很可能演变为未来占主导地位的高吞吐量“众核”架构。

本文首先描述了驱动实时图形系统发展的高层次力量，然后转向实时图形算法中为响应这些高层次力量而出现的一些详细技术趋势。最后，它考虑了未来的图形架构预计将如何发展以适应图形算法的这些变化，并讨论了这些架构将给软件开发人员带来的挑战。

应用驱动图形架构的演进

要理解未来图形架构可能采取的形式，我们需要研究驱动这些架构演进的力量。与任何工程制品一样，图形架构旨在在基本技术约束范围内为最终用户提供最大利益，这些约束决定了在特定时间点的可承受性。随着 VLSI（超大规模集成）制造技术的进步，可承受性的边界也在变化，因此每一代图形架构都可以在与上一代相同的成本下提供额外的功能。因此，关键的高层次问题是：我们希望这些新功能是什么？

粗略地说，图形硬件用于三个目的：3D 图形，特别是娱乐应用（即游戏）；2D 桌面显示，过去严格来说是 2D，但现在使用 3D 功能来合成桌面，例如 Microsoft Vista 和 Apple Mac OS X 中发现的那些；以及视频回放（即，流媒体视频和 DVD 的解压缩和显示）。

虽然对于大多数用户来说，桌面显示和视频回放比 3D 图形更重要，但本文重点关注 3D 图形的需求，因为这些应用程序对性能和功能的巨大需求一直是推动图形架构演进的最强大力量。

为未来的 3D 娱乐应用设计图形系统尤其棘手，因为从技术层面上来说，目标是不明确的。目前不可能以实时帧率计算出理想质量的图像，计算机生成电影中的图像质量高于电脑游戏中的图像质量就证明了这一点。因此，设计师必须对理想的计算进行近似。有无数种可能的近似选择，每种近似都会在图像中引入不同类型的视觉伪影，并且每种近似都使用不同的算法，这些算法反过来可能在不同的架构上运行最佳。本质上，系统设计问题被简化为一个不明确的问题，即哪个系统（软件和硬件）以特定成本产生最佳质量的游戏图像。图 1 说明了这个问题。在实践中，还有其他约束，例如向后兼容性以及构建有助于内容创建的系统的愿望。

随着 VLSI 技术随时间的推移而进步，系统设计师获得了更多的晶体管。如果我们假设帧率固定为 60 Hz，那么这些晶体管提供的额外计算能力可以用于三个基本方面：提高屏幕分辨率；增加场景细节（多边形计数或材质着色器复杂性）；以及通过更改基本渲染算法或其特定组件来更改整体近似。

回顾过去六年，我们可以看到这些力量在发挥作用。游戏采用了可编程着色器，允许对材质进行复杂的建模，以及逼近阴影、反射和其他效果的多通道技术。图形架构通过添加可编程顶点和片段单元，以及数据在图形管线各个阶段之间移动方式的更大灵活性，实现了这些变化。

当前的图形处理器使用图 2a 所示的编程模型。该模型支持传统的 Z 缓冲算法，并围绕预定义的管线结构组织，该结构仅可由应用程序部分重新配置。¹ 预定义的管线结构为 Z 缓冲算法（特别是用于多边形光栅化和 Z 缓冲读取-修改-写入操作），以及其他操作（例如可编程阶段所需的线程调度）采用了专用硬件。

许多单独的管线阶段是可编程的（特别是为了支持可编程材质着色计算），所有可编程阶段都复用到一组同构的可编程硬件处理器上。然而，在这些管线阶段内执行的程序，在它们如何相互通信以及它们如何（如果可以）访问全局共享内存方面受到严格限制。这种编程模型为其设计支持的计算提供了高性能，但使其难以有效支持其他计算。

重要的是要意识到，现代游戏应用程序从根本上需要在图形硬件中实现可编程性。这是因为现实世界包含种类繁多的材质（木材、金属、玻璃、皮肤、毛皮，…），而指定这些材质与光相互作用的唯一合理方法是为每种材质使用不同的程序。

这种情况与在其他高性能任务（例如视频解码）中发现的情况非常不同，视频解码本质上不需要可编程硬件；可以设计固定功能硬件来充分支持标准视频格式，而无需任何可编程性。实际上，大多数视频解码硬件确实包含一些可编程单元，但这是一种实现选择，而不是基本要求。3D 图形应用程序对可编程性的这种需求使图形架构具有独特的优势，可以演变为更通用的高吞吐量并行计算机架构，以处理图形以外的任务。

传统 Z 缓冲图形管线的局限性

以当今图形架构为基础的、具有可编程着色的 Z 缓冲图形管线，做出了一些基本的近似和假设，这些近似和假设对图像质量施加了实际的上限。例如，Z 缓冲无法有效地确定两个任意选择的点是否彼此可见，而许多高级视觉效果都需要这样做。另一方面，光线追踪器可以有效地做出这种确定。因此，计算机生成的电影使用比标准 Z 缓冲图形管线更复杂的渲染技术，例如光线追踪算法和 Reyes（渲染你曾经看到的一切）算法²。

在过去的几年中，已经变得清楚的是，实时 3D 图形中提高视觉质量的下一个前沿领域将涉及更真实地（但不一定是照片般真实地）建模光照和复杂的光照效果，从而生成质量更接近计算机生成电影的图像。这些效果包括硬边阴影（来自小光源）、软边阴影（来自大光源）、水面反射，以及更复杂效果的近似，例如漫反射光照交互，这种交互在大多数室内环境中占主导地位。人们还希望对运动模糊等效果进行建模，并使用更高质量的抗锯齿技术。对于传统的 Z 缓冲图形管线来说，大多数这些效果都难以生成。

现代游戏引擎（例如，虚幻引擎 3、CryEngine 2）已经开始使用当今的图形硬件支持其中一些效果，但存在重大限制。例如，虚幻引擎 3 使用四种不同的阴影算法，因为没有一种算法在所有情况下都能提供可接受的性能和图像质量组合。这个问题是传统 Z 缓冲管线支持的可见性查询的局限性造成的。此外，诸如阴影和部分透明之类的不同效果通常是互不兼容的（例如，部分透明物体投射阴影，就像它们是完全不透明的物体一样）。这种算法鲁棒性和通用性的缺乏，对于游戏引擎程序员和创建游戏内容的艺术家来说都是一个问题。这些局限性也可以被视为违反了良好系统设计的重要原则，例如抽象（一种能力应该适用于所有相关情况）和正交性（不同的能力不应以意外的方式相互作用）。

根本问题在于，传统的 Z 缓冲图形管线旨在计算从单个点发出的规则间隔光线的可见性（即，第一个表面命中）（参见图 3a），但诸如硬边阴影、软边阴影、反射和漫反射光照交互等效果都需要更通用的可见性计算。特别是，反射和漫反射光照交互需要能够有效地计算沿各种起点和方向的光线的可见表面（图 3d）。这些类型的可见性查询无法通过传统的图形管线有效地执行，但 VLSI 技术现在提供了足够的晶体管来支持更复杂的实时可见性算法，这些算法可以有效地执行这些查询。然而，这些晶体管必须组织成一种可以有效支持更复杂的可见性算法的架构。

由于 Z 缓冲图形管线不适合生成所需的效果，因此自然的解决方案是围绕更强大的可见性算法设计图形系统。图 3 概述了其中一些算法。我认为，为了应对标准 Z 缓冲的不足，这些更强大的可见性算法将在未来几年内逐步被采用，尽管图形界对于这种变化发生的速度存在很大的争议。特别是，与电影渲染相比，光线追踪等算法很可能在实时图形中更快地被采用，因为实时图形不允许像电影渲染中那样为每个镜头手动调整光照。

通用图形硬件的论据

鉴于需要支持更强大的可见性算法，图形架构师可以采取几种方法。新的可见性技术应该在某种专用硬件（如今天的 Z 缓冲可见性计算）中实现，还是应该在灵活的并行架构上的软件中实现？我认为灵活的并行架构是最佳选择，因为它支持以下软件功能

混合可见性技术。 灵活的硬件支持多种可见性算法，从传统的 Z 缓冲到光线追踪和光束追踪。每个应用程序都可以根据其需求选择最佳算法。这些更复杂的可见性算法需要构建和遍历不规则数据结构（例如 KD 树）的能力，这需要比当今 GPU 使用的更灵活的并行编程模型。

应用程序定制的近似。 以实时帧率渲染图像需要进行数学近似（例如，对于特定的光照效果），但可能的近似种类繁多。通常，不同的近似使用非常不同的整体渲染算法，并且具有非常不同的性能特征。由于最佳近似和算法因应用程序而异，有时甚至在应用程序内部也不同，因此允许应用程序选择其近似的架构可以为整体渲染任务提供比缺乏这种灵活性的架构更高的效率。

渲染与场景管理的集成。 传统上，实时图形系统使用一组数据结构来表示场景的持久状态（例如，对象位置、速度和分组），并使用另一组数据结构来计算可见性。这两组数据结构位于诸如 DirectX 或 OpenGL 之类的中间 API 的两侧。对于每一帧，所有可见的几何图形都通过此 API 传输。在 Z 缓冲系统中，这种方法是可行的，因为确定哪些几何图形可能是可见的相对简单。然而，在光线追踪系统中，这种方法效果不佳，并且希望更紧密地集成这两组数据结构，使它们都驻留在图形处理器上（图 4）。还希望更改传统的 API 分层，以便游戏引擎接管当前由图形硬件处理的大部分低级渲染任务（图 5）。高度可编程的架构使这种集成更容易实现，同时仍然保持应用程序以最有效的方式维护持久数据结构的灵活性。它还允许在高性能图形硬件上执行场景管理计算，从而消除 CPU 上的瓶颈。

支持游戏物理和 AI。灵活的并行架构可以轻松支持诸如碰撞检测、流体动力学模拟（例如，用于爆炸）和游戏玩法人工智能之类的计算。它还允许这些计算与渲染计算紧密集成。

快速创新。 软件可以比硬件更快地更改，因此使用软件来表达其图形算法的灵活并行架构比传统设计能够实现更快的创新。

作为整体系统的最佳选择是使用灵活的并行硬件，允许软件使用积极的算法专业化和优化，而不是使用强制特定算法的专用并行硬件。

编程模型

当我说未来的图形架构很可能支持极其灵活的并行编程模型时，我的意思是什么？关于图形架构在不久的将来应该采用的具体编程模型，图形硬件社区内部存在相当大的争议。我预计在短期内，主要的图形硬件公司将各自采取略有不同的道路。这种多样性有多种原因：对添加新功能与提高旧编程模型的性能的不同侧重；解决并行编程问题的基本理念差异；以及一些公司希望逐步发展现有设计的愿望。

在较长期（五年左右），编程模型可能会趋同，但对于这种趋同的编程模型会是什么样子，目前还没有共识。本节介绍当今图形架构师面临的一些关键问题，以及对趋同的未来编程模型可能是什么样子以及它将给程序员带来的挑战的一些思考。这里讨论的大多数编程挑战将适用于所有未来的图形架构，即使是那些与我期望的架构略有不同的架构。

硬件定义的管线的终结

图形处理器将朝着类似于图 2b 所示的编程模型演进。用户编写的软件指定了计算的总体结构，以极其灵活的并行编程模型表示，类似于用于编程当今多核 CPU 的模型。用户编写的软件可以选择性地使用专用硬件来加速特定任务，例如纹理映射。专用硬件可以通过 ISA（指令集架构）中的指令、特殊内存映射寄存器和特殊的处理器间消息的组合来访问。

来自 NVIDIA 和 AMD 的最新一代 GPU（图形处理单元）已经朝着未来的图形编程模型迈出了重要一步，通过为非图形计算支持单独的编程模型，该模型比用于图形的编程模型更灵活。第二种编程模型是一种汇编级并行编程模型，具有在硬件线程之间进行细粒度同步和数据共享的一些功能。NVIDIA 称其模型为 PTX（并行线程执行），AMD 的模型称为 CTM（接近金属）。请注意，NVIDIA 类 C 的 CUDA 语言（参见本期“使用 CUDA 进行可扩展并行编程”）是建立在汇编级 PTX 之上的层。然而，重要的是要认识到，与传统的通用并行编程模型相比，PTX 和 CTM 存在一些重大限制。PTX 和 CTM 仍然相当受限，尤其是在它们的内存和并发模型中。

当将 PTX 和 CTM 与其他单芯片高度并行处理器（例如 Sun 的 Niagara 服务器芯片）支持的编程模型进行比较时，这些限制变得显而易见。我相信，未来图形架构的编程模型将比 PTX 和 CTM 灵活得多。

任务并行性和多线程

当前 GPU 支持的并行性主要采用数据并行性的形式——也就是说，GPU 同时对许多数据元素（例如顶点或像素或数组中的元素）进行操作。相比之下，任务并行性没有得到很好的支持，除了并发处理像素和顶点的特定情况。由于更好地支持任务并行性对于有效支持用户定义的渲染管线是必要的，因此我预计未来的 GPU 将更积极地支持任务并行性。特别是，多个任务将能够彼此异步地执行，并且与 CPU 异步地执行，并且能够相互通信和同步。这些更改将需要比当今 GPU 使用的更复杂的软件运行时环境，并将为线程管理的硬件/软件交互引入显着的复杂性。

与当今的 GPU 和 Sun 的 Niagara 处理器一样，每个核心都将使用硬件多线程³，可能会通过额外的软件多线程来增强，类似于 Cell 架构的程序员使用的多线程。这种多线程服务于两个目的

首先，即使每条指令的管线延迟为多个周期，它也允许核心保持充分利用——核心只是执行来自另一个线程的指令。
其次，即使核心上的一个或多个线程由于片外 DRAM 访问（例如从纹理中获取数据时发生的那些访问）而停顿，它也允许核心保持充分利用。程序员将面临暴露多个核心和每个核心上多个线程的并行性的挑战。这种挑战已经开始出现在诸如 NVIDIA CUDA 之类的编程模型中。

每个核心内的 SIMD 执行

图形硬件设计中一个重要的考虑因素是使用固定数量的芯片晶体管获得尽可能高的性能。如果一个指令缓存/提取/解码单元可以在多个算术单元之间共享，那么与每个算术单元都有一个指令单元的设计相比，硬件的芯片面积和功耗要求都会降低。也就是说，只要 SIMD 向量中的大多数元素在大多数时间内保持活动状态，SIMD（单指令，多数据）执行模型就会提高效率。SIMD 执行模型还提供了一种简单的细粒度同步形式，有助于确保内存访问具有良好的局部性。

当前的图形硬件使用 SIMD 执行模型，尽管有时它在 NVIDIA 硬件中以标量编程接口的形式对程序员隐藏。正在进行的争论和变化的一个领域可能是底层硬件 SIMD 宽度；随着 SIMD 宽度的增加，规则计算获得的效率与随着 SIMD 宽度的减小，不规则计算获得的效率之间存在张力。NVIDIA GPU（GeForce 8000 和 9000 系列）的有效 SIMD 宽度为 32，但趋势是 GPU 的 SIMD 宽度减小，以提高具有不规则控制流的算法的效率。

关于如何公开 SIMD 执行模型也存在争论。它可以直接通过寄存器-SIMD 指令向程序员公开，就像 x86 SSE 指令所做的那样，或者它可以名义上隐藏在标量编程模型背后，就像 NVIDIA GeForce 9000 系列的情况一样。如果 SIMD 执行模型被隐藏，则从标量编程模型到 SIMD 硬件的转换可以由硬件（如 GeForce 9000 系列）、编译器或两者的某种组合来执行。无论使用哪种策略，关注性能的程序员都需要了解底层的 SIMD 执行模型和宽度。

少量本地存储

GPU 和 CPU 之间最重要的区别之一是，GPU 将更大比例的晶体管用于算术单元，而 CPU 将更大比例的晶体管用于缓存。这种差异是 GPU 的峰值性能远高于 CPU 的主要原因之一。

我预计这种差异将在未来继续存在。对程序员的影响将是显着的：尽管未来 GPU 的整体编程模型将变得与当今的 CPU 非常相似，但程序员需要在未来的 GPU 上比在当今的 CPU 上更仔细地管理数据局部性。

多线程使这个问题更具挑战性；如果每个核心上有 N 个线程，则每个核心每个线程的本地存储量有效地为核心总本地存储量的 1/N。如果核心上的 N 个线程共享一个工作集，则可以缓解此问题，但要做到这一点，程序员必须将 N 个线程视为彼此紧密耦合。同样，程序员将不得不考虑如何在不同核心上的线程之间共享工作集。

这些考虑因素在 CUDA 中已经变得明显。对于习惯于 CPU 大缓存的程序员来说，这些约束可能会令人沮丧，但他们需要意识到，额外的本地存储将以减少 ALU（算术逻辑单元）为代价，并且他们需要与硬件设计师紧密合作，以确定缓存和 ALU 之间的最佳平衡。

缓存一致性共享内存

任何并行架构最重要的方面是其整体内存和通信模型。为了说明设计这一方面的重要性，请考虑四种（许多）可能的替代方案（当然，这些模型的混合和增强是可能的）

消息传递架构，其中每个处理器核心都有自己的内存空间，并且所有通信都通过显式消息传递发生。大多数大型超级计算机（拥有 100 多个处理器的计算机）都使用此模型。
诸如 Sony/Toshiba/IBM Cell 之类的架构，具有非缓存、非一致性共享内存。在这种架构中，核心的小型私有内存和全局内存之间所有的数据传输都必须通过显式的内存传输命令来协调。
诸如 NVIDIA GeForce 8800 之类的架构，具有相当于最小缓存、非一致性共享内存的东西，并支持加载/存储到此内存。
诸如现代多核 CPU 之类的架构，具有缓存、一致性共享内存。在这种架构中，硬件机制管理缓存和主内存之间的数据传输，并确保不同处理器的缓存中的数据保持一致。

关于哪种内存和通信模型最适合未来的架构，图形架构社区内部存在相当大的争议，并且在短期内，不同的硬件供应商正在采取不同的方法。软件程序员应该认真思考这些问题，以便他们准备好影响这场辩论。

哪种方法最有可能在中长期内占据主导地位？我之前曾论证过，渲染算法的趋势是朝着构建和遍历不规则数据结构的方向发展。这些不规则数据结构允许算法适应场景几何形状和当前视点。显式管理这些算法的所有数据局部性是痛苦的，特别是当多个核心共享读/写数据结构时。根据我的经验，在缓存一致性架构上开发这些算法更容易，即使实现最佳性能通常仍然需要非常仔细地考虑性能关键内核的通信和内存访问模式。

由于这些原因以及其他太详细而无法在此处讨论的原因，我相信未来的图形架构将有效地支持缓存一致性内存模型，并且任何缺乏这些功能的架构对于正在开发创新渲染技术的程序员来说，最多也只是第二选择。Sun 的 Niagara 架构为我预期的未来 GPU 的内存和线程模型提供了一个很好的预览。然而，我也预计缓存一致性图形架构将包括各种机制，这些机制为程序员提供对通信和内存访问的显式控制，例如绕过缓存的流式加载。

细粒度专业化

支持更大算法多样性的愿望将推动未来的图形架构朝着更大的灵活性和通用性发展，但专业化仍将在为大多数应用程序提供足够大的好处时使用。大多数这种专业化将是细粒度的，用于加速特定操作，这与过去用于决定硬件上执行的算法的总体结构的粗粒度、单片粒度形成对比。

特别是，我预计以下专业化将继续存在于图形架构中

纹理硬件。 纹理寻址和过滤操作使用低精度（通常为 16 位）值，这些值从存储在内存中的压缩表示中动态解压缩。访问的数据量很大，需要多线程才能有效地处理缓存未命中。这些操作占总渲染成本的很大一部分，并且从专用硬件中获益匪浅。

专用浮点运算。 渲染大量使用浮点平方根和倒数运算。当前的图形硬件为这些运算以及其他用于着色的运算（例如，swizzling 和三角函数）提供了高性能指令。未来的图形硬件也需要这样做。

视频回放和桌面合成。 视频回放和 2D 和 2.5D 桌面窗口操作从专用硬件中获益匪浅。这些操作的专业化对于电源效率尤为重要。我预计大部分这种硬件将遵循传统的粗粒度单片固定功能模型，因此对用户编写的 3D 图形程序没有用处。

当前的图形硬件还包括用于辅助三角形光栅化的专用硬件，但我预计这项任务将在几年内被软件接管。原因是光栅化正逐渐成为总渲染成本中较小的一部分，因此在软件中实现它的代价正在降低。随着更复杂的可见性算法补充或取代 Z 缓冲，这种趋势将加速。

随着图形软件切换到更强大的可见性算法（例如光线追踪），可能会清楚地看到，某些操作占总计算成本的足够大一部分，因此硬件加速是合理的。例如，未来的架构可以包括专门的指令来加速光线追踪使用的数据结构遍历操作。

图形架构师面临的挑战

在高层次上，未来图形架构面临的关键挑战是在为现有图形算法提供高性能的愿望与提供支持具有高性能的新算法（包括非图形算法和下一代更强大和更复杂的图形算法）所需的灵活性之间取得最佳平衡。我认为，更复杂的图形算法提供的改进的视觉质量和鲁棒性的机会将导致向更灵活的架构的过渡相对迅速地发生，这一观点在图形架构社区内仍然存在争议。

图形架构的未来

过去，图形架构定义了用于渲染的算法及其性能。未来，图形架构将不再定义渲染算法，而只是设定软件开发人员可以随意在其范围内操作的性能和功耗限制。

对于程序员来说，未来的图形架构可能与当今的多核 CPU 架构非常相似，但具有更大的 SIMD 指令宽度以及用于某些操作的专用指令和处理单元。然而，与当今的 Niagara 处理器一样，每个处理器核心的缓存量将相对较小。为了获得峰值性能，程序员将不得不比使用现代 CPU 的大缓存时更仔细地考虑内存访问模式和数据结构大小。

未来的图形架构将开启图形创新的黄金时代；我预计在未来几年内，我们将看到各种新的渲染算法的开发，这些算法比过去使用的算法更有效、更强大。对于电脑游戏，这些架构将允许游戏逻辑、物理模拟和 AI 比以前更紧密地与渲染集成。对于数据可视化应用程序，这些架构将允许特定领域的数据分析与用于显示此分析结果的渲染计算紧密集成。这些架构的通用性以及其高销量市场带来的低成本也将使其成为几乎所有高性能浮点计算的首选平台。Q

致谢和进一步阅读

Don Fussell、Kurt Akeley、Matt Pharr、Pat Hanrahan、Mark Horowitz、Stephen Junkins 和几位图形硬件架构师通过许多有趣且富有成效的讨论，直接或间接地为本文中的观点做出了贡献。关于本文中讨论的许多观点的更多细节可以在我于 2005 年与 Don Fussell 合著的另一篇文章中找到⁴。图形硬件变得越来越通用，直到出现整合新的专用单元的诱惑，这种趋势由来已久，Myer 和 Sutherland 在 1968 年将其描述为“轮回之轮”⁵。然而，现在实时图形硬件中可编程性的根本需求比那时重要得多。

参考文献

Blythe, D. 2006. Direct3D 10 系统。载于 SIGGRAPH 2006 会议论文集: 724–734.
Cook, R.L.、Carpenter, L.、Catmull, E. 1987. Reyes 图像渲染架构。《计算机图形学》（ SIGGRAPH 会议论文集）：95–102。
Laudon, J.、Gupta, A.、Horowitz, M. 1994. 交错：一种面向多处理器和工作站的多线程技术。载于 第六届编程语言和操作系统体系结构支持国际会议论文集: 308–318。
Mark, W.、Fussell, D. 2005. 2010 年的实时渲染系统。德克萨斯大学技术报告 05-18。
Myer, T.H.、Sutherland, I.E. 1968. 关于显示处理器的设计。《通讯》，11(6): 410–414。

BILL MARK 领导英特尔先进图形研究实验室。他目前休假离开德克萨斯大学奥斯汀分校，直到 2008 年 1 月，他在该校领导一个研究小组，研究未来的图形算法和架构。在 2001-2002 年，他是 NVIDIA 团队的技术负责人，该团队（与微软合作）共同设计了用于可编程图形硬件的 Cg 语言，并开发了 NVIDIA Cg 编译器的第一个版本。他的研究兴趣集中于实时计算机图形的系统和硬件架构，以及扩展这些系统以支持更通用的并行计算和更广泛的图形算法（包括交互式光线追踪）的机会。

最初发表于 Queue 杂志第 6 卷第 2 期—
在数字图书馆中评论本文

更多相关文章

David Crandall, Noah Snavely - 使用互联网照片集对人物和地点进行建模
本文介绍了我们使用在线照片集重建关于世界及其居民在全球和本地范围内信息的工作。这项工作得益于社交内容共享网站的 dramatic growth，这些网站创建了大量的用户生成的视觉数据在线集合。仅 Flickr.com 目前就托管了超过 60 亿张由超过 4000 万独立用户拍摄的图像，而 Facebook.com 表示其每天增长近 2.5 亿张照片。

Jeffrey Heer, Ben Shneiderman - 用于视觉分析的交互式动态
数字数据规模的不断扩大和可用性为公共政策、科学发现、商业策略，甚至我们的个人生活提供了非凡的资源。然而，为了充分利用这些数据，用户必须能够理解它：提出问题，发现感兴趣的模式，并识别（并可能纠正）错误。与数据管理系统和统计算法相结合，分析需要对数据中发现的集群、趋势和异常值的领域特定意义进行情境化的人工判断。

Robert DeLine, Gina Venolia, Kael Rowan - 使用代码地图进行软件开发
为了更好地理解专业软件开发人员如何使用代码的可视化表示，我们采访了微软的九位开发人员以确定常见场景，然后调查了 400 多位开发人员以更深入地了解这些场景。

Brendan Gregg - 可视化系统延迟
当 I/O 延迟以可视化热图的形式呈现时，可能会出现一些有趣而美丽的模式。这些模式提供了对系统实际运行情况以及最终用户应用程序体验到的延迟类型的深入了解。在这些模式中看到的许多特征仍然不被理解，但到目前为止，它们的分析正在揭示以前未知的系统行为。