Re: Feature requests for open-source graphics

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@xxxxxxxxxx>
To: Marcel Moolenaar <xcllnt@xxxxxxx>
Cc: John Baldwin <jhb@xxxxxxxxxxx>, Coleman Kane
<cokane@xxxxxxxxxxx>, Dag-Erling Smørgrav <des@xxxxxx>, Martin
Cracauer <cracauer@xxxxxxxx>, gnn@xxxxxxxxxxx,
developers@xxxxxxxxxxx
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

Attachment: signature.asc
Description: This is a digitally signed message part