Date: Fri, 16 May 2008 10:03:25 -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 (OT) Message-ID: <1210946605.2668.22.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
--=-PV4XDANNPwIyzawesES7 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 Yeah. Thanks to the brilliance of subsidized monopoly I got my traffic blocked suddenly without notice. I am in the process of hopping to an ISP that actually respects customer right of use of service (I'm not doing anything illegal). I'll shove the stuff up to freefall in a bit and get back to you... Rant warning (look away if you don't want a rant about the "competitive" US ISP market): Had Comcast, and they decided that it is a better use of customer money to spend it on expensive half-baked filtering systems that make the service garbage even for non-bittorrent users (as well as preventing me from getting fbsd/linux ISOs with bittorrent), as well as threatening to disconnect all of my service if I didn't stop serving my personal website and personal email on my personal Internet connection. Moved to Verizon who said that they don't block. Turns out that they block port 80 but just don't tell anybody. If they are so ashamed to admit this block, then they shouldn't do it (IMHO). Otherwise, it should be clearly stated in the TOS agreement, and conveyed to the salespeople (who told me that I could run my server on their connection). The upper-level technicians' reason was that they specifically want to prevent residential lines from being webservers. No block on public mailservers, not even a block on public Windows filesharing ports (yes!! They are open!!). Their business class service also apparently blocks port 80 unless you get the highest-level static-IP service. So I am going with one of the independent DSL operators that provide service over Verizon's lines. Both Comcast and Verizon insist that these policies are exercised by all major providers, but this is not true. Time Warner cable doesn't do this, and neither does Cincinnati Bell (last remaining non-RBOC in the lower 48). Additionally, AT&T actually has a section dedicated to expressing the customers' rights. They specifically bar hosting a server only in the cases of dial-up accounts. Server usage appears to be allowed by them for their DSL service (but I've never used AT&T service before). One of the nice perks of DSL regulation is that the line controllers don't have a monopoly on the lines themselves, which are required to be open to other ISPs who are willing to invest in the DSL system. So I actually have a choice of about 10 companies that I can have DSL from. Almost all of my alternatives seem to provide a line that endorses running a server on it. So I chose dslextreme.com, which seems like a pretty decent vendor, and provides a line that can be served from. --=20 Coleman Kane --=-PV4XDANNPwIyzawesES7 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) iEYEABECAAYFAkgtlCkACgkQcMSxQcXat5f5SwCfXdXT+JzXDfrA/RPFUMgp0TO0 KWoAnAoN0SQwal5C+ImtR0fjqwgdsXQp =FCTu -----END PGP SIGNATURE----- --=-PV4XDANNPwIyzawesES7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1210946605.2668.22.camel>