Re: OpenGL-based framebuffer concepts

From: D. Hazelton
Date: Tue May 23 2006 - 23:41:46 EST

On Tuesday 23 May 2006 10:28, Jeff Garzik wrote:
> Alan Cox wrote:
> > On Maw, 2006-05-23 at 01:08 -0400, Kyle Moffett wrote:
> >> 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
> >
> > So for a low end video card you want to put a full software opengl es
> > stack into the kernel including the rendering loops which tend to be
> > large and slow, or dynamically generated code ?
> Indeed, consider the extent of that phrase "dynamically generated code."
> To do modern OpenGL (mostly fragment and vertex shaders), you basically
> must have a compiler front-end (C-like language), a code generator (JIT)
> backend for your architecture (x86, x86-64, ...), and a code generator
> backend for your GPU.
> Further, as Keith Whitwell and others have rightly pointed out, a modern
> GPU needs such advanced resource management that the X server (or
> whatever driver) essentially becomes a _multi-tasking scheduler_.
> Consider the case of two resource-hungry 3D processes rendering to the
> same X11 screen, and you'll see why a GPU scheduler is needed.
> Modern graphics is highly aligned with the Cell processor programming
> model: shipping specialized binary code elsewhere, to be remotely
> executed.
> OTOH, I think a perfect video driver would be in kernel space, and do
> * delivery of GPU commands from userspace to hardware, hopefully via
> zero-copy DMA. For older cards without a true instruction set, "GPU
> commands" simply means userspace prepares hardware register
> read/write/test commands, and blasts the sequence to hardware at the
> appropriate moment (a la S3 Savage's BCI).
> * delivery of bytecode commands (faux GPU commands) from userspace to
> kernel to hardware. Much like today's ioctls, but much more efficient
> delivery. Used for mode switching commands, basic monitor management
> commands, and other not-vendor-specific operations that belong in the
> kernel.
> * interrupt and DMA handling
> * multi-context, multi-thread GPU resource scheduler (2D/3D context
> switching is lumped in here too)
> * suspend and resume
> and nothing else.

Thanks for this list. Looks like if I'm going to do any code writing it won't
be solo, because a lot of this stuff - mostly the scheduler and interrupt
handling - is way over my head. (However, I will try to learn and will be
doing even more research when I get to the point where this is needed to be

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