Feature requests for open-source graphics (OT)

Fri May 16 14:04:02 UTC 2008

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 at anholt.net>
> > > > To: Marcel Moolenaar <xcllnt at mac.com>
> > > > Cc: John Baldwin <jhb at freebsd.org>, Coleman Kane
> > > > <cokane at freebsd.org>, Dag-Erling Smørgrav <des at des.no>, Martin
> > > > Cracauer <cracauer at cons.org>, gnn at freebsd.org,
> > > > developers at 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
> > > > 
> > > > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote:
> > > > > On May 7, 2008, at 8:29 AM, John Baldwin wrote:
> > > > > 
> > > > > > Quite, and this has been covered several times already.  In fact,  
> > > > > > they engage
> > > > > > in several hacks to support Linux.  Other OS's such as Solaris and  
> > > > > > OS X have
> > > > > > cleaner interfaces for many of the things they wish to do.
> > > > > 
> > > > > 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 
> > > > 
> > > > 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.
> > 
> > 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=drm.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...
> 
> Looks like your webserver is dead.  Could you push your tree up on
> freefall or something so I can just ssh and grab it?
> 

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.

-- 
Coleman Kane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080516/434c78c2/attachment.pgp