Messages in this thread | | | From | "D. Hazelton" <> | Subject | Re: OpenGL-based framebuffer concepts | Date | Tue, 23 May 2006 23:41:41 +0000 |
| |
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/
| |