This is a pretty deep topic. The best resource I've found is: https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ https://

This is a pretty deep topic. The best resource I've found is: https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-... I'll also do my best to answer your questions, though I won't be able to do them justice in this space. A pretty good model for GPUs is remote procedure calls. When you want to do something like draw some triangles, you call a function in the GL API on the client side, and what the driver actually does under the hood is serialize the parameters of that call into some binary sequence, then at some point that "command buffer" is uploaded to the GPU, and a combination of hardware and software on the GPU side decodes it and uses it to set up the hardware pipeline that actually draws a triangle. There's a lot more to it than that, obviously. A very big deal is that if you did an actual RPC for every triangle draw, it would be hopelessly inefficient. So a large part of what OpenGL drivers do is use heuristics for batching up a bunch of calls into one actual request. In OpenGL, the details of that batching, and the way the command buffer is encoded, are completely hidden from the application. Shaders are basically small pieces of code that get run on the GPU hardware as part of the rendering pipeline. A vertex shader is a program that gets run every vertex in a mesh, and a fragment shader is another program that gets run for every fragment (pixel) that gets rasterized. There are other shaders that are run for other tasks, but those are the two biggies. In the early days of OpenGL, lighting calculations and so on were done by "fixed function" hardware, but these days it's programmable. In classic OpenGL, you call a function to compile a shader from a string containing GLSL source code, and the driver compiles it to machine language for the GPU hardware. You can use Radeon Shader Analyzer (available online at http://shader-playground.timjones.io/ http://shader-playground.timjones.io/) to see what that assembly language looks like. Even just to understand OpenGL better, it might make sense to learn about Vulkan. A good (though somewhat daunting) resource is "API without Secrets: Introduction to Vulkan": https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-1.html https://software.intel.com/content/www/us/en/develop/article... . In Vulkan, the batching and other aspects of resource management are much more explicit and under control of the application, though other details are still abstracted by the driver. For example, there is no one standard binary format for encoding command lists. Also, instead of the driver compiling shaders all the way from source, the application is responsible for compiling the shader into an intermediate language (SPIR-V), then the driver compiles that to the actual GPU machine language. There are some other low level GPU resources here: https://raphlinus.github.io/gpu/2020/02/12/gpu-resources.html https://raphlinus.github.io/gpu/2020/02/12/gpu-resources.htm... Best of luck, I find GPUs to be a fascinating journey!