I am running Psychtoolbox3 on an Ubuntu Linux system (20.04.3 LTS) with an NVIDIA Quadro P4000, hosted by a Lenovo multi-core processor (ThinkStationP720B, Intel Xeon). The ultimate aim is to have some binocularly flickering stimuli for use under high-bit depth mode (M16) in an MRI scanner.
The NVIDIA card communicates with a Propixx data projector via a Propixx controller. The cable from NVIDIA to Propixx controller is DP at the NVIDIA end and DVI at Propixx. The projector has a stereo switcher with associated polarized spectacles. I have installed Ubuntu Studio, configured and made user member of group “audio”.
Most trial/test software runs just fine. All the PyPixx demos appear to work and VPutils behaves as expected.
The demo software from Psychtoolbox also works in general: for example Gabor, StereoDemos, Dots. This is being run from MATLAB 2021a
Where things fail is with the Datapixx versions of the BitsPlusPlus tests provided in Psychtoolbox.
BitsPlusImagingPipelineTest : this completes and reports frame rate accurately
BitsPlusIdentityClutTest (1,1) : the simple version of this (with no intensive checking) runs, but it is extremely slow, updating once every several seconds. The red stripe takes (almost) forever to complete one cycle and the gray square appears almost frozen. The background is clean, no flickering of colours. The coloured writing does not appear to cycle through expected set colours, according to description in software. The KbWait also appears to get locked up, or very slow, and MATLAB shows a spinning wheel, saying busy. CNTL-C kills the whole process.
The long version of the ClutTest cycles around and keeps reporting over a 100 iterations of “trying to fix” things. The numbers coming back suggest that this process is diverging away from any fix, as the errors increase from 3 or 4 to more than 100 during that processing. Eventual the code stops trying to fix things and goes back to the simple version of the test.
Accidentally running the wrong version of the test (the one meant for BitsPlus devices) actually shows better behaviour. The colours are all wrong, with an intense green background, but the timing of changes in the display appears correct and the test completes without locking up the keyboard and writes a file.
My diagnosis (admittedly part-intuition) is that there are problems in writing the M16/C48 mode to the Propixx when trying to communicate through PTB/X11/openGL. M16/C48 modes seem to work OK when using the Python interface, so I am assuming these problems are not inherent to the NVIDIA card and drivers.
A few details about X and drivers. Using the NVIDIA drivers (as advised by VPixx), version 470.63.01, cannot get Nouveau drivers to work on two screens as yet. Open GL is version 4.6.0 Nvidia. Dithering is forced to be off. Tried turning on/off Triple Buffering but no improvement. Tried setting both screens to same size.
I am ruling out hardware/cable problems because things “seem to work”, including M16/C48 demos from PyPixx. That may or may not be justified.
I’d be very grateful for any points to the obvious, “next things to try”. If the advice is go and buy an AMD card, then that can be done. All I have to fight then is central IT purchasing. But I am surprised that things seem to work OK, except with PTB.