Re: OpenGL-based framebuffer concepts

---------- Forwarded message ----------
From: Xiong Jiang <linuster@xxxxxxxxx>
Date: May 23, 2006 10:15 AM
Subject: Re: OpenGL-based framebuffer concepts
To: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>


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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree
    ... with the existing mess of real hardware. ... common execution environment for a kernel to find itself in. ... All you need is exactly ONE paravirt clockevent device and ONE paravirt ... paravirt_ops->clockwahtever interface and we are all happy. ...
    (Linux-Kernel)
  • Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
    ... conceeeeeeiveably the kernel could keep track of the state of the ... I believe we need an kernel level interface that will pin user pages, ... by drivers when the hardware mappings are done. ... to map the hardware, there will always be opportunity for abuse. ...
    (Linux-Kernel)
  • A proposal - binary
    ... I would like to propose an interface for linking a GPL kernel, specifically, ... explain in precise detail what a binary blob is. ... I believe some hardware vendors are trying to do. ...
    (Linux-Kernel)
  • Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree
    ... discussion at Kernel Summit was, that paravirt ops are exactly there to ... hypervisors to interact via a sane interface inside of the kernel. ... clocksource/events infrastructure, and so each would have its own ... It's not a huge reach to expect the hardware vendors to get a clue about ...
    (Linux-Kernel)
  • [BUG] panic 2.6.20-rc3 in nf_conntrack
    ... When I shut down my ppp0 interface the kernel ... This kernel had the ipp2p patch from patch-o-matic-ng applied, ... # Firmware Drivers ... # ACPI Support ...
    (Linux-Kernel)