how do graphics drivers work?

OpenGL OpenGL: Basic Coding
1

can anyone explain me how do graphics drivers work?

and how some graphics features are added to a graphics board just by installing up-to-date drivers?

please, explain me this things because i’m sure it’s vital for any programmer.

2

Hi !

Not an easy question to answer, when you add new features by updating the driver you can of course not make any changes to the hardware, you just add new software that makes better use of the hardware.

On windows you have the opengl32.dll that does all the (OpenGL 1.1) software emulation, when you install an OpenGL driver with hardware support the driver takes over most/all functionallity from opengl32.dll unless there is something that isn’t supported in hardware, in that case it will fall back on the opengl32.dll driver.

Today the CPU (often called a GPU) is just as most other CPU’s so that you can write software for it and download it to add fancy shading effects and other stuff.

You don’t need to know much about the driver itself to write OpenGL applications.

Mikael

3

that’s a… very… uh…
well, its not an easy question to answer.

a graphics driver implements an interface. That’s how all drivers and all layers of abstraction work: the underlying software knows that a particular “black box” has an interface and for all intents and purposes, that’s all that matters. The question about how a driver adds new features is answered by noting that a drivr implements an interface, but that isn’t to say it implements it in hardware… unless you have a programmable gate array, but that’s another story.

ok, for a simple and stupid example… suppose I have a Very Fast Increment Instructoin Chip. All it does is adds one to some address. Sweet, eh? I publish an API called OpenIL (open increment library), like so:

void ilIncrement(void *address); // th value at address is increased by one

I set my team of engineers onto the problem, and after several cases of beer they decide that the device is memory mapped to address 0x31337 and responds to interrupt 0xff. who knows why? but, meh, who cares? The graphcis driver people are sobred up and thrown a crust of bread, and they sit down and come back a month later with the code:

void ilIncrement(void *address)
{
  asm mov [0x31337], address;  // i know, i know... but this is JUST an example, alrighty?
  asm int 0xFF
}

and badda-bing, badda-boom… we have a driver that implements the OpenIL interface. Users rejoice. Never before have they been able ot add one at such speed!
However, some technical people think that it would be nice to release OpenIL 2.0: now with INCREMENT BY TWO functionality. Not one to despair with such sadness because their hardware can only add one, the graphics driver people are given some more pizza and they come up with the addition:

void ilAddTwo(void *address)
{
  ilIncrement(address);
  ilIncrement(address);
}

not very clever, hey? but to the programmer, all they know is that the driver has openil two functionality. Sure, its not necessarily as fast as the Increment 10000 hardware that just came out, but the graphics system supports a new feature. It also does it in hardware, too. Suppose that OpenIL v3.0 came out which now has the ability to add any constant to the address. Well, that sounds like a bit too much like hardwork for the h/w, so what the driver writers do is this:

void ilAddConstant(void *address, unsigned int n)
{
  *address+=n;
}

Now the driver has OpenIL 3 functionalty, but nary a hardware accelerated feature in sight.

does this somewhat stupid example illustrate that

  1. drivers implement an interface,
  2. no one says that interface has to be suported by the actual underlying h/w
  3. new features are actually somewhat easy to add

cheers,
John

4

quote frmo mikael: Not an easy question to answer,

snap! this forum should use RCS.
:slight_smile: