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?)
Posted Apr 18, 2008 6:56 UTC (Fri)
by dlang (guest, #313)
[Link]
Posted Apr 18, 2008 7:34 UTC (Fri)
by Duncan (guest, #6647)
[Link] (4 responses)
Posted Apr 18, 2008 15:49 UTC (Fri)
by johnkarp (guest, #39285)
[Link]
Posted Apr 18, 2008 23:01 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
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 ?
Posted Apr 21, 2008 19:18 UTC (Mon)
by Spudd86 (subscriber, #51683)
[Link]
Stable kernel 2.6.25 released
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
> [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
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
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
Re: kernel/xorg disconnect
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.
