Re: [Solved] Nouveau on dom0

[Arvind R <arvino55@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5297 bytes --]

On Fri, Mar 12, 2010 at 1:45 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> >> THAT SOLVED THE FAULTING; OUT_RING now completes under Xen.
>
> :-)
>
>> >
>> > That is great! Thanks for doing all the hard-work in digging through the
>> > code.
>> >
>> >
>> > So this means you got graphics on the screen? Or at least that Kernel
>> > Mode Setting and the DRM parts show fancy graphics during boot?
>>
>> AT LAST, yes! Patch: (after aboout 600 reboots!)
>>
>> 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:
vma_get_vm_prot in last added line should be vm_get_page_prot

>> The previous patch worked for memory-space exported to user via
>> mmap. That worked for the pushbuf, but not for mode-setting (I guess).
>> The ensuing crashes were hard - no logs, nothing. So had to devise
>> ways of forcing log-writing before crashing (and praying). The located
>> iomem problem and had search code for appropriate condition.
>
> Aaah.
>> And setting the vm_page_prot IS important!
>>
>> Nouveau does kernel-modesetting only. The framebuffer device uses
>> channel 1 and is as regular a framebuffer as any other. 2D graphics
>> operations use channel 2 (xf86-video-nouveau). 3D graphics (gallium)
>> use a channel for every 3D window. There are 128 channels, 0 and 127
>> being reserved. Every channel has a dma-engine which is user triggered
>
> What happens if you use only one channel? Does it grow to accomodate
> more of the writes to the ring?
One channel for one compostion. So channel 1 for the consolefb device. So
if X is set to omit acceleration, it works thro the consolefb. Channel 2 is set
up for 2D graphics which alone xf86-video-nouveau (the DDX component)
supports. Channel 3 is set up for 3D acceleration provided by gallium (Mesa)
- sort of tunneling thro the DDX layer. If you run glxgears in a
window, Channel 4
will be set up the application.

Each 'Channe' is self-contained with pushbufs, dma, bo, gpuobject ....
>
>> thro' pushbuffer rings. Every DMA has a 1MiB VRAM space which forms one
>> of the targets of DMA ops - the other being in the opaque GPU-space. The
>
> So 1MiB per channel? Is this how the textures get loaded via this 1MiB
> VRAM?
Yes.

>> BO encapsualtes the virtual-address space of the user VM. and the GPU-DMA
>> is provided a constructed PageTable that is consistent with the kernel view of
>> that space. The GEM_NEW ioctl sets up the whole space-management machinery,
>> the user-space is mmaped out, and the operations triggered thro the pushbuf.
>
> So when the write to the RING is done, the GPU accesses the System RAM memory.
> What is then the deal with the 512MB or so video cards? Is that only
> used for putting textures on it?
Half the memory is used as the viewport to the system CPU and the other
half is the GPU system. The system/user transfer to the viewport (and
controls via the iomem space). The DMA is NOT programmed in the conventional
way - it has the lowest-level pagetable created for the instances 1MiB space
(to which it is bound) and the other end is managed by the GPU intelligence.

>> YAHOO! (just a simple shout)
>
> <grins> Thank you for solving this problem! If you ever are in the
> Boston area give me a ring and the beers (or your favorite liquid) is on
> me!
>
vice-versa if you are around Chennai, India.

Actually, I'm neither an expert on the deep internals of the kernel (though
I'm getting to know more about it) nor the new generation of graphics.
Just reading about the graphics devices of today got me
frustrated because I could not get it it up on Xen, and the debates on
TTM, GEM made me think that either something was drastically wrong
or something stupid was missed. So this mission.

Video-cards have loads of specialised processors - dozens of them often.
CUDA is an environment/architecure that allows normal C programs to
use these cores - someday graphics cards will also do graphics!
So somebody will have to ensure that Xen in the future is enabled for it
- it doesn't stop with Direct-Rendering - which also needs enhancements.
Having X accelerated brought down dom0 CPU usage from 15-30% on
my system to 1-5% when running a sample WinXP (with meadowcourt
PVops drivers) domU!

PS. I sent a mail to your personal address with all the patches I used in
the workout - am attaching it here too - in case it is of interest to somebody.
You should look a the correct_section_mismatch.patch for what it is worth.

[-- Attachment #2: xen-2.6.31.6.patches.tar.gz --]
[-- Type: application/x-gzip, Size: 16478 bytes --]

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

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