# re: PTB on intel **URL:** \ **Category:** Uncategorized\ **Created:** [May 31, 2006, 3:28pm UTC](https://psychtoolbox.discourse.group/t/re-ptb-on-intel/1637 "2006-05-31T15:28:33Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Russ\_Poldrack](https://avatars.discourse-cdn.com/v4/letter/r/a88e57/32.png) [@Russ\_Poldrack](https://psychtoolbox.discourse.group/u/Russ_Poldrack)\ **Post date:** [May 31, 2006, 3:28pm UTC](https://psychtoolbox.discourse.group/t/re-ptb-on-intel/1637/1 "2006-05-31T15:28:33Z")
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](mailto: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 email: [poldrack@...](mailto:poldrack@...) web: [www.poldracklab.org](http://www.poldracklab.org)