I think we saw a similar issue when we first started testing the ATI cards.
For this and other reasons, we run one xserver for each ATI card.
On Fri, Dec 20, 2013 at 3:40 PM, Tyson Whitehead twhiteh...@gmail.comwrote:
We have a VNC + VirtualGL setup on machines with dual AMD FirePro V9800
ATI
On December 23, 2013 07:03:05 Kevin Van Workum wrote:
I think we saw a similar issue when we first started testing the ATI cards.
For this and other reasons, we run one xserver for each ATI card.
Slightly off topic, but since you mentioned two xservers with two ATI cards.
Have you managed to
On December 21, 2013 03:03:25 DRC wrote:
By chance have you tried the latest code in subversion trunk? I think
this may be another symptom of a bug I already fixed, but it was fixed
after the 2.3.3 release.
I haven't tried the latest subversion. I certainly can though.
Do you still think
On Mon, Dec 23, 2013 at 11:02 AM, Tyson Whitehead twhiteh...@gmail.comwrote:
On December 23, 2013 07:03:05 Kevin Van Workum wrote:
I think we saw a similar issue when we first started testing the ATI
cards.
For this and other reasons, we run one xserver for each ATI card.
Slightly off
I may have misunderstood. I thought you were running your test program with
VGL. How else would you be running it in TurboVNC? Yes, I think it's worth 5
seconds to see if the fix I made in trunk works around this. If not, I'll look
at it at some point, but since I don't keep the ATI card in my
On Mon, 2013-12-23 at 14:14 -0600, DRC wrote:
I may have misunderstood. I thought you were running your test program with
VGL. How else would you be running it in TurboVNC? Yes, I think it's worth 5
seconds to see if the fix I made in trunk works around this. If not, I'll
look at it at some
By chance have you tried the latest code in subversion trunk? I think
this may be another symptom of a bug I already fixed, but it was fixed
after the 2.3.3 release.
On 12/20/13 2:40 PM, Tyson Whitehead wrote:
We have a VNC + VirtualGL setup on machines with dual AMD FirePro V9800 ATI
I've never seen that before. Seems like it may be a driver bug.
On 12/20/13 2:40 PM, Tyson Whitehead wrote:
PS: One other big of strangeness I noticed was that under the single card
configuration all the tc visuals from DISPLAY=:0 glxinfo have id 0x0a3
81 GLX Visuals
...
0x0a3 32 tc 0
On Fri, 2013-12-20 at 15:40 -0500, Tyson Whitehead wrote:
I'm presuming this maybe means the AMD GLX implementation has some sort of
buggy shared state between displays that is tripping it up when the number of
screens differs? Any thoughts?
By a lot more stepping through code, I've