On 03/12/2010 06:27 AM, Arvind R wrote:
> On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen <pq@xxxxxx> 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@xxxxxxxxx>
>> 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:
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home