Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4174 bytes --]

On 03/12/2010 06:27 AM, Arvind R wrote:
> On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq@iki.fi> 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@.
>> 
>> Thanks.
>> 
>> 
>> On Wed, 10 Mar 2010 18:51:21 +0530 Arvind R <arvino55@gmail.com>
>> wrote:
>> 
>>> Hi, Following is a simple patch that is needed in nouveau to get 
>>> 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.
>>> 
>>> Patch: diff -Naur
>>> nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 
>>> 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 
>>> 10:19:28.000000000 +0530 +++
>>> nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c  2010-03-10 
>>> 17:28:59.000000000 +0530 @@ -271,7 +271,10 @@ */
>>> 
>>> vma->vm_private_data = bo; -       vma->vm_flags |= VM_RESERVED |
>>> VM_IO | VM_MIXEDMAP | VM_DONTEXPAND; +       vma->vm_flags |=
>>> VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; +       if
>>> (!((bo->mem.placement & TTM_PL_MASK_MEM) & TTM_PL_FLAG_TT)) +
>>> vma->vm_flags |= VM_IO; +       vma->vm_page_prot =
>>> vma_get_vm_prot(vma->vm_flags); return 0; out_unref: 
>>> ttm_bo_unref(&bo);
>>> 
> Sorry for the typo: in the last added line, 
> vma_get_vm_prot(vma->vm_flags) should be
> vma->vm_get_page_prot(vma->vm_flags)
> 
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 = bo;
-       vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND;
+    vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND;
+    if (!((bo->mem.placement & TTM_PL_MASK_MEM) & TTM_PL_FLAG_TT))
+        vma->vm_flags |= VM_IO;
        vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
        return 0;
 out_unref:


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel