Date: Sun, 22 Mar 2009 19:40:33 -0500 From: Robert Noland <rnoland@FreeBSD.org> To: Anonymous <swell.k@gmail.com> Cc: freebsd-x11 <freebsd-x11@freebsd.org> Subject: Re: [PREVIEW] Nouveau on FreeBSD (Take 2) Message-ID: <1237768833.1712.6.camel@balrog.2hip.net> In-Reply-To: <861vspxevi.fsf@gmail.com> References: <1237680263.1938.10.camel@balrog.2hip.net> <86r60pp8c0.fsf@gmail.com> <1237758423.1687.34.camel@balrog.2hip.net> <86y6uxfc0y.fsf@gmail.com> <1237759826.1697.2.camel@balrog.2hip.net> <861vspxevi.fsf@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-RmIGgJec2uWcfguN1PRV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-03-23 at 03:27 +0300, Anonymous wrote: > Robert Noland <rnoland@FreeBSD.org> writes: >=20 > > On Mon, 2009-03-23 at 01:06 +0300, Anonymous wrote: > >> (dropping freebsd-current@) > >>=20 > >> Robert Noland <rnoland@FreeBSD.org> writes: > >>=20 > >> > On Mon, 2009-03-23 at 00:15 +0300, Anonymous wrote: > >> >> Robert Noland <rnoland@FreeBSD.org> writes: > >> >>=20 > >> >> > 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 run= ning > >> >> > for Xv to work. That means xcompmgr, metacity with composite ena= bled, > >> >> > xfce (rumored to work as well, haven't tried). If your running G= nome > >> >> > with metacity, open gconf-editor and go to apps->metacity->genera= l 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 wi= th > >> >> TTF font (DejaVu Sans Mono). It's yet more noticeable when scroll= ing > >> >> in less(1)/screen(1) when redrawing affects whole screen not half= . > >> >> Besides, there is more flickering with highly updating cli apps w= hen > >> >> 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. > >>=20 > >> 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. >=20 > 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=3D1491, cmd=3D0= x80106449, nr=3D0x49, dev 0xffffff0001764900, auth=3D1 > Mar 23 02:00:11 luffy kernel: [drm:pid1491:nouveau_mem_free] freeing 0x24= 00000 type=3D0x00000101 > Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_ioctl] pid=3D1491, cmd=3D0= xc0206448, nr=3D0x48, dev 0xffffff0001764900, auth=3D1 > Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_addmap] offset =3D 0xe2400= 000, size =3D 0x00010000, type =3D 0 > Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_addmap] Added map 0 0xe240= 0000/0x10000 > Mar 23 02:00:11 luffy kernel: [drm:pid1491:nouveau_mem_alloc] allocated 6= 5536 bytes at 0x2400000 type=3D0x00000101 > Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_ioctl] pid=3D1491, cmd=3D0= x80106449, nr=3D0x49, dev 0xffffff0001764900, auth=3D1 > Mar 23 02:00:11 luffy kernel: [drm:pid1491:nouveau_mem_free] freeing 0x24= 00000 type=3D0x00000101 > Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_ioctl] pid=3D1491, cmd=3D0= xc0206448, nr=3D0x48, dev 0xffffff0001764900, auth=3D1 > Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_addmap] offset =3D 0xe2400= 000, size =3D 0x00010000, type =3D 0 > Mar 23 02:00:11 luffy kernel: [drm:pid1491:drm_addmap] Added map 0 0xe240= 0000/0x10000 Yes, on NV50 it is faking TTM and mapping the objects into the frame-buffer. robert. > several hundreds of them per second ;) --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD --=-RmIGgJec2uWcfguN1PRV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknG2oEACgkQM4TrQ4qfROPsAQCfWx0VbxAz/lrRJWFnD8mB5S3s q8UAnRasUrrSIo7cSPvsvK20zfN+GYT/ =5cfN -----END PGP SIGNATURE----- --=-RmIGgJec2uWcfguN1PRV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1237768833.1712.6.camel>