Can't get stimulus display to update at 60Hz

Support
1

I’m moving this issue to its own discussion, since I think it may not be related to the NVIDIA driver issue.

2

[Sent May 27, 2010 3:35:28 PM EDT]

Hi Laura,

Dave discovered a problem in some of MWorks’ OpenGL setup code that may be the cause of the display delays you’ve encountered. I’ve made a build with his suggested fix. Would you mind trying it out and testing whether you’re still seeing delays? You can grab the installer at

http://dicarlo-mwdev.mit.edu/mw/MWorks-0.4.4rc5+genfences.dmg

Note that since neither Dave nor I have been able to reproduce your problem, we have no evidence to suggest that this change is actually going to fix it. However, the issue Dave discovered could have an impact on display update performance, so it’s worth testing it out to see if it makes any difference.

Thanks,
Chris

3

[From Laura; sent May 31, 2010 11:03:08 AM EDT]

Dear Chris,

I have tested you new version.

Some strange things happen:

  • I first loaded the refreshTest.xml and MWorks skips every 2nd frame (i.e., 30 Hz update instead of 60 Hz). This is true for both the stimulus display monitor and the small display mirror on the experimental control monitor.
  • Then I closed the experiment and loaded refreshTestNoText.xml. The screen on which the stimulus should be displayed turned black (should be gray) and did not display anything, while the small display mirror on the experimental control screen turned gray and displayed the black and white squares. This time at 60 Hz.
  • The display infinitely goes on and on and does not stop after the requested number of presentations.
  • For both experiments, I did not get error messages on the console when frames are skipped regularly (every 2nd frame), although the refresh is not correct as measured by the photodiode (photodiode works fine because the same stimulus generated by the psychophysics toolbox runs at 60 Hz as measured by the photodiode).

I tested a little bit more.

  • Closing and then loading an experiment also leads to a black screen with refreshTest.xml.
  • Closing and then loading an experiment does not always lead to a black screen - the black screen seems to appear rather randomly for both experiments
  • The black screen is not always associated with infinite stimulus presentations
  • The black screen is not always associated with correct refreshes of the display mirror.
  • Sometimes, refreshes are skipped at irregular intervals (i.e., sometimes 1 refresh, sometimes 2 refreshes) - in this case the console displays error messages.

I can do more tests tomorrow, but maybe this already gives you a clue.
Best, Laura

4

[Sent May 31, 2010 12:30:13 PM EDT]

Hi Laura,

Thanks for the report. The issue with the screen going black was found and fixed during release candidate testing. If you want, you can download the final 0.4.4 release and verify that the problem is gone. You can get the installer at

http://github.com/downloads/mworks-project/mw_suite/MWorks-0.4.4.dmg

Note that 0.4.4 does not include the potential bug fix I originally asked you to test.

I’ll look in to the other issues when I’m back in the office tomorrow. (Today is a holiday here.)

Thanks,
Chris

5

[From Laura; sent June 1, 2010 10:38:35 AM EDT]

Dear Chris,

Thanks for your message.

I have installed 0.4.4, and as you already said the problem with the black screen is gone.
The refresh is still at 30 Hz (instead of 60 Hz); I do not get any error messages on the console for skipped frames.
Sometimes, the experiment goes on infinitely, and I have to stop it using the red button. The console displays the message “Starting state system…” and 'STARTING*. When I hit the red button it says “State system ending” “Resetting experiment”.
When I now hit the green triangle to run the experiment again it does not display anything, and the console says:
“Setting protocol to srt”
“Called start on state system”
“Starting state system”
“Starting state system”
“State system ending”
“Resetting experiment”

Not sure if this is a different problem unrelated to the refresh issue, so feel free to ignore it.

Since the release with the potential bug fix produced more interesting behavior, I tested it today in more detail:
I can confirm that the small display mirror sometimes operates at the correct refresh of 60 Hz, but it seems to happen only if the main display screen is black (not sure if it means anything). In those cases when the small display mirror operates at the correct refresh rate the experiment sometimes goes on infinitely, sometimes it stops after the requested number of trials.
I have never observed a correct refresh when the stimulus monitor was actually displaying something other than the black screen.

Please let me know if I can do anything to help.
Best,
Laura

6

Hi Laura,

[I moved this discussion to a new thread on Tender, since I’m starting to think your problem is different than Nicole’s.]

The experiment goes on infinitely after the first run because the counter variable isn’t reset at the beginning of the trial. I’ve attached an updated version of refreshTestNoText.xml that fixes the problem.

Your observation that MWorks drops every other frame when both the main stimulus display and the mirror window are active is troubling. What happens if you disable the mirror window (by setting always_display_mirror_window to 0 in setup_variables.xml)?

Also, I didn’t realize that you’ve been detecting the delays with a photodiode. I assumed you were getting delay warnings on the MWorks console, but it sounds like that’s not the case.

Dave, do you have any further thoughts on Laura’s problem?

Chris

7

Attachment: refreshTestNoText.xml (4.86 KB)

8

I don’t have any quick solutions, but here are a few notes to add:

  1. I just want to be clear on terminology: by “drops every other frame”, do you mean “goes half as fast?” There is a big difference between not showing frames and having all of the frames shown but at a slower rate.

  2. Chris: if you don’t have a photodiode handy, another way to measure the frame rate (assuming that the answer to (1) is “goes half as fast”) is to count the number of cycles and measure the time between. If we really believe that actual frames are being dropped (this would be very surprising), I probably have an extra photodiode hanging around that I could lend you.

  3. The console warnings are triggered based solely on the delay from when you ask for a frame update until when you get it. If there are delays happening in between consecutive update calls, then the system has no way of knowing what your intent is (e.g. if you were to put a “wait” action in between the two update display calls). Currently, the mirror window gets drawn after the main display is completely finished – I could imagine a problem with the mirror window (possibly hardware-specific) to cause it draw to take longer than normal such that you miss your window for the next frame to be drawn on time. This wouldn’t cause any late frame warnings, but it would slow the observed frame rate for experiments that are trying to draw on every frame update.

  4. Agreed with Chris on the always_display_mirror_window suggestion. If you’re doing fast / fine work with the video display, this might be a good policy in general – you might be happier, for instance, with hardware mirroring instead of software mirroring. Either way, I’m relatively confident that we should be able to get to the bottom of this.

I’ll break out some photodiodes tomorrow when I get back in the lab and see what I can see.

9
  1. I just want to be clear on terminology: by “drops every other frame”, do you mean “goes half as fast?” There is a big difference between not showing frames and having all of the frames shown but at a slower rate.

Sorry, I mean “goes half as fast”.

  1. The console warnings are triggered based solely on the delay from when you ask for a frame update until when you get it. If there are delays happening in between consecutive update calls, then the system has no way of knowing what your intent is (e.g. if you were to put a “wait” action in between the two update display calls). Currently, the mirror window gets drawn after the main display is completely finished – I could imagine a problem with the mirror window (possibly hardware-specific) to cause it draw to take longer than normal such that you miss your window for the next frame to be drawn on time. This wouldn’t cause any late frame warnings, but it would slow the observed frame rate for experiments that are trying to draw on every frame update.

I noticed the problem initially with lots of error messages in the console; and I could confirm these error messages with the photodiode. This was with one of the nightly builds around May 18.
With the new releases, I did not get the error messages in the console any longer, but the problem persisted as measured by the photodiode.

  1. Agreed with Chris on the always_display_mirror_window suggestion. If you’re doing fast / fine work with the video display, this might be a good policy in general – you might be happier, for instance, with hardware mirroring instead of software mirroring. Either way, I’m relatively confident that we should be able to get to the bottom of this.

Setting ‘always_display_mirror_window’ to 0 in the preferences unfortunately does not help - the display still updates at 30 Hz instead of 60 Hz.
Interestingly, without the small software mirror, I now start to see sporadic error messages at the console
“ERROR: updating main window display is taking longer than two frames () to update”
These error messages appear at seemingly random times, while the photodiode indicates that the display is refreshing consistently at 30 Hz instead of 60 Hz.

Just to summarize: the only configuration in which I sometimes achieve 60 Hz is with the special release of MWorks containing the potential fix, and when the stimulus screen is black and the refresh of the software mirror is measured with the photodiode.

10

Thanks for the updated info, and thanks for bearing with us. I think we’re narrowing in on a solution.

Chris: can you create an installer for Laura from the “glew_enabled” branch in mw_core?

This branch contains the latest display code – it’s actually been around for a little while, but we were saving for the next release for the sake of conservatism. I’m able to consistently clock this version up to 60Hz with an external display and mirror active at the same time, even on my laptop. I am hopeful that this version will solve your problem.

On my machine, I do variously see some throttling of the display updates in the 0.4.4 under 10.6.3, though I haven’t gotten to the bottom of why this is. We’ve seen Apple moving some of the OpenGL code around from under us lately (particularly in the 10.6.2 → 10.6.3 update), so I wouldn’t be surprised if this were another incarnation of that. I’ve also attached my version of the refreshTest xml that reports the frame rate at the end, in case that’s helpful.

11

Attachment: refresh_test.xml (5.95 KB)

12

I’m still trying to generate a working build of the glew_enabled branch.

However, I did do some tests with both Dave’s version of refresh_test.xml and an updated version of refreshTestNoText.xml (attached) that calculates the frame rate. Using the latest nightly build on my Mac Pro, with both stimulus display and mirror window enabled, running 10 trials in a row of each experiment, I consistently got 60 FPS.

Laura, can you try running one of the frame-rate-reporting scripts and let us know how the computed frame rate compares to what you measure with the photodiode?

Chris

13

Attachment: refreshTestNoText.xml (5.73 KB)

14

Laura,

I have a build of the glew_enabled branch for you to try. You can get it at:

http://dicarlo-mwdev.mit.edu/mw/MWorks-glew_enabled.dmg

Please try it out and let us know if it solves your problem. (Note that this build doesn’t include the full set of plugins. I’ve only included the core ones and RectangleStimulus, since that’s all that’s needed for the test scripts we’ve been using.)

Thanks,
Chris

15

Dear Chris & Dave,
using the glew_enabled version solves the problem. The display runs at 60 Hz with and without the software mirror. The console gives the correct refresh rate. The photodiode measurements give 60 Hz as well.
Thank you very much!
Laura

16

using the glew_enabled version solves the problem

Great! Dave’s in the process of moving the glew_enabled stuff into the master branch, so it should be in the nightly builds soon. These changes will also be included in MWorks 0.4.5, which hopefully will go out in the not-too-distant future.

17

Davide, Sina:

In addition to Dave’s installer, you could also try the nightly build, which contains the fix for Laura’s problem:

http://dicarlo-mwdev.mit.edu/mw/MWorks-NIGHTLY.dmg

Chris

18

Thanks Chris,

Dave’s installer solved the problem (at least on Sina’s MacBook Pro).
We still need to test it on our Mac Minis.

Our main problem now is to refurbish our OpenGL plugin, so that it can
work with this new MW version. Regarding this, I have a question: Dave
used to have in the GitHub repository a template plugin for Xcode. Did
you guys updated it so that all folder names, paths, dependences
reflect now the change of name form MonkeyWorks to MWroks?

Thanks
davide

19

Dave used to have in the GitHub repository a template plugin for Xcode. Did you guys updated it so that all folder names, paths, dependences reflect now the change of name form MonkeyWorks to MWroks?

Yes, the Xcode project template is fully up-to-date. It’s included in the nightly build installer (as part of the “Development files” component), or you can get it from GitHub.

Chris

20

The templates should also be in the installer that I gave you. It is
the same thing with a different payload of plugins.