This is not a flower, it's really a llama

Monday, April 30, 2012

Direct3D applications and API implementations

On almost all modern-day computers, tablets, and phones, computer graphics calculations are done on a separate processor – the GPU, or graphics processing unit – which frees up the main processor (CPU) for other work.

A graphics application runs on the CPU, typically in a user process, and makes calls to the Direct3D or OpenGL APIs.  These are the two most widely used low-level 3D graphics APIs.  Both are documented extensively.

In the case of Direct3D, the API methods are implemented by a Direct3D user-mode runtime, which runs synchronously in the application’s process.  The Direct3D user-mode runtime calls a GPU- and CPU-specific user-mode driver, which translates each Direct3D API call into a command packet that the GPU can interpret.  When the graphics application calls the DXGI Present method, all the command packets are passed by the Direct3D user-mode runtime to the DirectX graphics kernel, which passes it to a GPU- and CPU-specific kernel-mode driver.  The kernel-mode driver updates the command packets by replacing the virtual addresses of buffers and textures with physical addresses. It places the updated command packets into a memory location that is accessible by the GPU. It sets GPU registers and clocks as necessary, to indicate that new command packets are ready, and that the GPU must process them.  The GPU processes the command packets, and updates the framebuffer – this is a section of GPU-accessible memory that contains the color value for each pixel.  It is also known as the back color buffer. The GPU notifies the kernel-mode driver when it is done rendering, so that the kernel-mode driver can indicate to the display hardware that the framebuffer is ready to be blitted to the display.

No comments: