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 Tuesday 23 May 2006 10:11, 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 ?

Agreed. Anything of the sort should be in userspace.

> > framebuffer. There would also need to be a way for userspace to trap
> > and emulate or ignore unsupported OpenGL commands.
>
> That would be most of them for a lot of chips because the hardware can
> only do "most" of the work, eg using software fixups after a rendering
> command or splitting GL commands into a chain of simpler ones as Mesa
> does. All large code.

Putting a full GL stack into the kernel is just plain idiotic. Among the
suggestions I made in an initial reply to this was keeping everything
possible in userspace adn providing only the minimum necessary stuff
in-kernel.

Doing otherwise - providing full emulation for unsupported commands or
features - is just copying the mistakes made by M$ with DirectX.

> > effort. Given that sort of support, a rootless xserver would be a
> > fairly trivial wrapper over whatever underlying implementation there
> > was.
>
> You mean move the X server from being root (privileged) to kernel (even
> more privileged) and pray there are no bugs in it ?
>
> Bits of the model are right - look at DRI for some (perhaps not pretty)
> evidence of that. Clearly the kernel needs to control the GPU, DMA and
> access to buffers. It isn't clear anything higher level belongs anywhere
> but user space.

Exactly what I suggested on seeing the original post.

I am currently looking for some information or help in making the Framebuffer
devices use DRM and setting up a userspace system that interfaces with the
DRM backed framebuffer device to provide full 2D and 3D acceleration of all
supported features and *userspace* emulation of the unsupported stuff.

Mesa is a good place to start for the 3D stuff, and either XAA or one of the
numerous 2D graphics packages would be a place to start for the 2D
acceleration.

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/

\
 
 \ /
  Last update: 2006-05-24 05:42    [W:0.227 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site