Date: Sun, 4 Nov 2012 18:02:13 -0600 From: "Matthew D. Fuller" <fullermd@over-yonder.net> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-x11@freebsd.org Subject: Re: r300-based boards... Are they now officially a lost cause? Message-ID: <20121105000213.GZ66994@over-yonder.net> In-Reply-To: <20100.1352069313@tristatelogic.com> References: <20121104184847.GY66994@over-yonder.net> <20100.1352069313@tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 04, 2012 at 02:48:33PM -0800 I heard the voice of
Ronald F. Guilmette, and lo! it spake thus:
>
> So let me see if I understand this...
I'm no eXpert on such matters, but here's my understanding...
> Nowadays, the world (or at any rate, the important part of it, i.e. X.org)
> thinks that Kernel Mode Switching (KSM) is the Right Way to do this stuff,
KMS
> and that it is preferable to UMS, correct?
>
> X.org wants everybody to move to exclusively using KSM (?)
Well, more specifically, X.org is moving _themselves_ to KMS, what
everyone else does isn't their problem ;)
There are actually at least two pieces here. There's KMS itself,
which means the part of the drivers dealing with modesetting etc is
now no longer part of X proper, but part of the kernel[0]. And
there's GEM/TTM/etc which have to do with the memory management (both
system and GPU) for the cards, which is also no longer part of X
proper, but part of the kernel. The X driver itself now becomes a
relatively thin shim that calls into those two for a lot of its magic.
Technically, I believe Gallium3D requires the GEM/TTM bits, not the
KMS bits. But the whole pile is often referred to in one breath. And
AFAIK all the Gallium drivers are also KMS-related drivers; while it
may be theoretically possibly, given GEM/TTM, to write a UMS driver
that does Gallium, I'm pretty sure none exist or will.
FreeBSD 9.x+ has a KMS driver for (some?) Intel chips, and the GEM
bits that the Intel driver requires. For Radeon, we're using the (now
legacy) UMS drivers, that upstream probably isn't doing much with
beyond "make sure it keeps compiling". To get the newer stuff, we'd
need to write/port a Radeon KMS driver, and also build the TTM
infrastructure (I believe all the KMS drivers other than Intel use
TTM; Intel wrote GEM for themselves).
[0] One advantage of this is that, hey, writing a new GUI stack is
much easier, since you no longer need to write all the drivers
over again for every GUI stack. You only need to write them once
for every OS. And since "Open Source *nix" is really just a
long-winded way of saying Linux, that's no problem. It's
portable; it runs on both Red Hat _and_ Ubuntu!
One implication is that the kernel "driver" isn't just a one-time
shim we write; a lot of the card-specific stuff is now in that.
So all the stuff that used to be written for each new GPU family
in xf86-video-ati etc by X.org in the UMS world, now needs to be
written for each new GPU family in the kernel by us (or ported
from the stuff written in the Linux kernel, more like).
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121105000213.GZ66994>