Messages in this thread | | | Subject | Re: OpenGL-based framebuffer concepts | From | Alan Cox <> | Date | Tue, 23 May 2006 11:11:29 +0100 |
| |
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/
| |