[PREVIEW] Nouveau on FreeBSD (Take 2)

[Anonymous]

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

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

several hundreds of them per second ;)