Date: Fri, 09 May 2008 10:04:48 -0700 From: Eric Anholt <eric@anholt.net> To: arch@FreeBSD.org Subject: Feature requests for open-source graphics Message-ID: <1210352688.2152.78.camel@localhost>
next in thread | raw e-mail | index | archive | help
--=-A99sWqJyj5njfvQeoy+G Content-Type: multipart/mixed; boundary="=-sutqlD5+ZwOigSMbKaUt" --=-sutqlD5+ZwOigSMbKaUt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable (Re-sent after I dragged a discussion of NVIDIA on FreeBSD off-topic on developers@) 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... 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. 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, git clone anongit.freedesktop.org:/git/mesa/drm=20 and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines) work on -current. 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), git-remote add anholt people.freedesktop.org:~anholt/drm git-fetch anholt git-checkout anholt/drm-gem 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). 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. If above goes through, then another likely adventure: - Creating a filesystem exposing those objects we've been making fds for. --=20 Eric Anholt anholt@FreeBSD.org eric@anholt.net eric.anholt@intel.com --=-sutqlD5+ZwOigSMbKaUt Content-Disposition: inline Content-Description: Forwarded message - Re: Forward: Updated FreeBSD kernel feature requests (NVIDIA graphics) Content-Type: message/rfc822 Return-Path: <owner-all-developers@FreeBSD.org> X-Original-To: eric@anholt.net Delivered-To: eric@anholt.net Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by camus.anholt.net (Postfix) with ESMTP id A7C03732F9 for <eric@anholt.net>; Thu, 8 May 2008 19:26:08 -0700 (PDT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 296B315549F for <eric@anholt.net>; Fri, 9 May 2008 02:26:06 +0000 (UTC) (envelope-from owner-all-developers@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id B3851106568B; Fri, 9 May 2008 02:26:05 +0000 (UTC) Delivered-To: anholt@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id 9194F1065670; Fri, 9 May 2008 02:26:05 +0000 (UTC) Delivered-To: developers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC898106566C; Fri, 9 May 2008 02:26:03 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.freebsd.org (Postfix) with ESMTP id 269C28FC0A; Fri, 9 May 2008 02:26:02 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (localhost [127.0.0.1]) by vonnegut.anholt.net (8.14.2/8.14.2) with ESMTP id m48MsJQT011541; Thu, 8 May 2008 15:54:49 -0700 (PDT) (envelope-from eric@anholt.net) Received: (from anholt@localhost) by vonnegut.anholt.net (8.14.2/8.14.2/Submit) id m48MsIw9011539; Thu, 8 May 2008 15:54:18 -0700 (PDT) (envelope-from eric@anholt.net) X-Authentication-Warning: vonnegut.anholt.net: anholt set sender to eric@anholt.net using -f Subject: Re: Forward: Updated FreeBSD kernel feature requests (NVIDIA graphics) From: Eric Anholt <eric@anholt.net> To: Marcel Moolenaar <xcllnt@mac.com> Cc: John Baldwin <jhb@freebsd.org>, Coleman Kane <cokane@freebsd.org>, Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= <des@des.no>, Martin Cracauer <cracauer@cons.org>, gnn@freebsd.org, developers@freebsd.org In-Reply-To: <55982D27-8C59-4C3E-8832-5F0749E6C65C@mac.com> References: <20080407211738.GG10919@wolf.nvidia.com> <86k5i7ghrg.fsf@ds4.des.no> <1210117298.6421.103.camel@localhost> <200805071129.35835.jhb@freebsd.org> <55982D27-8C59-4C3E-8832-5F0749E6C65C@mac.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bLVuGJ7O4f72PRhEn7Mb" Date: Thu, 08 May 2008 15:54:17 -0700 Message-Id: <1210287258.2152.45.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port Sender: owner-all-developers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG --=-bLVuGJ7O4f72PRhEn7Mb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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... 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. 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, git clone anongit.freedesktop.org:/git/mesa/drm=20 and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines) work on -current. 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), git-remote add anholt people.freedesktop.org:~anholt/drm git-fetch anholt git-checkout anholt/drm-gem 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). 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. Down the line, likely to happen: - Creating a filesystem exposing those objects we've been making fds for. --=20 Eric Anholt anholt@FreeBSD.org eric@anholt.net eric.anholt@intel.com --=-bLVuGJ7O4f72PRhEn7Mb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgjhJkACgkQHUdvYGzw6veSAgCfZrIMMwWQlbr+LHjeqpeQZWUO 9BMAn18Ga7Dd0omCslpnf9HL4s28Bmv1 =g7ib -----END PGP SIGNATURE----- --=-bLVuGJ7O4f72PRhEn7Mb-- -- This mail is for the internal use of the FreeBSD project committers, and as such is private. This mail may not be published or forwarded outside the FreeBSD committers' group or disclosed to other unauthorised parties without the explicit permission of the author(s). --=-sutqlD5+ZwOigSMbKaUt-- --=-A99sWqJyj5njfvQeoy+G Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgkhDAACgkQHUdvYGzw6vcDcQCfTD9z3tRyP5yphrzJfnP7GKf3 KQUAnRF4nVOCH3TGjyKq4WA+i7Ybxd2T =bEev -----END PGP SIGNATURE----- --=-A99sWqJyj5njfvQeoy+G--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1210352688.2152.78.camel>