OpenGL-based framebuffer concepts

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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Where does OpenGL live?
    ... I assume that the command travels from my code to JOGL, ... into pieces that the graphics card can understand. ... Does the "hardware acceleration" for OpenGL occur automatically (by ... I know that my CPUs are not responsible for the rendering and that I'm ...
    (comp.graphics.api.opengl)
  • Re: opengl w/o dri capable hardware
    ... > how can I get opengl support with a graphics card which has no dri ... nVidia graphics chipsets don't have DRI support, ... well for accelerated OpenGL IME and from reports in the field. ... If you're not using an nVidia card, what's the graphics chipset in your ...
    (comp.os.linux.x)
  • Re: Graphics cards
    ... I was hoping to get some insight as to what constitutes a "good" PC graphics ... do some PC graphics cards support OpenGL better and others support ...
    (comp.graphics.api.opengl)
  • Re: Further questions on OpenGL hardware acceleration
    ... would have thought OpenGL, even running in software, would be faster than ... GDI because it's drawing functions are not highly generalised because they ... Since the GDI focuses on a very small subset of graphics ... Now using the GDI will put some constraints on the rendering capabilities. ...
    (comp.graphics.api.opengl)
  • Re: Microsoft Asleep At The Wheel Again: Missing the New Era of CAD
    ... I just learned Microsoft acquired Vexcel and Massive ... injection technology to inject an ad into the wallpape which is pasted to ... 3D graphics programming has been around for more than 20 ... platforms that natively support 3D vector graphics. ...
    (microsoft.public.dotnet.general)