[PREVIEW] Nouveau on FreeBSD (Take 2)

[Robert Noland]

On Mon, 2009-03-23 at 03:27 +0300, Anonymous wrote:
> Robert Noland <rnoland at FreeBSD.org> writes:
> 
> > On Mon, 2009-03-23 at 01:06 +0300, Anonymous wrote:
> >> (dropping freebsd-current@)
> >> 
> >> Robert Noland <rnoland at FreeBSD.org> writes:
> >> 
> >> > On Mon, 2009-03-23 at 00:15 +0300, Anonymous wrote:
> >> >> Robert Noland <rnoland at FreeBSD.org> writes:
> >> >> 
> >> >> > Ok, this patch should work on NV50 chips also.
> >> >> >
> >> >> > What you get is EXA and Xv.
> >> >> >
> >> >> > You still need:
> >> >> >
> >> >> > A recent -CURRENT or -STABLE.
> >> >> >
> >> >> > git master of libdrm and xf86-video-nouveau.
> >> >> >
> >> >> > This patch.
> >> >> >
> >> >> > Things I've figured out since the last patch...
> >> >> >
> >> >> > On NV50 class hardware you need to have a compositing manager running
> >> >> > for Xv to work.  That means xcompmgr, metacity with composite enabled,
> >> >> > xfce (rumored to work as well, haven't tried).  If your running Gnome
> >> >> > with metacity, open gconf-editor and go to apps->metacity->general and
> >> >> > check the composite box.
> >> >> [...]
> >> >> >
> >> >> > http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch
> >> >> >
> >> >> > robert.
> >> [...]
> >> >> - Scrolling (shift+pgup/pgdn) in xterm is *slower* with DRM than
> >> >>   without it but still faster than with NoAccel. I'm using xterm with
> >> >>   TTF font (DejaVu Sans Mono). It's yet more noticeable when scrolling
> >> >>   in less(1)/screen(1) when redrawing affects whole screen not half.
> >> >>   Besides, there is more flickering with highly updating cli apps when
> >> >>   using DRM. However, launching xcompmgr fixes this sluggishness.
> >> >
> >> > This may be related to compositing with git server.  Text rendering is
> >> > causing considerable load on the Xserver with compositing enabled.  The
> >> > composite manager is only needed for Xv, can you try without it.
> >> 
> >> Perhaps, you misread. That slow scrolling in xterm was *without*
> >> xcompmgr running. The last sentence was added afterwards when I
> >> *accidentally* successfully launched xcompmgr for XVideo test
> >> and noticed that scrolling is fast again, even faster than without DRM.
> >
> > Ah, ok... I'm not clear on why you need the composite manager on NV50
> > right now, but it seems to make things work, properly.
> 
> Well, I guess for EXAPixmaps case your statement was true. With xcompmgr
> rendering is even slower than without it, almost unusable. And XVideo
> doesn't work with xcompmgr. I can send you dmesg but it is usually
> several MB in size. Most messages look like this

I have not attempted to play with EXAPixmaps, so I can't comment right
now.

> Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_ioctl] pid=1491, cmd=0x80106449, nr=0x49, dev 0xffffff0001764900, auth=1
> Mar 23 02:00:11 luffy kernel: [drm:pid1491:nouveau_mem_free] freeing 0x2400000 type=0x00000101
> Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_ioctl] pid=1491, cmd=0xc0206448, nr=0x48, dev 0xffffff0001764900, auth=1
> Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_addmap] offset = 0xe2400000, size = 0x00010000, type = 0
> Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_addmap] Added map 0 0xe2400000/0x10000
> Mar 23 02:00:11 luffy kernel: [drm:pid1491:nouveau_mem_alloc] allocated 65536 bytes at 0x2400000 type=0x00000101
> Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_ioctl] pid=1491, cmd=0x80106449, nr=0x49, dev 0xffffff0001764900, auth=1
> Mar 23 02:00:11 luffy kernel: [drm:pid1491:nouveau_mem_free] freeing 0x2400000 type=0x00000101
> Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_ioctl] pid=1491, cmd=0xc0206448, nr=0x48, dev 0xffffff0001764900, auth=1
> Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_addmap] offset = 0xe2400000, size = 0x00010000, type = 0
> Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_addmap] Added map 0 0xe2400000/0x10000

Yes, on NV50 it is faking TTM and mapping the objects into the
frame-buffer.

robert.

> several hundreds of them per second ;)
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20090323/2a7e1ece/attachment.pgp