|
|
Subscribe / Log in / New account

Stable kernel 2.6.25 released

Stable kernel 2.6.25 released

Posted Apr 18, 2008 1:35 UTC (Fri) by djabsolut (guest, #12799)
Parent article: Stable kernel 2.6.25 released

better kernel support for Intel and ATI R500 graphics chipsets

Pardon my ignorance, but what does that exactly mean? The patches in question seem to make the kernel aware of the device, but not much else. I'm asking this as I'm interested in the kernel / X.org driver disconnect -- is there a page/site which would explain the current state of graphics drivers within the kernel? (or to put it another way, why are graphics drivers being included in X.org instead of directly in the kernel?)


to post comments

Stable kernel 2.6.25 released

Posted Apr 18, 2008 6:56 UTC (Fri) by dlang (guest, #313) [Link]

to answer your final question (why are drivers in X instead of the kernel)

it basicly boils down to historic reasons, it's always been done that way.

X works on many different systems with different kernels and it used the same drivers on all
of them.

there's work being done currently to define an interface between kernel drivers and X that
will shift this boundry significantly, but they will need to keep much of the old code around
to support other (and older) systems

Re: kernel/xorg disconnect

Posted Apr 18, 2008 7:34 UTC (Fri) by Duncan (guest, #6647) [Link] (4 responses)

> [W]hy are graphics drivers being included in
> X.org instead of directly in the kernel?

The following is based on what I've read as I've followed X events myself, 
not on any particular first-hand knowledge I have, as I most certainly 
don't, at least in this area!  If aspects or even the entire picture are 
wrong, please, someone correct me!

This is to a large degree historical legacy.  X11 thru xfree86 and 
therefore its in-practice successor xorg were/are designed to be a 
specific platform agnostic *ix graphics interface.  As such, formerly, the 
push was to keep for-the-most-part unified drivers in X, only putting in 
the various kernels enough functionality to expose the hardware interface, 
interrupts and etc, to the user-space X.  Back when X was more a 
networkable protocol with remote (from the user perspective) client and 
local server aspects and less a direct driver of the 3D hardware common 
today (to the point where 2D is legacy and now not necessarily included at 
all, the 3D hardware handles it), that made a lot of sense.

Today, as direct (and therefore local) 3D hardware interaction becomes 
more important, with extension support now and planned traditional X 
emulation on 3D OpenGL direct implementations a generation or two in the 
future, the latency and other issues related to all those kernel/userspace 
transitions now necessary to directly access that hardware are taking 
their toll, and the push is in the opposite direction.  Development into 
the future is pushing toward each platform implementing its own native 
drivers and code, with higher level common "stub" drivers in X.  As 
mentioned, this is likely to take the form of kernel drivers implementing 
OpenGL directly on the hardware, while exposing a common interface to 
software, both 2D/3D direct, likely mostly in the kernel, and a 
traditional 2D X, likely implemented mostly in X as a mini-driver 
interfacing with the kernel drivers.

Note that a specific goal of this transition is to maintain and actually 
improve X's traditional network transparency.  By design, it's not going 
away anytime soon.  One improvement will be that due to the layering, it 
should actually be possible (over a suitable link and with a certain loss 
in speed, but acceptable in certain applications none-the-less) to do 3D 
over the network as well, while that aspect is currently extremely 
limited.  The effect is likely to be somewhat like trying to run software 
3D today, limited and slower than direct hardware access 3D, but it'll be 
possible, where it basically isn't today.

However, that's a way off still, with a number of intermediate steps in 
the middle.  Linux and the BSDs (among others, Solaris, OSX...) will need 
to gradually increase their driver functionality in step with xorg's 
development (and xfree86 still exists too, AFAIK, with at least some of 
the BSDs having moved rather more slowly to xorg and only now defaulting 
to it, with both still options) and exposure of mini-drivers and a new 
common direct hardware access OpenGL API that the kernel drivers can all 
be written to implement on their side of the interface.  We're talking 
several years of effort, on a journey that's likely to have various 
unexpected twists and turns of its own, such that the eventual 
implementation may not look much like it has been described here at all, 
altho chances are it'll be fairly close and only in the journey will we 
find the necessary different paths that end up being taken.

Confusing to the newbie it certainly can be, but that's what I've gathered 
from the various articles I've read.  Hope it clarifies things a bit for 
you as it has for me.

Duncan

Re: kernel/xorg disconnect

Posted Apr 18, 2008 15:49 UTC (Fri) by johnkarp (guest, #39285) [Link]

GLX, which is the X11 extension for OpenGL support, has supported 
networked connections since the beginning. And it does work... when I was 
a student I ran a graphical application from my dorm room to a SGI 
workstation on the other side of campus, and it was quite useable.

Re: kernel/xorg disconnect

Posted Apr 18, 2008 23:01 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (2 responses)

The kernel isn't going to do OpenGL. Doesn't want to do OpenGL. Doesn't need to do OpenGL.

OpenGL is huge. The kernel is interested only in mediating userspace access to your graphics
hardware. So it does not need to care whether you are sending co-ordinates mixed with color
information in the form of 16-bit "half precision" floating point values, which is something
you might do with OpenGL -- but instead only cares about whether your userspace program has
permission to write to this particular part of the card's RAM, or to twiddle some particular
register in the chipset.

And yes, like the other poster said, OpenGL already runs fine using GLX on a remote machine,
so long as you have enough bandwidth, and a good enough driver. nVidia's (sadly proprietary)
driver, plus a cheap 1000baseT network, is enough to play relatively recent 3D games on one
machine, with the display on another. I've seen Quake 3 played that way a few years back, and
one of the MMORPGs. Network transparency already applies just the same to 3D graphics as with
2D.

Re: kernel/xorg disconnect

Posted Apr 21, 2008 5:07 UTC (Mon) by djabsolut (guest, #12799) [Link] (1 responses)

The kernel isn't going to do OpenGL. Doesn't want to do OpenGL. Doesn't need to do OpenGL. OpenGL is huge. The kernel is interested only in mediating userspace access to your graphics hardware.

Do correct me if I'm wrong -- isn't the job of the kernel to not only mediate access, but also to abstract hardware? Allowing a user-space program to twiddle a particular register (chip specific, by implication) sounds like weaselly half-a-driver here and half-a-driver there approach. The second part of the driver allegedly lives in user-space, but for all intents and purposes it's an extension to the kernel -- this "user-space" program is directly banging the hardware.

Shouldn't the kernel provide a set of primitives on which a hardware-neutral OpenGL / Xorg is built in userspace ?

Re: kernel/xorg disconnect

Posted Apr 21, 2008 19:18 UTC (Mon) by Spudd86 (subscriber, #51683) [Link]

OpenGL is a massive abstraction, what might make sense is for the kernel to provide an
abstraction that is more low level and closer to the hardware than OpenGL that a generic
OpenGL implementation can be built on.

This is essentially what the Gallium3D people are working on making, although I can't recall
how much of that stuff is gonna be in kernel.

Modern 3D hardware can be driven primarily by writing to it's memory so the driver can
actually run in userspace for little or no penalty, possibly even requiring fewer transitions
from kernel to userspace and so actually being faster, this however applies slightly less to
older less general graphics hardware.

To find out lots about this sort of thing poke around on the nouveau wiki since the direction
taken by them is likely to be the direction taken by other open source drivers, and they are
moving some things into the kernel that are at the moment userspace only things.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds