Xen devel - Dec 2012 - 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.

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?

Thanks,
Aurelien





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

On 07/12/12 14:12, Aurélien MILLIAT wrote:
>
> 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?
How many graphic cards per guest?
How many guests? On how many hosts?
>
> 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]).

--
Mats
>
> Thanks,
>
> Aurelien
>

>> 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.


>>
>> 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.



I will try next week with others computers.



Thanks for the reply,

Aurelien



--

Mats
>
> Thanks,
>
> Aurelien
>


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

On 07/12/12 16:51, Aurélien MILLIAT wrote:
>
> >> 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?

And just to be clear, there is only Dom0 and one Windows 7 HVM guest on 
each machine?
> >>
>
> >> 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.

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].

--
Mats
>
> I will try next week with others computers.
>
> Thanks for the reply,
>
> Aurelien
>
> --
>
> Mats
>
> >
>
> > Thanks,
>
> >
>
> > Aurelien
>
> >
>

On 07/12/12 16:51, Aur?lien MILLIAT wrote:
>>
>> >> 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''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.
>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.

Aurélien
--
Mats
>
> I will try next week with others computers.
>
> Thanks for the reply,
>
> Aurelien
>
> --
>
> Mats
> > Thanks,
> > Aurelien

On 10/12/12 14:11, Aurélien MILLIAT wrote:
> On 07/12/12 16:51, Aur?lien MILLIAT wrote:
>>>>> 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!
>
>> 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.

--
Mats
>
> Aurélien
> --
> Mats
>> I will try next week with others computers.
>>
>> Thanks for the reply,
>>
>> Aurelien
>>
>> --
>>
>> Mats
>>> Thanks,
>>> Aurelien
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

>>>>>> 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!

Aurelien 
>--
>Mats
>

Monday, December 10, 2012, 5:49:16 PM, you wrote:
>>>>>>> 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!
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)

--
Sander
> Aurelien 
>>--
>>Mats
>>

>>>>>>>> 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
>>