From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel Date: Sun, 28 Mar 2010 12:20:13 +0200 Message-ID: <4BAF2D5D.3030605@invisiblethingslab.com> References: <20100311130258.49dc04bd@farn> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1261611061==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Arvind R Cc: xen-devel@lists.xensource.com, Pekka Paalanen List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1261611061== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9E3E2DBC66F2DA82134C4EB0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9E3E2DBC66F2DA82134C4EB0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/12/2010 06:27 AM, Arvind R wrote: > On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen wrote: >> I'm adding dri-devel@ to CC, since this suggested patch touches TTM >> code, and none of the Nouveau code. TTM patches go via dri-devel@. >>=20 >> Thanks. >>=20 >>=20 >> On Wed, 10 Mar 2010 18:51:21 +0530 Arvind R >> wrote: >>=20 >>> Hi, Following is a simple patch that is needed in nouveau to get=20 >>> accelerated X on a Xen dom0 pv_ops kernel. The kernel is >>> jeremy's 2.6.31.6 as of 20100222. The whole gpu tree of nouveau >>> (which is almost the mainline merge), was substituted into the >>> kernel-tree. All components of X (mesa, Xorg-server-7.5, >>> xf86-nouveau, libdrm) used of the same day. >>>=20 >>> Patch: diff -Naur >>> nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c=20 >>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c --- >>> nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27=20 >>> 10:19:28.000000000 +0530 +++ >>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10=20 >>> 17:28:59.000000000 +0530 @@ -271,7 +271,10 @@ */ >>>=20 >>> vma->vm_private_data =3D bo; - vma->vm_flags |=3D VM_RESERVED |= >>> VM_IO | VM_MIXEDMAP | VM_DONTEXPAND; + vma->vm_flags |=3D >>> VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; + if >>> (!((bo->mem.placement & TTM_PL_MASK_MEM) & TTM_PL_FLAG_TT)) + >>> vma->vm_flags |=3D VM_IO; + vma->vm_page_prot =3D >>> vma_get_vm_prot(vma->vm_flags); return 0; out_unref:=20 >>> ttm_bo_unref(&bo); >>>=20 > Sorry for the typo: in the last added line,=20 > vma_get_vm_prot(vma->vm_flags) should be > vma->vm_get_page_prot(vma->vm_flags) >=20 Arvind, I've just tried your patch (with the above correction applied). I tried it against the latest pvops0 kernel from xen/stable-2.6.32.x with back-ported nouveau code. Xen 3.4.3-rc4 hypervisor. The actual kernel is based on Fedora 2.6.32.10.x kernel SRPM, more specifically on the Michael Young's SRPM (that integrates pvops patches): http://fedorapeople.org/~myoung/dom0/src/kernel-2.6.32.10-1.2.92.xendom0.= fc12.src.rpm With your patch I can get my nouveau X driver now working *without* NoAccel or ShadowFB settings in the xorg.conf, which was not possible before. I have enabled desktop composition using XRender in KDE (that runs in Dom0), but I see a very high "latency" in how e.g. Windows react to me wanting to move them on screen, or before the KDE's "Strat" menu appears, or when I activate the "Expose effect" (Ctrl-F8), etc. It looks like if the composition buffers were still kept in host memory and transferred to the video memory only when I want to do something with an object (e.g. move the window). So, e.g. after this delay at the beginning (e.g. after pressing Ctrl-F8) I can get smooth graphics effects (e.g. Expose effect), but this initial delay, that manifests itself before pretty much any action I take, makes the system practically unusable... I'm using the latest KDE 4.4. I've been wondering if you, or any other of xen-devel readers, have: 1) Tried the patch with some composting X Window manager in Dom0? 2) Got similar results? FWIW, when I enable ShadowFB in xorg.conf the effect no longer occurs. But ShadowFB disables H/W acceleration, so even though I can get rid of the "latency", I'm not getting smooth visual effects anymore (no smooth Expose effect :( Thanks, joanna. BTW, this is the patch I used for the recent pvops0 xen/stable-2.6.32.x: diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 3dc8d6b..0f57125 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -271,7 +271,9 @@ int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma, */ vma->vm_private_data =3D bo; - vma->vm_flags |=3D VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXP= AND; + vma->vm_flags |=3D VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & TTM_PL_FLAG_TT)) + vma->vm_flags |=3D VM_IO; vma->vm_page_prot =3D vm_get_page_prot(vma->vm_flags); return 0; out_unref: --------------enig9E3E2DBC66F2DA82134C4EB0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuvLV0ACgkQORdkotfEW85cgQCgj1pc6YUhAl2gWR7btlg393iO QcgAoKUhgE22oRSXyBcXX8ND209UtIRJ =vZdm -----END PGP SIGNATURE----- --------------enig9E3E2DBC66F2DA82134C4EB0-- --===============1261611061== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1261611061==--