flip, vbl_syncmode suggestion

1
hi,

looking through the source code for flip i have a suggestion/request
for an alternate method for syncing to the vbl. Instead of calling
glfinish() as in when dontsync=0, can we have a version that simply
calls glflush() and then returns with the beamposition query?
Alternately, simply enabling beampos queries from within matlab would
suffice via using flip with dontsync=1 (or just returning beamposition
queries when using this flag).

i would like this because i think it would help to avoid the latency
jitter in windows due to the sleeping involved in the glfinish call.
Obviously there will still be latencies in glflush, but they should be
much lower. After flip returns, i can then use a busy waiting routine
within matlab (without putting the process to sleep) using the
predicted time to VBL or stimulus onset. This will help guarantee
syncing to VBL and returning before stimulus onset which is crucial
for the electrophysiology experiments i'm designing, as it would
enable, say, sending a TTL pulse precisely aligned with stimulus onset
with ~microsecond accuracy. Although my current rig works very well
with the standard flip calls (using my new nvidia 7950), there are
still occaisional frames where flip returns after SOT which i would
like to avoid, and i think this simple software fix would really help.

I have played with the hidden vbl_synclevel=3 as another option. It
generally gives much higher timing accuracy for me but fails
frequently (missing a frame) for reasons I can't pinpoint, as I
somewhat expected from the inline comments saying it's 'dangerous.'

Thoughts?
Scott
2
Jap. The R2007a version for Windows is not yet updated with
the 'GetWindowInfo' command. You're right that overload is
probably not a (big) problem on multi-processor systems as
Matlab can only hog one of the processors, so the other one
is free to perform OS processing like sound, memory management,
i/o...

So it works on your setup, but its not a generally workable thing,
so nothing to implement in Screen without begging for trouble.
But of course you are free to provide your M-File "Flip"
implementation for inclusion into PTB for people with the same
special needs as you.

-mario

--- In psychtoolbox@yahoogroups.com, "stuckdoingwork" <gorlins@...> wrote:
>
> Mario -
>
> Thanks a lot! I have the new flip mode working perfectly on Matlab
> 7.3 with reliably ~20 us time errors, and I can do about anything I
> want during the busy waiting sequence. However, the
> Screen('GetWindowInfo') function seems to be missing from Matlab 7.4
> on the same machines, with the same PTB installations. Has it not
> been implemented yet in the new mex compilations?
>
> Btw, it seems like CPU overload at realtime priority is not a problem
> with dual-processors, as Matlab can only hog 50% of total CPU time at
> once, due to its single-threadedness. At least, I've never seen the
> OS downgrade the priority over the course of several hours on several
> XP machines that i've been using, and responses to input all seem to
> work just fine.
>
> Cheers,
> Scott
>
> --- In psychtoolbox@yahoogroups.com, "Mario Kleiner"
> <mario.kleiner@> wrote:
> >
> > Lucky you are!
> >
> > You can use dontsync = 1 and use the new Screen subfunction
> > beampos = Screen('GetWindowInfo', window, 1); to do what you
> > want. Such a feature was recently implemented (in PTB beta)
> > for other purposes, mostly for internal use by some PTB
> > M-Files.
> >
> > You can certainly try your approach but it won't be a reliable
> > approch, ie it might work by pure chance on your specific
> > setup for your specific script, but its not a robust general
> > solution:
> >
> > 1. The only way to find out reliably if bufferswap actually
> > happened on MS Windows is the one implemented with the
> > glFinish() approach. A glFlush() would be useless for that
> > purpose. Just "falling through" flip via dontsync=1 and then
> > using beampos queries, e.g., to find out when the VBL
> > is entered, only will allow you to detect VBL onset, but not
> > if the buffers were actually swapped at that point in time.
> > E.g., in case of a deadline-miss, you wouldn't notice that at
> > all. That's one reason why the hidden parameter vbl_synclevel=3
> > is hidden and dangerous. It does essentially what you proposed,
> > has a low latency and suffers the problem of not
> > reliably detecting deadline misses etc.
> >
> > You could however decrease chance of deadline miss by
> > issuing a Screen('DrawingFinished', win, 0, 1); command
> > before the flip - it forces the GPU to finish all pending
> > rendering operations before returning control to Matlab,
> > so given you did everything else right, you could be fairly
> > confident that Flip will flip at the predicted SOT.
> >
> >
> > 1. Draw stimulus.
> > 2. Screen('DrawingFinished', ....);
> > 3. whatever.
> > 4. Screen('Flip',....., dontsync = 1);
> > 5. Busy wait and trigger....
> >
> > Another problem with busy-waiting is that you may overload
> > the cpu, which can kill proper timing or cause malfunctions
> > in other areas like sound output, keyboard and mouse queries,
> > trigger output and network communication to name a few. You
> > should use WaitSecs() to wait as long as possible, only then use
> > busy-waiting. WaitSecs internally uses a hybrid approach of
> > sleeping and busy-waiting itself on Windows.
> >
> > Using Priority() is also a priority for proper timing...
> >
> > A cleaner solution for such things would be to allow for
> > async flipping: Flip would do its work in an extra parallel thread,
> > so the timing code can block in glFinish and thereby reliably
> > detect if a flip met its deadline. The main Matlab thread would
> > continue, e.g., to initiate a trigger pulse at predicted SOT. That
> > way one could reliably assess after the trial if timing was ok or
> > not. However such a solution would be easy to implement on
> > OS/X and Linux but not on Windoze.
> >
> > Or one uses a special threaded parallel port driver to execute
> > an async trigger signal, independent of Matlabs execution.
> >
> > Another funny approach to triggering would be to use good
> > sound hardware in combination with our new PsychPortAudio
> > sound driver to generate a trigger pulse (encoded as sound
> > signal). Testing on one sound card here allowed to get
> > scheduled sound onset at the sub-100 microseconds level,
> > after some installation of special sound drivers and some
> > calibration.
> >
> > Or you use a photo-diode mounted to the top left corner
> > of your display for triggering, then you can be sure to only
> > trigger at stimulus onset.
> >
> > -mario
> >
> >
> > --- In psychtoolbox@yahoogroups.com, "stuckdoingwork" <gorlins@> wrote:
> > >
> > > hi,
> > >
> > > looking through the source code for flip i have a suggestion/request
> > > for an alternate method for syncing to the vbl. Instead of calling
> > > glfinish() as in when dontsync=0, can we have a version that simply
> > > calls glflush() and then returns with the beamposition query?
> > > Alternately, simply enabling beampos queries from within matlab would
> > > suffice via using flip with dontsync=1 (or just returning beamposition
> > > queries when using this flag).
> > >
> > > i would like this because i think it would help to avoid the latency
> > > jitter in windows due to the sleeping involved in the glfinish call.
> > > Obviously there will still be latencies in glflush, but they should be
> > > much lower. After flip returns, i can then use a busy waiting routine
> > > within matlab (without putting the process to sleep) using the
> > > predicted time to VBL or stimulus onset. This will help guarantee
> > > syncing to VBL and returning before stimulus onset which is crucial
> > > for the electrophysiology experiments i'm designing, as it would
> > > enable, say, sending a TTL pulse precisely aligned with stimulus onset
> > > with ~microsecond accuracy. Although my current rig works very well
> > > with the standard flip calls (using my new nvidia 7950), there are
> > > still occaisional frames where flip returns after SOT which i would
> > > like to avoid, and i think this simple software fix would really help.
> > >
> > > I have played with the hidden vbl_synclevel=3 as another option. It
> > > generally gives much higher timing accuracy for me but fails
> > > frequently (missing a frame) for reasons I can't pinpoint, as I
> > > somewhat expected from the inline comments saying it's 'dangerous.'
> > >
> > > Thoughts?
> > > Scott
> > >
> >
>