ptb3-matlab works fine but not when -nojvm is called

1
Hi,

I have just installed ubuntu 16.04 and the all packages to run PTB. Everything looks fine when I run my stimuli on a VPIXX screen.
My config is ubuntu 16.04 (4.8.0-34-lowlatency kernel), matlab 2015a, ptb-3 installed through neurodebian, and PsychLinuxConfiguration script has been run.
I still need to run ptb3-matlab with sudo to run BitsPlusImagingPipelineTest and BitsPlusCLUTtest, but everything seems to work fine when I call my scripts. However when I try those with -nojvm  (I want to display fast stimuli), then I have the following error message:
[...]
PTB-INFO: This is Psychtoolbox-3 for GNU/Linux X11, under Matlab 64-Bit (Version 3.0.14 - Build date: Dec 22 2016).
PTB-INFO: Support status on this operating system release: Linux 4.8.0-34-lowlatency Supported.
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: NVIDIA Corporation - GF119 [GeForce GT 520] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to NVidia GF119 [GeForce GT 520] GPU of NV-0d0 family with 2 display heads. Beamposition timestamping enabled.

PTB-WARNING: Your graphics driver doesn't allow me to control syncing wrt. vertical retrace!
PTB-WARNING: Please update your display graphics driver as soon as possible to fix this.
PTB-WARNING: Until then, you can manually enable syncing to VBL somehow in a manner that is
PTB-WARNING: dependent on the type of gfx-card and driver. Google is your friend...
PTB-WARNING: Seems that a Mesa OpenGL software renderer is active! This will likely cause miserable
PTB-WARNING: performance, lack of functionality and severe timing and synchronization problems.
[...]

When I run those scripts whith java I have this:

PTB-INFO: NVIDIA Corporation - GF119 [GeForce GT 520] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to NVidia GF119 [GeForce GT 520] GPU of NV-0d0 family with 2 display heads. Beamposition timestamping enabled.
PTB-INFO: Fixed point precision integer framebuffer enabled.


PTB-INFO: OpenGL-Renderer is nouveau :: Gallium 0.4 on NVD9 :: 3.0 Mesa 11.2.0
PTB-INFO: VBL startline = 1080 , VBL Endline = 1242
PTB-INFO: Measured monitor refresh interval from beamposition = 8.333737 ms [119.994194 Hz].
PTB-INFO: Will try to use OS-Builtin OpenML sync control support for accurate Flip timestamping.
PTB-INFO: Measured monitor refresh interval from VBLsync = 8.333836 ms [119.992768 Hz]. (50 valid samples taken, stddev=0.000529 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 8.333472 ms [119.998001 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.
PTB-INFO: Psychtoolbox imaging pipeline starting up for window with requested imagingmode 1061 ...
PTB-INFO: Will use 32 bits per color component floating point framebuffer for stimulus drawing. Alpha blending should work correctly.
PTB-INFO: Will use 32 bits per color component floating point framebuffer for stimulus post-processing (if any).
PTB - Info: Your framebuffer is configured for maximum precision. All internal processing will be done
PTB - Info: with about 23 bits of linear precision -- DataPixx will be able to finally output with 16 bits precision.
PTB - Info: Alpha-blending should be fully supported at this precision by your hardware.

PTB - Info: Aspect ratio preserving half horizontal resolution color conversion for C48
PTB - Info: mode selected. All odd-numbered pixel columns will be ignored/skipped.

LoadIdentityClut: Info: Could not use GPU low-level setup for setup of pixel passthrough. Will use fallback method.
LoadIdentityClut: NVidia gpu detected. Enabling type-III LUT.
Building a fragment shader:Reading shader from file /usr/share/matlab/site/m/psychtoolbox-3/PsychOpenGL/PsychGLSLShaders/ICMCLUTCorrectionShader.frag.txt ...
Compiling all shaders matching Bits++_Color++_FormattingShader * into a GLSL program.
Building a fragment shader:Reading shader from file /usr/share/matlab/site/m/psychtoolbox-3/PsychOpenGL/PsychGLSLShaders/Bits++_Color++_FormattingShader.frag.txt ...
PsychDatapixx:GPU-Rasterizertest: Warning: glVertex2f() command draws at wrong position (Offset 0, 1)!
LoadIdentityClut: Info: Could not use GPU low-level setup for setup of pixel passthrough. Will use fallback method.
LoadIdentityClut: NVidia gpu detected. Enabling type-III LUT.
PsychColorCorrection: Using a 32 bit float CLUT -> 23 bits effective linear output precision for color correction.

I am missing something? Is there a lib I cannot access to when -nojvm is called?

Thanks for any help you could provide.


Romain Bachy


2
It should work without Java, at least it did with the R2012a Matlab version i test with.

However it should also work without any need for sudo if your user account got properly added to the 'psychtoolbox' Unix user group by PsychLinuxConfiguration, as it proposed to do.

Did you install Matlab before PTB and allowed the NeuroDebian setup to automatically get rid of Matlab's incompatible libraries?
-mario

XX---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :

Hi,

I have just installed ubuntu 16.04 and the all packages to run PTB. Everything looks fine when I run my stimuli on a VPIXX screen.
My config is ubuntu 16.04 (4.8.0-34-lowlatency kernel), matlab 2015a, ptb-3 installed through neurodebian, and PsychLinuxConfiguration script has been run.
I still need to run ptb3-matlab with sudo to run BitsPlusImagingPipelineTest and BitsPlusCLUTtest, but everything seems to work fine when I call my scripts. However when I try those with -nojvm  (I want to display fast stimuli), then I have the following error message:
[...]
PTB-INFO: This is Psychtoolbox-3 for GNU/Linux X11, under Matlab 64-Bit (Version 3.0.14 - Build date: Dec 22 2016).
PTB-INFO: Support status on this operating system release: Linux 4.8.0-34-lowlatency Supported.
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: NVIDIA Corporation - GF119 [GeForce GT 520] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to NVidia GF119 [GeForce GT 520] GPU of NV-0d0 family with 2 display heads. Beamposition timestamping enabled.

PTB-WARNING: Your graphics driver doesn't allow me to control syncing wrt. vertical retrace!
PTB-WARNING: Please update your display graphics driver as soon as possible to fix this.
PTB-WARNING: Until then, you can manually enable syncing to VBL somehow in a manner that is
PTB-WARNING: dependent on the type of gfx-card and driver. Google is your friend...
PTB-WARNING: Seems that a Mesa OpenGL software renderer is active! This will likely cause miserable
PTB-WARNING: performance, lack of functionality and severe timing and synchronization problems.
[...]

When I run those scripts whith java I have this:

PTB-INFO: NVIDIA Corporation - GF119 [GeForce GT 520] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to NVidia GF119 [GeForce GT 520] GPU of NV-0d0 family with 2 display heads. Beamposition timestamping enabled.
PTB-INFO: Fixed point precision integer framebuffer enabled.


PTB-INFO: OpenGL-Renderer is nouveau :: Gallium 0.4 on NVD9 :: 3.0 Mesa 11.2.0
PTB-INFO: VBL startline = 1080 , VBL Endline = 1242
PTB-INFO: Measured monitor refresh interval from beamposition = 8.333737 ms [119.994194 Hz].
PTB-INFO: Will try to use OS-Builtin OpenML sync control support for accurate Flip timestamping.
PTB-INFO: Measured monitor refresh interval from VBLsync = 8.333836 ms [119.992768 Hz]. (50 valid samples taken, stddev=0.000529 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 8.333472 ms [119.998001 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.
PTB-INFO: Psychtoolbox imaging pipeline starting up for window with requested imagingmode 1061 ...
PTB-INFO: Will use 32 bits per color component floating point framebuffer for stimulus drawing. Alpha blending should work correctly.
PTB-INFO: Will use 32 bits per color component floating point framebuffer for stimulus post-processing (if any).
PTB - Info: Your framebuffer is configured for maximum precision. All internal processing will be done
PTB - Info: with about 23 bits of linear precision -- DataPixx will be able to finally output with 16 bits precision.
PTB - Info: Alpha-blending should be fully supported at this precision by your hardware.

PTB - Info: Aspect ratio preserving half horizontal resolution color conversion for C48
PTB - Info: mode selected. All odd-numbered pixel columns will be ignored/skipped.

LoadIdentityClut: Info: Could not use GPU low-level setup for setup of pixel passthrough. Will use fallback method.
LoadIdentityClut: NVidia gpu detected. Enabling type-III LUT.
Building a fragment shader:Reading shader from file /usr/share/matlab/site/m/psychtoolbox-3/PsychOpenGL/PsychGLSLShaders/ICMCLUTCorrectionShader.frag.txt ...
Compiling all shaders matching Bits++_Color++_FormattingShader * into a GLSL program.
Building a fragment shader:Reading shader from file /usr/share/matlab/site/m/psychtoolbox-3/PsychOpenGL/PsychGLSLShaders/Bits++_Color++_FormattingShader.frag.txt ...
PsychDatapixx:GPU-Rasterizertest: Warning: glVertex2f() command draws at wrong position (Offset 0, 1)!
LoadIdentityClut: Info: Could not use GPU low-level setup for setup of pixel passthrough. Will use fallback method.
LoadIdentityClut: NVidia gpu detected. Enabling type-III LUT.
PsychColorCorrection: Using a 32 bit float CLUT -> 23 bits effective linear output precision for color correction.

I am missing something? Is there a lib I cannot access to when -nojvm is called?

Thanks for any help you could provide.


Romain Bachy


3
Hi Mario,
Thank you for your reply. I will double check that and will re-install everything from scratch. I might have missed a step.

Anyway, since I am trying to display 1 or 2 frames large stimuli with the C48 mode on the VPIXX, I think I might as well upgrade my computer with a more decent/recent graphic card (a radeon HD or RX if I understand), get rid of the dual display etc. Does the -nojvm improve significantly the drawing performance ???


best regards

Romain Bachy

---In PSYCHTOOLBOX@yahoogroups.com, <mario.kleiner@...> wrote :

It should work without Java, at least it did with the R2012a Matlab version i test with.

However it should also work without any need for sudo if your user account got properly added to the 'psychtoolbox' Unix user group by PsychLinuxConfiguration, as it proposed to do.

Did you install Matlab before PTB and allowed the NeuroDebian setup to automatically get rid of Matlab's incompatible libraries?
-mario

XX---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :

Hi,

I have just installed ubuntu 16.04 and the all packages to run PTB. Everything looks fine when I run my stimuli on a VPIXX screen.
My config is ubuntu 16.04 (4.8.0-34-lowlatency kernel), matlab 2015a, ptb-3 installed through neurodebian, and PsychLinuxConfiguration script has been run.
I still need to run ptb3-matlab with sudo to run BitsPlusImagingPipelineTest and BitsPlusCLUTtest, but everything seems to work fine when I call my scripts. However when I try those with -nojvm  (I want to display fast stimuli), then I have the following error message:
[...]
PTB-INFO: This is Psychtoolbox-3 for GNU/Linux X11, under Matlab 64-Bit (Version 3.0.14 - Build date: Dec 22 2016).
PTB-INFO: Support status on this operating system release: Linux 4.8.0-34-lowlatency Supported.
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: NVIDIA Corporation - GF119 [GeForce GT 520] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to NVidia GF119 [GeForce GT 520] GPU of NV-0d0 family with 2 display heads. Beamposition timestamping enabled.

PTB-WARNING: Your graphics driver doesn't allow me to control syncing wrt. vertical retrace!
PTB-WARNING: Please update your display graphics driver as soon as possible to fix this.
PTB-WARNING: Until then, you can manually enable syncing to VBL somehow in a manner that is
PTB-WARNING: dependent on the type of gfx-card and driver. Google is your friend...
PTB-WARNING: Seems that a Mesa OpenGL software renderer is active! This will likely cause miserable
PTB-WARNING: performance, lack of functionality and severe timing and synchronization problems.
[...]

When I run those scripts whith java I have this:

PTB-INFO: NVIDIA Corporation - GF119 [GeForce GT 520] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to NVidia GF119 [GeForce GT 520] GPU of NV-0d0 family with 2 display heads. Beamposition timestamping enabled.
PTB-INFO: Fixed point precision integer framebuffer enabled.


PTB-INFO: OpenGL-Renderer is nouveau :: Gallium 0.4 on NVD9 :: 3.0 Mesa 11.2.0
PTB-INFO: VBL startline = 1080 , VBL Endline = 1242
PTB-INFO: Measured monitor refresh interval from beamposition = 8.333737 ms [119.994194 Hz].
PTB-INFO: Will try to use OS-Builtin OpenML sync control support for accurate Flip timestamping.
PTB-INFO: Measured monitor refresh interval from VBLsync = 8.333836 ms [119.992768 Hz]. (50 valid samples taken, stddev=0.000529 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 8.333472 ms [119.998001 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.
PTB-INFO: Psychtoolbox imaging pipeline starting up for window with requested imagingmode 1061 ...
PTB-INFO: Will use 32 bits per color component floating point framebuffer for stimulus drawing. Alpha blending should work correctly.
PTB-INFO: Will use 32 bits per color component floating point framebuffer for stimulus post-processing (if any).
PTB - Info: Your framebuffer is configured for maximum precision. All internal processing will be done
PTB - Info: with about 23 bits of linear precision -- DataPixx will be able to finally output with 16 bits precision.
PTB - Info: Alpha-blending should be fully supported at this precision by your hardware.

PTB - Info: Aspect ratio preserving half horizontal resolution color conversion for C48
PTB - Info: mode selected. All odd-numbered pixel columns will be ignored/skipped.

LoadIdentityClut: Info: Could not use GPU low-level setup for setup of pixel passthrough. Will use fallback method.
LoadIdentityClut: NVidia gpu detected. Enabling type-III LUT.
Building a fragment shader:Reading shader from file /usr/share/matlab/site/m/psychtoolbox-3/PsychOpenGL/PsychGLSLShaders/ICMCLUTCorrectionShader.frag.txt ...
Compiling all shaders matching Bits++_Color++_FormattingShader * into a GLSL program.
Building a fragment shader:Reading shader from file /usr/share/matlab/site/m/psychtoolbox-3/PsychOpenGL/PsychGLSLShaders/Bits++_Color++_FormattingShader.frag.txt ...
PsychDatapixx:GPU-Rasterizertest: Warning: glVertex2f() command draws at wrong position (Offset 0, 1)!
LoadIdentityClut: Info: Could not use GPU low-level setup for setup of pixel passthrough. Will use fallback method.
LoadIdentityClut: NVidia gpu detected. Enabling type-III LUT.
PsychColorCorrection: Using a 32 bit float CLUT -> 23 bits effective linear output precision for color correction.

I am missing something? Is there a lib I cannot access to when -nojvm is called?

Thanks for any help you could provide.


Romain Bachy


4

Dear Mario,

I reconfigured the matlab-support without success regarding the -nojvm. I checked if the lib had been renamed in the sys folder and it is the case, so mystery unsolved yet, but it is probably not a big deal since it works fine otherwise. I haven't tried yet with matlab 2013b.

This task is, I think, quite demanding. With the C48 mode activated, I try to display a full screen stimulus for 1 (or 2) frame followed by a full screen noise mask for 2 (or 4) frames. When I check the vbl timestamp, it cannot flip faster than 0.0417sec i.e. 5 frames. The VBLsynctest is ok, but when I run the CheckFrameTiming script with a large [1080 1080] window, I see as well that it does not refresh at each frame. Thinking about it, the issue is probably more related to Matlab function execution time course, and not to the gpu process.
I ran the function with the profiler on and the pb seems to come from the Screen('flip') function that can be quite "slow" to get executed: for 60 trials it takes 0.56sec so 0.0093sec on average which is already more than a frame. is the flip execution supposed to be that slow for very large stimuli with a C48 mode? With the normal mode I can easily display only 1 frame without any error or delays.

Then, I should probably up to a point stop trying to display full screen stimuli with the C48 mode and go back to a normal mode. I already ran a bunch of expe with large pictures and a calibration specific to this mode so I am trying to not change that, but I will if needed.
Not completely related, but are matlab functions better optimized for linux, windows or mac os, or it really does not matter???

best

Romain Bachy

---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :




---In PSYCHTOOLBOX@yahoogroups.com, <mario.kleiner@...> wrote :

XX---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :

Hi Mario,
I re installed everything from scratch and I can use and update xorgCreator/BitsPlusImagingPipelinetest and so on without launching pt3-matlab with sudo now. However, still the same issue with -nojvm. I am
investing in a new video card (a Radeon RX) so it will eventually solve the issue. I might try as well to install Matlab 2013b to check what happens with the last old graphic matlab system.

-> Good for the sudo thing. The -nojvm thing is puzzling. I don't think swapping the graphics card would do anything about that at all, and your current card seems to work well enough for the task, so probably no point in upgrading that systems gpu. Trying a different Matlab version may be more fruitful.

---> ok, but I cannot resist to try at least a more recent radeon gpu, it is a perfect excuse to upgrade :-)

-> You could try running ...
sudo dpkg-reconfigure matlab-support
and make sure to yes to questions about renaming conflicting libraries, just to make sure this has really run at some point for your current Matlab installation.

---> ok I will do that.

-> All in all, -nojvm is not needed that often on a modern Linux system and modern hardware, it is an extra tweak one can try if one runs into timing problems, so maybe you can do without it. I don't quite understand your task about those "1 or 2 frames stimuli"? Is this something especially demanding or are you running into performance/timing problems?

---> This task is, I think, quite demanding. With the C48 mode activated, I try to display a full screen stimulus for 1 (or 2) frame followed by a full screen noise mask for 2 (or 4) frames. When I check the vbl timestamp, it cannot flip faster than 0.0417sec i.e. 5 frames. The VBLsynctest is ok, but when I run the CheckFrameTiming script with a large [1080 1080] window, I see as well that it does not refresh at each frame. Thinking about it, the issue is probably more related to Matlab function execution time course, and not to the gpu process. I should check how long it takes to the Screen('drawtextures') function to draw those large matrices with the profiler.
Then, I will probably up to a point stop trying to display full screen stimuli with the C48 mode and go back to a normal mode with smaller stim. I already ran a bunch of expe with large pictures and a calibration specific to this mode so I am trying to not change that, but I will if needed.
Not completely related, but are matlab functions better optimized for linux, windows or mac os, or it really does not matter???

Best

Romain

-mario


Thanks for everything you are doing for the community!

Best

Romain Bachy
 
 
5
Just replying without having followed this thread, or having experience with the VPixx. Flip often takes a long time, because, by default, it does not return until the flip has actually been performed. As long as the long wait is not because a flip i missed (then it blocks until the next), you're good there.

Cheers,
Dee

On Mon, Jan 30, 2017 at 6:57 PM, mannow1@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:



Dear Mario,

I reconfigured the matlab-support without success regarding the -nojvm. I checked if the lib had been renamed in the sys folder and it is the case, so mystery unsolved yet, but it is probably not a big deal since it works fine otherwise. I haven't tried yet with matlab 2013b.

This task is, I think, quite demanding. With the C48 mode activated, I try to display a full screen stimulus for 1 (or 2) frame followed by a full screen noise mask for 2 (or 4) frames. When I check the vbl timestamp, it cannot flip faster than 0.0417sec i.e. 5 frames. The VBLsynctest is ok, but when I run the CheckFrameTiming script with a large [1080 1080] window, I see as well that it does not refresh at each frame. Thinking about it, the issue is probably more related to Matlab function execution time course, and not to the gpu process.
I ran the function with the profiler on and the pb seems to come from the Screen('flip') function that can be quite "slow" to get executed: for 60 trials it takes 0.56sec so 0.0093sec on average which is already more than a frame. is the flip execution supposed to be that slow for very large stimuli with a C48 mode? With the normal mode I can easily display only 1 frame without any error or delays.

Then, I should probably up to a point stop trying to display full screen stimuli with the C48 mode and go back to a normal mode. I already ran a bunch of expe with large pictures and a calibration specific to this mode so I am trying to not change that, but I will if needed.
Not completely related, but are matlab functions better optimized for linux, windows or mac os, or it really does not matter???

best

Romain Bachy

---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :





---In PSYCHTOOLBOX@yahoogroups.com, <mario.kleiner@...> wrote :

XX---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :

Hi Mario,
I re installed everything from scratch and I can use and update xorgCreator/ BitsPlusImagingPipelinetest and so on without launching pt3-matlab with sudo now. However, still the same issue with -nojvm. I am
investing in a new video card (a Radeon RX) so it will eventually solve the issue. I might try as well to install Matlab 2013b to check what happens with the last old graphic matlab system.

-> Good for the sudo thing. The -nojvm thing is puzzling. I don't think swapping the graphics card would do anything about that at all, and your current card seems to work well enough for the task, so probably no point in upgrading that systems gpu. Trying a different Matlab version may be more fruitful.

---> ok, but I cannot resist to try at least a more recent radeon gpu, it is a perfect excuse to upgrade :-)

-> You could try running ...
sudo dpkg-reconfigure matlab-support
and make sure to yes to questions about renaming conflicting libraries, just to make sure this has really run at some point for your current Matlab installation.

---> ok I will do that.

-> All in all, -nojvm is not needed that often on a modern Linux system and modern hardware, it is an extra tweak one can try if one runs into timing problems, so maybe you can do without it. I don't quite understand your task about those "1 or 2 frames stimuli"? Is this something especially demanding or are you running into performance/timing problems?

---> This task is, I think, quite demanding. With the C48 mode activated, I try to display a full screen stimulus for 1 (or 2) frame followed by a full screen noise mask for 2 (or 4) frames. When I check the vbl timestamp, it cannot flip faster than 0.0417sec i.e. 5 frames. The VBLsynctest is ok, but when I run the CheckFrameTiming script with a large [1080 1080] window, I see as well that it does not refresh at each frame. Thinking about it, the issue is probably more related to Matlab function execution time course, and not to the gpu process. I should check how long it takes to the Screen('drawtextures') function to draw those large matrices with the profiler.
Then, I will probably up to a point stop trying to display full screen stimuli with the C48 mode and go back to a normal mode with smaller stim. I already ran a bunch of expe with large pictures and a calibration specific to this mode so I am trying to not change that, but I will if needed.
Not completely related, but are matlab functions better optimized for linux, windows or mac os, or it really does not matter???

Best

Romain

-mario


Thanks for everything you are doing for the community!

Best

Romain Bachy



6
Hi,
Thanks for your reply. I had forgotten this "detail", so I am back to my initial issue: everything is ok with the normal display mode but when the C48 mode is activated I cannot refresh faster than every 5 frames.

Best
7

Hi Mario,

quick feedback as everything works perfectly now thanks to you, lots of coffee, and google-ing!
With the RX480 on ubuntu 16.04 LTS I had to:
- Install the 4.8 kernel, so I am living on the edge right now.
- Install the PPA Padoka library (https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa). I had to force the upgrades that were kept back.
-Uninstall completely the amdgpu-pro package provided by amd.
-Change one of my HDMI cable since it was too old and the screen was then not detected once the video card driver was active (lost 8 hours on this one)
I can now run my stimuli as fast as I want (1 frame works perfectly), with 2 screens.

While I was doing all those tests I found a really useful terminal command that I share here:

/usr/lib/nux/unity_support_test -p

it returns so many useful info on the graphic card, the drivers used at the time and the function activated!!!

example

OpenGL vendor string:   X.Org
OpenGL renderer string: Gallium 0.4 on AMD POLARIS10 (DRM 3.3.0 / 4.8.0-34-lowlatency, LLVM 5.0.0)
OpenGL version string:  3.0 Mesa 17.1.0-devel - padoka PPA

Not software rendered:    yes
Not blacklisted:          yes
GLX fbconfig:             yes
GLX texture from pixmap:  yes
GL npot or rect textures: yes
GL vertex program:        yes
GL fragment program:      yes
GL vertex buffer object:  yes
GL framebuffer object:    yes
GL version is 1.4+:       yes

Unity 3D supported:       yes


Thanks again

Romain Bachy
 

---In PSYCHTOOLBOX@yahoogroups.com, <mario.kleiner@...> wrote :




XX---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :

Thanks,
I tried to updgrade the video card with one of those new radeon RX400 series and:
# The bitsplusplusCLuttest fails partially on windows 7, it displays for few seconds the right patterns then it slows down or freezes.

-> Read the help texts of BitsPlusClutIdentityTest. On Windows we don't have the ability to automatically bypass gamma lut's, dithering etc. and other tricks as on Linux, so manual work/time and a bit of luck is needed to get a functional setup for Viewpixx and similar devices.

# The RX480 does not detect my second screen on ubuntu 16.04 so it is not a good start...

-> RX480 was released multiple months after Ubuntu 16.04.0, so hardware support for it is missing in 16.04.0/1's Linux 4.4 kernel. It falls back to a very basic vesa driver with one display and no graphics hardware acceleration at all.

-> The Linux 4.8 kernel will support that card and will be part of the Ubuntu 16.04.2 LTS release at ETA 9th february. "sudo apt install linux-lowlatency-16.04-hwe" to get it once its there. This will always keep the system updated to the latest fully QA tested kernel and hardware support.

If you wanted that driver support today, but then live on the bleeding edge, you could execute "sudo apt install linux-lowlatency-16.04-hwe-edge" with all the good or bad consequences. This will keep the system on the latest official Ubuntu kernel, up to 6 months before "normal" users get it, without up to 6 month of additional quality testing and debugging obviously...

I will put back the old video card and try the benchmark in AdditiveBlendingForLinearSuperpositionTutorial

-mario


best

---In psychtoolbox@yahoogroups.com, <mario.kleiner@...> wrote :

Looking at CheckFrameTiming, it is likely mostly the execution time of Matlab randn() function causing 5 frame delays. That takes a lot of cpu time and goes with the square of the size. I don't know if that function can take advantage of multi-core cpu's, some recent Matlab versions functions can, some can't. I wouldn't expect huge differences between the same Matlab version on different OS'es for typical basic functions, but haven't measured that in years. Maybe the internet knows.

Texture upload of those large random noise textures would also take quite a bit of time and MakeTextureTimingTest2 allows to benchmark different modes of doing that. Some are more efficient for some cases than others.

In the end i'd suggest precomputing a few dozen noise textures, so they don't need to get generated/uploaded during a trial. We also have ProceduralNoiseDemo for generating Perlin noise procedurally on the gpu, but Perlin noise is not quite the same as, e.g., gaussian noise, and the implemented algorithm is very sensitive to implementation details of given gpu's and drivers, so often the results are not good and random enough on many systems for many applications.

If you run AdditiveBlendingForLinearSuperpositionTutorial it has a benchmark mode to test how fast your gpu can go in C48 mode if it does nothing but display a high resolution gray background, so that gives you an idea if the current gpu is in principle fast enough for 120 fps or not. My feeling is that either use of the proprietary NVidia driver, or a bit of performance tuning under nouveau might make it fast enough if it isn't already.

I doubt that -nojvm or not would play any significant role in what you describe.
-mario

XX---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :


Dear Mario,

I reconfigured the matlab-support without success regarding the -nojvm. I checked if the lib had been renamed in the sys folder and it is the case, so mystery unsolved yet, but it is probably not a big deal since it works fine otherwise. I haven't tried yet with matlab 2013b.

This task is, I think, quite demanding. With the C48 mode activated, I try to display a full screen stimulus for 1 (or 2) frame followed by a full screen noise mask for 2 (or 4) frames. When I check the vbl timestamp, it cannot flip faster than 0.0417sec i.e. 5 frames. The VBLsynctest is ok, but when I run the CheckFrameTiming script with a large [1080 1080] window, I see as well that it does not refresh at each frame. Thinking about it, the issue is probably more related to Matlab function execution time course, and not to the gpu process.
I ran the function with the profiler on and the pb seems to come from the Screen('flip') function that can be quite "slow" to get executed: for 60 trials it takes 0.56sec so 0.0093sec on average which is already more than a frame. is the flip execution supposed to be that slow for very large stimuli with a C48 mode? With the normal mode I can easily display only 1 frame without any error or delays.

Then, I should probably up to a point stop trying to display full screen stimuli with the C48 mode and go back to a normal mode. I already ran a bunch of expe with large pictures and a calibration specific to this mode so I am trying to not change that, but I will if needed.
Not completely related, but are matlab functions better optimized for linux, windows or mac os, or it really does not matter???

best

Romain Bachy

---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :




---In PSYCHTOOLBOX@yahoogroups.com, <mario.kleiner@...> wrote :

XX---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :

Hi Mario,
I re installed everything from scratch and I can use and update xorgCreator/BitsPlusImagingPipelinetest and so on without launching pt3-matlab with sudo now. However, still the same issue with -nojvm. I am
investing in a new video card (a Radeon RX) so it will eventually solve the issue. I might try as well to install Matlab 2013b to check what happens with the last old graphic matlab system.

-> Good for the sudo thing. The -nojvm thing is puzzling. I don't think swapping the graphics card would do anything about that at all, and your current card seems to work well enough for the task, so probably no point in upgrading that systems gpu. Trying a different Matlab version may be more fruitful.

---> ok, but I cannot resist to try at least a more recent radeon gpu, it is a perfect excuse to upgrade :-)

-> You could try running ...
sudo dpkg-reconfigure matlab-support
and make sure to yes to questions about renaming conflicting libraries, just to make sure this has really run at some point for your current Matlab installation.

---> ok I will do that.

-> All in all, -nojvm is not needed that often on a modern Linux system and modern hardware, it is an extra tweak one can try if one runs into timing problems, so maybe you can do without it. I don't quite understand your task about those "1 or 2 frames stimuli"? Is this something especially demanding or are you running into performance/timing problems?

---> This task is, I think, quite demanding. With the C48 mode activated, I try to display a full screen stimulus for 1 (or 2) frame followed by a full screen noise mask for 2 (or 4) frames. When I check the vbl timestamp, it cannot flip faster than 0.0417sec i.e. 5 frames. The VBLsynctest is ok, but when I run the CheckFrameTiming script with a large [1080 1080] window, I see as well that it does not refresh at each frame. Thinking about it, the issue is probably more related to Matlab function execution time course, and not to the gpu process. I should check how long it takes to the Screen('drawtextures') function to draw those large matrices with the profiler.
Then, I will probably up to a point stop trying to display full screen stimuli with the C48 mode and go back to a normal mode with smaller stim. I already ran a bunch of expe with large pictures and a calibration specific to this mode so I am trying to not change that, but I will if needed.
Not completely related, but are matlab functions better optimized for linux, windows or mac os, or it really does not matter???

Best

Romain

-mario


Thanks for everything you are doing for the community!

Best

Romain Bachy
 
 
 
 
8
XX---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :
Hi Mario,

quick feedback as everything works perfectly now thanks to you, lots of coffee, and google-ing!

-> Cool.

With the RX480 on ubuntu 16.04 LTS I had to:
- Install the 4.8 kernel, so I am living on the edge right now.
- Install the PPA Padoka library (https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa). I had to force the upgrades that were kept back.

-> Yeah the Padoka PPA with up to date Mesa OpenGL drivers. Forgot you'd need that as well. However, i would get rid of that again, once Ubuntu 16.04.2 LTS ships with a sufficiently modern stable Mesa version. Padoka is truly bleeding edge, always installing the latest alpha quality prototype code that has seen almost zero testing, only passed code peer review.

-> Just for anybody else reading this in the future: The above steps won't be neccessary if one installs/upgrades to Ubuntu 16.04.2 LTS, once it has been released at eta 9th february 2017:
https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule

-> The procedure of kernel upgrades to well tested or beta quality (edge) kernels is described in detail here:

https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack

-Uninstall completely the amdgpu-pro package provided by amd.

-> How did that get installed in the first place? Currently not recommended, as it has known bugs wrt. visual stimulation timing and the kind of gamma table control we need for VPixx or CRS high precision display devices.

-Change one of my HDMI cable since it was too old and the screen was then not detected once the video card driver was active (lost 8 hours on this one)
I can now run my stimuli as fast as I want (1 frame works perfectly), with 2 screens.

-> I would recommend running the following additional correctness tests, given that this card is so far untested and a Datapixx/Viewpixx/Propixx is exactly what you need to give it a good run, e.g., FlipTimingWithRTBoxPhotoDiodeTest, HighColorPrecisionDrawingTest, DriftTexturePrecisionTest. I don't expect any trouble with your card, but it is nice to have actual test results, and easy to do with your setup, so we can recommend that card for performance hungry applications. So far the most modern AMD card i could test myself extensively was a Radeon R9 380 Tonga, a top model from the year before.

-> My condolence, hardware failures like that are no fun to resolve. Especially with HDMI and DisplayPort, low quality or broken cables can cause a lot of weird trouble that is hard to diagnose.

While I was doing all those tests I found a really useful terminal command that I share here:

/usr/lib/nux/unity_support_test -p

it returns so many useful info on the graphic card, the drivers used at the time and the function activated!!!

-> There's even a better one which i only discovered by accident a few days ago: inxi

It shows tons of information about all kind of system properties, depending on what command line switches one specifies, e.g., inxi -G for the graphics system.

-mario

example

OpenGL vendor string:   X.Org
OpenGL renderer string: Gallium 0.4 on AMD POLARIS10 (DRM 3.3.0 / 4.8.0-34-lowlatency, LLVM 5.0.0)
OpenGL version string:  3.0 Mesa 17.1.0-devel - padoka PPA

Not software rendered:    yes
Not blacklisted:          yes
GLX fbconfig:             yes
GLX texture from pixmap:  yes
GL npot or rect textures: yes
GL vertex program:        yes
GL fragment program:      yes
GL vertex buffer object:  yes
GL framebuffer object:    yes
GL version is 1.4+:       yes

Unity 3D supported:       yes


Thanks again

Romain Bachy
 

---In PSYCHTOOLBOX@yahoogroups.com, <mario.kleiner@...> wrote :




XX---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :

Thanks,
I tried to updgrade the video card with one of those new radeon RX400 series and:
# The bitsplusplusCLuttest fails partially on windows 7, it displays for few seconds the right patterns then it slows down or freezes.

-> Read the help texts of BitsPlusClutIdentityTest. On Windows we don't have the ability to automatically bypass gamma lut's, dithering etc. and other tricks as on Linux, so manual work/time and a bit of luck is needed to get a functional setup for Viewpixx and similar devices.

# The RX480 does not detect my second screen on ubuntu 16.04 so it is not a good start...

-> RX480 was released multiple months after Ubuntu 16.04.0, so hardware support for it is missing in 16.04.0/1's Linux 4.4 kernel. It falls back to a very basic vesa driver with one display and no graphics hardware acceleration at all.

-> The Linux 4.8 kernel will support that card and will be part of the Ubuntu 16.04.2 LTS release at ETA 9th february. "sudo apt install linux-lowlatency-16.04-hwe" to get it once its there. This will always keep the system updated to the latest fully QA tested kernel and hardware support.

If you wanted that driver support today, but then live on the bleeding edge, you could execute "sudo apt install linux-lowlatency-16.04-hwe-edge" with all the good or bad consequences. This will keep the system on the latest official Ubuntu kernel, up to 6 months before "normal" users get it, without up to 6 month of additional quality testing and debugging obviously...

I will put back the old video card and try the benchmark in AdditiveBlendingForLinearSuperpositionTutorial

-mario


best

---In psychtoolbox@yahoogroups.com, <mario.kleiner@...> wrote :

Looking at CheckFrameTiming, it is likely mostly the execution time of Matlab randn() function causing 5 frame delays. That takes a lot of cpu time and goes with the square of the size. I don't know if that function can take advantage of multi-core cpu's, some recent Matlab versions functions can, some can't. I wouldn't expect huge differences between the same Matlab version on different OS'es for typical basic functions, but haven't measured that in years. Maybe the internet knows.

Texture upload of those large random noise textures would also take quite a bit of time and MakeTextureTimingTest2 allows to benchmark different modes of doing that. Some are more efficient for some cases than others.

In the end i'd suggest precomputing a few dozen noise textures, so they don't need to get generated/uploaded during a trial. We also have ProceduralNoiseDemo for generating Perlin noise procedurally on the gpu, but Perlin noise is not quite the same as, e.g., gaussian noise, and the implemented algorithm is very sensitive to implementation details of given gpu's and drivers, so often the results are not good and random enough on many systems for many applications.

If you run AdditiveBlendingForLinearSuperpositionTutorial it has a benchmark mode to test how fast your gpu can go in C48 mode if it does nothing but display a high resolution gray background, so that gives you an idea if the current gpu is in principle fast enough for 120 fps or not. My feeling is that either use of the proprietary NVidia driver, or a bit of performance tuning under nouveau might make it fast enough if it isn't already.

I doubt that -nojvm or not would play any significant role in what you describe.
-mario

XX---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :


Dear Mario,

I reconfigured the matlab-support without success regarding the -nojvm. I checked if the lib had been renamed in the sys folder and it is the case, so mystery unsolved yet, but it is probably not a big deal since it works fine otherwise. I haven't tried yet with matlab 2013b.

This task is, I think, quite demanding. With the C48 mode activated, I try to display a full screen stimulus for 1 (or 2) frame followed by a full screen noise mask for 2 (or 4) frames. When I check the vbl timestamp, it cannot flip faster than 0.0417sec i.e. 5 frames. The VBLsynctest is ok, but when I run the CheckFrameTiming script with a large [1080 1080] window, I see as well that it does not refresh at each frame. Thinking about it, the issue is probably more related to Matlab function execution time course, and not to the gpu process.
I ran the function with the profiler on and the pb seems to come from the Screen('flip') function that can be quite "slow" to get executed: for 60 trials it takes 0.56sec so 0.0093sec on average which is already more than a frame. is the flip execution supposed to be that slow for very large stimuli with a C48 mode? With the normal mode I can easily display only 1 frame without any error or delays.

Then, I should probably up to a point stop trying to display full screen stimuli with the C48 mode and go back to a normal mode. I already ran a bunch of expe with large pictures and a calibration specific to this mode so I am trying to not change that, but I will if needed.
Not completely related, but are matlab functions better optimized for linux, windows or mac os, or it really does not matter???

best

Romain Bachy

---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :




---In PSYCHTOOLBOX@yahoogroups.com, <mario.kleiner@...> wrote :

XX---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :

Hi Mario,
I re installed everything from scratch and I can use and update xorgCreator/BitsPlusImagingPipelinetest and so on without launching pt3-matlab with sudo now. However, still the same issue with -nojvm. I am
investing in a new video card (a Radeon RX) so it will eventually solve the issue. I might try as well to install Matlab 2013b to check what happens with the last old graphic matlab system.

-> Good for the sudo thing. The -nojvm thing is puzzling. I don't think swapping the graphics card would do anything about that at all, and your current card seems to work well enough for the task, so probably no point in upgrading that systems gpu. Trying a different Matlab version may be more fruitful.

---> ok, but I cannot resist to try at least a more recent radeon gpu, it is a perfect excuse to upgrade :-)

-> You could try running ...
sudo dpkg-reconfigure matlab-support
and make sure to yes to questions about renaming conflicting libraries, just to make sure this has really run at some point for your current Matlab installation.

---> ok I will do that.

-> All in all, -nojvm is not needed that often on a modern Linux system and modern hardware, it is an extra tweak one can try if one runs into timing problems, so maybe you can do without it. I don't quite understand your task about those "1 or 2 frames stimuli"? Is this something especially demanding or are you running into performance/timing problems?

---> This task is, I think, quite demanding. With the C48 mode activated, I try to display a full screen stimulus for 1 (or 2) frame followed by a full screen noise mask for 2 (or 4) frames. When I check the vbl timestamp, it cannot flip faster than 0.0417sec i.e. 5 frames. The VBLsynctest is ok, but when I run the CheckFrameTiming script with a large [1080 1080] window, I see as well that it does not refresh at each frame. Thinking about it, the issue is probably more related to Matlab function execution time course, and not to the gpu process. I should check how long it takes to the Screen('drawtextures') function to draw those large matrices with the profiler.
Then, I will probably up to a point stop trying to display full screen stimuli with the C48 mode and go back to a normal mode with smaller stim. I already ran a bunch of expe with large pictures and a calibration specific to this mode so I am trying to not change that, but I will if needed.
Not completely related, but are matlab functions better optimized for linux, windows or mac os, or it really does not matter???

Best

Romain

-mario


Thanks for everything you are doing for the community!

Best

Romain Bachy
 
 
 
 
9
XX--In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :

I confess I am responsible of the amdgpu-pro package installation. I tried at first with that when I was struggling with the 4.4 kernel.

-> Ah ok.

I will run those tests:
should I try with dual and single screen configuration?

-> Dual screen is enough, essentially how you use the system.

Do I wait for the more official 16.04.2?

-> Makes probably sense, so i/people know how it behaves out of the box. Once 16.04.2 is released, you won't need that padoka ppa anymore (See ppa-purge instructions on the ppa's website on how to uninstall it properly), and i'd switch to the linux-lowlatency-16.04-hwe kernel instead of the *-edge one, as that should be sufficient for your hardware and keeps you on something well tested instead of too new stuff.

Do I send the results through this channel?

Yes, that's fine. Most of it is just text output to Matlab ("diary on"), the timing tests also create plots, although most of the plots are not needed if the textual summary signals success, as i would expect.

thanks,
-mario

10
ok, I tried quickly anyway with the actual packages to see how to run that on the d-day. The only troubles I faced so far are that I could not load the octave fliptimingdefaultconfig.mat, so I re saved it from octave, then I do not know what I am supposed to answer regarding the secondary gpu and the number of rectangles for max GPU load. Results look nice but I prefer to wait for the stable set-up to share them. Stay tuned!

best
 
11

Thank you so much for the feedback:
The amd limitation makes sense to me since I have this error message when I try to use a 16bits CLUT in my workflow:
"Error using PsychColorCorrection (line 1319)
SetLookupTable: Tried to assign a clut with 65536 slots. This is more than your graphics hardware
can handle! [Maximum is 16384 slots]."
So the maximum is indeed " officially 14bits/channel

I ran again the flipTiming test and I end more or less with the same number of missed flips for 1000 rectangles (20 misses out of 10000) and the number increases for 10000 rectangles which makes sense I believe (250 misses out of 10000), I will check the radeon dpm options, but truth is that everything looks perfectly fine when I check my timestamps in my experiment.

Thanks again for everything!

Romain

---In psychtoolbox@yahoogroups.com, <mario.kleiner@...> wrote :

XX---In PSYCHTOOLBOX@yahoogroups.com, <mannow1@...> wrote :

Dear Mario,

I ran the tests with the 16.04.2 configuration:

CPU~Quad core Intel Core i7 960 (-HT-MCP-) speed/max~1600/3200 MHz Kernel~4.8.0-36-lowlatency x86_64 Up~1:09 Mem~1559.0/12005.4MB HDD~500.1GB(46.4% used) Procs~297 Client~Shell inxi~2.2.35

OpenGL vendor string:   X.Org
OpenGL renderer string: Gallium 0.4 on AMD POLARIS10 (DRM 3.3.0 / 4.8.0-36-lowlatency, LLVM 3.8.0)
OpenGL version string:  3.0 Mesa 12.0.6

Not software rendered:    yes
Not blacklisted:          yes
GLX fbconfig:             yes
GLX texture from pixmap:  yes
GL npot or rect textures: yes
GL vertex program:        yes
GL fragment program:      yes
GL vertex buffer object:  yes
GL framebuffer object:    yes
GL version is 1.4+:       yes

Unity 3D supported:       yes

I attach 2 files with the results.

-> Thanks. Btw. i think 16.04.2 LTS wasn't out when you tested, as it was delayed again until Friday or potentially coming Mondey. But the software you have already is essentially identical to what will be shipping: Linux 4.8 and Mesa 12.0.6.

I have actually few questions related to those tests:

-- I had never realized I could have real feedback from my viewpixx, shame on me to not read more carefully datasheets and user manuals... does it mean that I could have better estimation of my display time thanks to those kind of functions (found in FlipTimingWithRTBoxPhotoDiodeTest )?:
PsychDataPixx('BoxsecsToGetsecs', res.measuredTime)
or are the [vbl, xx, yy] output from Screen('flip')  equivalent?

-> The short answer would be they are equivalent, so use of Flip timestamps is usually more simple with no loss of precision or reliability, and a potential performance gain if you have demanding experiment scripts.

-> The PsychDatapixx functions can be used to give a second independent opinion on stimulus onset timestamps. It's useful to verify that your PTB + OS + graphics-driver/graphics-card combo delivers trustworthy and precise visual stimulus onset timestamps. So its good to run that test script once after modifying the OS+graphics hardware as an extra check if timing matters and you have a VPixx device. In practice, for all NVidia, AMD and Intel graphics cards i ever tested in the last > 8 years, there was never any meaningful discrepancy between the VPixx devices measurements and what PTB's Screen('Flip') command reports. At least if the setup is properly setup, PTB doesn't complain about any timing/timestamping problems and you are using Linux. The Linux mechanisms get regularly tested, so that PTB either just works reliably or very likely warns you if something is amiss. I wouldn't dare to give any guarantees for current MacOS or Windows operating systems, as there exist failure modes caused by MS-Windows limitations or macOS bugs that PTB can't reliably detect anymore in all cases. Windows, and macOS with the kernel driver installed on supported hardware, can be as accurate if everything works correctly, but problems often can't be reliably detected anymore.

-> The Viewpixx timestamping, or photo-diodes and similar methods of verification are also not fool-proof against certain graphics driver and hardware bugs. So if both timestamps agree closely and our various tests pass, then your setup is likely fine. If there is disagreement/failure it can be either trouble in PTBs software timestamping, or OS/graphics driver/hardware bugs.

-> If everything is fine then the timestamps are practically equivalent, within ~ 0.1 msecs on your setup, typically even better. In that sense our Flip timestamps are preferrable, as you don't need extra code complexity, accuracy problems due to clock drift between the Vpixx device and the host computers clock are avoided, and you save about 1-2.5 msecs of extra processing latency for each Flip -- the time it takes for the VPixx device to transmit measured timestamps back to the computer via USB.

-> So my approach in practice if you have such a device would be "trust but verify": Use our scripts or self written scipts to verify your experimental setup with the help of those functions, e.g., after set up your experiment setup, so you know you can trust PTB's timestamping, and then simply go with PTB's timestamps for simplicity. Of course the devices have various other functions for digital/analog i/o or response boxes which may come handy for synchronizing multi-modal stimuli, and if you use those anyway, it could make sense to go completely with all the timestamping provided by the VPixx device, instead of with PTB's timestamping. It depends, adjust your level of paranoia accordingly.

-> You should also have a careful look at how the scanning backlight works and can be enabled or disabled, if you haven't already. This can matter a lot for blur reduction/visual onset timing, depending on the type of stimuli you want to present, and how important very precise visual timing is for you.

-- What are the heavy load GPU and rectangles number options for?

The test draws up to that many randomly placed and sized rectangles onto the screen (before overdrawing them with all white or black), depending on the selected test profile, to generate some realistic gpu load as it would happen when drawing some visual stimuli. I usually use 1000 rectangles, to create some at least moderate load. But it doesn't matter for just testing correctness of flip scheduling and timestamp reliability/accuracy. The "heavy GPU load" is just an answer that gets logged for analysis. I answered yes when i ran some other graphics intense application on another X-Screen to see how it copes with some "distractor" gpu load. The FlipTimingTest... script is what i used to benchmark/test the visual onset timing/timestamping under various loads and conditions on different operating systems/versions and graphics cards, to see how the different operating systems and drivers generally perform, and how to tune for better performance. The different profiles correspond to different conditions. In the PsychDocumentation subfolder there is the ECVP2010 poster pdf with the results of those tests on different setups, and with various recommendations for improved visual timing precision/reliability. FlipTimingTest... was used for data collection, the AnalyzeTiming... script for analyzing the data.

Nowadays i only use the script for regular reliability/precision testing under some stress. E.g., i run it for every major Linux release or whenever PTB's timing algorithms get tweaked/modified on a set of graphics cards i have at hand, to make sure no bugs or regressions get introduced somewhere. I use a Datapixx to get ground truth data to compare to.

-- Also any feedback related to the results would be much appreciated. It looks good to me but it is still a bit fuzzy.

--> Results look ok. Notable:

a) HighColorPrecisionDrawingTest shows a limitation that many AMD gpu's seem to have lately on all operating systems, to differing degree depending on OS type, OS version and gfx-driver version: When Screen('DrawTexture') is used with high precision floating point textures at default settings, and therefore bilinear texture filtering enabled then high bit precision suffers quite a bit. It can't draw at full >= 16 bpc color precision, but precision goes down to 15 bpc or even 14 bpc. With the 'modulateColor' parameter it can degrade to 8 bpc. So one can either use that special ConserveVRAM setting kPsychAssumeGfxCapVCGood to work around it and get at least 14 bpc consistently, or if one doesn't need to resize textures or scroll them smoothly, one can use nearest neighbour filtering to get full 23 bpc precision. That only matters for very high precision displays though, probably only if one would use a Datapixx device + CRT, whose output precision exceeds 14 bpc.

"2D drawing test: DrawTexture : Mindiff.: 0.00000000000000000, Maxdiff.: 0.00001519965007901 --> Accurate to 15 bits out of max tested bitdepths 16.  --> PROBLEMATIC!
2D drawing test: GammaCorrection : Mindiff.: 0.00000000000000000, Maxdiff.: 0.00000011920928955 --> Accurate to full tested bitdepth range of 16 bits.   --> GOOD!
DrawTexture-modulateColor : Maxdiff.: 0.00195309531409293 --> Accurate to at least 8 bits.
DrawTexture-modulateColor&Blend1+1 : Maxdiff.: 0.00390619062818587 --> Accurate to at least 7 bits with 2 overdraws.
"
If one wants to draw/display very high color/luminance precision stimuli, or very low contrast stimuli ie. > standard 8 bpc, one should always run HighColorPrecisionDrawingTest and read its output and recommendations carefully.

b) There's a difference of pretty much constant 0.1 msecs between stimulus onset timestamps reported by 'Flip' and by the Viewpixx, in that Flip's are ~ 100 usecs too early. Usually both timestamps agree to better than 40 usecs on average. Maybe the new DCE 11 display engine in the latest Polaris gpu's has a bit more output latency unaccounted by the current time-stamping code. Given it's a fixed offset one could just add 0.1 msecs to reported Flip timestamps though, assuming anybody cares about such a small fixed offset at all. Otherwise timing looks excellent, microsecond accurate.

c) The number of missed flips is with 20 out of 5000 a bit higher than what i'd like to see. Usually we have 0 or close to zero missed flips on Linux. In your test run, skipped frames only happened when flipping every 2nd video refresh cycle was requested, hinting at some interaction with gpu dynamic power management. However, this is highly application specific, so might not happen with a larger number of test 'rectangles' to draw, e.g., the value of 1000 i usually use for that test, or with other stimuli of yours. Also one can tweak power management settings if it affects a real use case.

best,
-mario

best

Romain