Re: OpenGL-based framebuffer concepts

[D. Hazelton]

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/