Skip to content
Permalink
Branch: master
Commits on Dec 19, 2019
  1. Merge pull request #614 from bmwiedemann/sort

    kleinerm committed Dec 19, 2019
    Sort source file list
  2. Merge pull request #626 from kleinerm/master

    kleinerm committed Dec 19, 2019
    Pull for "Timely Twinkler"
    
    General improvements:
    
    - Adds PsychPhotodiode() driver for combining photo-diodes with sound cards for visual stimulus onset timestamping. Demonstrated in VRRTest.m as hwmeasurement=5 method.
    
    - UpdatePsychtoolbox() will now potential file conflicts automatically by forcing the updated files from the upstream server, simply overwriting/discarding user modifications.
    
    - Documentation updates. Among other minor things, point to the new user forum at Discourse.
    
    Linux improvements:
    
    - Ship basic set of MEX files for Octave 4.4 on Linux, e.g., for easy use with Octave on Ubuntu 19.10. Currently missing, to be part of a later update: Eyelink.mex, PsychCV.mex.
    
    - Improved VRR support for fine-grained visual stimulus onset timing on Linux. The API has been reworked to allow for more future flexibility and future extensions without breaking backwards compatibility of user scripts. Most importantly, a more sophisticated multi-threaded VRR scheduler is now used, which should take hardware (gpu and display) and operating system/driver constraints into account to provide more precise and stable visual stimulus onset timing. Testing shows pretty good results on AMD FreeSync hardware, and some improvements on NVidia G-Sync hardware. AMD gpu's and compatible "FreeSync" displays are strongly recommended over NVidia G-Sync for optimal current results and to take advantage of substantial improvements on Linux in the future.
Commits on Dec 18, 2019
  1. UpdatePsychtoolbox: Add "--accept theirs-full" to svn update.

    kleinerm committed Dec 18, 2019
    Add "--accept theirs-full" to svn update, so in case of conflicts,
    server provided upstream files will just override/overwrite user
    modified files. Not super-friendly of us, but may cut down support
    overhead for users confused about interactive prompting for file
    conflict resolution.
  2. Add mex files for 64-Bit Octave 4.4.1 on 64-Bit Linux for Intel.

    kleinerm committed Dec 18, 2019
    This provides the prebuilt mex files to run with Octave 4.4.1 on
    Ubuntu 19.10, and hopefully on future 20.04-LTS Octave 5.1.
    
    Screen.mex_dis for Wayland test build worked, but leave it out
    for the moment, i don't have need for it atm. and it is not
    officially supported by PTB yet.
    
    PsychCV.mex is left out, because i'm too lazy to build libAR atm.,
    and i doubt anybody is actually using it anyway. Tbd. when 20.04-LTS
    is released.
    
    Eyelink.mex is left out of lazyness atm. Tbd. latest when 20.04-LTS
    ships.
  3. linuxmakeit64/octave3: Fix PsychOpenHMDVRCore mex build.

    kleinerm committed Dec 18, 2019
    -> Adapt to new location of openhmd.h file.
  4. Linux: Add support for Octave-4.4 and Octave-5.

    kleinerm committed Dec 18, 2019
    Update linuxmakeitoctave, PsychtoolboxPostInstallRoutine,
    datapixxmakemex, DownloadPsychtoolbox, UpdatePsychtoolbox
    accordingly. Also some help text updates wrt. missing svn
    clients on macOS.
    
    We assume until proven otherwise that Octave-4.4 and 5.1
    can share the same set of mex files. Ubuntu 19.10 ships
    with Octave-4.4, Ubuntu 20.04 LTS will ship with at least
    Octave 5.1.
    
    -> Actual initial build of mex files for Octave 4.4+ pending.
Commits on Dec 16, 2019
  1. Screen for 64-Bit Octave/Matlab on Linux rebuilt.

    kleinerm committed Dec 16, 2019
    -> Rebuild of all mex files for this release done.
Commits on Dec 15, 2019
  1. Merge pull request #164 from kleinerm/vrrstuff

    kleinerm committed Dec 15, 2019
    Screen/Linux: Add our own custom VRR scheduler.
  2. Screen/Linux: Add our own custom VRR scheduler.

    kleinerm committed Dec 6, 2019
    Add a new VRR mode, mode 3 (aka "OwnScheduled"). It can be passed as
    mode 3 for the vrrParams=[mode, styleHint, minDuration, maxDuration]
    argument vector to Screen('OpenWindow', ..., vrrParams);
    
    Or preferrably it can be requested via a call to:
    
    PsychImaging('AddTask', 'General', 'UseFineGrainedTiming', 'OwnScheduled');
    
    In the current implementation, mode 3 / 'OwnScheduled' gets also
    selected as current best default choice if mode 1 is selected in
    Screen('OpenWindow') or 'Auto' is specified in PsychImaging via
    PsychImaging('AddTask', 'General', 'UseFineGrainedTiming', 'Auto');
    
    The difference to mode 2 / 'Simple' is that we don't simply wait
    until the Screen('Flip', window, when); 'when' deadline and then
    call glXSwapBuffers() to request a buffer swap at 'when' (or call
    glXSwapBuffers() immediately for an immediate flip), but schedule
    the exact time of swapbuffers calls to take information about the
    specific constraints of the operating-system/display-drivers, gpu,
    VRR display device into account, knowing how the VRR hardware
    operates. We also try to compensate for average latency/jitter in
    the display systems response to our swapbuffers calls.
    
    We also use current display system state, like the time of the end
    of the last vblank (= start of a new scanout cycle on the display),
    the time of the last completed flip, current system time, and how
    far into the future the next flip is requested. We aim to time
    glXSwapBuffers() calls so that the requested stimulus onset time
    'when' ideally falls into the extended variable length/duration
    front-porch of the vblank, so the display engine can respond to
    the page-flip right away, minimizing time between flip completion
    and start of active scanout of the post-flip stimulus image. We aim
    to avoid hitting the timeout condition of "max vblank duration
    reached", which would cause a large dead-zone in which we can't
    show the stimulus on time if 'when' falls into the dead-zone.
    
    To achieve this, we reuse much of the infrastructure of our frame-
    sequential stereo implementation for stereo shutter goggles.
    
    At startup, calibrations of average system flip delay are performed,
    in order to compensate for average system delay during operation.
    
    The image post-processing pipeline is started up, and finalizedFBO[0]
    is allocated as a dedicated "bounce-backbuffer" FBO, instead of
    just redirecting to the windows system backbuffer.
    
    The flipper thread is started as in frame-seq stereo or for async
    flips, but the threads main-loop uses a different implementation:
    
    1. All usercode driven stimulus rendering happens into the imaging
       pipelines drawBufferFBO as usual. At 'Flip' / 'DrawingFinished'
       time, all image post-processing is done by the pipeline and its
       shaders as usual per the imaging pipeline configuration.
    
    2. The final stimulus image isn't rendered by the pipeline into the
       system backbuffer directly, but into the finalizedFBO[0] bounce
       FBO.
    
    3. Like in an async flip, PsychFlipWindowBuffersIndirect() is used
       to pass the finalizedFBO to the flipper-thread, together with
       the target stimulus onset timestamp 'when'.
    
    4. The flipper-thread is in one of three possible states:
    
       a) Idle/Prevent-timeout processing: If no new 'Flip' request is
          pending, the thread performs idle swapbuffers calls, taking
          the current active frontbuffer image, copying it into the
          backbuffer, then swapping it back into the new frontbuffer,
          iow. a no-op swap that doesn't change the actual stimulus
          image. The no-op swapbuffers calls are timed in a way to try
          to prevent vblank timeout condition in the display engines.
    
       b) Runup/Prevennt-timeout processing: If a new 'Flip' request
          with a new stimulus image is pending, try do a), while aiming
          to prevent timeout and place the 'when' Flip deadline into
          the extended front-porch of a future scanout cycle. This if
          the 'when' deadline is too far away from current time wrt.
          some criterion.
    
       c) Actual stimulus onset flip: After b) is over, and the target
          front-porch with 'when' in it is in reach, blit the new
          stimulus image from finalizedFBO into the system backbuffer.
          Then do a timed wait until shortly before 'when', taking
          measured average system timing delay into account, then
          swapbuffers the new stimulus, wait for swap completion, do
          the usual stimulus onset timestamping, post-flip operations,
          then transition back to state a) or b).
    
    Note:
    
    - This critically depends on the OS graphics stack providing very
      stable execution timing, which is the case for Linux with FOSS/Mesa,
      less so on Linux with NVidia proprietary driver, and would be way
      less stable on other operating systems.
    
    - Precise and trustworthy timestamps about time of last flip/stimulus
      onset and last end of vblank are absolutely critical. Linux with
      FOSS/Mesa provides this with micro-second precision at all times
      on all supported driver + gpu combos. Linux on NVidia proprietary
      blob doesn't, so we have to use hackery and heuristic tricks to
      abuse our self-made beamposition timestamping to get reasonable
      timestamps. Ergo, Linux + NVidia proprietary driver, as needed
      for VRR on NVidia gpu's, ie. NVidia G-Sync, is expected to be
      less reliable and accurate. Nothing we can do about this. FOSS
      VRR implementations like AMD's FreeSync are therefore strongly
      recommended.
    
    - As we are using the imaging pipelines finalizedFBO bounce
      buffering and the flipper thread, this method is incompatible
      with the following:
    
      - Frame-sequential shutter-goggles stereo: Also because shutter
        goggles need predictable fixed-duration video refresh cycles,
        which are at odds with VRR.
    
      - Dual-Display stereo involving a 2nd onscreen window or dual
        display that isn't hardware-syned in VRR mode to each other,
        as we need OS support for VRR flips sync'ed across display
        engines. Also we can't use a secondary slave onscreen window,
        as our bounce buffering / flipper thread does not support
        VRR.
    
      - Our own software display mirroring, because it would also
        depend on finalizedFBO's that are already used for VRR.
    
      - Dual stream stereo, and custom finalized FBO sinks.
    
      Trying to co-enable any of these with VRR will lead to an error
      abort and a message "Don't do this."
    
    This implementation has been tested on Linux 5.4-rc7+ / 5.5 upcoming
    under Ubuntu 19.10, Mesa 19.2.1, X-Server 1.20.5 with AMD gpu's
    of the Polaris DCE-11 and Raven DCN-1 family for FreeSync VRR.
    Some very light testing was also performed under Ubuntu 18.04.3 LTS
    with NVidia 435-series drivers on a GeForce GTX 1070 Pascal gpu
    for G-Sync. It works ok, a substantial improvement over the previous
    'Simple' method for many use cases. VRRTest.m is used to demo and
    validate VRR.
    
    Future plans:
    
    - While this baseline implementation is a good improvement, it
      is only a starting point, providing the infrastructure and initial
      proof-of-concept implementation. The scheduling algorithm will
      likely change substantially, to actually reach the goals described
      above as aims. We are not there yet.
    
    - The current implementation also allow for passing in an optional
      vrrParams parameter 'styleHint', which allows the user script to
      give the VRR scheduler some hints about how the stimulation paradigm
      wants to work wrt. timing. PsychImaging exposes the same optional
      semantic 'styleHint'. Currently only one setting is accepted, which
      is 0 for 'OpenWindow' aka 'None' for PsychImaging. The idea would
      be that the scheduler can adapt its strategy or tuning parameters
      to give better onset timing precision iff the users script does
      stimulus onset timing according to the semantic high-level hint
      provided via 'styleHint'. E.g., a 'styleHint' could tell us that
      the user-code will usually request 'Flip's on short notice, e.g.,
      because stimulus onset is not known beforehand, but triggered by
      some external event like user input, key-presses, eye movements,
      external triggers. Or the app may tell us that stimulus ISI's will
      be spaced variable on a low millisecond timescale, or on a large
      (hundreds / thousands msecs, seconds) timescales, or that this is
      mostly fixed fps animation/movie playback, with no or little flip
      to flip variation, but unusual fps (ie. not 60 fps, 30 fps, 20 fps).
      Only time and applications will tell iff and how much and what type
      of styleHints we will need and if we actually can adapt in a
      meaningful effective way. Additional api may be needed to change
      strategy during a session, instead of having a fixed strategy per
      session.
    
    - The focus here is on getting maximum performance out of Linux FOSS
      implementations of VRR like AMD's FreeSync or upcoming Intel variants,
      not on proprietary NVidia G-Sync implementations. Users have been
      advised to avoid NVidia and go for FOSS compatible implementations
      for years, so the burden of doing the wrong thing should be carried
      by them and not by people who listen to good advise.
    
    - A future planned VRR implementation for Linux FOSS will offload most
      of the VRR processing to the OS via dedicated api's, as this should
      not only simplify our job, but put VRR to a whole new level of
      reliability, accuracy and precision. This will only work on FOSS
      drivers and is still at least 6-12 months away at this time, possibly
      longer. Therefore the current implementation will have to do for a
      while.
Commits on Dec 12, 2019
  1. PsychPhotodiode: Add 'lrMode' handling, minor cleanups.

    kleinerm committed Dec 12, 2019
    'lrMode' to control if on a multi-channel stereo sound signal,
    the 1st channel, 2nd channel, or a sum or an average of both
    channels should be used for the triggering and stuff.
    
    Default is lrMode 0 = Sum of stereo channels, if any.
    
    This is only well tested for 0 = Sum and 1 = Left channel so far.
    
    Some results wrt. accuracy of the photo-diode method:
    
    CRT monitor: stddev of jitter 13 usecs, < 0.2 msecs error.
    MBP 2017 Retina panel: < 2.5 msecs error on good days.
    MBP 2010 panel:        < 4 msecs error on good days.
    
    -> On panels one should crank display brightness to the max, to
       avoid or minimize backlight pwm modulation artifacts.
    
    -> This is in a reasonable shape for use with displays where one
       can't use VPixxx devices, VGA VideoSwitcher + RTBox etc.
  2. PsychPhotodiode: Various improvements in usability.

    kleinerm committed Dec 12, 2019
    Renamed some functions, removed some arguments or changed their
    defaults. Most importantly, trigger calibration can now be done
    fully by PsychPhotodiode() by driving the display itself.
    
    It also now computes the triggerLevel as weighted mean between
    max intensity at all-black screen and all-white screen, to find
    a better threshold automatically. One could go much more fancy
    here, doing statistics over the two signal distributions for
    all black and all white and find optimal separating threshold,
    but for the moment this seems to work well at least as tested
    on a good old CRT, where we get jitter < 20 usecs and a mean
    error wrt. Flip timestamping of less than 0.2 msecs.
    
    -> VRRTest.m adapted accordingly to demonstrate optimal use of
       PsychPhotodiode(). Also some other cleanups wrt. code linting.
  3. PsychPhotodiode: Prefer Mario's favourite USB plug-in sound card.

    kleinerm committed Dec 12, 2019
    It's handy to plug in the same audio adapter into any machine,
    so if it is plugged in, auto-select it for photo-diode measurements.
  4. Add PsychPhotodiode() for photo-diode based visual onset timestamping.

    kleinerm committed Dec 12, 2019
    This new function allows to (ab)use a sound-card via PsychPortAudio
    for visual onset timestamping. The idea is to connect a photo-diode
    or such via suitable amplifier to the microphone/line-input of a
    sound card, then use PsychPortAudio to capture with timestamps from
    the soundcard, threshold signal spikes and timestamp accordingly
    for cheap and easy spot-checking of visual onset timing, comparable
    to Screen('Flip')'s timestamps.
    
    First user of PsychPhotodiode() is VRRTest.m, which now has a new
    hwmeasurement method 5, using this. Verified to work reasonably
    with my photo-diodes and an external USB soundcard on the Retina
    panel of my MBP 2017 "groovy" under Ubuntu Linux 19.10. Also minor
    cosmetics to VRRTest.m.
Commits on Dec 10, 2019
  1. Merge pull request #163 from Psychtoolbox-3/beta

    kleinerm committed Dec 10, 2019
    Resync with public beta "Funky Syncopation!" SP2
  2. Merge pull request #622 from Psychtoolbox-3/master

    kleinerm committed Dec 10, 2019
    PTB BETA "Funky Syncopation!" SP2
    
    * Emergency fix for Screen + NVidia blob on Linux.
    * Improvements to Snd() and Beeper()
    * Some fix to FillInPhotoReceptors()
  3. Merge pull request #621 from kleinerm/master

    kleinerm committed Dec 10, 2019
    Pull emergency fix for Screen + NVidia blob on Linux.
    Also improvements to Snd() and Beeper()
  4. Screen for 64-Bit Octave/Matlab rebuilt.

    kleinerm committed Dec 10, 2019
    -> Emergency fix for NVidia proprietary blob.
Commits on Dec 9, 2019
  1. Screen/Linux: Fix totally f#$$d NVidia proprietary support.

    kleinerm committed Dec 9, 2019
    A misplaced PsychUnlockMutex() wrt. VRR setup code under G-Sync
    totally kills the NVidia proprietary driver regardless if G-Sync
    or not.
    
    Fixed. This warrants an emergency release for Linux!
  2. Beeper(): Close Snd() device after each beep, be less chatty.

    kleinerm committed Dec 9, 2019
    This way, if PsychPortAudio() is used by Snd(), we release
    the driver and thereby the soundcard whenever we don't need
    it. Should lead to less interference/impairment of, e.g.,
    GStreamer movie playback or other audio clients that don't
    use PsychPortAudio(). The extra overheard for repeated audio
    open->close->open... is fine, as we never claimed that Beeper
    is in any way low latency / high timing precision / high perf.
    
    Also use new Snd('Verbosity') command to suppress chatty status
    messages during these open/close... sequences.
  3. Snd(): Add new subcommand 'Verbosity' to set verbosity.

    kleinerm committed Dec 9, 2019
    Non-zero == Chatty. Zero == Mute unless critical errors.
Commits on Dec 8, 2019
  1. Merge pull request #162 from Psychtoolbox-3/beta

    kleinerm committed Dec 8, 2019
    Resync with public beta "Funky Syncopation!" SP1
  2. Merge pull request #620 from Psychtoolbox-3/master

    kleinerm committed Dec 8, 2019
    PTB BETA UPDATE "Funky Syncopation!" SP1
    
    * Fix Retina display on macOS at > 8 bpc precision.
    * Fix plotting under Matlab in AudioFeedbackLatencyTest.m
  3. Merge pull request #619 from kleinerm/master

    kleinerm committed Dec 8, 2019
    PULL macOS Screen + Retina + high precision framebuffer fixes.
    
    * Fix Retina display on macOS at > 8 bpc precision.
    * Fix plotting under Matlab in AudioFeedbackLatencyTest.m
Commits on Dec 7, 2019
  1. Screen for 64-Bit Octave/Matlab on OSX rebuilt.

    kleinerm committed Dec 7, 2019
    -> Integrate “Retina display at > 8 bpc framebuffer” fixes.
    -> Also verified that AudioFeedbackLatencyTest.m works on Octave/Matlab.
  2. AudioFeedbackLatencyTest: Fix plotting on Matlab.

    kleinerm committed Dec 7, 2019
    This file has more issues, like it needs a total overhaul
    of implementation. And worst, Git thinks this is a binary
    file so diffing and source control don't work. Happens on
    both Linux and macOS, so something is screwed with this
    file, so far not able to fix it.
  3. Screen/OSX: Fix Retina displays for > 8 bpc framebuffers.

    kleinerm committed Dec 7, 2019
    Apples 10.14 trainwreck can't do better than 8 bpc / depth 24
    and maintain compositor bypass, so timing would suck
    anyway. Let's give up already and switch to Cocoa, so at
    least Retina scaling will be ok at > 8 bpc.
    
    Also some cosmetic to debug/status messages.
Commits on Dec 4, 2019
  1. Merge pull request #161 from Psychtoolbox-3/beta

    kleinerm committed Dec 4, 2019
    Resync with public beta "Funky Syncopation!"
  2. Merge pull request #616 from Psychtoolbox-3/master

    kleinerm committed Dec 4, 2019
    PTB BETA "Funky Syncopation"
    
    Improvements for all systems:
    
    - drawChromaticity() renamed to DrawChromaticity(), so Matlab/Octave don't complain and our documentation generator can actually generate documentation. Other small cleanups/refinements.
    
    - InitializePsychSound() made less chatty.
    
    - Minor improvements to PsychPortAudioTimingTest et al.: Go back to 44100 Hz sample rate, as that seems to be supported on a wider range of sound hardware. Weird, because the HDA spec only mandates 48000 Hz, so one would expect lazy hw vendors to implement that foremost.
    
    - BasicSoundInputDemo: Only switch from recording to playback on ESCape key press.
    
    Improvements on Linux:
    
    - XOrgConfCreator can now configure hybrid graphics laptops also when running under Matlab, not just Octave, by working around a Matlab limitation. So far it didn't recognize a multi-gpu laptop as such when executed under Matlab, only on Octave.
    
    - Support for use of Variable Refresh Rate (VRR) displays, also known as VRR, HDMI-2.1 VRR, DisplayPort Adaptive Sync, AMD FreeSync or NVidia G-Sync, with suitable AMD FreeSync or NVidia G-Sync gpu's on suitable Linux versions and drivers. "help VRRSupport" explains hardware and software requirements, gives setup instructions and usage / test instructions, and also provides background infos. VRRTest exercises suitable system setups. PsychImaging('AddTask', 'General', 'UseFineGrainedTiming'); requests use of VRR on supported setups. This is an initial implementations of the basics. It is expected to work best on AMD gpu's of the Vega gpu family or later, e.g., Ryzen / Raven Ridge integrated graphics controllers and Vega or Navi family discrete gpu's. It will also work with some more limitations on older AMD gpu's like Polaris, Volcanic Islands and Sea Islands family. It may work ok'ish on NVidia G-Sync gpu's, but use of AMD graphics + AMD FreeSync2 monitors is strongly recommended over NVidia graphics + NVidia G-Sync displays. Stay tuned for future improvements to VRR based fine grained visual stimulus timing. Not supported on MS-Windows yet.
  3. Merge pull request #615 from kleinerm/master

    kleinerm committed Dec 4, 2019
    PULL for "Funky Syncopation"
    
    Improvements for all systems:
    
    - drawChromaticity() renamed to DrawChromaticity(), so Matlab/Octave don't complain and our documentation generator can actually generate documentation. Other small cleanups/refinements.
    
    - InitializePsychSound() made less chatty.
    
    - Minor improvements to PsychPortAudioTimingTest et al.: Go back to 44100 Hz sample rate, as that seems to be supported on a wider range of sound hardware. Weird, because the HDA spec only mandates 48000 Hz, so one would expect lazy hw vendors to implement that foremost.
    
    - BasicSoundInputDemo: Only switch from recording to playback on ESCape key press.
    
    Improvements on Linux:
    
    - XOrgConfCreator can now configure hybrid graphics laptops also when running under Matlab, not just Octave, by working around a Matlab limitation. So far it didn't recognize a multi-gpu laptop as such when executed under Matlab, only on Octave.
    
    - Support for use of Variable Refresh Rate (VRR) displays, also known as VRR, HDMI-2.1 VRR, DisplayPort Adaptive Sync, AMD FreeSync or NVidia G-Sync, with suitable AMD FreeSync or NVidia G-Sync gpu's on suitable Linux versions and drivers. "help VRRSupport" explains hardware and software requirements, gives setup instructions and usage / test instructions, and also provides background infos. VRRTest exercises suitable system setups. PsychImaging('AddTask', 'General', 'UseFineGrainedTiming'); requests use of VRR on supported setups. This is an initial implementations of the basics. It is expected to work best on AMD gpu's of the Vega gpu family or later, e.g., Ryzen / Raven Ridge integrated graphics controllers and Vega or Navi family discrete gpu's. It will also work with some more limitations on older AMD gpu's like Polaris, Volcanic Islands and Sea Islands family. It may work ok'ish on NVidia G-Sync gpu's, but use of AMD graphics + AMD FreeSync2 monitors is strongly recommended over NVidia graphics + NVidia G-Sync displays. Stay tuned for future improvements to VRR based fine grained visual stimulus timing. Not supported on MS-Windows yet.
Older
You can’t perform that action at this time.