深度解析Direct3D 11：实战渲染与计算

5星 · 超过95%的资源需积分: 10 137 浏览量更新于2024-07-26 收藏 40.01MB PDF 举报

"Jason Zink, Matt Pettineo, Jack Hoxley的《Practical Rendering and Computation with Direct3D 11》是一本由Direct3D社区活跃成员编写的书籍，旨在帮助用户深入理解Direct3D 11的高级和低级概念，以及如何有效地利用其丰富的功能。该书提供了关于Direct3D 11 API使用的具体细节和实现，弥补了技术文档在实际应用指导上的不足。" 《Practical Rendering and Computation with Direct3D 11》详细探讨了Direct3D 11在图形渲染和计算方面的实践应用，这涵盖了Windows平台的DirectX编程。Direct3D 11是微软开发的一个图形应用程序接口(API)，用于处理复杂的3D图形任务，广泛应用于游戏开发、科学可视化、工程模拟等领域。书中内容可能包括但不限于以下几个关键知识点： 1. **Direct3D 11基础**：介绍Direct3D 11的基本架构，包括设备创建、上下文管理、资源类型（如纹理、缓冲区）以及状态对象等。 2. **渲染管线**：详述从顶点输入到像素输出的完整渲染过程，包括顶点着色器、几何着色器、光栅化阶段、像素着色器等各阶段的工作原理和优化技巧。 3. **深度缓冲与模板测试**：讲解如何使用深度缓冲和模板缓冲进行3D场景的正确渲染，以避免物体穿透和排序问题。 4. **多线程渲染**：探讨如何利用Direct3D 11的多线程支持提高渲染性能，包括工作线程的管理和同步机制。 5. **资源管理**：介绍纹理、缓冲区和其他资源的创建、更新和销毁，以及使用视图和状态对象进行资源绑定的最佳实践。 6. **着色语言（ HLSL ）**：讲解High-Level Shader Language，包括编写顶点、像素和其他类型的着色器，以及如何利用HLSL实现复杂效果。 7. **计算着色器（Compute Shader）**：介绍如何利用Direct3D 11的计算着色器进行通用计算，如物理模拟、图像处理等。 8. **硬件加速与特性查询**：讨论如何利用Direct3D 11 API查询硬件特性，以充分利用现代GPU的能力。 9. **Direct3D 11扩展和特效**：涵盖诸如Tessellation细分、多重采样抗锯齿、阴影映射、后期处理特效等高级特性。 10. **调试和性能分析**：提供工具和方法来诊断和优化Direct3D 11代码，以提高效率和稳定性。通过《Practical Rendering and Computation with Direct3D 11》，读者将能够系统地学习Direct3D 11的各个方面，并具备创建高效、高质量3D应用程序的能力。本书不仅适合初学者入门，也对经验丰富的开发者有宝贵的参考价值，帮助他们解决实际开发中的问题并提升技术深度。

1.1 Direct3D Framework 3

or other high level content are provided by the application; they are usually specialized to

the particular needs of each application.

Direct3D provides a set of API functions that can be used to convert the high-level

content of the application into a format that can be interpreted by the user-mode driver. The

content required by the application must be formatted according to the rules of Direct3D.

This includes the actual data formatting, as well as the required sequencing of function

calls. As long as the application follows the required Direct3D usage, it can be sure that it

is operating within the graphics architecture.

Once Direct3D has received a series of function calls from the application, it interacts

with the user-mode driver to produce a list of commands that are executed by the GPU.

The results of these actions are relayed to the DXGI interface to manipulate the contents of

hardware resources. DXGI handles the lower-level hardware interfaces, such as providing

an "adapter" interface for each video card that is installed in a computer. It is DXGI that

also provides access to what are called swap chains, which encapsulate the actual buffers

that can be used to present the rendered contents to a window.

Although this is not shown in Figure 1.1, it is quite likely that multiple applica-

tions will simultaneously be using the Direct3D runtime. This is one of the benefits of

the Windows display driver model (WDDM), that the video resources are virtualized and

shared among all applications. Applications do not have to worry about gaining access to

the GPU, since it is available to all applications simultaneously. Of course, when a user

is performing a very graphically intensive operation, like playing a high end game, there

are likely to be fewer applications using the GPU, and hence more of its computational

power can be directed to the game. This is a departure from the Windows XP driver model

(XPDM) which did not explicitly virtualize access to the GPU.

1.1.2 Benefits of Abstraction

Since an application interfaces with the Direct3D API instead of directly to a driver, it only

needs to learn the rales of interfacing with one API to produce the desired output instead

of trying to adapt to all of the various devices that a user might have installed. This shifts

the burden of creating a uniform rendering system with which to interact to the video card

manufacturers—they must adhere to the Direct3D standard, as opposed to the application

trying to implement its own "standard" rendering system.

The video system of modern computers typically contains specialized hardware that is

designed to perform graphics operations. However, it is possible that an entry-level com-

puter doesn't have Direct3D-capable hardware installed, or that it only has a subset of

the required functionality for a particular application. Fortunately, Direct3D 11 provides

a software driver implementation that can be used in the absence of Direct3D-capable

1. Overview of Direct3D 11

hardware (up to the Direct3D 10.1 feature level). Whether such hardware is present or not

is conveniently abstracted from the developer by Direct3D.

Both of these situations greatly benefit the developer. As long as an application can

properly interact with Direct3D 11, it will have access to a standardized rendering system,

as well as support for whatever devices are present in the system, regardless of if they are

hardware- or software-based devices.

1.2 Pipeline

Arguably, the most important concept required for understanding Direct3D 11 is a

clear understanding of its pipeline configuration. The Direct3D 11 specification de-

fines a conceptual processing pipeline to perform rendering computations, and ulti-

mately, to produce a rendered image. The term pipeline is used since data "flows" into

the pipeline, is processed in some way at each stage throughout the pipeline, and then

"flows" out of the pipeline. Over the past few iterations of the API, several changes

have been made to the pipeline to both simplify it and add additional functionality to it.

The pipeline concept itself is composed of a number of stages, which each perform dis-

tinctly different operations. Data passed into each stage is processed in some fashion before

being passed on to the next stage. Each individual stage provides a unique configurable

set of parameters that can be controlled by the developer to customize what processing is

performed. Some of the stages are referred to as fixed-function stages, which offer a limited

customization capability. These stages typically expose a state object, which can be bound

with the desired new configuration as needed.

The other stages are referred to as programmable stages, which provide a signifi-

cantly broader configuration capacity by allowing custom programs to be executed within

them. These programs are typically referred to as shader programs, and the stages are

referred to as programmable shader stages. Instead of performing a fixed set of operations

on the data that is passed into it, these programmable shader stages can implement a wide

range of different functions.

It is these shader programs that provide the most flexibility for implementing cus-

tom rendering and computational algorithms. Each programmable shader stage provides a

common feature set, called the common shader core, to provide some level of uniformity

in its abilities. These features can be thought of as a toolbox that is available to all of the

programmable shader stages. Operations like texture sampling, arithmetic instruction sets,

and so on are all common among all of the programmable stages. However, each stage

also provides its own unique functionality, either in its instruction set or in its input/output

semantics, to allow distinct types of operations to be performed.

1.2 Pipeline 5

From a high level, there are currently two general pipeline paradigms—one which is

used for rendering, and one which is used for computation. Strictly speaking, the distinc-

tion between these two configurations is somewhat loose, since they can both be used for

the other purpose. However, the distinction exists, and there is a clear difference in the

two pipelines' capabilities. We will discuss both pipelines, beginning with the rendering

pipeline.

1.2.1 Rendering Pipeline

The rendering pipeline is the origin from which the modern GPU has grown. The initial

graphics accelerators provided hardware vertex transformation to speed up 3D applica-

tions. From there, each new generation of hardware provided additional capabilities to

perform ever more complex rendering. Today, we have quite a complex pipeline, with

significant flexibility to perform nearly any algorithm in hardware. Books are published

regularly describing new techniques for using the latest hardware such as (Engel, 2009)

and(Nguyen, 2008). The level of advances in real-time rendering has really been quite

staggering over the last 5-10 years.

The rendering pipeline is intended to take a set of 3D object descriptions and convert

it into an image format that is suitable for presentation in the output window of an applica-

tion. Before diving into the details of each of the individual stages, let's take a closer look

at the complete Direct3D 11 rendering pipeline. Figure 1.2 shows a block diagram of the

pipeline, which we will see many times throughout the remainder of the book, in several

different formats.

Here, the two different types of pipeline stages, fixed-function and programmable,

are depicted with different colors. The fixed-function stages are shown with a green back-

ground, and the programmable stages with a blue background. Each stage defines its own

required input data format and also defines the output data format that it will produce when

executed. We will step through the pipeline and briefly discuss each stage, and its intended

purpose.

Figure 1.2. The complete Direct3D 11 rendering pipeline.

6 1. Overview of Direct3D 11

The entry point to the rendering pipeline is the input assembler stage. This stage is

responsible for reading input data from resources and then "assembling" vertices for use

later in the pipeline. This allows for multiple vertex buffers to be used and also provides the

ability to use instanced rendering (described in more detail in Chapter 3). In addition, the

connectivity of the vertices is also determined, based on the input resources and the desired

rendering configuration. The assembled vertices and primitive connectivity information

are then passed down the pipeline.

The vertex shader stage reads the assembled vertex data from the input assembler

stage and processes a single vertex at a time. This is the first programmable stage in the

pipeline, and it applies the current vertex shader program to each input vertex. It cannot

create or destroy vertices; it can only process the vertices that are given to it. In addition,

every vertex is processed in isolation—the information from one vertex shader invocation

is never accessible in another invocation. The primary responsibility of the vertex shader

used to be to project the vertex positions into clip space, but the addition of the tessellation

stages (discussed next) has somewhat changed this. In general, any operation that must be

performed on every vertex of the input model should be performed in the vertex shader.

The next three stages are recent additions to the pipeline to accommodate hardware

tessellation, and they must all be used together. The hull shader stage receives primitives

from the vertex shader and is responsible for two different actions. First, the hull shader

provides a function that is only run once per primitive to determine a set of tessellation

factors. These factors are used by the tessellator stage to know how finely to tessellate or

split up the current primitive. The second action that the hull shader stage must perform is

executed once for each control point in the desired output control patch configuration. In

essence, it must create the control points that will be later be used by the domain shader

stage to create the actual tessellated vertices that will eventually be used in rendering.

When the tessellation stage receives its data from the hull shader, it uses one of sev-

eral algorithms to determine an appropriate sampling pattern for the current primitive type.

Depending on the tessellation factors (from the hull shader), as well as its own configura-

tion (which is actually specified in the hull shader as well), it will determine which points

in the current primitive need to be sampled in order to tessellate the input primitive into

smaller parts. The output of the tessellation stage is actually a set of barycentric coordinates

that are passed along to the domain shader.

The domain shader takes these barycentric coordinates, in addition to the control

points produced by the hull shader, and uses them to create new vertices. It can use the

complete list of control points generated for the current primitive, textures, procedural al-

gorithms, or anything else, to convert the barycentric "location" for each tessellated point

into the output geometry that is passed on to the next stage in the pipeline. This flexibility in

deciding how to generate the resulting geometry from the tessellator stages' amplified out-

put provides significant freedom to implement many different types of tessellation algorithms.

The geometry shader stage resides in the next pipeline location. As its name implies,

the geometry shader operates on a geometric level. In practice, this means that it operates

1.2 Pipeline

on complete geometric primitives, and also produces geometric primitives. This stage can

both add and remove data elements from the pipeline, which allows for some interesting,

non-traditional uses. In addition, it can take one type of geometry as input and generate

a different type of geometry as output. This allows the conversion of single vertices into

complete triangles, or even multiple triangles. The geometry shader is also the conduit

through which processed geometry can be streamed out of the pipeline into a buffer re-

source. This is accomplished in the stream output stage.

After the geometry is sent out of the geometry shader, it has completed the portion

of the pipeline that operates at the geometric level. From this point on, the geometry is

rasterized and dealt with at the fragment level. A fragment is essentially a group of data

that corresponds to a pixel in a render target, and that can potentially be used to update the

current value of that pixel if it makes its way through the rest of the pipeline. The genera-

tion of fragment-level data begins with the fixed-function rasterizer stage. The rasterizer

produces fragments from the geometric data passed to it, by determining which pixels of

a render target are covered by the geometry. Each fragment receives interpolated versions

of all of the per-vertex attributes, to provide the information needed for further processing

later in the pipeline. In addition, the rasterizer produces a depth value for each fragment,

which will later be used for visibility testing in the output merger stage.

Once a fragment has been generated, the pixel shader is invoked to process it. The

pixel shader is required to generate a color value output for each of the render target out-

puts bound to the pipeline. To accomplish this, it may sample textures or perform computa-

tions on the incoming fragment attributes. In addition, it can also override the depth value

produced by the rasterizer stage, to allow for specialized algorithms to be implemented in

the pixel shader stage.

After the pixel shader has finished its work, its output is passed to the output merger

stage. It must correctly "merge" the pixel shader output with the bound depth/stencil and

render target resources. This includes performing depth and stencil tests, performing the

blending function, and finally, performing the actual writing of the output to the appropri-

ate resources.

This has been a brief high-level overview of each of the pipeline stages, but there are

many more details to be considered when using each of them. We will dive much deeper

into all of the available configurations and capabilities of each stage in the Chapter 3, "The

Rendering Pipeline." Until we reach that point, keep this overview of the pipeline in mind

as we continue our overview of the API.

1.2.2 Computation Pipeline

With all of the other new pipeline stages that came along with Direct3D 11, there is one ad-

ditional stage that has not yet been discussed—the compute shader stage. This stage is in-

tended to perform computation outside of the traditional rendering paradigm, and therefore

剩余636页未读，继续阅读

u010180083

粉丝: 0
资源: 1

深度解析Direct3D 11：实战渲染与计算

Practical Rendering and Computation with Direct3D 11

mesa-zink-android:Building Zink-适用于Android的镓驱动程序

Synthese und Strukturaufklärung von neuen (Eisencarbonyl)zinkund -cadmiumchlorid-Derivaten

ZinK (ZOPE in KOREAN)-开源

部署新的John-Zink-clarity-prod

Chemischer Transport fester Lösungen. 10 [1] Zum Chemischen Transport von quaternären Cobalt(II)-Zink- und Mangan(II)-Zinkgermanaten

05-27-2015_Intro-to-App-Extensions-Using-Swift:Will Zink 使用 Swift 介绍 Apple Watch 和应用程序扩展

Heterodinukleare Cobalt(II)-, Nickel(II)-, Kupfer(II)-, Zink(II)und Palladium(II)-Komplexe mit einem makrocyclischen Liganden vom Schiff-Basen-Typ: Synthesen und Strukturen

2024-2030中国Zink相纸市场现状研究分析与发展前景预测报告.docx

[Li(THF)][Zn3(CH2CN)3(LiBr)(NPMe3)4] - ein funktionalisierter Phosphaniminato-Komplex von Zink mit supramolekularer Struktur

最新资源