PTB/Nvidia P4000/Datapixx - M16 mode doen't work properly

Hardware
, ,
1

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.

  1. BitsPlusImagingPipelineTest : this completes and reports frame rate accurately

  2. 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.

  3. 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.

  4. 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.

Andrew

2

Hi Andrew,

Does settings useclutmodeonly make any difference?Can you even change the CLUT in BitsPlusIdentityClutTest (press [SPACE])?

My general intuition is that the PyPixx code does not do the low level configuration checking that PTB does, so I’m not entirely sure that the fact the Python code appears to work is a reliable indicator of fully successful operation.

Mario can give you a more definitive answer (though I don’t know if he has this hardware), and perhaps Peter and team at VPixx also has a specific recommendation, but in general having set up many PTB systems, NVidia GPUs often cause problems, and those problems just go away when swapping in an AMD GPU (and certainly Ubuntu + Display++ + AMD GPU works great, we have two of these in Shanghai). I do also have access to a Propixx system in our new MEG facility, I can check the GPU model and see the performance in BitsPlusIdentityClutTest…

Cheers, Ian

3

What @Ian-Max-Andolina says. Almost certainly not a PTB bug. High likelihood that the other tools are giving you a false sense of success, given PTB has more stringent checking. AMD is a generally trouble free choice.

Any further help from my side requires paid priority support.

Have a nice weekend,
-mario

4

One other thing to try is to modify the working PTB demos to use the M16/C48 modes, it may be that the basic high bit-depth modes themselves are working well, even if the CLUT fiddling of the overlay modes have issues. As I understand it you do not actually need the overlay, you just want the high-bit resolution afforded by M16/C48? You need to add the correct PsychImaging incantation, so for example if you try the ProceduralColorGratingDemo.m you can edit line 50 to:

PsychImaging('PrepareConfiguration');
PsychImaging('AddTask', 'General', 'FloatingPoint32BitIfPossible');
PsychImaging('AddTask', 'General', 'EnableDataPixxM16Output');
[win, winRect] = PsychImaging('OpenWindow', screenid, baseColor);

If you want to confirm the bit depth is working, then ultimately you will want to use a photometer and measure a range of luminance steps. If the high-bitdepth mode is not working then you will see a jagged set of steps (i.e. if the output is 2^8 and your desired steps are 2^10 you will see a flat line for 4 steps then a jump, flat line for 4 steps etc.). I have some code somewhere to test this for the Display++ (using the SpectroCal also from CRS, ) so that can be easily adapted for the Propixx…

5

That won’t work, although it is an excellent way to fool yourself, unless you do the photometer testing described by Ian below. For that reason, PTB tries hard to prevent you from using this functionality at all in your own scripts, unless/until you’ve successfully run our tests. Anything that tampers with the video output signal will also tamper with the M16 or C48 video content, not just the overlay or the Psync pixel code. The result may look visually right to the naive observer, but will be effectively degraded to about 8 bpc, like on any cheap monitor. Our tests are designed to catch such things, and did in this case. In fact, the whole clut color overlay animations and test patterns are mostly there to uncover these bugs that affect M16/C48 precision in the most visually salient and “in your face” way, not so much to test the color palette - that is just a welcome and cute looking side effect. They have to do that, because the original CRS Bits+ didn’t have a feedback path to the computer, so the software could not test itself if things are sane.

If PTB’s tests detect a problem for VPixx or CRS devices, then these problems are there and they are serious enough to make high precision display useless, iow. the tests have a cose to zero false negative rate for detecting failure.

This is a case where the NVidia gpu/drivers, or a misconfiguration of them by the user or the software, is the most likely cause of trouble.

If it would be a PTB problem, e.g., PTB using the wrong gamma tables for the gpu by default, then it would be caused by NVidia making breaking backwards incompatible changes to their drivers or gpu’s for specific driver versions or models, iow. it is indirectly NVidia’s fault. It would also almost certainly affect other software, which is usually less well equipped than PTB in that area. These are some of the problems that are way less likely to happen, although not impossible, if people choose the hardware we recommend with the drivers we recommend, instead of NVidia.

There’s also MeasureLuminancePrecision.m, which could be adapted to run automated testing with all photometers/colormeters supported by PTB. The script is a rework of the original script by Denis Pelli, and it is always a work in progress, but i use it a lot verifying gpu built in high precision modes. Not for validating the CRS or VPixx devices atm. though, as my last CRT monitor died more than a year ago. Also, no real need, as i have very high trust in PTB’s ability to detect most problems with VPixx devices and modern CRS devices by itself.

Anyway, so far we’ve spent more than unpaid 3000 Euros of work time this year alone, and the time it takes, delaying actual paid work, for helping VPixx customers for free. This is a substantial amount of money for a severely underfunded project like PTB, so i can’t give free advice here anymore wrt. these topics, until somebody pays the bills.

-mario

6

Ok, one more bit of info: My notes say that the last test of a NVidia GeForce 1650GTX about 1 year ago on Ubuntu 20.04-LTS with whatever was installed as NVidia driver at that time, showed failure of identity pixel passthrough at least on the proprietary driver. nouveau wasn’t tested in that context, so may or may not behave the same. This is a more modern gpu than yours, but the brokeness may apply. No further investigation was done, as we recommend against the use of NVidia hardware and fixing such problems is more difficult and time consuming than with AMD.

7

All very helpful. in various ways.

  1. I did manage to tame the slowness by throwing various option switches on the NVIDIA card controller. But the BitsPlusIdentityClutTest still failed to converge.

  2. Ian Andolina’s suggested lines of code to set the state of the PTB/DataPixx were useful:
    PsychImaging(‘AddTask’, ‘General’, ‘FloatingPoint32BitIfPossible’);
    PsychImaging(‘AddTask’, ‘General’, ‘EnableDataPixxM16Output’);

The outcome here was that testing the effect of these settings on the visual display and checking the reported values in Gamma LUTs revealed inconsistencies by reading back the values.

  1. Immediate action is to order an AMD card and see whether we can resolve these issues.

  2. Mario, I may well be posting you directly for paid support as this unfolds. However, as the mythology reminds us, if I am allowed to ask three questions of a wise man to settle my problems, I had better be clear about which questions need answering before we start.