Re: OpenGL-based framebuffer concepts

["Xiong Jiang" <linuster@gmail.com>]

---------- Forwarded message ----------
From: Xiong Jiang <linuster@gmail.com>
Date: May 23, 2006 10:15 AM
Subject: Re: OpenGL-based framebuffer concepts
To: Alan Cox <alan@lxorguk.ukuu.org.uk>


What about initialization, mode and context switching? From the
discussion I thought that people would like to see X server and
framebuffer console could coexist in a more coordinated way, which
could be coordinated DRI in kernel.

Agreed that kernel should only deal with necessary tasks as minimum as
possible. 2D/3D engine in user mode and the reorg of Xserver/APIs
around the engine is the thing people are discussing.

Designing the interface inevitably involves clear understanding of the
hardware capabilities and closed hardware spec is an obvious obstacle.
Open Graphics card (when becoming available) would be a great thing
and I wish a great X run it to its full strength.

It's a little offtopic for this list but, it's an interface between
kernel and user mode so both the Xorg and this mailing list would see
a lot discussion on it. I am glad to see such discussion is happening.

Of course a lot of education is needed for me to discuss such, with
the wish that a better X / GUI running on modern graphics hardware is
desirable for everyone.

Regards,

On 5/23/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2006-05-23 at 11:41 -0400, Kyle Moffett wrote:
> > So a modern GPU is essentially a proprietary CPU with an obscure
> > instruction set and lots of specialized texel hardware?  Given the
> > total lack of documentation from either ATI or NVidia about such
> > cards I'd guess it's impossible for Linux to provide any kind of
> > reasonable 3d engine for that kind of environment, and it might be
> > better to target a design like the Open Graphics Project is working
> > to provide.
>
> Its typically a device you feed a series of fairly low level rendering
> commands to sometimes including instructions (eg shaders). DRI provides
> an interface that is chip dependant but typically looks like
>
>
>      [User provided command buffer]
>                    |
>      [Kernel filtering/DMA interface]
>                    |
>      [Card command queue processing]
>
>
> All the higher level graphic work is done in the 3D client itself.
>
> -
> 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/
-
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/