How the "hw acceleration" works?

[nobond]

This might be a dumb question for the driver guy.

Suppose I got a OGL application drawing a 3D object.
PC 1 does not get any 3D HW and PC 2 has a powerful Gforce stuff.

Obviously it is driver's task to put the "3D command" into the 3D HW. But I just do not understand, how it can do it?

For PC2 Does the driver has the power to "trap" the instruction from the application?

For PC1, just nothing happend, OGL itself will be translated into CPU instruction?

 

[Zengar]

Uhm, if a 3d card is present then the OGL commands are sent to the driver. The driver knows how to communucate with the 3d hardware and will set up the card accordingly, to process the commands. If there is no 3d hardware present, then a default, "software" (CPU-side) implementation of OGL is used. Very simple.

 

[bridgman]

Yep. There are also some in-between levels, eg if a GPU has pixel shaders but no vertex shaders (say an AMD 690 IGP part) then the driver accepts the OGL commands, runs the vertex processing on CPU and the pixel processing on GPU.

 

[nobond]

I know this. My question is how technically it is translated? I mean how driver can talk to application?
Is it through the OS system call?

Uhm, if a 3d card is present then the OGL commands are sent to the driver. The driver knows how to communucate with the 3d hardware and will set up the card accordingly, to process the commands. If there is no 3d hardware present, then a default, "software" (CPU-side) implementation of OGL is used. Very simple.

 

[Zengar]

I mean how driver can talk to application?

When a OGL function is called, the OpenGL library forwards this call to the driver. With another words, the application communicates with the driver via the OpenGL library. And teh driver itself has means to access the hardware, using the mechanisms provided by the OS.

 

[ShaidarHaran]

Here's the software stack for 3d rendering in a modern OS (simplified):

application -> application programming interface (API) -> driver -> graphics hardware -> output

 

[nobond]

Does this rely on the mechasim by the OS as well?

When a OGL function is called, the OpenGL library forwards this call to the driver. With another words, the application communicates with the driver via the OpenGL library.

 

[ShaidarHaran]

Does this rely on the mechasim by the OS as well?

Pardon? That would be the interaction between the API and the driver, I believe.

 

[Zengar]

Does this rely on the mechasim by the OS as well?

The OpenGL library on Windows is written so, that it redirects all GL commands to the driver (if available). On Linux, for example, the IHV may choose to provide it's own OpenGL library (Nvidia does).

Does it answer your question?

 

[Simon F]

nobond, perhaps the concept you are looking for is "shared libraries" ( aka "dynamic link libraries" or DLL on the pc)

 

[nobond]

Sort of.
I am just curious of how the library (DLL in windows and share libraries in Linux like stuff) can
redirects to the driver.
Library must be written in a way without previous knowledge of the driver at all
Is there a general interface between the library and the driver?
My guess will be the library will have to talk to the OS first to get the informaiton of the hw etc.?

Pardon? That would be the interaction between the API and the driver, I believe.

The OpenGL library on Windows is written so, that it redirects all GL commands to the driver (if available). On Linux, for example, the IHV may choose to provide it's own OpenGL library (Nvidia does).

nobond, perhaps the concept you are looking for is "shared libraries" ( aka "dynamic link libraries" or DLL on the pc)

 

[Davros]

Is there a general interface between the library and the driver?

game sends d3d (or opengl) commands to the driver -- driver tells card to execute commands

Library must be written in a way without previous knowledge of the driver at all

yes, driver is written with knowledge of the library (by library i assume you mean api)
you cant have a directx10 driver without first having directx10

 

[Zengar]

Sort of.
Library must be written in a way without previous knowledge of the driver at all

Where do you get that from? An example how windows opengl32.dll may work:

glDrawElements(...)
{
  if (_driver_Installed)
     driver_glDrawElements(...) else softwareDrawElements(...)
}

 

[nobond]

I see what you mean.
but
_dirver_Installed is assigned by the OS when driver is installed?

glDrawElements(...)
{
if (_driver_Installed)
driver_glDrawElements(...) else softwareDrawElements(...)
}

 

[OpenGL guy]

I see what you mean.
but
_dirver_Installed is assigned by the OS when driver is installed?

When the driver is instantiated, a table of entry points is filled in and returned to the OS. So, for D3D, the driver fills in things like DrawPrimitive, Present, etc. This way the runtime knows how to communicate with the driver. A similar thing is done for OpenGL, only there are a lot more entry points.

 

[nobond]

Thanks. That is exactly what I am looking for.

When the driver is instantiated, a table of entry points is filled in and returned to the OS.

 

[cass]

The exact implementation depends on the OS and the design of driver interface.

The WGL model is quite different from most GLX ones, for example. In the WGL one, you do have an intermediate dispatch through OpenGL32.dll that connects to the installable client driver (ICD) of the hardware vendor where the hw vendor fills in dispatch tables, but in most linux implementations, the hardware vendor provides a libGL.so that *is* the driver.

Whether, how, and why the driver talks to the OS and hardware (if any hardware exists) is an orthogonal issue.

 

[mczak]

The WGL model is quite different from most GLX ones, for example. In the WGL one, you do have an intermediate dispatch through OpenGL32.dll that connects to the installable client driver (ICD) of the hardware vendor where the hw vendor fills in dispatch tables, but in most linux implementations, the hardware vendor provides a libGL.so that *is* the driver.

I don't think it works like that in "most" linux implementations (nvidia does work like that however). It's definitely not the standard way there. Though some implementations required (or still require) their own libGL, which pretty worked the same way as the standard one but was slightly incompatible. It's actually pretty funny, due to the way the dispatch and extension mechanism work (a standard libGL can't know all possible extensions), apps can query for any entry point (so "glXGetProcAddress("glThisFunctionDoesNotExist") for instance) and will get back an entry point, right there (of course, no driver is going to fill it in so calling it won't quite work...). Some apps actually incorrectly checked for presence of some gl functions like that (e.g. just assume non-null entry points can be called) instead of checking the extension string, and failed miserably...