Is OpenGL a CPU or GPU?

OpenGL is a specification for GPU-accelerated rendering, but it never runs on the GPU alone. The CPU executes the driver code that translates OpenGL calls into GPU instructions, so every frame depends on both processors working together.

Where does the CPU vs GPU confusion come from?

OpenGL gets filed under the graphics API label, which sounds like it belongs entirely to the GPU. In reality, an application's OpenGL calls, binding buffers, setting shader uniforms, issuing draw calls, all execute as regular code on the CPU first. Silicon Graphics released the original OpenGL specification in 1992, when the CPU and the graphics chip were already separate hardware, and that division has stayed part of the API's design ever since. The GPU only sees the work once the driver has processed and queued it.

How is the work actually split between CPU and GPU?

The CPU handles scene logic, state changes, and driver-side command translation. The OpenGL specification does not require multi-threaded command submission, so this CPU-side work has historically run on a single thread per context. The GPU takes over once commands reach the hardware queue, running vertex and fragment shaders across thousands of cores in parallel. That single-thread limitation on the CPU side is a major reason Khronos designed Vulkan, released in 2016, to let developers spread command generation across multiple CPU cores instead.

Why does this matter when a frame rate drops?

A slow OpenGL application can bottleneck on either processor, and assuming it is always a GPU problem wastes debugging time. Too many draw calls or frequent state changes overload the CPU-side driver before the GPU is even busy, while heavy shaders or large textures overload the GPU itself. Tools such as RenderDoc or a vendor GPU profiler show this split directly, breaking a captured frame into CPU submission time and GPU execution time so the actual bottleneck stops being a guess.