3 ms·

There's one piece of information about the OpenGL pipeline I never quite understood: Years ago when I was playing writing my own operating system, I wanted to

There's one piece of information about the OpenGL pipeline I never quite understood: Years ago when I was playing writing my own operating system, I wanted to add accelerated video drivers, and obviously OpenGL. I now know it's out of the reach of hobby OSes, but I could never figure out what's the relationship with OpenGL and the actual hardware. Is OpenGL just an API, with the actual API -> hardware command translation done by the video driver? Or does the hardware understand some part of the OpenGL spec? Rephrased, does the OpenGL spec mandate some ABI to talk with the video card? I seem to think the former's the right answer, as I never managed to find any of the actual OpenGL -> HW command translation source code anywhere. At the time Intel wasn't a player in the video card space, so nVidia and ATI were the only option, but alas, closed source.

stuaxo 10y ago
The former is the right answer. Now, there are open source options, e.g. Nouveau for Nvidia originally for Linux, but has been ported to FreeBSD. Gallium should make it easier to do what you wanted as well - providing the glue between a video driver and APIs such as OpenGL / DirectX ( - there is a gallium implementation of DirectX 9 for Wine).
flohofwoe 10y ago
As far as I understand the history of 3D APIs, the very early GL-like APIs (in the IrisGL and Silicon Graphics days), were quite closely modelled to the hardware, e.g. the hardware was a state machine with many individual knobs and gears which were manipulated by the many different OpenGL functions. Over time GPUs became more and more like universal (but heavily parallelized) CPUs with less and less fixed-function-parts, especially after the introduction of vertex- and pixel-shaders OpenGL's model matched the underlying hardware less and less, which lead to a lot of software complexity in the driver layer (e.g. changing a single render state would lead to re-building big blocks of associated state). This was when the new APIs like D3D12, Vulkan and Metal were introduced which basically rebootet the complicated driver software layer and are again closer to what the underlying GPU hardware looks like. Hopefully the evolution continues and in a few years the software translation layer will be gone completely, and the GPUs will be exposed just as an instruction set and memory model, like regular CPUs today.

stuaxo 10y ago

The former is the right answer. Now, there are open source options, e.g. Nouveau for Nvidia originally for Linux, but has been ported to FreeBSD. Gallium should make it easier to do what you wanted as well - providing the glue between a video driver and APIs such as OpenGL / DirectX ( - there is a gallium implementation of DirectX 9 for Wine).

flohofwoe 10y ago

As far as I understand the history of 3D APIs, the very early GL-like APIs (in the IrisGL and Silicon Graphics days), were quite closely modelled to the hardware, e.g. the hardware was a state machine with many individual knobs and gears which were manipulated by the many different OpenGL functions. Over time GPUs became more and more like universal (but heavily parallelized) CPUs with less and less fixed-function-parts, especially after the introduction of vertex- and pixel-shaders OpenGL's model matched the underlying hardware less and less, which lead to a lot of software complexity in the driver layer (e.g. changing a single render state would lead to re-building big blocks of associated state). This was when the new APIs like D3D12, Vulkan and Metal were introduced which basically rebootet the complicated driver software layer and are again closer to what the underlying GPU hardware looks like. Hopefully the evolution continues and in a few years the software translation layer will be gone completely, and the GPUs will be exposed just as an instruction set and memory model, like regular CPUs today.