From owner-freebsd-x11@FreeBSD.ORG Mon Nov 5 00:02:16 2012 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 338A8824 for ; Mon, 5 Nov 2012 00:02:16 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0275F8FC15 for ; Mon, 5 Nov 2012 00:02:15 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 28EEE37B4E0; Sun, 4 Nov 2012 18:02:14 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3XvvFx2GVnzDDS; Sun, 4 Nov 2012 18:02:13 -0600 (CST) Date: Sun, 4 Nov 2012 18:02:13 -0600 From: "Matthew D. Fuller" To: "Ronald F. Guilmette" Subject: Re: r300-based boards... Are they now officially a lost cause? Message-ID: <20121105000213.GZ66994@over-yonder.net> References: <20121104184847.GY66994@over-yonder.net> <20100.1352069313@tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100.1352069313@tristatelogic.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-x11@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 00:02:16 -0000 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.