Re: OpenGL-based framebuffer concepts

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

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 ?

> framebuffer.  There would also need to be a way for userspace to trap  
> and emulate or ignore unsupported OpenGL commands.  

That would be most of them for a lot of chips because the hardware can
only do "most" of the work, eg using software fixups after a rendering
command or splitting GL commands into a chain of simpler ones as Mesa
does. All large code.

> effort.  Given that sort of support, a rootless xserver would be a  
> fairly trivial wrapper over whatever underlying implementation there  
> was.

You mean move the X server from being root (privileged) to kernel (even
more privileged) and pray there are no bugs in it ?

Bits of the model are right - look at DRI for some (perhaps not pretty)
evidence of that. Clearly the kernel needs to control the GPU, DMA and
access to buffers. It isn't clear anything higher level belongs anywhere
but user space.

Alan

-
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/