

Untangling The Linux Graphics Stack - keeperofdakeys
http://www.carbon-project.org/Untangling_the_Linux_graphics_stack.html

======
ordinary
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.

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

------
marchdown
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.

------
iam
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.

------
Mavrik
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?

~~~
MostAwesomeDude
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.

------
MostAwesomeDude
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.

