re: PTB on intel

Hi Mario - Thanks, this seemed to have fixed the major problems. here are the results of most of the PsychTests suite:

PerceptualVBLSyncTest: flicker seems uniform

TestAlphaBlending: passed 1-3, failed 4 (max discrepancy b/w MATLAB double and OpenGL multiplication=0.73725)

TestDrawingStuffOSX: seems to draw fine, though it never returns to the terminal and has to be killed

TestFillPolyOSX: passes

TestFlip: passes with Results:.
Median frame period: 0.016700 seconds
Max frame period: 0.018806 seconds
Min frame period: 0.013597 seconds
Median frame frequency: 59.880229 seconds

TestMakeTextureTiming:
Result:
Average time to allocate texture memory: 4.8474e-05 Secs.
Average time to copy the MATLAB matrix into the OpenGL texture: 0.0017633 Secs
Average proportion of time which MakeTexture spends allocating memory: 0.027491

TestMATLABTimingOSX:
The actual number of timing loops was 14406 loops in 2.410013e+02 seconds.
We preallocated enough memory for 18029 timing loops, a saftey factor of 1.251492.
The shortest loop was: 0.006480 seconds
The longest loop was: 0.484306 seconds
The median loop was: 0.016698 seconds
8 glitches predicted in 241 second test interval, assuming 30-second interval between glitches
The 8 longest loop delays occured at times and intervals:
3.3227 s
delta=12.2072 s
15.5299 s
delta=7.9153 s
23.4452 s
delta=0.83497 s
24.2801 s
delta=3.8742 s
28.1543 s
delta=5.7278 s
33.8822 s
delta=3.5235 s
37.4056 s
delta=125.4454 s
162.851 s
The 9th longest loop delay, at time 19.6045 seconds, was 0.019959 seconds, 1.0011 times smaller than the 8th longest delay
Detected loop durations shorter than blocking period. The durations and times are:
0.0087815 15.5545
0.0064798 24.307
0.0098939 33.9056
0.0097394 37.4294
The timing loop computation time exceeded the allocated computation time on 5 loops.
The loop durations, computation times, and timestamps are listed below.
0.02462 0.00792 15.52985
0.02686 0.01016 24.28013
0.48431 0.46761 28.15433
0.02342 0.00672 33.88215
0.02377 0.00707 37.40563

TestMexTimingLoopOSX:
The shortest loop was: 0.000508 seconds
The longest loop was: 0.002044 seconds
The median loop was: 0.000584 seconds
4 glitches predicted in 121 second test interval, assuming 30-second interval between glitches
The 4 longest loop delays occured at times and intervals:
0.015103 s
delta=0.70545 s
0.72055 s
delta=0.003191 s
0.72374 s
delta=4.9985 s
5.7223 s
The 5th longest loop delay, at time 0 seconds, was 0.00069461 seconds, 1.1229 times smaller than the 4th longest delay
The timing loop computation time exceeded the allocated computation time on 3 loops.
The loop durations, computation times, and timestamps are listed below.
0.00199 0.00149 0.72055
0.00204 0.00154 0.72374
0.00102 0.00052 5.72228

TestPsychHID: behaves somewhat strangely - the requests to press a key/move the mouse don't appear until after it has stopped waiting
Result:
Making a list of all your HID-compliant devices. ...
You have 6 HID-compliant devices:
device 1: Consumer Usage 0x1, Apple Computer, Inc., Apple IR, 18 inputs, 0 outputs
device 2: Consumer Usage 0x1, Apple Computer, Apple Internal Keyboard / Trackpad, 1 inputs, 0 outputs
device 3: Mouse, Apple Computer, Apple Internal Keyboard / Trackpad, 4 inputs, 0 outputs, serialNumber 0
device 4: Page: 0xff, Usage: 0x1, Apple, Trackpad, 2 inputs, 0 outputs
device 5: Mouse, Apple, Trackpad, 7 inputs, 0 outputs
device 6: Keyboard, Apple Computer, Apple Internal Keyboard / Trackpad, 238 inputs, 5 outputs
Test keyboard.
device 6: Apple Computer, Apple Internal Keyboard / Trackpad
Now flickering the LEDs on your keyboard. ... Success!!
Now reading your keyboard. Press any key to continue. ...
I gave up waiting after 5 s.
Test 2 mice.
device 3: Apple Computer, Apple Internal Keyboard / Trackpad
Now reading your mouse. Move the mouse to continue. ...
I gave up waiting after 5 s.
device 5: Apple, Trackpad
Now reading your mouse. Move the mouse to continue. ...
I gave up waiting after 5 s.


TestStandaloneTimingOSX: fails
??? Error using ==> TestStandaloneTimingOSX
Arguments "use_sigsetjmp" and "savemask" are required.


TestTextBug: seems to work fine

TestTextBounds:
Result:
TextBounds says the bounds of 'Wordy' are [2 13 198 78].
Screen 'TextBounds' says the bounds of 'Wordy' are [0 0 200 85].

TestTextFont: nothing happens

TestTextInitBug: seems to work fine

TestTextInOffscreenWindowOSX results:
Passed the test; the contents of onscreen and offscreen windows match

TestTextureOSX: seems to work fine

VBLSyncTest: fails with the following output:
screenwidth =
1440
screenheight =
900
finalprio =
0
??? Error using ==> rethrow
Input must be a structure.
Error in ==> VBLSyncTest at 464
rethrow(lasterr);


hope that helps
cheers
russ


On May 31, 2006, at 12:24 AM, psychtoolbox@yahoogroups.com wrote:

Hi Russ,


could you upgrade to the latest beta and retest? The warnings you've

seen are just warnings, not fatal errors. They tell you that

rasterbeam position queries don't work on your setup and that PTB is

using a less accurate fallback-path. I've improved the code in the

beta so that it differentiates between "beamposition queries not

supported by system" and "beamposition queries supported but not

working properly" on OS-X. In case of missing functionality, it now

silently switches to the fallback code instead of outputting a lot of

scary warnings - There's no point outputting warnings if one can't do

anything to fix them. The same fallback code is always silently used

on M$-Windows, as this system doesn't support beampos queries. In

practice it means that timing noise for reported stimulus onset

timestamps (the return value 'vbl' of vbl=Screen('Flip')) can increase

from reliably less than 100 microseconds on OS-X/PowerPC to something

in the order of multiple 100 microseconds up to occasional spikes of

multiple milliseconds. This only refers to the reported timestamps and

the internal timing checks. *Stimulus onset* will be still synced to

retrace with microsecond accuracy.


It would be sad if beamposition queries would get removed from the

gfx-drivers on Intel-Macs - a step back for OS-X and in the direction

of M$-Windows. But maybe this is just a temporal limitation and the

drivers will improve with future OS-X software updates.


I tried to "fix" MacModelName as well: It should shut up instead of

giving error messages. That's not a real fix, because Apple decided to

change the format of some name mapping files in OS-X 10.4.5 to break

this function. Would need to be rewritten from scratch to get it

working again :(


best,

-mario


---
Russell A. Poldrack, Ph.d.
Associate Professor
UCLA Department of Psychology
Franz Hall, Box 951563
Los Angeles, CA 90095-1563

phone: 310-794-1224
fax: 310-206-5895