Feature requests for open-source graphics

Mon May 19 17:17:53 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?
> 

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.

-- 
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/20080519/b2f49105/attachment.pgp