API Layers (Direct3D 10)

The Direct3D 10 runtime is constructed with layers, starting with the basic functionality at the core and building optional and developer-assist functionality in outer layers.

Core Layer

The core layer exists by default; providing a very thin mapping between the API and the device driver, minimizing overhead for high-frequency calls. As the core layer is essential for performance, it only performs critical validation.

The remaining layers are optional. As a general rule, layers add functionality, but do not modify existing behavior. For example, core functions will have the same return values independent of the debug layer being instantiated, although additional debug output may be provided if the debug layer is instantiated.

Create layers when a device is created by calling D3D10CreateDevice and supplying one or more D3D10_CREATE_DEVICE_FLAG values.

Debug Layer

The debug layer provides extensive additional parameter and consistency validation (such as validating shader linkage and resource binding, validating parameter consistency, and reporting error descriptions). The output generated by the debug layer consists of a queue of strings which are accessible using the ID3D10InfoQueue Interface (see Customize Debug Output with ID3D10InfoQueue (Direct3D 10)). Errors generated by the core layer are highlighted with warnings by the debug layer.

To create a device that supports the debug layer, you must install the DirectX SDK (to get D3D10SDKLayers.DLL), and then specify the D3D10_CREATE_DEVICE_DEBUG flag when calling D3D10CreateDevice. Of course, running an application with the debug layer will be substantially slower. To enable/disable debug messages for D3DX10 APIs, call D3DX10DebugMute.

When the debug layer lists memory leaks, it outputs a list of object interface pointers along with their friendly names. The default friendly name is "<unnamed>". You can set the friendly name by using the ID3D10DeviceChild::SetPrivateData method and the WKPDID_D3DDebugObjectName GUID that is in D3Dcommon.h. For example, to name pTexture with a SDKLayer name of mytexture.jpg, use the following code:

const char c_szName[] = "mytexture.jpg";
pTexture->SetPrivateData( WKPDID_D3DDebugObjectName, sizeof( c_szName ) - 1, c_szName );

Typically, you should compile these calls out of your production version.

Switch-to-Reference Layer

This layer enables an application to transition between a hardware device (HAL) and a reference or software device (REF). To switch a device, you must first create a device that supports the switch-to-reference layer (see D3D10CreateDevice) and then call ID3D10SwitchToRef::SetUseRef.

All device states, resources and objects are maintained through this device transition. However, it is sometimes not possible to exactly match resource data. This is due to the fact that some information is available to a hardware device that is not available to a reference device.

Virtually all real-time applications use the HAL implementation of the pipeline. When the pipeline is switched from a hardware device to a reference device, rendering operations are done simultaneously in both hardware and software. As the software device is rendering, it will require that resources are downloaded to system memory. This may require other resources cached in system memory to be evicted to make room.

Thread-Safe Layer

This layer is designed to allow multi-threaded applications to access the device from multiple threads.

A Direct3D 10 application can control a device synchronization using device functions. This enables an application to enable/disable critical sections (temporarily enabling/disabling multithreading protection), and take/release a critical-section lock over multiple Direct3D 10 API entry points. The thread-safe layer is enabled by default. For single-threaded applications, the thread-safe layer has no impact on performance.

Differences between Direct3D 9 and Direct3D 10:

• Unlike Direct3D 9, the Direct3D 10 API defaults to fully thread-safe.

Related topics

API Features (Direct3D 10)