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:4.939 / U:0.212 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site