Scribd
Upload
21 views

How Does An OpenGL Program Interface With Different Graphic Cards - Stack Overflow

The document discusses how OpenGL programs interface with different graphics cards. OpenGL converts function calls to GPU driver calls specific to the card's hardware interface like PCIe. Drivers not only handle the interface but allow cards to perform vendor-specific commands.

Uploaded by

ciuciu.denis.2023
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
21 views

How Does An OpenGL Program Interface With Different Graphic Cards - Stack Overflow

The document discusses how OpenGL programs interface with different graphics cards. OpenGL converts function calls to GPU driver calls specific to the card's hardware interface like PCIe. Drivers not only handle the interface but allow cards to perform vendor-specific commands.

Uploaded by

ciuciu.denis.2023
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

How does an OpenGL program interface with different graphic

cards
Asked 10 years, 3 months ago Modified 10 years, 3 months ago Viewed 2k times

From what I understand (correct me if I am wrong), the OpenGL api converts the function calls written by
the programmer in the source code into the specific gpu driver calls of our graphic card. Then, the gpu
8 driver is able to really send instructions and data to the graphic card through some hardware interface
like PCIe, AGP or PCI.

My question is, does openGL knows how to interact with different graphic cards because there are
basically only 3 types of physical connections (PCIe, AGP and PCI)?

I think it is not that simple, because I always read that different graphic cards have different drivers, so a
driver is not just a way to use the physical interfaces, but it serves also the purpose to have graphic
cards able to perform different types of commands (which are vendor specific).

I just do not get the big picture.

opengl graphics 3d driver gpu

Share Improve this question Follow asked Dec 12, 2013 at 10:43
Kami
1,099 2 13 28

1 Answer Sorted by: Highest score (default)

This is a copy of my answer to the question "How does OpenGL work at the lowest level?" (the question
has been marked for deletion, so I add some redundancy here).
9
This question is almost impossible to answer because OpenGL by itself is just a front end API, and as
long as an implementations adheres to the specification and the outcome conforms to this it can be
done any way you like.

The question may have been: How does an OpenGL driver work on the lowest level. Now this is again
impossible to answer in general, as a driver is closely tied to some piece of hardware, which may again
do things however the developer designed it.

So the question should have been: "How does it look on average behind the scenes of OpenGL and the
graphics system?". Let's look at this from the bottom up:

1. At the lowest level there's some graphics device. Nowadays these are GPUs which provide a set of
registers controlling their operation (which registers exactly is device dependent) have some
program memory for shaders, bulk memory for input data (vertices, textures, etc.) and an I/O
channel to the rest of the system over which it recieves/sends data and command streams.

2. The graphics driver keeps track of the GPUs state and all the resources application programs that
make use of the GPU. Also it is responsible for conversion or any other processing the data sent by
applications (convert textures into the pixelformat supported by the GPU, compile shaders in the
machine code of the GPU). Furthermore it provides some abstract, driver dependent interface to
application programs.

3. Then there's the driver dependent OpenGL client library/driver. On Windows this gets loaded by
proxy through opengl32.dll, on Unix systems this resides in two places:

X11 GLX module and driver dependent GLX driver

and /usr/lib/libGL.so may contain some driver dependent stuff for direct rendering

On MacOS X this happens to be the "OpenGL Framework".


It is this part that translates OpenGL calls how you do it into calls to the driver specific functions in
the part of the driver described in (2).

4. Finally the actual OpenGL API library, opengl32.dll in Windows, and on Unix /usr/lib/libGL.so; this
mostly just passes down the commands to the OpenGL implementation proper.

How the actual communication happens can not be generalized:

In Unix the 3<->4 connection may happen either over Sockets (yes, it may, and does go over network if
you want to) or through Shared Memory. In Windows the interface library and the driver client are both
loaded into the process address space, so that's no so much communication but simple function calls
and variable/pointer passing. In MacOS X this is similar to Windows, only that there's no separation
between OpenGL interface and driver client (that's the reason why MacOS X is so slow to keep up with
new OpenGL versions, it always requires a full operating system upgrade to deliver the new framework).

Communication betwen 3<->2 may go through ioctl, read/write, or through mapping some memory into
process address space and configuring the MMU to trigger some driver code whenever changes to that
memory are done. This is quite similar on any operating system since you always have to cross the
kernel/userland boundary: Ultimately you go through some syscall.

Communication between system and GPU happen through the periphial bus and the access methods it
defines, so PCI, AGP, PCI-E, etc, which work through Port-I/O, Memory Mapped I/O, DMA, IRQs.

Share Improve this answer Follow edited May 23, 2017 at 11:45 answered Dec 12, 2013 at 19:17
Community Bot datenwolf
1 1 161k 13 188 303

To summarize in a few words... Every graphic card vendor has to supply their buyers with a gui driver (otherwise
the card would be useless) AND (if they wish, but it is probably a standard the facto) a specific OpenGL(and I
guess directX also at this point) driver. The high level opengl api will basically map every function call with his low
level opengl counterpart (like you say in 4). Am I right? – Kami Dec 12, 2013 at 20:12

@Max: Correct except that the driver also contians the high level OpenGL API implementation. The "opengl32.dll"
you link against in Windows just offers some kind of "slots" which the actual GPU driver (the so called ICD) fills. In
Linux, FreeBSD and Solaris (to this day) the libGL.so which provides the OpenGL API is part of the driver
package. However Linux is due for a new OpenGL ABI (not to confuse with API) which provides a similar facade
libGL.so into which the driver hooks its stuff. – datenwolf Dec 12, 2013 at 20:53

You might also like