OpenGL-based framebuffer concepts

From: Kyle Moffett
Date: Tue May 23 2006 - 01:09:48 EST

Tentatively going with the assumption put forth by Jon Smirl in his future-of-linux-graphics document and the open-graphics-project group that 3d rendering is an absolutely essential part of any next- generation graphics system, I'd be interested in ideas on a new or modified /dev/fbX device that offers native OpenGL rendering support. Someone once mentioned OpenGL ES as a possibility as it provides extensions for multiple-process windowing environments. Other requirements would obviously be the ability to allow client programs to allocate and share out chunks of graphics memory to other clients (later used as textures for compositing), support for multiple graphics cards with different hardware renderers over different busses, using DMA to transfer data between cards as necessary (and user-configurable policy about how to divide use of the cards), support for single or multiple framebuffers per GPU, as well as an arbitrary number of hardware and software viewports per framebuffer. There would also need to be a way for userspace to trap and emulate or ignore unsupported OpenGL commands. The kernel would need some rudimentary understanding of OpenGL to be able to handle buggy GPUs and prevent them from hanging the PCI bus (some GPUs can do that if sent invalid commands), but you obviously wouldn't want a full software renderer in the kernel. The system should also support transmitting OpenGL textures, commands, and other data asynchronously over a TCP socket, though doing it locally via mmap would be far more efficient. I'm probably missing other necessary generics, but that should provide a good discussion starter.

The necessary kernel support would include a graphics-memory allocator, resource management, GPU-time allocation, etc, as well as support for an overlaid kernel console. Ideally an improved graphics driver like that would be able to dump panics directly to the screen composited on top of whatever graphics are being displayed, so you'd get panics even while running X. If that kind of support was available in-kernel, fixing X to not need root would be far simpler, plus you could also write replacement X-like tools without half the effort. Given that sort of support, a rootless xserver would be a fairly trivial wrapper over whatever underlying implementation there was.

Kyle Moffett

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at