Date: Mon, 19 May 2008 13:17:16 -0400 From: Coleman Kane <cokane@FreeBSD.org> To: Eric Anholt <eric@anholt.net> Cc: arch@FreeBSD.org Subject: Re: Feature requests for open-source graphics Message-ID: <1211217436.29314.12.camel@localhost> In-Reply-To: <1210883909.96116.4.camel@localhost> References: <1210352688.2152.78.camel@localhost> <1210800676.2466.6.camel@localhost> <1210883909.96116.4.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-AOkRtzzGpc29BRyk/XaI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 2008-05-15 at 13:38 -0700, Eric Anholt wrote: > On Wed, 2008-05-14 at 17:31 -0400, Coleman Kane wrote: > > On Fri, 2008-05-09 at 10:04 -0700, Eric Anholt wrote: > > > email message attachment, "Forwarded message - Re: Forward: Updated > > > FreeBSD kernel feature requests (NVIDIA graphics)" > > > > -------- Forwarded Message -------- > > > > 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 Sm=C3=B8rgrav <des@des.no>, Martin > > > > Cracauer <cracauer@cons.org>, 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 fac= t, =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 bee= n > > > > > stating the obvious too often already... > > > >=20 > > > > It's OK, we're finally listening. By the end of the year, major Li= nux > > > > distributions should be shipping "DRM modesetting" -- the DRM devic= e > > > > takes over your graphics card and manages memory, execution, and > > > > suspend/resume. Your kernel console and X Server then sit on top o= f > > > > 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 nouvea= u. > > > >=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 wante= d 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 def= ines) > > > > 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 p= lus > > > > 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 associat= ed > > > > with them. > > > >=20 > > > > Down the line, likely to happen: > > > > - Creating a filesystem exposing those objects we've been making fd= s > > > > for. > >=20 > > Eric, > >=20 > > 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 > >=20 > > My custom branch is 'cokane-master' > > The fd.o branch is tracked on 'fd-master' > >=20 > > You can ignore the 'master' branch for now... I need to re-org my git a > > bit. > >=20 > > 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 ru= n > > 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. > >=20 > > 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 bu= g > > reports up to the DRI project, but they haven't been acted upon yet... >=20 > Looks like your webserver is dead. Could you push your tree up on > freefall or something so I can just ssh and grab it? >=20 Eric, Just met up w/ mhopf on #radeonhd on freenode. He pushed some updates to his radeonhd repo that might fix some GL bugs I've run into that prevent me from giving my changes a thumbs-up or not here. After today's buildworld/buildkernel I hope to have a little more results for you as to whether I have a functional DRI on my RS690. --=20 Coleman Kane --=-AOkRtzzGpc29BRyk/XaI 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) iEYEABECAAYFAkgxthsACgkQcMSxQcXat5etiACfa/vjpM81WuP8t/f7Oiykx7tn 8UUAniFgVecVRe7bVt5XPap1uOtgQbLV =HoA+ -----END PGP SIGNATURE----- --=-AOkRtzzGpc29BRyk/XaI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1211217436.29314.12.camel>