Re: OpenGL-based framebuffer concepts

[Kyle Moffett]

On May 23, 2006, at 06:28:40, 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 ?

First of all, absolutely not.  I stated elsewhere in the email:
> There would also need to be a way for userspace to trap and emulate  
> or ignore unsupported OpenGL commands.

A GPU which does not support OpenGL at all would look virtually  
identical to the current framebuffer model.  If it does support a few  
2D-acceleration features, those should be exported through a similar  
but distinct interface.  Using 3D on a GPU would trigger something  
like the following series of events:

During boot:
1)  Userspace software renderer connects to a GL-framebuffer device  
first, determines device capabilities, and installs OpenGL traps for  
all unsupported operations that it can software-render (may be none).
2)  Window-server connects to a subset of the available GL- 
framebuffer and input devices.

At client start:
1)  Client connects to the window-server via TCP or UNIX socket.
2)  If client is over UNIX socket, it receives specially-configured  
open filehandles to the graphics device and mmaps those or performs  
other operations via them, otherwise it sends and receives commands  
and textures over the socket and the window-server does those  
operations locally.

For each rendering operation (either directly via filehandle or  
indirectly through TCP to window-server):
1)  Client program loads texture into mapped texture memory  
"allocated from the GPU" (may actually be system RAM, depending on  
card capabilities and memory utilization).
2)  Client program sends OpenGL commands through kernel framebuffer  
device.
3)  Kernel either passes the OpenGL commands to the GPU or if they  
were trapped by the software renderer it passes them to that, which  
can emulate them using more primitive operations.

IMHO, the way it should work is the kernel should export "rendering  
contexts" to which a single client can connect (EX: software  
renderer, window-server, The GIMP, etc).  By default the kernel would  
export a single rendering context associated with the actual display  
device as a whole.  A client can then use kernel calls to subdivide  
its rendering context to other clients such that the client can  
choose between trapping OpenGL calls, passing them up the stack, or  
pre-rendering them to a texture.  This would allow the kernel to  
manage CPU and GPU time, memory (it could "swap" data out from the  
GPU to system RAM if necessary).  If no parent-client trapped a given  
OpenGL command and it was unsupported by the GPU then the kernel  
would return an error to the originating client.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/