Vaguely discussed during the Radeon X1000 release one year ago, the possibility of a low-level access, which means a direct access to the GPU without using an API such as Direct3D or OpenGL has been unveiled by ATI in detail to developers at SIGGRAPH 2006. This access which takes the shape of a virtual machine is called DPVM for Data Parallel Virtual Machine. It shows the GPU as a parallel calculation unit with its own memory controller and system management and masks some of its aspects only dedicated to graphic rendering. Roughly, only pixel shader units are exposed and the rest (vertex shader, setup engine etc.) doesn't seem to exist. The developer no longer has to worry about how get around the primary function of a GPU to use it as a calculation unit and only sees a mathematical co-processor.
A representation of the DPVMThe point of this low-level access is to increase performances. As developers have a direct access to hardware they can more easily optimise the code and set up optimisations that are impossible to do via a graphic API. Also, the control of what is really going on considerably increases especially at the memory level. It is no longer the driver which makes policy decision such as where data reside in memory and when they are copied but the developer who now has almost the absolute control. Last but not least, with the DPVM ATI gives access to developers to some of the functions of the Radeon X1000 that are not usable in DirectX9 and OpenGL such as scattering which enables the possibility to write in memory any kind of temporary result.
The DPVM has been implemented using low-level internal components from ATi's OpenGL driver. An assembler/disassembler has been developed to program the processor in its machine language but a compiler also gives the possibility to convert shaders written in HLSL or in ASM version PS 3.0.
The calculation unit exposed by the DPVM, named DPA (Data Parallel Array) processors, is the pixel shader calculation unit as we know it. It means that it is capable of processing one vec3 operation and one scalar operation in parallel and simple operations on inputs via a "mini-ALU". The calculation format is close but not identical to the simple precision floating point as it is defined by the IEEE (FP32) : the precision of some of the instructions is not as high and rounded-off numbers aren't defined. These are logical simplifications in the case of calculation units intended first of all to 3D rendering.
How will that be interesting? Hard to tell. This project is sill at an experimental stage and only a few researchers must have access to it at this date. We are still far from a tool usable in production. Nevertheless, it is interesting to see ATI opening its access to GPUs. Today, we are tempted to speculate on two different possible utilisations:
Allowing the use of an ATI GPU as a coprocessor on AMD's Torrenza platform.
Allowing the use of a current graphic card (DX9) to process physics effects in a DX10 game. When ATI said that its implementation of physic acceleration would make possible to recycle current graphic card to process physics we were seriously sceptical since the DX10 API won't want to hear about DX9 cards. Physics effects as they are currently presented (via Havok FX) are based on the use of Direct3D which is deviated from its initial purpose. Rendering a game with DX10 and processing physic effects by a DX9 card will be in consequence impossible... unless if the DPVM is used to accelerate such a physics API with on top higher performances. We remind you that these are only speculations but ATI clearly indicates that the DPVM might be used at the same time as a 3D API and also in a multi GPU environment…
