lkml.org 
[lkml]   [2006]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: OpenGL-based framebuffer concepts
Date
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@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-24 05:44    [W:0.619 / U:0.524 seconds]
©2003-2014 Jasper Spaans. Advertise on this site