>>>>>>>>> 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.
>
Finally I handle the synchronization issues, as Mats said, this issue was coming
for the synchronization configuration.
The synchronization doesn''t work if an EyeInfinity group has not been
properly configured...
The synchronization is stabilized, and I get the expected behaviors (as a native
installation).
I have not been able to get the FirePro drivers works, yet!
Aurelien
>Aurelien
>
>--
>Sander
>
> Aurelien
>>--
>>Mats
>>