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:2.408 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site