Re: OpenGL-based framebuffer concepts

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
done)

DRH
-
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: OpenGL-based framebuffer concepts
    ... modified /dev/fbX device that offers native OpenGL rendering support. ... Further, as Keith Whitwell and others have rightly pointed out, a modern GPU needs such advanced resource management that the X server essentially becomes a _multi-tasking scheduler_. ... OTOH, I think a perfect video driver would be in kernel space, and do ... 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. ...
    (Linux-Kernel)
  • Re: Cello/OS X update
    ... rendering, even if you are using MesaGL, by updating the bare minimum at ... Whatever GPU you have is just gravy. ... > your display lists provide for free). ... do boring 2D graphics in OpenGL and you scream as well. ...
    (comp.lang.lisp)
  • Re: OpenGL-based framebuffer concepts
    ... Someone once mentioned OpenGL ES as a possibility as it ... stack into the kernel including the rendering loops which tend to be ... Anything of the sort should be in userspace. ... command or splitting GL commands into a chain of simpler ones as Mesa ...
    (Linux-Kernel)
  • Re: OpenGL-based framebuffer concepts
    ... No GPU today "supports" OpenGL ... Kernel either passes the OpenGL commands to the GPU or if they ... I build an OpenGL rendering context. ...
    (Linux-Kernel)
  • Re: OpenGL-based framebuffer concepts
    ... Someone once mentioned OpenGL ES as a possibility as it ... stack into the kernel including the rendering loops which tend to be ... command or splitting GL commands into a chain of simpler ones as Mesa ... You mean move the X server from being root to kernel (even ...
    (Linux-Kernel)