From owner-freebsd-arch@FreeBSD.ORG Wed May 14 22:50:30 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E21B1065671 for ; Wed, 14 May 2008 22:50:30 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mx1.freebsd.org (Postfix) with ESMTP id 08BF68FC1D for ; Wed, 14 May 2008 22:50:29 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from mail.cokane.org ([71.168.87.213]) by vms173003.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K0V00AXVOI6OIU0@vms173003.mailsrvcs.net> for arch@FreeBSD.org; Wed, 14 May 2008 16:46:55 -0500 (CDT) Received: by mail.cokane.org (Postfix, from userid 103) id 8318B25AD3C; Wed, 14 May 2008 17:49:45 -0400 (EDT) Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cokane.org (Postfix) with ESMTP id 3EC721DB2F9; Wed, 14 May 2008 17:49:37 -0400 (EDT) Date: Wed, 14 May 2008 17:49:33 -0400 From: Coleman Kane In-reply-to: <1210352688.2152.78.camel@localhost> To: Eric Anholt Message-id: <1210801773.2466.12.camel@localhost> Organization: FreeBSD Project MIME-version: 1.0 X-Mailer: Evolution 2.22.1.1 FreeBSD GNOME Team Port Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-yBBmb6AbjuCblXyHzTIP" X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia References: <1210352688.2152.78.camel@localhost> X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8-gr1 X-Spam-Level: Cc: arch@FreeBSD.org Subject: Re: Feature requests for open-source graphics X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2008 22:50:30 -0000 --=-yBBmb6AbjuCblXyHzTIP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 2008-05-09 at 10:04 -0700, Eric Anholt wrote: > (Re-sent after I dragged a discussion of NVIDIA on FreeBSD off-topic on > developers@) >=20 > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > >=20 > > > Quite, and this has been covered several times already. In fact, =20 > > > they engage > > > in several hacks to support Linux. Other OS's such as Solaris and =20 > > > OS X have > > > cleaner interfaces for many of the things they wish to do. > >=20 > > I think this is where I normally say that we need kernel drivers > > for graphics hardware. I'm not going to do that anymore; I've been > > stating the obvious too often already... >=20 > It's OK, we're finally listening. By the end of the year, major Linux > distributions should be shipping "DRM modesetting" -- the DRM device > takes over your graphics card and manages memory, execution, and > suspend/resume. Your kernel console and X Server then sit on top of > that, submitting video mode setting and command execution requests to > the DRM. The chips I would expect to be supported by then are all > Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. >=20 > What FreeBSD needs to do to keep up is implement the memory manager > part. I think I've got a reasonable design going that should take about > a month of reimplementing for the FreeBSD kernel. If someone wanted to > get us closer to doing that, >=20 > git clone anongit.freedesktop.org:/git/mesa/drm=20 >=20 > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines) > work on -current. >=20 > To see what we're working on for what we're calling the "graphics > execution manager" now (memory management plus caching management plus > plans for execution scheduling), >=20 > git-remote add anholt people.freedesktop.org:~anholt/drm > git-fetch anholt > git-checkout anholt/drm-gem >=20 > The interesting things we're needing from the kernel: > - Private storage associated with file descriptors > - Callback to driver on destruction of file descriptor > - Ability to allocate a swap-backed pile of memory > - Ability to pin pages from that object and get addresses for them to > stuff into the GTT. > - Ability to map pages in the kernel with the uncached bits set > (non-intel) > - Ability to map pages to userland with the uncached bits set > (non-intel, likely not required, but may come at a performance > cost). >=20 > Interesting things we're likely going to need from the kernel: > - Ability to create fds above 1024 from our driver, associated with our > own set of file operations (read/write/mmap/ioctl/close). > - Ability to look up those fds and get our private storage associated > with them. >=20 > If above goes through, then another likely adventure: > - Creating a filesystem exposing those objects we've been making fds > for. >=20 > email message attachment, "Forwarded message - Re: Forward: Updated > FreeBSD kernel feature requests (NVIDIA graphics)" > > -------- Forwarded Message -------- > > From: Eric Anholt > > To: Marcel Moolenaar > > Cc: John Baldwin , Coleman Kane > > , Dag-Erling Sm=C3=B8rgrav , Martin > > Cracauer , gnn@freebsd.org, > > developers@freebsd.org > > Subject: Re: Forward: Updated FreeBSD kernel feature requests > > (NVIDIA graphics) > > Date: Thu, 08 May 2008 15:54:17 -0700 > > Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port > >=20 > > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > > >=20 > > > > Quite, and this has been covered several times already. In fact, =20 > > > > they engage > > > > in several hacks to support Linux. Other OS's such as Solaris and = =20 > > > > OS X have > > > > cleaner interfaces for many of the things they wish to do. > > >=20 > > > I think this is where I normally say that we need kernel drivers > > > for graphics hardware. I'm not going to do that anymore; I've been > > > stating the obvious too often already... > >=20 > > It's OK, we're finally listening. By the end of the year, major Linux > > distributions should be shipping "DRM modesetting" -- the DRM device > > takes over your graphics card and manages memory, execution, and > > suspend/resume. Your kernel console and X Server then sit on top of > > that, submitting video mode setting and command execution requests to > > the DRM. The chips I would expect to be supported by then are all > > Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. > >=20 > > What FreeBSD needs to do to keep up is implement the memory manager > > part. I think I've got a reasonable design going that should take abou= t > > a month of reimplementing for the FreeBSD kernel. If someone wanted to > > get us closer to doing that, > >=20 > > git clone anongit.freedesktop.org:/git/mesa/drm=20 > >=20 > > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines= ) > > work on -current. > >=20 > > To see what we're working on for what we're calling the "graphics > > execution manager" now (memory management plus caching management plus > > plans for execution scheduling), > >=20 > > git-remote add anholt people.freedesktop.org:~anholt/drm > > git-fetch anholt > > git-checkout anholt/drm-gem > >=20 > > The interesting things we're needing from the kernel: > > - Private storage associated with file descriptors > > - Callback to driver on destruction of file descriptor > > - Ability to allocate a swap-backed pile of memory > > - Ability to pin pages from that object and get addresses for them to > > stuff into the GTT. > > - Ability to map pages in the kernel with the uncached bits set > > (non-intel) > > - Ability to map pages to userland with the uncached bits set > > (non-intel, likely not required, but may come at a performance > > cost). > >=20 > > Interesting things we're considering needing from the kernel: > > - Ability to create fds above 1024 from our driver, associated with our > > own set of file operations (read/write/mmap/ioctl/close). > > - Ability to look up those fds and get our private storage associated > > with them. > >=20 > > Down the line, likely to happen: > > - Creating a filesystem exposing those objects we've been making fds > > for. Eric, I mentioned earlier that I would get my local git repo's changes to the mesa/drm tree available from fd.o up somewhere. I have them here: * http://www.cokane.org/cgi-bin/gitweb.cgi?p=3Ddrm.git My custom branch is 'cokane-master' The fd.o branch is tracked on 'fd-master' You can ignore the 'master' branch for now... I need to re-org my git a bit. Right now, this gets my RS690 notebook to almost work with the in-development radeonhd DRI code, but it causes Xorg to run in a busyloop when I try using the xf86-video-ati driver with it. I did a run at trying to get the vblank stuff ported over, but I got busy and haven't touched it in a bit. I also tried to tweak anything else that kept the radeon code from compiling under FreeBSD. If I have another set of eyes on this it might help me front-burner it more often to get patches in here-and-there. I've tried shoving some bug reports up to the DRI project, but they haven't been acted upon yet... --=20 Coleman Kane --=-yBBmb6AbjuCblXyHzTIP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkgrXmwACgkQcMSxQcXat5dpKACfcxjNSh8P0aBxFxu1M+FJBxpf srMAnAkJRaFXh2fRnWdW7YZbiumPDITq =xxUW -----END PGP SIGNATURE----- --=-yBBmb6AbjuCblXyHzTIP--