lkml.org 
[lkml]   [2006]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: OpenGL-based framebuffer concepts
Date
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-05-23 16:14    [W:0.335 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site