Direct3D

From Wikipedia, the free encyclopedia

Direct3D is part of Microsoft's DirectX API. Direct3D is only available for Microsoft's various Windows operating systems (Windows 95 and above) and is the base for the graphics API on the Xbox and Xbox 360 console systems. Direct3D is used to render three dimensional graphics in applications where performance is important, such as games. Direct3D also allows applications to run fullscreen instead of embedded in a window, though they can still run in a window if programmed for that feature. Direct3D uses hardware acceleration if it is available on the graphics card, allowing for hardware acceleration of the entire 3D rendering pipeline or even only partial acceleration. Direct3D exposes the advanced graphics capabilities of 3D graphics hardware, including z-buffering, anti-aliasing, alpha blending, mipmapping, atmospheric effects, and perspective-correct texture mapping. Integration with other DirectX technologies enables Direct3D to deliver such features as video mapping, hardware 3D rendering in 2D overlay planes, and even sprites, providing the use of 2D and 3D graphics in interactive media titles.

Direct3D is a 3D API. That is, it contains many commands for 3D rendering, however since version 8 Direct3D has superseded the old DirectDraw framework and also taken responsibility for the rendering of 2D graphics.[1] Microsoft strives to continually update Direct3D to support the latest technology available on 3D graphics cards. Direct3D offers full vertex software emulation but no pixel software emulation for features not available in hardware. For example, if software programmed using Direct3D requires pixel shaders and the video card on the user's computer does not support that feature, Direct3D will not emulate it, although it will compute and render the polygons and textures of the 3D models, albeit at a usually degraded quality and performance compared to the hardware eqivilent. The API does define a Reference Rasterizer (or REF device), which emulates a generic graphics card, although it's too slow to be used in any application to emulate pixel shaders and is usually ignored.

Direct3D's main competitor is OpenGL. There are numerous features and issues that proponents for either API disagree over, see comparison of Direct3D and OpenGL for a summary.

Contents

[edit] Architecture

Abstract Layer
Abstract Layer

Direct3D is a Microsoft DirectX API subsystem component. The aim of Direct3D is to abstract the communication between a graphics application and the graphics hardware drivers. It is presented like a thin abstract layer at a level comparable to GDI (see attached diagram). With a COM based architecture, the main difference between GDI and Direct3D is that Direct3D is directly connected to display drivers and gets better results at rendering than GDI.

Direct3D is an Immediate mode graphics API. It provides a low-level interface to every video card 3D function (transformations, clipping, lighting, materials, textures, depth buffering and so on). It also had an higher level Retained mode component, that has now been officially discontinued.

Direct3D immediate mode presents three main abstractions: devices, resources and swap chains (see attached diagram). Devices are responsible for rendering the 3D scene. They provide an interface with different options of renderization. For example, mono device provides white and black renderization and the RGB device uses colours to render. There are four types of devices:

Device
Device
  • Reference device: it is necessary to install previously the Direct3D SDK to use this device type, as this allows it to simulate those new features that aren’t yet supported by the graphics hardware.
  • Null reference device: it does nothing but returns a black screen. This device is used when the SDK is not installed and a reference device is requested.
  • Pluggable software device: it is used to perform software rasterization. Previously, it was needed to provide the device through the RegisterSoftwareDevice method. This device type was not used until DirectX 9.0.[2]

Every device contains at least one swap chain. A swap chain is made up of one or more back buffer surfaces (rectangular collection of pixel data and its attributes such as colour, depth/stencil, alpha or texture). In the back buffer is where the render will occur.

Moreover, devices contain a collection of resources too. Resources are specific data used during rendering. Each resource has four attributes:

  • Type: it describes what kind of resource is: surface, volume, texture, cube texture, volume texture, surface texture, index buffer or vertex buffer.
  • Pool:[3] it describes how the resource is managed by the runtime and where it is stored. Default pool means that the resource will exist only in device memory; managed pool means that the resource will be stored in system memory and will be sent to the device when required; system memory pool means that the resource will only exist in system memory, and scratch pool means the same as system memory pool, but, in this case, resources are not bound by hardware restrictions.
  • Format: it describes the layout of the resource’s data in memory, mainly pixel data. For example, D3DFMT_R8G8B8 format value means a 24 bits colour depth (8 bits for red, 8 bits for green and 8 bits for blue).
  • Usage: it describes, with a collection of flag bits, how the resource will be used by the application. These flags are used to know which resources are used in dynamic or in static access pattern. Static resource values don’t change after being loaded, whereas dynamic resource values are repeatedly modified.

[edit] Pipeline

Graphics pipeline process
Graphics pipeline process

The Microsoft Direct3D 10 API defines a process to convert a group of vertices, textures, buffers, and state into an image on the screen. This process is described as a rendering pipeline with several distinct stages. The different stages of the Direct3D 10 pipeline[4] are:[5]

  1. Input Assembler: Reads in vertex data from an application supplied vertex buffer and feeds them down the pipeline.
  2. Vertex Shader: Performs operations on a single vertex at a time, such as transformations, skinning, or lighting.
  3. Geometry Shader: Processes entire primitives such as triangles, points, or lines. Given a primitive, this stage discards it, or generates one or more new primitives.
  4. Stream Output: Can write out the previous stage's results to memory. This is useful to recirculate data back into the pipeline.
  5. Rasterizer: Converts primitives into pixels, feeding these pixels into the pixel shader. The Rasterizer may also perform other tasks such as clipping what is not visible, or interpolating vertex data into per-pixel data.
  6. Pixel Shader: Determines the final pixel colour to be written to the render target and can also calculate a depth value to be written to the depth buffer.
  7. Output Merger: Merges various types of output data (pixel shader values, alpha blending, depth/stencil...) to build the final result.

The pipeline stages illustrated with a round box are fully programmable. The application provides a shader program that describes the exact operations to be completed for that stage. Many stages are optional and can be disabled altogether.

[edit] Example

Drawing a triangle in Direct3D:

// A 3-vertex polygon definition
 D3DLVERTEX v[3];
 // Vertex established
 v[0]=D3DLVERTEX( D3DVECTOR(0.f, 5.f, 10.f), 0x00FF0000, 0, 0, 0 );
 // Vertex established
 v[1]=D3DLVERTEX( D3DVECTOR(0.f, 5.f, 10.f), 0x0000FF00, 0, 0, 0 );
 // Vertex established
 v[2]=D3DLVERTEX( D3DVECTOR(0.f, 5.f, 10.f), 0x000000FF, 0, 0, 0 );
 // Function call to draw the triangle
 pDevice->DrawPrimitive( D3DPT_TRIANGLELIST, D3DFVF_LVERTEX, v, 3, 0 );

Drawing a triangle in Direct3D 9

struct Vertex { float x, y, z; D3DCOLOR color; };
 Vertex triangle[] = {
  { 0.f, 5.f, 10.f, 0x00FF0000 },
  { 0.f, 5.f, 10.f, 0x0000FF00 },
  { 0.f, 5.f, 10.f, 0x000000FF }
 };
 // set Flexible Vertex Format
 pDevice->SetFVF(D3DFVF_XYZ | D3DFVF_DIFFUSE);
 // Draw - UP stands for 'user pointer', that is data 
 //is provided through a pointer and not through buffers
 pDevice->DrawPrimitiveUP(D3DPT_TRIANGLELIST, 1, triangle, sizeof(Vertex));

[edit] Display modes

Direct3D implements two display modes:

  • Fullscreen mode: The Direct3D application generates all of the graphical output for a display device. In this mode Direct3D automatically captures Alt-Tab and sets/restores screen resolution and pixel format without the programmer intervention. This also provides plenty of problems for debugging due to the 'Exclusive Cooperative Mode'.
  • Windowed mode: The result is shown inside the area of a window. Direct3D communicates with GDI to generate the graphical output in the display. Depending on driver support windowed mode can perform the same as full-screen.

[edit] History

In 1992, Servan Keondjian started a company named RenderMorphics, which developed a 3D graphics API named Reality Lab, which was used in medical imaging and CAD software. Two versions of this API were released. Microsoft bought RenderMorphics in February 1995, bringing Keondjian on board to implement a 3D graphics engine for Windows 95. This resulted in the first version of Direct3D that shipped in DirectX 2.0 and DirectX 3.0.

Direct3D initially implemented "retained mode" and "immediate mode" 3D APIs. The retained mode was a COM-based scene graph API that attained little adoption. Game developers clamored for more direct control of the hardware's activities than the Direct3D retained mode could provide. Only one game that sold a significant volume, Lego Island, was based on the Direct3D retained mode, so Microsoft did not update the retained mode after DirectX 3.0.

The first version of Direct3D immediate mode was based on an "execute buffer" programming model that Microsoft hoped hardware vendors would support directly. Execute buffers were intended to be allocated in hardware memory and parsed by the hardware in order to perform the 3D rendering. They were extremely awkward to program, however, hindering adoption of the new API and stimulating calls for Microsoft to adopt OpenGL as the official 3D rendering API for games as well as workstation applications. (see OpenGL vs. Direct3D)

Rather than adopt OpenGL as a gaming API, Microsoft chose to continue improving Direct3D, not only to be competitive with OpenGL, but to compete more effectively with proprietary APIs such as 3dfx's Glide. A team in Redmond took over development of the Direct3D Immediate mode, while Servan's RenderMorphics team continued work on the Retained mode.

Direct3D 5.0 introduced the DrawPrimitive API that eliminated the need for applications to construct execute buffers.

Direct3D 6.0 introduced numerous features to cover contemporary hardware (such as multitexture [6] and stencil buffers) as well as optimized geometry pipelines for x87, SSE and 3DNow! and optional texture management to simplify programming. Direct3D 6.0 also included support for features that had been licensed by Microsoft from specific hardware vendors for inclusion in the API, in exchange for the time-to-market advantage to the licensing vendor. S3 texture compression support was one such feature, renamed as DXTC for purposes of inclusion in the API. Another was TriTech's proprietary bump mapping technique. By including these features in DirectX, Microsoft virtually guaranteed that all PC graphics hardware vendors would support the feature at their earliest opportunity, driving industry standardization in a way that was inconceivable under the auspices of the OpenGL Architectural Review Board.

Direct3D 7.0 introduced the .dds texture format[7] and support for transform and lighting hardware acceleration (first available on PC hardware with NVIDIA's GeForce), as well as the ability to allocate vertex buffers in hardware memory. Hardware vertex buffers represent the first substantive improvement over OpenGL in DirectX history. Direct3D 7.0 also augmented DirectX support for multitexturing hardware, and represents the pinnacle of fixed-function multitexture pipeline features: although powerful, it was so complicated to program that a new programming model was needed to expose the shading capabilities of graphics hardware.

Direct3D 8.0 introduced programmability in the form of vertex and pixel shaders, enabling developers to write code without worrying about superfluous hardware state. The complexity of the shader programs depended on the complexity of the task, and the display driver compiled those shaders to instructions that could be understood by the hardware. Direct3D 8.0 and its programmable shading capabilities were the first major departure from an OpenGL-style fixed-function architecture, where drawing is controlled by a complicated state machine. Direct3D 8.0 also eliminated DirectDraw as a separate API.[8] Direct3D subsumed all remaining DirectDraw API calls still needed for application development, such as Present(), the function used to display rendering results.

Direct3D was not considered to be user friendly, but as of DirectX version 8.1, many usability problems were resolved. Direct3D 8 contained many powerful 3D graphics features, such as vertex shaders, pixel shaders, fog, bump mapping and texture mapping.

Direct3D 9.0 added a new version of the High Level Shader Language,[9] support for floating-point texture formats, multiple render targets, and texture lookups in the vertex shader. An extension only available in Windows Vista, called Direct3D 9Ex (previously versioned 9.0L), allows the use of the advantages offered by Windows Vista's Windows Display Driver Model (WDDM) and is used for Windows Aero.[10] D3D 9Ex, in conjunction with DirectX 9 class WDDM drivers allows graphics memory to be virtualized and paged out to system memory, allows graphics operations to be interrupted and scheduled and allow DirectX surfaces to be shared across processes.[11] DirectX 9.0Ex was previously known as version 1.0 of Windows Graphics Foundation (WGF).

Direct3D 10.0, was launched with and included in Windows Vista. Previously known as Windows Graphics Foundation (WGF) 2.0, D3D10 adds a number of capabilities including shader model 4.0, geometry shaders and optionally interruptibility for shader programs.[11] The DirectX 10 SDK became available in February 2007.[12]

[edit] Direct3D 10

See also: List of games with DirectX 10 support and Windows Display Driver Model

Windows Vista includes a major update to the Direct3D API. Originally called WGF 2.0 (Windows Graphics Foundation 2.0), then DirectX 10 and DirectX Next, Direct3D 10 features an updated shader model, shader model 4.0. In this model shaders still consist of fixed stages as on previous versions, but all stages sport a nearly unified interface, as well as a unified access paradigm for resources such as textures and shader constants. The language itself has been extended to be more expressive, including integer operations, a greatly increased instruction count, and more C-like language constructs. In addition to the previously available vertex and pixel shader stages, the API includes a geometry shader stage that breaks the old model of one vertex in/one vertex out, to allow geometry to actually be generated from within a shader, allowing for complex geometry to be generated entirely on the graphics hardware.

Unlike prior versions of the API, Direct3D 10 no longer uses "capability bits" (or "caps") to indicate which features are supported on a given graphics device. Instead, it defines a minimum standard of hardware capabilities which must be supported for a display system to be "Direct3D 10 compatible". This is a significant departure, with the goal of streamlining application code by removing capability-checking code and special cases based on the presence or absence of fine-grain capabilities.

Because Direct3D 10 hardware was comparatively rare after the initial release of Windows Vista and because of the massive installed based of non-Direct3D 10 compatible graphics cards, the first Direct3D 10-compatible games still provide Direct3D 9 render paths. Examples of such titles are games originally written for Direct3D 9 and ported to Direct3D 10 after their release, such as Company of Heroes, or games originally developed for Direct3D 9 with a Direct3D 10 path retrofitted later in development, such as Hellgate: London. No games have yet been announced that will natively and exclusively use Direct3D 10.

New features:

  • Fixed pipelines[13] are being done away with in favor of fully programmable pipelines (often referred to as unified pipeline architecture), which can be programmed to emulate the same.
  • New state object to enable (mostly) the CPU to change states efficiently.
  • Shader model 4.0, enhances the programmability of the graphics pipeline. It adds instructions for integer and bitwise calculations.
  • Geometry shaders, which work on adjacent triangles which form a mesh.
  • Texture arrays enable swapping of textures in GPU without CPU intervention.
  • Predicated Rendering allows drawing calls to be ignored based on some other conditions. This enables rapid occlusion culling, which prevents objects from being rendered if it is not visible or too far to be visible.
  • Instancing 2.0 support, allowing multiple instances of similar meshes, such as armies, or grass or trees, to be rendered in a single draw call, reducing the processing time needed for multiple similar objects to that of a single one.[14]

[edit] Direct3D 10.1

Direct3D 10.1 was announced by Microsoft shortly after the release of Direct3D 10. It's a minor update to the Direct3D 10 interface, adding features that had to be left out of the initial specification[citation needed]. Direct3D 10.1 sets a few more image quality standards for graphics vendors, and gives developers more control over image quality.[15] Its feature will be supported exclusively by new hardware.

The Direct3D 10.1 API is now included with the Windows Vista SP1,which is available since mid-March. The specification was finalized with the release of November 2007 DirectX SDK. [1] Direct3D 10.1 will be backwards compatible with Direct3D 10.0 hardware, but the new features will not be available until 10.1 compliant hardware is released. The only available Direct3D 10.1 hardware as of November 2007 is the Radeon HD 3000 series from ATI and the upcoming Chrome 430 GPU from S3 Graphics. NVIDIA will not be releasing any hardware to support Direct3D 10.1, the first GeForce 9 cards to be released will use GPUs from GeForce 8 series cards which support up to Direct3D 10.0. NVIDIA plans to go straight to Direct3D 11; but the first GPU specific to GeForce 9 series, was released before Direct3D 11 ( Geforce 9600 GT ).[16]

Direct3D 10.1 features bigger control over antialiasing (both multisampling and supersampling with per sample shading and application control over sample position), more flexibilities to some of the existing features (cubemap arrays, independent blending modes). Direct3D 10.1 hardware must support the following features:

Though this was made mandatory only with Direct3D 10.1, it should be noted that all Direct3D 10.0 parts out there support at least 4x multisampling and 32-bit floating point filtering, so this is not a new feature per se, just a change in wording of the specification.

[edit] Future development

Direct3D 11 is currently under development and will be presented at NVISION 08 technical conference on August 26, 2008.[17] No exhaustive specification has been made publicly available, but has listed some of the features - including tesselation — to increase at runtime the number of visible polygons from a low detail polygonal model, multithreaded rendering — to render to the same Direct3D device object from different threads for multi core CPUs, compute shaders — which exposes the shader pipeline for non-graphical tasks such as stream processing and physics acceleration, similar in spirit to what NVIDIA CUDA achieves, and Shader Model 5 among others.[17] Tesselation was earlier considered for Direct3D 10, but was later abandoned. GPUs such as Radeon R600 features a tesselation engine but is not exposed through any high level API. Microsoft has also hinted at conferences that other features such as order independent transparency, which was never exposed by the Direct3D API but supported almost transparently by early Direct3D hardware such as Videologic's PowerVR line of chips.

[edit] Related tools

Direct3D comes with D3DX, a library of tools designed to perform common mathematical calculations on vectors, matrices and colors, calculating look-at and projection matrices, spline interpolations, and several more complicated tasks, such as compiling or assembling shaders used for 3D graphic programming, compressed skeletal animation storage and matrix stacks. There are several functions that provide complex operations over 3D meshes like tangent-space computation, mesh simplification, precomputed radiance transfer, optimizing for vertex cache friendliness and stripification, and generators for 3D text meshes. 2D features include classes for drawing screen-space lines, text and sprite based particle systems. Spatial functions include various intersection routines, conversion from/to barycentric coordinates and bounding box/sphere generators. D3DX is provided as a dynamic link library (DLL).

DXUT (also called the sample framework) is a layer built on top of the Direct3D API. The framework is designed to help the programmer spend less time with mundane tasks, such as creating a window, creating a device, processing Windows messages and handling device events. It is only usable for writing simple technology-oriented demos, tutorials and workshops.

The Wine project has a somewhat working implementation of Direct3D 8 on top of OpenGL running on X and Unix-like operating systems. Currently it is under heavy development.

[edit] Direct3D and Vista

Vista and its updated driver model brings some new improvements and changes compared to the Windows XP model, and is expected to evolve even more as the hardware and the OS evolve (via future service packs or in the next version of Windows).

Windows Vista forces multithreading, via a theoretically unlimited number of execution contexts on the GPU. Multithreading was already supported in Windows XP as two applications or more could execute in different windows and be hardware accelerated. Windows Vista makes it a requirement to support an arbitrarily large number of execution contexts (or threads) in hardware or in software. Vista, in its basic scheduling incarnation (the current driver model), manages threads all by itself, allowing the hardware to switch from one thread to the other when appropriate. This is a departure from Windows XP, where the hardware could decide to switch threads on its own, as the OS had limited control about what the GPU could do. Also Windows Vista handles memory management and paging (to system memory and to disk), which is a necessity in order to support a large number of execution contexts with their own resources. Each execution context is presented with a resource view of the GPU that matches the maximum available (or exceeds it for aware applications). Most of the management is implemented on the OS side in order to be properly integrated into the OS-kernel memory management. This extra scheduling/management layer can cause performance decrease in the single-execution-thread case (especially on the CPU front), unless offloaded by adequate hardware support (or masked by other efficiency gains).

Execution contexts are protected from each other. Because of the user-mode implementation of the Vista driver, a rogue or badly written app can take control of the execution of the driver and could potentially access data from another process within GPU memory by sending modified commands. Though protected from access by another app, a well-written app still needs to protect itself against failures and device loss caused by other applications. The user-mode implementation can reduce the occurrence of BSODs caused by graphics drivers (which is a much more catastrophic event to a running app than a device-lost event).

Regularly Microsoft spokespeople talked about the necessity to have a finer grain context switching (referred to as "advanced scheduling") so as to be able to switch two execution threads at the shader-instruction level instead of the single-command level or even batch of commands. This is not a requirement of Vista, nor of Direct3D 10 compatibility. Direct3D10 apps can run, and are now running, on top of the basic scheduling implementation. This isn't typically a problem except for a potential app that would have very long execution of a single command/batch of commands (which is currently prevented under Windows Vista). Vista cannot enforce right now a finer-grained context switching, as it will require additional support from hardware vendors, but it may appear in the future.

[edit] See also

[edit] References

[edit] External links