From: Rick van Haasen (rick.van.haasen++at++philips.com)
Date: 01/18/2006 04:58:58
correct, that is what it does. I checked this with an application
that runs on 2 locked PC's. If one application does'nt swap,
the other will be hold in the barrier.
These are the things i did for getting proper swap & sync
behaviour. there is one tricky thing that can cause trouble.
The application was used for a Windows system, for Linux
the functions are about equal (except xgl iso wgl...)
// Enable genlock
if (!wglEnableGenlockI3D(hDC)) {
MessageBox(NULL,"wglEnableGenlockI3D failed","ERROR",MB_OK |
MB_ICONINFORMATION);
}
// Query swapgroups
if (wglQueryMaxSwapGroupsNV(hDC,&group, &barrier)==FALSE) {
MessageBox(NULL,"wglQueryMaxSwapGroupsNV failed","ERROR",MB_OK |
MB_ICONINFORMATION);
}
if (wglJoinSwapGroupNV(hDC, group)==FALSE) {
MessageBox(NULL,"wglJoinSwapGroupNV failed","ERROR",MB_OK |
MB_ICONINFORMATION);
}
// Bind group to barrier
if (wglBindSwapBarrierNV(group, barrier)==FALSE) {
MessageBox(NULL,"wglBindSwapBarrierNV failed","ERROR",MB_OK |
MB_ICONINFORMATION);
}
wglQueryMaxSwapGroupsNV returned 1 as maximum for group and barrier.
The strange thing was that i had to give 1 as parameter to
wglJoinSwapGroup() and
alse (1,1) to wglBindSwapBarrierNV. I would have expected 0 and (0,0) as
parameters
to these functions, because only 1 group and barrier is available. This is
at least
not documented well.
I can't remember if the function calls fail if 0 is used iso 1. I don't
have the 2 systems
available now.
Maybe your'e also dealing with this issue.
Rick.
owner-info-performer++at++performer.engr.sgi.com wrote on 2006-01-18 11:28:08:
> Yes, we use the primary head. Vertical refresh is correctly
> synchronized, the problem is regarding buffer swap synchronization.
> When using the two GLX functions, the whole display group should
> wait for each display to be ready before swapping all together,
> isn't it? I mean, they should all swap when the slowest display is
> ready, no? For example, if one of the computers sleeps for 5 seconds
> before asking to swap, all the others should wait for him. This is
> what we want but it doesn't seem to be the case. Is this what swap
> sync is for, or not? If not, how is it supposed to be used?
>
> On Wednesday 18 January 2006 10:32, Rick van Haasen wrote:
> > Hugues,
> >
> > Are you using the primary head? synchronisation is only done
> > on the primairy head, the second head of the card is not
> > synchronised. We faced this situation some months ago.
> > Someone from nvidia support told me that the 4500G is "hardwarewise"
> > capable of synchronisationing on the second head, but that this
> > capability was not yet implemented in the driver (this was a few
> > months ago).
> >
> > Rick
> >
> > owner-info-performer++at++performer.engr.sgi.com wrote on 2006-01-18
09:06:12:
> >
> > > Hi all,
> > >
> > > we are trying to use our OpenGL Performer application on several
> > > computers with an nVIDIA Quadro 4500G card and use the frame lock
> > > capability to ensure the buffer swaps happen synchronously on all
> > > the cards. We are using GNU/Linux. Frame lock is enabled with the
> > > nvidia-settings utility. For swap sync, we use glXJoinSwapGroupNV()
> > > and glXBindSwapBarrierNV() but the displays doesn't synchronise
> > correctly.
> > >
> > > Has anyone faced the same problem?
> > >
> > > Thank you.
> > >
> > > Regards,
> > >
> > > Hugues De Keyzer
> > > de pinxi
> > >
> > >
> > >
-----------------------------------------------------------------------
> > > List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> > > Open Development Project: http://oss.sgi.com/projects/performer/
> > > Submissions: info-performer++at++sgi.com
> > > Admin. requests: info-performer-request++at++sgi.com
> > >
-----------------------------------------------------------------------
> > >
> >
> >
> >
>
>
> -----------------------------------------------------------------------
> List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
> -----------------------------------------------------------------------
>
This archive was generated by hypermail 2b29 : Wed Jan 18 2006 - 05:03:59 PST