Untangling The Linux Graphics Stack | Hacker News Reader

Untangling The Linux Graphics Stack

carbon-project.org

When I was 16, I wrote an essay on quantum physics for my Dutch class. It was 10 pages long and then I discovered the instructions were to write a 2 page essay. Desperate not to lose any of the interesting stuff, I took every 10 sentence paragraph and condensed as many of them as I could into single sentences. I kept all the equations, but none of the context. Strictly speaking, none of the information was lost, but the essay became completely incomprehensible, even when adjusting for the expectations one might have for an essay on quantum physics by a 16 year old. Needless to say, I was rather shocked when I got a failing grade.

This article reminds me a little of that essay. As a Linux user, which the first sentence implies is the target audience, this article helps me understand exactly nothing.

P.S. For your own sanity, never read back anything you wrote as a teenager. Dear lord.

That probably would have made sense to me if I already knew how the Linux Graphics Stack worked...

This is incredibly helpful even if incomplete. Finally somebody took time to write a decent exposure. Now, if only there were something like that about keyboard (geometry, modifiers, layouts, media keys, dead keys, compositing, input methods, capture priorities) and sound.

I actually had a pretty decent idea of the userspace graphics stack going into this, and I still understood very little of this article.. It seems to be more of a bunch of notes rather than anything that's supposed to be helpful to someone.

Hmm... this is a very basic overview. For e.g. it doesn't explain what Gallium3D actually is and also, how do proprietary (nvidia/fglrx) driver come into this picture.

Does anyone here know more details?

nvidia and fglrx have a string of binary blobs that plug in to each spot on the stack: kernel, X server, GLX. The way they communicate with each other is pretty proprietary and beyond what I know.

Gallium is an interface for doing 3D stuff. It's very generalized and describes a very general, shaderful, batched renderer. "Shaderful" means that the renderer has shaders instead of old-school fixed-function TCL and pixel combiners; "batched" means that the renderer prefers to operate on pre-cooked buffers full of data rather than vertex-at-a-time data.

Gallium matters because it is a much more direct and low-level interface for describing hardware which enables hardware-specific optimizations to be decoupled from API-level logic. We have implemented GL, D3D (not open-source!), VG, X11 (EXA, Xv, XvMC, VDPAU), etc. on top of Gallium, without having to write entirely new backends each time. It makes it easier to write drivers. Gallium's actual interface is also less verbose than user-level APIs, which means the actual drivers are smaller by anywhere from 30-50% LOCs.

To perhaps supplement the acronyms somewhat...

There are two basic parts to graphics drivers: kernel and userspace. All policy is in userspace; for graphics, this means things like rendering APIs (Cairo, GTK, X11, GL, VG). The kernel part manages the card's low-level state, handling its memory, outputs, onboard audio, power states, and so forth, but doesn't actually control how the card renders things.

The big complexity is how many different userspace clients there are that can ask the graphics card to render something fancy for them. In the X11 world, there's the internal X11 driver, which speaks EXA and uses the card to draw the general desktop, but there's also GLX, which goes through Mesa to get GL commands translated into commands for the specific graphics card. On top of those, there's special drivers for video, with four (!!) different APIs: Xvideo, Xvideo MC, VDPAU, VAAPI, and those each require helper code. VDPAU and VAAPI each require external helper libraries too.

Still with me? Awesome. Your toolkits also have graphics stuff, although they usually target an intermediate API rather than a specific card. These include Cairo, GTK, Qt, Wx, Pango, and so forth. Usually these toolkits speak the neutral X11 protocol, but they might decide to speak GL if they think it can make things go faster.

Reply on news.ycombinator.com