Re: OpenGL-based framebuffer concepts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux