lkml.org 
[lkml]   [2006]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectOpenGL-based framebuffer concepts
Date
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.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-05-23 07:12    [W:0.213 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site