The battle of the drivers

To understand and appreciate what goes into a modded GPU driver the best starting point is to have a grasp of what makes up a driver in general. In simplest terms, a driver is a chunk of software – often written in C – that gets hardware and the OS talking happily, so that requests can be made from (for example) a game that sits on top of the OS through to the device in question to cause the sweet action that happens on-screen. Device drivers are powerful little critters which operate in kernel mode rather than the more standard ‘user’ mode of an application. This means drivers get to access to all kinds of low-level functions within Windows not normally available (but obviously required for a device driver to work) and there are no restrictions to the driver being able to write and read protected areas of memory or be in direct I/O access with physical devices.

It’s this ability for drivers to cut through the higher level guff that most ordinary applications must wade through to execute code on a PC that makes them both tricky to successfully write, and potentially catastrophic when they go wrong. Ever wondered why so many BSoDs or fatal exceptions are caused by driver mismatches or incompatibility? The unrelenting low-level access to the architecture that is the nature of a software driver – GPU drivers included – is largely to blame.

Keeping things basic, two important bits of code allow a driver to function; a DRIVER_OBJECT data structure created by Windows and a DEVICE_OBJECT data structure created by the driver itself. The DRIVER_OBJECT is a block of memory allocated by Windows that describes where the driver code is loaded into memory, the name of the driver itself and the functions supported by it. The DEVICE_OBJECT structure is created by the driver itself and is used to reference a physical device like your video card, describing different characteristics of the device. The DEVICE_OBJECT becomes the target of I/O (Input / Output) requests from applications like your favourite blood-bath FPS, acting as the go-between for user-mode programs to get functionality out of actual hardware. In amongst this are functions stored in the driver’s DLL (Dynamic Link Library) files that can be exposed and used to get the magic happening on the physical device in conjunction with Microsoft’s unifying DirectX APIs.

There’s a hell of a lot more going on, but we don’t have the room to get too deeply involved there. The crux of it is that drivers are complex, clever and absolutely required to get any useful functionality out of your GPU. So, where do modded drivers come in? Surely they are super enhanced software where the guts of reference drivers from NVIDIA or ATI have been completely revamped to allow your video card to wear its underpants on the outside and be super fast? Unfortunately, the truth is a little less glamorous.