Slowdown using Datapixx routines with PTB tests

Our setup: Mac Pro 5,1, Mac OSX 10.7.5, single-display mode with ViewPixx 3D (up-to-date firmware), PsychtoolboxKernelDriver, and either MATLAB 2012a with Mario's master branch or 2010a with the PTB-3 version from DownloadPsychtoolbox.m.

I've run BitsPlusIdentityClutTest (with usedpixx=1) and noticed that hitting the spacebar to cycle through candidate LUTs took a long time (I have to spam escape to exit the script too). This slowdown isn't present when usedpixx=0. I profiled the function which can be viewed here: https://dl.dropbox.com/u/39385610/profile_results/file0.html. Looks like 'SetVideoClut' is chewing up time.

Additionally, when VBLSyncTest has Datapixx timestamping turned on (last function argument = 1) the drifting square never shows up. By never I mean after 2-3 minutes of not seeing anything, I get frustrated and mash ctrl+c to break the script. No issues when that last argument is 0.

I can reproduce these problems on both MATLAB/PTB setups. The problem persists even if I switch to the 32-bit kernel (hold '3' '2' at boot), and use the 32-bit PTB Kernel driver.

Any ideas? Or is this something the VPixx guys need to figure out?

Thanks,
Zack


What graphics card does this machine have? With AMD/ATI cards, PTB can do more to fix the broken OSX graphics drivers, with NVidia it is more limited.

Did you do a download and upgrade of the firmware after 21st December 2012? Firmware rev. 17 from that day should have a bugfix for a bug which caused the ViewPixx 3D to misbehave. If you have a buggy firmware you'll see a thin black horizontal line somewhere in the uppermost quarter of the display while BitsPlusIdentityClutTest is running.

Once that is ruled out, it could be one of the many graphics driver bugs in "the most advanced operating system in the world", as the iPhone company likes to call it, proving again their infinite capacity for self-irony. The bugs mess up the video signal that leaves your machine and makes decoding by the ViewPixx impossible.

Then UpdatePsychtoolbox, because a new beta was just released. It contains a couple of new workarounds for a couple of new highly entertaining OSX bugs.

Then you can run BitsPlusImagingPipelineTest and BitsPlusIdentityClutTest again, the latter with usedpixx=1. Also say 'y'es to the extended Datapixx tests if it asks you.

Other than that, PTB's Matlab output would be useful, especially the bits relating to LoadIdentityCLUT.

The slowdown / hangs are likely because if the device doesn't recognize the embedded control codes in the video signal it has a programmable timeout to avoid hangs. BitsPlusIdentityClutTest sets the timeout to something like a bit less than a second, causing an apparent slowdown, whereas our VBLSyncTest leaves it at a rather high default of multiple minutes, causing an apparent hang.

Btw. Using my own master branch is usually not the best idea for a production environment, it is called prototype for a reason.

-mario


--- In psychtoolbox@yahoogroups.com, Zack Lindbloom-Brown wrote:
>
> Our setup: Mac Pro 5,1, Mac OSX 10.7.5, single-display mode with ViewPixx
> 3D (up-to-date firmware), PsychtoolboxKernelDriver, and either MATLAB 2012a
> with Mario's master branch or 2010a with the PTB-3 version from
> DownloadPsychtoolbox.m.
>
> I've run BitsPlusIdentityClutTest (with usedpixx=1) and noticed that
> hitting the spacebar to cycle through candidate LUTs took a long time (I
> have to spam escape to exit the script too). This slowdown isn't present
> when usedpixx=0. I profiled the function which can be viewed here:
> https://dl.dropbox.com/u/39385610/profile_results/file0.html. Looks like
> 'SetVideoClut' is chewing up time.
>
> Additionally, when VBLSyncTest has Datapixx timestamping turned on (last
> function argument = 1) the drifting square never shows up. By never I mean
> after 2-3 minutes of not seeing anything, I get frustrated and mash ctrl+c
> to break the script. No issues when that last argument is 0.
>
> I can reproduce these problems on both MATLAB/PTB setups. The problem
> persists even if I switch to the 32-bit kernel (hold '3' '2' at boot), and
> use the 32-bit PTB Kernel driver.
>
> Any ideas? Or is this something the VPixx guys need to figure out?
>
> Thanks,
> Zack
>