How does OpenGL work at the lowest level?

Question

I understand how to write OpenGL / DirectX programs, and I know the math and conceptual materials behind it, but I'm curious how the interaction of the GPU with the processor works at a low level.

Say I have an OpenGL program written in C that displays a triangle and rotates the camera 45 degrees. When I compile this program, it will be turned into a series of ioctl calls, and the gpu driver will then send the appropriate commands to gpu, where is all the logic for rotating the triangle and setting the corresponding pixels in the corresponding color connected to? Or will the program be compiled into a “gpu program” that loads onto gpu and calculates rotation, etc.? Or something completely different?

Edit : A few days later I found this series of articles that basically answers the question: http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part- one/

Answer 1

This question is almost impossible to answer, because OpenGL itself is just an API, and as long as the implementation complies with the specification and the result complies with this, it can be done in any way.

Perhaps the question arose: how does the OpenGL driver work at the lowest level. Now, again, it is impossible to answer in general, since the driver is closely connected with some kind of hardware that can do something again, but the developer developed it.

So, the question was supposed to be: "What does it look like on average behind the scenes of OpenGL and the graphics system?" Let's look at it from the bottom up:

• At the lowest level there is some kind of graphic device. Currently, these are graphic processors that provide a set of registers that control their operation (which are accurately registered on the device), have some program memory for shaders, bulk memory for input data (vertices, textures, etc.) and an input / output channel for the rest of the system in which it receives / sends data and command streams.

• The graphics driver monitors the state of the GPU and all resource applications that use the graphics processor. He is also responsible for converting or any other processing of data sent by applications (convert textures to a pixel format supported by the GPU, compile shaders into the GPU machine code). In addition, it provides some abstract, driver-dependent interfaces for applications.

• Then there is the driver library / driver OpenGL, depending on the driver. On Windows, this gets the downloaded proxy through opengl32.dll, on Unix systems it is in two places:

  • X11 GLX module and driver-dependent GLX driver.
  • and /usr/lib/libGL.so may contain some driver-specific files for direct rendering

  On MacOS X, this will be the "OpenGL Framework".

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

• Finally, the actual OpenGL API library, opengl32.dll on Windows and Unix / usr / lib / libGL.so; it basically just passes commands to implement OpenGL.

How actual communication takes place cannot be generalized:

On Unix, a 3 ↔ 4 connection can occur either through sockets (yes, it can and does through the network, if you want), or through shared memory. On Windows, the front-end library and the driver client are loaded into the address space of the process, so there are not so many messages, but simply function calls and passing variables / pointers. On MacOS X, this is similar to Windows, only the lack of separation between the OpenGL interface and the driver client (the reason MacOS X is so in no hurry with new versions of OpenGL always requires a complete update of the operating system to deliver a new framework).

The betwen 3 ↔ 2 communication can go through ioctl, read / write, or by matching some memory in the process address space and configuring the MMU to run some driver code whenever changes to this memory occur. This is very similar to any operating system, since you always need to cross the kernel / user interface: in the end, you go through some kind of system call.

Communication between the system and the GPU takes place via the peripheral bus and the access methods that it determines, therefore PCI, AGP, PCI-E, etc., which work through port I / O, memory Mapped I / O, DMA, IRQ .

Answer 2

When I compile this program, it will be turned into a series of ioctl calls, and the gpu driver will then send the appropriate commands to gpu, where is all the logic of turning the triangle and setting the corresponding pixels in the corresponding color connected? Or will the program be compiled into a “gpu program” that loads onto gpu and calculates rotation, etc.?

You're not far off. Your program calls the installation client driver (which is not really a driver, it is a shared user library). This will use ioctl or a similar mechanism to transfer data to the kernel driver.

For the next part, it depends on the hardware. Old video cards had the so-called fixed-function pipeline. In the video card, allocated memory spaces for matrices and dedicated equipment for texture search, mixing, etc. were allocated. The video driver loaded the correct data and flags for each of these blocks, and then set the DMA to transmit vertex data (position, color, texture coordinates, etc.).

Newer equipment has processor cores ("shaders") inside the video card, which differ from your processor in that each of them works much slower, but there are many more that work in parallel. For these video cards, the driver prepares software binaries to work in the GPU shaders.

Answer 3

Your program has not been compiled for any particular GPU; it is simply dynamically linked to the library that will implement OpenGL. An actual implementation may include sending OpenGL commands to the GPU, running software backups, compiling shaders and sending them to the GPU, or even using shader backups for OpenGL commands. The graphic landscape is quite complex. Fortunately, binding isolates you from most of the driver complexities, giving drivers the opportunity to use whatever methods they see fit.

Answer 4

C / C ++ compilers / linkers do one thing: they convert text files into a series of operation codes defined by the machine that run on the processor. OpenGL and Direct3D are just C / C ++ APIs; they cannot magically convert your C / C ++ compiler / linker to GPU compiler / linker.

Each line of C / C ++ code you write will be executed on the CPU. Calls in OpenGL / Direct3D will call in C / C ++ libraries, static or dynamic, depending on the situation.

The only place the gpu program comes into play is if your code explicitly creates shaders. That is, if you call API calls in OpenGL / D3D that cause compilation and binding of shaders. To do this, you (at runtime, not C / C ++ compilation time) generate or load strings that represent shaders in some kind of shader language. Then you insert them through the shader compiler and return the object to this API that this shader represents. Then you apply one or more shaders to a specific rendering command. Each of these steps is performed explicitly in the direction of your C / C ++ code, which, as described above, runs on the CPU.

Many shader languages ​​use syntax like C / C ++. But that does not make them equivalent to C / C ++.