|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] VGA passthrough and AMD drivers
>>>>>>>> Hi all,
>>>>>>>> I have made some tests to find a good driver for FirePro V8800
>>>>>>>> on windows 7 64bit HVM.
>>>>>>>> I have been focused on ?advanced features?: quad buffer and
>>>>>>>> active stereoscopy, synchronization ?
>>>>>>>> The results, for all FirePro drivers (of this year); I can?t get
>>>>>>>> the quad buffer/active stereoscopy feature.
>>>>>>>> But they work on a native installation.
>>>>>>> Can you describe the setup a little more?
>>>>>> I?ve got 2 HP Z800 workstation with FirePro V8800, one per computer.
>>>>>>
>>>>>> It?s a setup used in CAVE system, I try (and its works, minus some
>>>>>> issues) to virtualize ?virtual reality contexts? that needs full
>>>>>> graphics card features.
>>>>>>
>>>>>> Intel Xeon E5640 CPU with Intel 5520 chipset
>>>>>>
>>>>>> cores_per_socket : 4
>>>>>>
>>>>>> threads_per_core : 2
>>>>>>
>>>>>> cpu_mhz : 2660
>>>>>>
>>>>>> total_memory : 4079
>>>>>>
>>>>>>> How many graphic cards per guest?
>>>>>> One card per guest.
>>>>>>
>>>>>>> How many guests? On how many hosts?
>>>>>> One guest per computer.
>>>>>>
>>>>> And of course, I just thought of some other questions:
>>>>> What version of Xen are you using?
>>>>> What kernel are you using in Dom0?
>>>> release : 2.6.32-5-xen-amd64
>>>> version : #1 SMP Sun May 6 08:57:29 UTC 2012
>>>> machine : x86_64
>>>> nr_cpus : 8
>>>> nr_nodes : 1
>>>> cores_per_socket : 4
>>>> threads_per_core : 2
>>>> cpu_mhz : 2660
>>>> hw_caps :
>>>> bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000000:00000001:00000000
>>>> virt_caps : hvm hvm_directio
>>>> total_memory : 4079
>>>> free_cpus : 0
>>>> xen_major : 4
>>>> xen_minor : 2
>>>> xen_extra : -unstable
>>>> xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
>>>> hvm-3.0-x86_32p hvm-3.0-x86_64
>>>> xen_scheduler : credit
>>>> xen_pagesize : 4096
>>>> platform_params : virt_start=0xffff800000000000
>>>> xen_changeset : Sun Jul 22 16:37:25 2012 +0100 25622:3c426da4788e
>>>> xen_commandline : placeholder
>>>> cc_compiler : gcc version 4.4.5 (Debian 4.4.5-8)
>>>> xend_config_format : 4
>>>>
>>>> I will change to a newer version and use xl toolstack when VGA
>>>> passthrough will be supported.
>>>>
>>>>> And just to be clear, there is only Dom0 and one Windows 7 HVM guest on
>>>>> each machine?
>>>> Yes
>>>>
>>>>>>>> The only driver that allows this feature is a Radeon HD driver
>>>>>>>> (Catalyst 12.10 WHQL).
>>>>>>>> But this driver becomes unstable when an application using
>>>>>>>> active stereo and synchronization is closed:
>>>>>>>> -The synchronization between two computers is lost.
>>>>>>>> -The CCC can crash when the synchronization is made again.
>>>>>>>> Someone have any clues about this?
>>>>>>> I don't know exactly how this works on AMD/ATI graphics cards,
>>>>>>> but I have worked with synchronisation on other graphics cards
>>>>>>> about 7 years ago, so I have some idea of how you solve the
>>>>>>> various problems.
>>>>>>> What I don't quite understand is why it would be different
>>>>>>> between a virtual environment and the bare-metal ("native")
>>>>>>> install. My immediate guess is that there is a timing difference,
>>>>>>> for one of two reasons:
>>>>>>> 1. IOMMU is adding extra delays to the graphics card reading system
>>>>>>> memory.
>>>>>>> 2. Interrupt delays due to hypervisor.
>>>>>>> 3. Dom0 or other guest domains "stealing" CPU from the guest.
>>>>>>> I don't think those are easy to work around (as they all have to
>>>>>>> "happen" in a virtual system), but I also don't REALLY understand
>>>>>>> why this should cause problems in the first place, as there isn't
>>>>>>> any guarantee as to the timings of either memory reads, interrupt
>>>>>>> latency/responsiveness or CPU availability in Windows, so the
>>>>>>> same problem would appear in native systems as well, given "the right"
>>>>>>> circumstances.
>>>>>>> What exactly is the crash in CCC?
>>>>>>> (CCC stands for "Catalyst Control Center" - which I think is a
>>>>>>> Windows "service" to handle certain requests from the driver that
>>>>>>> can't be done in kernel mode [or shouldn't be done in the driver
>>>>>>> in general]).
>>>>>> After the application is closed, I launch the Catalyst Control
>>>>> Center, the synchronization state seems to be good. But there is
>>>>>> no synchronization.
>>>>>>
>>>>>> If I try to apply any modifications of synchronization (synchro
>>>>>> server or client), CCC freeze and I need to kill it manually.
>>>>>>
>>>>>> I can set the synchronization back after this.
>>>>>>
>>>>> This clearly sounds like a software issue in the CCC itself. I could be
>>>>> wrong, but that's what I think right now. It would be rather difficult to
>>>>> figure out what is going wrong without at least a repro environment.
>>>> I've made a bunch of tests this morning:
>>>> -CCC crash when I've got two displays: I set one to be the synchronization
>>>> server and the other a client at the same time. When I set the server,
>>>> apply this configuration and set the client after, it didn't crash.
>>>> -If my application (Virtools) crash, synchronization is reset.
>>>> -Eyes are sometimes inverted with the same trigger edge.
>>>I saw that problem with the product I was working on once or twice.
>>>Makes it look really "confusing". This was a settings problem in my case
>>>(because I wrote my own "controls", I could set almost every aspect of
>>>everything that could possibly be changed, with a very basic command line
>>>>>application that interacted pretty straight down to the driver - with the
>>>usual caveat of "make sure you know what you are doing" - the normal GUI
>>>Control panel setup was much more "you can only set things that make sense
>>>>>for you to set"). That is probably not really what your problem is... But
>>>could be a configuration of driver or application issue, of course.
>>>
>>>>
>>>> I've got all this behaviors with both HVM and native installation under 7
>>>> 64bits. So I think it's clearly a software issue.
>>>>
>>>> Next step: 7 32bits.
>>>So, this is not a Xen issue... Report it to the ATI/AMD folks!
>>>
>> Yes, but it doesn't explain why I can't get active stereoscopy with FirePro
>> drivers on HVM.
>
>>>>> Whilst I'm all for using Xen for everything, there are sometimes
>>>>> situations when "not using Xen" may actually be the right choice. Can you
>>>>> explain why running your guests in Xen is of benefit? [If you'd like to
>>>>> answer "none >of >>>your business", that's fine, but it may help to
>>>>> understand what the "business case" is for this].
>>>> The objective is to mutualize graphical cluster for immersive systems.
>>>> Virtual Reality applications are sensitive in their configurations; it's a
>>>> pain to manage multiple users and it's nearly impossible to have different
>>>> >configurations for these users. Usually immersive systems are stuck in
>>>> one configuration (OS, drivers, applications ...), and only few people are
>>>> allowed to change settings.
>>>> The idea is to use Xen and VGA passthrough, for create personals
>>>> environments that allow every user to make their own configurations
>>>> without impacts on others.
>>>>
>>>> Be able to have VR configurations in virtual machines and to able to run
>>>> it with 3D features, is a serious benefit for Virtual Reality users.
>>>
>>>Thanks for your explanation. Makes some sense, however, I feel that it also
>>>makes things more complex - if the system is so sensitive, it may get
>>>"upset" simply by having the differences in system behaviour that you
>>>>>automatically get from running on a virtual machine vs. "bare metal".
>>>Don't let that stop you, I'm just saying there may be issues caused by Xen
>>>(or other Virtualisation products) are not quite as transparent as they
>>>really should >>be.
>>>>>
>
>> It's not the hardware configurations that is so sensitive but more the
>> software configurations and drivers versions.
>> I've already made some demonstrations of Xen capabilities in our use case,
>> there is no negative feedback. I think that HVM behavior is perfect for our
>> uses, except these driver issues.
>>
>> I found one minor bug (for us), if the first HVM executed (id=1) has the VGA
>> card, the computer reboot without logs.
>> My workaround is to launch an HVM without VGA first, stop it properly, and
>> launch my usual HVM with VGA passthrough.
>> I think, it's a bug due to my installation (Xen 4.2.0-unstable).
>>
>> I just got a new test computer, a Dell Precision T7500 with a V9800 FirePro,
>> maybe I will have the time to test something tomorrow!
Exactly the same behaviors with this computer.
>
>Hi,
>
>My experiences with CCC and vga passthrough aren't great either (bluescreen
>most of the time).
>It works now with the 12.11 catalyst beta drivers and not installing CCC, but
>just installing the driver and opencl packages from the c:\AMD\packages dir
>after stopping the install after the total package is unpacked.
>Don't know if the stereoscopy also comes in a seperate package.
>
>It runs opencl fine now, with near native performance (with luxmark benchmark)
>:-) (with xen-unstable, qemu-upstream, linux 3.7 dom0, win7 guest, 12.11
>catalyst drivers, ati radeon HD 6570 at the moment)
>
Thanks for the feedbacks! I will try what you said.
But for my use case I need CCC, even if it isn't works properly, users know how
to use it and make it work.
Aurelien
>--
>Sander
>
> Aurelien
>>--
>>Mats
>>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |