equipment/soft for 240Hz refresh rate

Hi Mario,

>=> A bit more than that. Upgrading the Linux kernel to the
very latest stable kernel, >to see if the problem has been fixed sometime during the ~10 months of development >since your Linux 4.4 kernel and the latest stable Linux kernel 4.9, just released 2 >weeks ago.
I tried 4.9, as you suggested, but there was no improvement. It seems very unlikely that 4.10 will resolve the problem either.

Since our stimuli are presented in the middle of the screen I am not interested in periphery, unless it affects the center. Can we be sure that the central part is not affected by the imperfections in the 1/5 right side of the screen? Otherwise we will go for suboptimal 144 Hz.

Elena







On 22 December 2016 at 17:12, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

XXX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Hi Mario,

...

The trembling occurs irrespective of blue or normal screen. When i do 'xrands -r 240 ' thr trembling is there. I attached a photo. (Note that you can't read the text on the left side - my right).


=> Ok, thanks. That photo looks different from what i would have expected. Maybe because it's a photo and not a movie, so one doesn't see the trembling. Or maybe because my suspicion about the cause of the trembling is wrong, and something else goes wrong with signal transmission. Seems to be more the rightmost 1/5th of the display? Why ist the photo left-right flipped?

I removed the empty spaces, and I have not had any error while running the commands.

cat /sys/class/drm/card0/device/ power_dpm_state

performance

>and
>cat /sys/class/drm/card0/device/ power_dpm_force_performance_ level
auto

=> Looks correct.

the full output of the command dmesg would be interesting to see if the driver reports back any errors during >switching of video refresh rate to 60 Hz and back to 240 Hz:
sudo su
>echo 4 > /sys/module/drm/parameters/ debug
>xrandr -r 60
>xrandr -r 240
>dmesg > dmesg_log.txt
>Creates a text file dmesg_log.txt with that output in the current directory.
I performed these operations and attached the dmesg_log.txt file

=> Thanks. Doesn't show anything suspicious, but captures useful debug info.

Another thing you could try is upgrading to the latest version of the Linux kernel, in the hope that the 240 Hz problem >doesn't exist in the latest drivers anymore, if you are interested in that?
Do you meen upgrating to another Ubuntu version?
I've already done : sudo apt-get dist-upgrade

=> A bit more than that. Upgrading the Linux kernel to the very latest stable kernel, to see if the problem has been fixed sometime during the ~10 months of development since your Linux 4.4 kernel and the latest stable Linux kernel 4.9, just released 2 weeks ago.

You would download the following files by clicking on the links:

http://kernel.ubuntu.com/~ kernel-ppa/mainline/v4.9/ linux-headers-4.9.0-040900_4. 9.0-040900.201612111631_all. deb

http://kernel.ubuntu.com/~ kernel-ppa/mainline/v4.9/ linux-headers-4.9.0-040900- lowlatency_4.9.0-040900. 201612111631_amd64.deb

http://kernel.ubuntu.com/~ kernel-ppa/mainline/v4.9/ linux-image-4.9.0-040900- lowlatency_4.9.0-040900. 201612111631_amd64.deb

Then in a terminal go into the Downloads folder, probably

cd ~/Downloads

Then install the files:

sudo dpkg -i linux-headers* linux-image*
And after that finished, reboot. That would boot into this new Linux 4.9 kernel by default, and then you can see if a 1920x1080 240 Hz refresh works better. This also installs a low-latency kernel for potentially better realtime behaviour. The boot loader menu at system power up/restart allows selection between all installed kernels.

If that wouldn't work, we could go to an even newer kernel, which at this point is just a prototype for the in-development Linux 4.10 kernel. If that wouldn't fix it, i could contact my people at AMD to see if they have an idea, although that would take time given imminent christmas/new year vacation time.


>->
Another thing you could try is keeping the 240 Hz refresh rate, but reduce the display resolution to >1280x1024 if that is sufficient for your purpose, as according to one of your previous posts, that video >resolution also supports 240 Hz and maybe the driver handles that better?

Yes, indeed, there is no trembling any more with these settings. Possibly, I can use this screen size.

=> If you run PerceptualVBLSyncTest with these settings, you should get again very homogeneous black-white flicker - or actually just some solid grey, given that at 240 Hz switching rate there shouldn't be any perceptible black-white transitions anymore. That would be a cue that the monitor can handle 240 Hz also properly at other resolutions than its native 1920x1080 resolution without introducing timing or visual artifacts.

-mario


Thanks!
Elena

On 22 December 2016 at 07:57, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Hi Mario,
just to update,...
after
CTRL + F1 and rebooting I have now a normal ubuntu display. So, no worries.

-> Ok, good. However, i wonder how stable that is, and if it can't come back under certain conditions? The trembling you describe and that "blue screen" are likely related. It could be that on average load on the memory you get trembling, but if there is some spike in memory bandwidth demand, the display controller doesn't get enough date for even the leftmost 3/4 of the display and malfunctions harder and that causes that "blue screen". It's quite unclear to me how these things look. Could you create some photos or a short video of it somewhere?

My suspicion why you got that after a reboot would be that the desktop GUI remembered that you prefer the display running at 240 Hz, ie. it stored that setting in a configuration file. Then during login, the desktop GUI switched the display from the default mode of 60 Hz back to 240 Hz.

If this happens again, and you can't easily recover from it, one way to recover is to press CTRL+ALT+F1 for a text console (sorry, i gave you the wrong key combo, it is not CTRL+F1 but CTRL+ALT+F1), login at the text console, and then type:

rm ~/.config/monitors.xml

to delete the file with the display default video settings. Then go back to the GUI with CTRL+ALT+F7 and login normally. That should start the desktop GUI at a safe default video mode for your display of 60 Hz instead of 240 Hz, after the GUI has forgotten your preferred setting.


However,
echo performance > /sys/class/drm/card0/device/ power_dpm_state
echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level
commands have not had any positive effect on the 240 Hz display. I still have the same trembling/smearing on 1/4th part if the screen.

-> What confuses me here in your post is that single blank space between /sys/class/drm/card0/device/ and the power_dpm_state and power_dpm_force_performance_ level? Is this a copy & paste / formatting error or did you really have a blank space there? In that case the commands would have failed and done nothing except maybe print some error message?

If you apply above commands, what is the output of:

cat
/sys/class/drm/card0/device/ power_dpm_state

and

cat
/sys/class/drm/card0/device/ power_dpm_force_performance_ level


Also the full output of the command dmesg would be interesting to see if the driver reports back any errors during switching of video refresh rate to 60 Hz and back to 240 Hz:

echo 4 > /sys/module/drm/parameters/ debug
xrandr -r 60
xrandr -r 240
dmesg > dmesg_log.txt

Creates a text file dmesg_log.txt with that output in the current directory.


At the same time, PTB does not complain and when I run P
erceptualVBLSyncTest, the yellow lines are concentrated on the top of the screen.

-> Apart from that smeared right 1/4 of your screen, the output of PTB you posted and the figures look perfect. Everything else seems to work optimally and at least our VBLSyncTest apparently works without dropping any frames at 240 Hz. So if that would work for your experiment script as well, you should be good. If not, there are various ways to tweak the script.

-> Another thing you could try is upgrading to the latest version of the Linux kernel, in the hope that the 240 Hz problem doesn't exist in the latest drivers anymore, if you are interested in that?

-> Another thing you could try is keeping the 240 Hz refresh rate, but reduce the display resolution to 1280x1024 if that is sufficient for your purpose, as according to one of your previous posts, that video resolution also supports 240 Hz and maybe the driver handles that better?

From within PTB scripts you can use SetResolution() to change resolution and refresh rate as long as only one display is connected, e.g.,

oldres = SetResolution (0, 1280, 1024, 240);

to set 1280x1024 at 240 Hz, and

SetResolution(0, oldres);

to restore the previous video settings.

-mario



Elena


*****************************
PerceptualVBLSyncTest

Press ENTER key to start the test. The test will stop after 10 seconds
or any keypress...


PTB-INFO: This is Psychtoolbox-3 for GNU/Linux X11, under Matlab 64-Bit (Version 3.0.12 - Build date: May 13 2016).
PTB-INFO: Support status on this operating system release: Linux 4.4.0-53-generic 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: Advanced Micro Devices, Inc. [AMD/ATI] - Tonga PRO [Radeon R9 285/380] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to Advanced Micro Devices, Inc. [AMD/ATI] Tonga PRO [Radeon R9 285/380] GPU with DCE-10.0 display engine [6 heads]. Beamposition timestamping enabled.


PTB-INFO: OpenGL-Renderer is X.Org :: Gallium 0.4 on AMD TONGA (DRM 3.1.0, LLVM 3.8.0) :: 3.0 Mesa 11.2.0
PTB-INFO: VBL startline = 1080 , VBL Endline = 1213
PTB-INFO: Measured monitor refresh interval from beamposition = 4.308817 ms [232.082245 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 = 4.308782 ms [232.084168 Hz]. (50 valid samples taken, stddev=0.003222 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 4.170855 ms [239.759003 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.
>>



On 21 December 2016 at 03:05, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

XX-In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


>1. sudo su
>2. Enter admin password.
>3. echo performance > /sys/class/drm/card0/device/ power_dpm_state

>If step 3 doesn't help, try this:

>4. echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level

>Any change?

I have done steps 1-3, relaunched the terminal window/matlab, but have not noticed any changes in the display.
Then I have done the step 4 and rebooted the computer.

-> So no improvement, and also not any error message in response to your commands?

After the reboot I had a strange pattern on the screen for 3 seconds and then an empty blue screen forever.
It seems that I spoiled something...

-> You can't have spoiled something, at least not with those commands. Those settings are not persistent over a reboot. They apply immediately and get reset to defaults when the machine restarts. When exactly did the screen turn blue? Did it make it to the login window and only turned blue then? Or already before? If you press CTRL + F1, do you get a proper text console? Does it happen on each reboot? What happens if you connect a different monitor?

-mario



Elena



On 20 December 2016 at 10:19, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Indeed, after removing the drivers i have now "X.Org :: Gallium 0.4 on AMD Tonga...'
message. PTB does not generate the errors any more. However, I now have another problem, that I have not had with the amdgpu-pro driver: the right side of the screen (about 1/4 of the screen) is a kind of smeared and trembles. It seems that the generic driver does not fully support 240Hz. On the other hand, I only use the central part of the screen for presentation and the trembling is not seen on the gray background. Is it still unsafe to use 240 Hz refresh mode in this situation?

-> Ok, so the timing and timestamping should be solid if PTB doesn't print any warnings or errors anymore, but that trembling/smear (photo/video would be interesting to judge how those artifacts look) is not nice at all of course. Probably the display controller doesn't get enough memory bandwidth for the fast 240 Hz and the line buffer fifos underflow.

-> Can you post the full output and possibly figures of a run of VBLSyncTest?

We can try to force the driver into choosing a higher performance level, using faster memory clocks, maybe that helps. Try this from a terminal and see if it helps:

1. sudo su
2. Enter admin password.
3. echo performance > /sys/class/drm/card0/device/ power_dpm_state

If step 3 doesn't help, try this:

4. echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level

Any change?

You should run VBLSyncTest, and PerceptualVBLSyncTest to see if they show expected results and if the systm is capable of presenting at 240 fps without dropping frames. Timing-wise it should be safe to use the system at 240 Hz even with the artifacts, if you are certain they don't extend into the display area where you actually show your stimuli. But lets see if we can fix this.

-mario

Elena

On 17 December 2016 at 07:27, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

Not sure what happened on your side, but the driver is not properly uninstalled or not uninstalled at all, otherwise it wouldn't say "OpenGL-Renderer is ATI Technologies Inc. :: AMD Radeon R9 200 Series ::" but something like "X.Org :: Gallium 0.4 on AMD Tonga" in that place. That's also the reason for those error messages. Other than that you managed at least to switch the display to 240 Hz mode, so that's a good step forward.

Can your try again, checking the instructions for uninstallation carefully?
-mario






XX-In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :

Hi Mario,

>=>
If you run PerceptualVBLSyncTest with these settings, you should get again very homogeneous black-white flicker - >or actually just some solid grey, given that at 240 Hz switching rate there shouldn't be any perceptible black-white >transitions anymore. That would be a cue that the monitor can handle 240 Hz also properly at other resolutions than its >native 1920x1080 resolution without introducing timing or visual artifacts.
If I run PerceptualVBLSyncTest with these settings (1280x1024 x240) I get the error (below). And it does not help to run
PsychLinuxConfiguration(), as suggested. So, changing the resolution seem not to be an option.

-> Hi Elena,

a rather strange error in response to a video resolution change. If this happens with the upgraded kernels as well, could you post the output of the "dmesg" command again like before?

-mario




I will try to update the Linux kernel.

Thank you!
Elena

*********************************************
PTB-INFO: This is Psychtoolbox-3 for GNU/Linux X11, under Matlab 64-Bit (Version 3.0.12 - Build date: May 13 2016).
PTB-INFO: Support status on this operating system release: Linux 4.4.0-53-generic 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: Advanced Micro Devices, Inc. [AMD/ATI] - Tonga PRO [Radeon R9 285/380] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to Advanced Micro Devices, Inc. [AMD/ATI] Tonga PRO [Radeon R9 285/380] GPU with DCE-10.0 display engine [6 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.
PTB-WARNING: Most likely you are running Psychtoolbox on a Matlab version 8.4 (R2014b) or later and
PTB-WARNING: Matlab is causing this problem by overriding your operating systems OpenGL library with
PTB-WARNING: its own outdated software library. Please run the setup script PsychLinuxConfiguration()
PTB-WARNING: now from your Matlab command window and then quit and restart Matlab to fix this problem.

PTB-WARNING: Actually, it is pointless to continue with the software renderer, as that will cause more trouble than good.
PTB-WARNING: I will abort now. Read the troubleshooting tips above to fix the problem. You can override this if you add the following
PTB-WARNING: command: Screen('Preference', 'ConserveVRAM', 64); to get a functional, but close to useless window up and running.
****************************************************

>>

On 22 December 2016 at 17:12, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

XXX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Hi Mario,

...

The trembling occurs irrespective of blue or normal screen. When i do  'xrands -r 240 ' thr trembling is there. I attached a photo. (Note that you can't read the text on the left side - my right).


=> Ok, thanks. That photo looks different from what i would have expected. Maybe because it's a photo and not a movie, so one doesn't see the trembling. Or maybe because my suspicion about the cause of the trembling is wrong, and something else goes wrong with signal transmission. Seems to be more the rightmost 1/5th of the display? Why ist the photo left-right flipped?

I removed the empty spaces, and I have not had any error while running the commands.

cat /sys/class/drm/card0/device/ power_dpm_state

   performance

>and
>cat /sys/class/drm/card0/device/ power_dpm_force_performance_ level
   auto

=> Looks correct.

the full output of the command dmesg would be interesting to see if the driver reports back any errors during >switching of video refresh rate to 60 Hz and back to 240 Hz:
sudo su
>echo 4 > /sys/module/drm/parameters/ debug
>xrandr -r 60
>xrandr -r 240
>dmesg > dmesg_log.txt
>Creates a text file dmesg_log.txt with that output in the current directory.
 I performed these operations and attached the  dmesg_log.txt file

=> Thanks. Doesn't show anything suspicious, but captures useful debug info.

Another thing you could try is upgrading to the latest version of the Linux kernel, in the hope that the 240 Hz problem >doesn't exist in the latest drivers anymore, if you are interested in that?
Do you meen upgrating to another Ubuntu version?
I've already done :   sudo apt-get dist-upgrade

=> A bit more than that. Upgrading the Linux kernel to the very latest stable kernel, to see if the problem has been fixed sometime during the ~10 months of development since your Linux 4.4 kernel and the latest stable Linux kernel 4.9, just released 2 weeks ago.

You would download the following files by clicking on the links:

http://kernel.ubuntu.com/~ kernel-ppa/mainline/v4.9/ linux-headers-4.9.0-040900_4. 9.0-040900.201612111631_all. deb

http://kernel.ubuntu.com/~ kernel-ppa/mainline/v4.9/ linux-headers-4.9.0-040900- lowlatency_4.9.0-040900. 201612111631_amd64.deb

http://kernel.ubuntu.com/~ kernel-ppa/mainline/v4.9/ linux-image-4.9.0-040900- lowlatency_4.9.0-040900. 201612111631_amd64.deb

Then in a terminal go into the Downloads folder, probably

cd ~/Downloads

Then install the files:

sudo dpkg -i linux-headers* linux-image*
And after that finished, reboot. That would boot into this new Linux 4.9 kernel by default, and then you can see if a 1920x1080 240 Hz refresh works better. This also installs a low-latency kernel for potentially better realtime behaviour. The boot loader menu at system power up/restart allows selection between all installed kernels.

If that wouldn't work, we could go to an even newer kernel, which at this point is just a prototype for the in-development Linux 4.10 kernel. If that wouldn't fix it, i could contact my people at AMD to see if they have an idea, although that would take time given imminent christmas/new year vacation time.


>->
Another thing you could try is keeping the 240 Hz refresh rate, but reduce the display resolution to >1280x1024 if that is sufficient for your purpose, as according to one of your previous posts, that video >resolution also supports 240 Hz and maybe the driver handles that better?

Yes, indeed, there is no trembling any more with these settings. Possibly, I can use this screen size.

=> If you run PerceptualVBLSyncTest with these settings, you should get again very homogeneous black-white flicker - or actually just some solid grey, given that at 240 Hz switching rate there shouldn't be any perceptible black-white transitions anymore. That would be a cue that the monitor can handle 240 Hz also properly at other resolutions than its native 1920x1080 resolution without introducing timing or visual artifacts.

-mario


Thanks! 
Elena

On 22 December 2016 at 07:57, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Hi Mario,
 just to update,...
after
CTRL + F1 and rebooting I have now a normal ubuntu display. So, no worries.

-> Ok, good. However, i wonder how stable that is, and if it can't come back under certain conditions? The trembling you describe and that "blue screen" are likely related. It could be that on average load on the memory you get trembling, but if there is some spike in memory bandwidth demand, the display controller doesn't get enough date for even the leftmost 3/4 of the display and malfunctions harder and that causes that "blue screen". It's quite unclear to me how these things look. Could you create some photos or a short video of it somewhere?

My suspicion why you got that after a reboot would be that the desktop GUI remembered that you prefer the display running at 240 Hz, ie. it stored that setting in a configuration file. Then during login, the desktop GUI switched the display from the default mode of 60 Hz back to 240 Hz.

If this happens again, and you can't easily recover from it, one way to recover is to press CTRL+ALT+F1 for a text console (sorry, i gave you the wrong key combo, it is not CTRL+F1 but CTRL+ALT+F1), login at the text console, and then type:

rm ~/.config/monitors.xml

to delete the file with the display default video settings. Then go back to the GUI with CTRL+ALT+F7 and login normally. That should start the desktop GUI at a safe default video mode for your display of 60 Hz instead of 240 Hz, after the GUI has forgotten your preferred setting.


However,
echo performance > /sys/class/drm/card0/device/ power_dpm_state
echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level
commands have not had any positive effect on the 240 Hz display. I still have the same trembling/smearing on 1/4th part if the screen.

-> What confuses me here in your post is that single blank space between /sys/class/drm/card0/device/ and the power_dpm_state and power_dpm_force_performance_ level? Is this a copy & paste / formatting error or did you really have a blank space there? In that case the commands would have failed and done nothing except maybe print some error message?

If you apply above commands, what is the output of:

cat
/sys/class/drm/card0/device/ power_dpm_state

and

cat
/sys/class/drm/card0/device/ power_dpm_force_performance_ level


Also the full output of the command dmesg would be interesting to see if the driver reports back any errors during switching of video refresh rate to 60 Hz and back to 240 Hz:

echo 4 > /sys/module/drm/parameters/ debug
xrandr -r 60
xrandr -r 240
dmesg > dmesg_log.txt

Creates a text file dmesg_log.txt with that output in the current directory.


At the same time, PTB does not complain and when I run P
erceptualVBLSyncTest, the yellow lines are concentrated on the top of the screen.

-> Apart from that smeared right 1/4 of your screen, the output of PTB you posted and the figures look perfect. Everything else seems to work optimally and at least our VBLSyncTest apparently works without dropping any frames at 240 Hz. So if that would work for your experiment script as well, you should be good. If not, there are various ways to tweak the script.

-> Another thing you could try is upgrading to the latest version of the Linux kernel, in the hope that the 240 Hz problem doesn't exist in the latest drivers anymore, if you are interested in that?

-> Another thing you could try is keeping the 240 Hz refresh rate, but reduce the display resolution to 1280x1024 if that is sufficient for your purpose, as according to one of your previous posts, that video resolution also supports 240 Hz and maybe the driver handles that better?

From within PTB scripts you can use SetResolution() to change resolution and refresh rate as long as only one display is connected, e.g.,

oldres = SetResolution (0, 1280, 1024, 240);

to set 1280x1024 at 240 Hz, and

SetResolution(0, oldres);

to restore the previous video settings.

-mario



Elena


*****************************
PerceptualVBLSyncTest

Press ENTER key to start the test. The test will stop after 10 seconds
or any keypress...


PTB-INFO: This is Psychtoolbox-3 for GNU/Linux X11, under Matlab 64-Bit (Version 3.0.12 - Build date: May 13 2016).
PTB-INFO: Support status on this operating system release: Linux 4.4.0-53-generic 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: Advanced Micro Devices, Inc. [AMD/ATI] - Tonga PRO [Radeon R9 285/380] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to Advanced Micro Devices, Inc. [AMD/ATI] Tonga PRO [Radeon R9 285/380] GPU with DCE-10.0 display engine [6 heads]. Beamposition timestamping enabled.


PTB-INFO: OpenGL-Renderer is X.Org :: Gallium 0.4 on AMD TONGA (DRM 3.1.0, LLVM 3.8.0) :: 3.0 Mesa 11.2.0
PTB-INFO: VBL startline = 1080 , VBL Endline = 1213
PTB-INFO: Measured monitor refresh interval from beamposition = 4.308817 ms [232.082245 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 = 4.308782 ms [232.084168 Hz]. (50 valid samples taken, stddev=0.003222 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 4.170855 ms [239.759003 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.
>>



On 21 December 2016 at 03:05, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

XX-In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


>1. sudo su
>2. Enter admin password.
>3. echo performance > /sys/class/drm/card0/device/ power_dpm_state

>If step 3 doesn't help, try this:

>4. echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level

>Any change?

I have done steps 1-3, relaunched the terminal window/matlab, but have not noticed any changes in the display.
Then I have done the step 4 and rebooted the computer.

-> So no improvement, and also not any error message in response to your commands?

After the reboot I had a strange pattern on the screen for 3 seconds and then an empty blue screen forever.
It seems that I spoiled something...

-> You can't have spoiled something, at least not with those commands. Those settings are not persistent over a reboot. They apply immediately and get reset to defaults when the machine restarts. When exactly did the screen turn blue? Did it make it to the login window and only turned blue then? Or already before? If you press CTRL + F1, do you get a proper text console? Does it happen on each reboot? What happens if you connect a different monitor?

-mario



Elena



On 20 December 2016 at 10:19, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Indeed, after removing the drivers i have now "X.Org :: Gallium 0.4 on AMD Tonga...'
message. PTB  does not generate the errors any more. However, I now have another problem, that I have not had with the amdgpu-pro driver: the right side of the screen (about 1/4 of the screen) is a kind of smeared and trembles. It seems that  the generic driver  does not fully support 240Hz. On the other hand,  I only use the central part of the screen for presentation and the trembling is not seen on the gray background. Is it still unsafe to use 240 Hz refresh mode in this situation?

-> Ok, so the timing and timestamping should be solid if PTB doesn't print any warnings or errors anymore, but that trembling/smear (photo/video would be interesting to judge how those artifacts look) is not nice at all of course. Probably the display controller doesn't get enough memory bandwidth for the fast 240 Hz and the line buffer fifos underflow.

-> Can you post the full output and possibly figures of a run of VBLSyncTest?

We can try to force the driver into choosing a higher performance level, using faster memory clocks, maybe that helps. Try this from a terminal and see if it helps:

1. sudo su
2. Enter admin password.
3. echo performance > /sys/class/drm/card0/device/ power_dpm_state

If step 3 doesn't help, try this:

4. echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level

Any change?

You should run VBLSyncTest, and PerceptualVBLSyncTest to see if they show expected results and if the systm is capable of presenting at 240 fps without dropping frames. Timing-wise it should be safe to use the system at 240 Hz even with the artifacts, if you are certain they don't extend into the display area where you actually show your stimuli. But lets see if we can fix this.

-mario

Elena

On 17 December 2016 at 07:27, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

Not sure what happened on your side, but the driver is not properly uninstalled or not uninstalled at all, otherwise it wouldn't say "OpenGL-Renderer is ATI Technologies Inc. :: AMD Radeon R9 200 Series ::" but something like "X.Org :: Gallium 0.4 on AMD Tonga" in that place. That's also the reason for those error messages. Other than that you managed at least to switch the display to 240 Hz mode, so that's a good step forward.

Can your try again, checking the instructions for uninstallation carefully?
-mario






XXX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :

Hi Mario,

>=> A bit more than that. Upgrading the Linux kernel to the
very latest stable kernel, >to see if the problem has been fixed sometime during the ~10 months of development >since your Linux 4.4 kernel and the latest stable Linux kernel 4.9, just released 2 >weeks ago.
I tried 4.9, as you suggested, but there was no improvement. It seems very unlikely that 4.10 will resolve the problem either.

-> You never know. At least then we know there is need for improvement when the latest code doesn't solve the problem. This would be the latest to test:

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/current/linux-headers-4.9.0-996_4.9.0-996.201612132217_all.deb

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/current/linux-headers-4.9.0-996-lowlatency_4.9.0-996.201612132217_amd64.deb

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/current/linux-image-4.9.0-996-lowlatency_4.9.0-996.201612132217_amd64.deb
Since our stimuli are presented in the middle of the screen I am not interested in periphery, unless it affects the center. Can we be sure that the central part is not affected by the imperfections in the 1/5 right side of the screen? Otherwise we will go for suboptimal 144 Hz.

-> As we don't know the exact nature of the problem, we can't be 100% sure. However, if PTB doesn't malfunction or complain with any errors or warnings, and doesn't report skipped frames etc. you can be pretty sure that presentation timing is correct, and frame presentation is coherent/tear-free so your motion stimulus should move correctly, assuming your experiment script is written correctly and your own checks of the visual presentation timestamps in your script don't show skipped frames. If you don't see any visual artifacts reaching into the center of the screen, you are probably fine, but that only you can judge.

If upgrading to the latest 4.10 candidate kernel above doesn't help, and that switching of resolution doesn't work with this most recent kernel either ("dmesg" output please if it fails), it would be good to get a better picture or even better a video clip filmed of your monitor that clearly shows the visual artifacts. Your photo is somewhat blurry and a static image can't convey how the artifacts change over time. I could use that to get the people at AMD interested in this problem.

-mario







On 22 December 2016 at 17:12, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

XXX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Hi Mario,

...

The trembling occurs irrespective of blue or normal screen. When i do  'xrands -r 240 ' thr trembling is there. I attached a photo. (Note that you can't read the text on the left side - my right).


=> Ok, thanks. That photo looks different from what i would have expected. Maybe because it's a photo and not a movie, so one doesn't see the trembling. Or maybe because my suspicion about the cause of the trembling is wrong, and something else goes wrong with signal transmission. Seems to be more the rightmost 1/5th of the display? Why ist the photo left-right flipped?

I removed the empty spaces, and I have not had any error while running the commands.

cat /sys/class/drm/card0/device/ power_dpm_state

   performance

>and
>cat /sys/class/drm/card0/device/ power_dpm_force_performance_ level
   auto

=> Looks correct.

the full output of the command dmesg would be interesting to see if the driver reports back any errors during >switching of video refresh rate to 60 Hz and back to 240 Hz:
sudo su
>echo 4 > /sys/module/drm/parameters/ debug
>xrandr -r 60
>xrandr -r 240
>dmesg > dmesg_log.txt
>Creates a text file dmesg_log.txt with that output in the current directory.
 I performed these operations and attached the  dmesg_log.txt file

=> Thanks. Doesn't show anything suspicious, but captures useful debug info.

Another thing you could try is upgrading to the latest version of the Linux kernel, in the hope that the 240 Hz problem >doesn't exist in the latest drivers anymore, if you are interested in that?
Do you meen upgrating to another Ubuntu version?
I've already done :   sudo apt-get dist-upgrade

=> A bit more than that. Upgrading the Linux kernel to the very latest stable kernel, to see if the problem has been fixed sometime during the ~10 months of development since your Linux 4.4 kernel and the latest stable Linux kernel 4.9, just released 2 weeks ago.

You would download the following files by clicking on the links:

http://kernel.ubuntu.com/~ kernel-ppa/mainline/v4.9/ linux-headers-4.9.0-040900_4. 9.0-040900.201612111631_all. deb

http://kernel.ubuntu.com/~ kernel-ppa/mainline/v4.9/ linux-headers-4.9.0-040900- lowlatency_4.9.0-040900. 201612111631_amd64.deb

http://kernel.ubuntu.com/~ kernel-ppa/mainline/v4.9/ linux-image-4.9.0-040900- lowlatency_4.9.0-040900. 201612111631_amd64.deb

Then in a terminal go into the Downloads folder, probably

cd ~/Downloads

Then install the files:

sudo dpkg -i linux-headers* linux-image*
And after that finished, reboot. That would boot into this new Linux 4.9 kernel by default, and then you can see if a 1920x1080 240 Hz refresh works better. This also installs a low-latency kernel for potentially better realtime behaviour. The boot loader menu at system power up/restart allows selection between all installed kernels.

If that wouldn't work, we could go to an even newer kernel, which at this point is just a prototype for the in-development Linux 4.10 kernel. If that wouldn't fix it, i could contact my people at AMD to see if they have an idea, although that would take time given imminent christmas/new year vacation time.


>->
Another thing you could try is keeping the 240 Hz refresh rate, but reduce the display resolution to >1280x1024 if that is sufficient for your purpose, as according to one of your previous posts, that video >resolution also supports 240 Hz and maybe the driver handles that better?

Yes, indeed, there is no trembling any more with these settings. Possibly, I can use this screen size.

=> If you run PerceptualVBLSyncTest with these settings, you should get again very homogeneous black-white flicker - or actually just some solid grey, given that at 240 Hz switching rate there shouldn't be any perceptible black-white transitions anymore. That would be a cue that the monitor can handle 240 Hz also properly at other resolutions than its native 1920x1080 resolution without introducing timing or visual artifacts.

-mario


Thanks! 
Elena

On 22 December 2016 at 07:57, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Hi Mario,
 just to update,...
after
CTRL + F1 and rebooting I have now a normal ubuntu display. So, no worries.

-> Ok, good. However, i wonder how stable that is, and if it can't come back under certain conditions? The trembling you describe and that "blue screen" are likely related. It could be that on average load on the memory you get trembling, but if there is some spike in memory bandwidth demand, the display controller doesn't get enough date for even the leftmost 3/4 of the display and malfunctions harder and that causes that "blue screen". It's quite unclear to me how these things look. Could you create some photos or a short video of it somewhere?

My suspicion why you got that after a reboot would be that the desktop GUI remembered that you prefer the display running at 240 Hz, ie. it stored that setting in a configuration file. Then during login, the desktop GUI switched the display from the default mode of 60 Hz back to 240 Hz.

If this happens again, and you can't easily recover from it, one way to recover is to press CTRL+ALT+F1 for a text console (sorry, i gave you the wrong key combo, it is not CTRL+F1 but CTRL+ALT+F1), login at the text console, and then type:

rm ~/.config/monitors.xml

to delete the file with the display default video settings. Then go back to the GUI with CTRL+ALT+F7 and login normally. That should start the desktop GUI at a safe default video mode for your display of 60 Hz instead of 240 Hz, after the GUI has forgotten your preferred setting.


However,
echo performance > /sys/class/drm/card0/device/ power_dpm_state
echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level
commands have not had any positive effect on the 240 Hz display. I still have the same trembling/smearing on 1/4th part if the screen.

-> What confuses me here in your post is that single blank space between /sys/class/drm/card0/device/ and the power_dpm_state and power_dpm_force_performance_ level? Is this a copy & paste / formatting error or did you really have a blank space there? In that case the commands would have failed and done nothing except maybe print some error message?

If you apply above commands, what is the output of:

cat
/sys/class/drm/card0/device/ power_dpm_state

and

cat
/sys/class/drm/card0/device/ power_dpm_force_performance_ level


Also the full output of the command dmesg would be interesting to see if the driver reports back any errors during switching of video refresh rate to 60 Hz and back to 240 Hz:

echo 4 > /sys/module/drm/parameters/ debug
xrandr -r 60
xrandr -r 240
dmesg > dmesg_log.txt

Creates a text file dmesg_log.txt with that output in the current directory.


At the same time, PTB does not complain and when I run P
erceptualVBLSyncTest, the yellow lines are concentrated on the top of the screen.

-> Apart from that smeared right 1/4 of your screen, the output of PTB you posted and the figures look perfect. Everything else seems to work optimally and at least our VBLSyncTest apparently works without dropping any frames at 240 Hz. So if that would work for your experiment script as well, you should be good. If not, there are various ways to tweak the script.

-> Another thing you could try is upgrading to the latest version of the Linux kernel, in the hope that the 240 Hz problem doesn't exist in the latest drivers anymore, if you are interested in that?

-> Another thing you could try is keeping the 240 Hz refresh rate, but reduce the display resolution to 1280x1024 if that is sufficient for your purpose, as according to one of your previous posts, that video resolution also supports 240 Hz and maybe the driver handles that better?

From within PTB scripts you can use SetResolution() to change resolution and refresh rate as long as only one display is connected, e.g.,

oldres = SetResolution (0, 1280, 1024, 240);

to set 1280x1024 at 240 Hz, and

SetResolution(0, oldres);

to restore the previous video settings.

-mario



Elena


*****************************
PerceptualVBLSyncTest

Press ENTER key to start the test. The test will stop after 10 seconds
or any keypress...


PTB-INFO: This is Psychtoolbox-3 for GNU/Linux X11, under Matlab 64-Bit (Version 3.0.12 - Build date: May 13 2016).
PTB-INFO: Support status on this operating system release: Linux 4.4.0-53-generic 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: Advanced Micro Devices, Inc. [AMD/ATI] - Tonga PRO [Radeon R9 285/380] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to Advanced Micro Devices, Inc. [AMD/ATI] Tonga PRO [Radeon R9 285/380] GPU with DCE-10.0 display engine [6 heads]. Beamposition timestamping enabled.


PTB-INFO: OpenGL-Renderer is X.Org :: Gallium 0.4 on AMD TONGA (DRM 3.1.0, LLVM 3.8.0) :: 3.0 Mesa 11.2.0
PTB-INFO: VBL startline = 1080 , VBL Endline = 1213
PTB-INFO: Measured monitor refresh interval from beamposition = 4.308817 ms [232.082245 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 = 4.308782 ms [232.084168 Hz]. (50 valid samples taken, stddev=0.003222 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 4.170855 ms [239.759003 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.
>>



On 21 December 2016 at 03:05, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

XX-In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


>1. sudo su
>2. Enter admin password.
>3. echo performance > /sys/class/drm/card0/device/ power_dpm_state

>If step 3 doesn't help, try this:

>4. echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level

>Any change?

I have done steps 1-3, relaunched the terminal window/matlab, but have not noticed any changes in the display.
Then I have done the step 4 and rebooted the computer.

-> So no improvement, and also not any error message in response to your commands?

After the reboot I had a strange pattern on the screen for 3 seconds and then an empty blue screen forever.
It seems that I spoiled something...

-> You can't have spoiled something, at least not with those commands. Those settings are not persistent over a reboot. They apply immediately and get reset to defaults when the machine restarts. When exactly did the screen turn blue? Did it make it to the login window and only turned blue then? Or already before? If you press CTRL + F1, do you get a proper text console? Does it happen on each reboot? What happens if you connect a different monitor?

-mario



Elena



On 20 December 2016 at 10:19, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Indeed, after removing the drivers i have now "X.Org :: Gallium 0.4 on AMD Tonga...'
message. PTB  does not generate the errors any more. However, I now have another problem, that I have not had with the amdgpu-pro driver: the right side of the screen (about 1/4 of the screen) is a kind of smeared and trembles. It seems that  the generic driver  does not fully support 240Hz. On the other hand,  I only use the central part of the screen for presentation and the trembling is not seen on the gray background. Is it still unsafe to use 240 Hz refresh mode in this situation?

-> Ok, so the timing and timestamping should be solid if PTB doesn't print any warnings or errors anymore, but that trembling/smear (photo/video would be interesting to judge how those artifacts look) is not nice at all of course. Probably the display controller doesn't get enough memory bandwidth for the fast 240 Hz and the line buffer fifos underflow.

-> Can you post the full output and possibly figures of a run of VBLSyncTest?

We can try to force the driver into choosing a higher performance level, using faster memory clocks, maybe that helps. Try this from a terminal and see if it helps:

1. sudo su
2. Enter admin password.
3. echo performance > /sys/class/drm/card0/device/ power_dpm_state

If step 3 doesn't help, try this:

4. echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level

Any change?

You should run VBLSyncTest, and PerceptualVBLSyncTest to see if they show expected results and if the systm is capable of presenting at 240 fps without dropping frames. Timing-wise it should be safe to use the system at 240 Hz even with the artifacts, if you are certain they don't extend into the display area where you actually show your stimuli. But lets see if we can fix this.

-mario

Elena

On 17 December 2016 at 07:27, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

Not sure what happened on your side, but the driver is not properly uninstalled or not uninstalled at all, otherwise it wouldn't say "OpenGL-Renderer is ATI Technologies Inc. :: AMD Radeon R9 200 Series ::" but something like "X.Org :: Gallium 0.4 on AMD Tonga" in that place. That's also the reason for those error messages. Other than that you managed at least to switch the display to 240 Hz mode, so that's a good step forward.

Can your try again, checking the instructions for uninstallation carefully?
-mario






Hi Mario,

Sorry for the delayed reply (vacations...)

>If upgrading to the latest 4.10 candidate kernel above doesn't help, and that switching of resolution doesn't work with this most recent kernel either ("dmesg" output please if it fails), it would be good to get a better picture or even better a video clip filmed of your monitor that clearly shows the visual artifacts. Your photo is somewhat blurry and a static image can't convey how the artifacts change over time. I could use that to get the people at AMD interested in this problem.

I upgraded to the 4.10 kernel. The trembling is still there, but PerceptualVBLSyncTest does not give the error any more with 1280x1024x240 (not native) resolution.

I attached a video that demonstrates the problem with 240Hz and native 1920x1080 resolution
Thank you!

Elena




On 31 December 2016 at 16:14, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

XXX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Hi Mario,

>=> A bit more than that. Upgrading the Linux kernel to the
very latest stable kernel, >to see if the problem has been fixed sometime during the ~10 months of development >since your Linux 4.4 kernel and the latest stable Linux kernel 4.9, just released 2 >weeks ago.
I tried 4.9, as you suggested, but there was no improvement. It seems very unlikely that 4.10 will resolve the problem either.

-> You never know. At least then we know there is need for improvement when the latest code doesn't solve the problem. This would be the latest to test:

http://kernel.ubuntu.com/~ kernel-ppa/mainline/drm-next/ current/linux-headers-4.9.0- 996_4.9.0-996.201612132217_ all.deb

http://kernel.ubuntu.com/~ kernel-ppa/mainline/drm-next/ current/linux-headers-4.9.0- 996-lowlatency_4.9.0-996. 201612132217_amd64.deb

http://kernel.ubuntu.com/~ kernel-ppa/mainline/drm-next/ current/linux-image-4.9.0-996- lowlatency_4.9.0-996. 201612132217_amd64.deb
Since our stimuli are presented in the middle of the screen I am not interested in periphery, unless it affects the center. Can we be sure that the central part is not affected by the imperfections in the 1/5 right side of the screen? Otherwise we will go for suboptimal 144 Hz.

-> As we don't know the exact nature of the problem, we can't be 100% sure. However, if PTB doesn't malfunction or complain with any errors or warnings, and doesn't report skipped frames etc. you can be pretty sure that presentation timing is correct, and frame presentation is coherent/tear-free so your motion stimulus should move correctly, assuming your experiment script is written correctly and your own checks of the visual presentation timestamps in your script don't show skipped frames. If you don't see any visual artifacts reaching into the center of the screen, you are probably fine, but that only you can judge.

If upgrading to the latest 4.10 candidate kernel above doesn't help, and that switching of resolution doesn't work with this most recent kernel either ("dmesg" output please if it fails), it would be good to get a better picture or even better a video clip filmed of your monitor that clearly shows the visual artifacts. Your photo is somewhat blurry and a static image can't convey how the artifacts change over time. I could use that to get the people at AMD interested in this problem.

-mario







On 22 December 2016 at 17:12, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

XXX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Hi Mario,

...

The trembling occurs irrespective of blue or normal screen. When i do 'xrands -r 240 ' thr trembling is there. I attached a photo. (Note that you can't read the text on the left side - my right).


=> Ok, thanks. That photo looks different from what i would have expected. Maybe because it's a photo and not a movie, so one doesn't see the trembling. Or maybe because my suspicion about the cause of the trembling is wrong, and something else goes wrong with signal transmission. Seems to be more the rightmost 1/5th of the display? Why ist the photo left-right flipped?

I removed the empty spaces, and I have not had any error while running the commands.

cat /sys/class/drm/card0/device/ power_dpm_state

performance

>and
>cat /sys/class/drm/card0/device/ power_dpm_force_performance_ level
auto

=> Looks correct.

the full output of the command dmesg would be interesting to see if the driver reports back any errors during >switching of video refresh rate to 60 Hz and back to 240 Hz:
sudo su
>echo 4 > /sys/module/drm/parameters/ debug
>xrandr -r 60
>xrandr -r 240
>dmesg > dmesg_log.txt
>Creates a text file dmesg_log.txt with that output in the current directory.
I performed these operations and attached the dmesg_log.txt file

=> Thanks. Doesn't show anything suspicious, but captures useful debug info.

Another thing you could try is upgrading to the latest version of the Linux kernel, in the hope that the 240 Hz problem >doesn't exist in the latest drivers anymore, if you are interested in that?
Do you meen upgrating to another Ubuntu version?
I've already done : sudo apt-get dist-upgrade


=> A bit more than that. Upgrading the Linux kernel to the very latest stable kernel, to see if the problem has been fixed sometime during the ~10 months of development since your Linux 4.4 kernel and the latest stable Linux kernel 4.9, just released 2 weeks ago.

You would download the following files by clicking on the links:

http://kernel.ubuntu.com/~ kernel-ppa/mainline/v4.9/ linux-headers-4.9.0-040900_4. 9.0-040900.201612111631_all. deb

http://kernel.ubuntu.com/~ kernel-ppa/mainline/v4.9/ linux-headers-4.9.0-040900- lowlatency_4.9.0-040900. 201612111631_amd64.deb

http://kernel.ubuntu.com/~ kernel-ppa/mainline/v4.9/ linux-image-4.9.0-040900- lowlatency_4.9.0-040900. 201612111631_amd64.deb

Then in a terminal go into the Downloads folder, probably

cd ~/Downloads

Then install the files:

sudo dpkg -i linux-headers* linux-image*
And after that finished, reboot. That would boot into this new Linux 4.9 kernel by default, and then you can see if a 1920x1080 240 Hz refresh works better. This also installs a low-latency kernel for potentially better realtime behaviour. The boot loader menu at system power up/restart allows selection between all installed kernels.

If that wouldn't work, we could go to an even newer kernel, which at this point is just a prototype for the in-development Linux 4.10 kernel. If that wouldn't fix it, i could contact my people at AMD to see if they have an idea, although that would take time given imminent christmas/new year vacation time.


>->
Another thing you could try is keeping the 240 Hz refresh rate, but reduce the display resolution to >1280x1024 if that is sufficient for your purpose, as according to one of your previous posts, that video >resolution also supports 240 Hz and maybe the driver handles that better?

Yes, indeed, there is no trembling any more with these settings. Possibly, I can use this screen size.

=> If you run PerceptualVBLSyncTest with these settings, you should get again very homogeneous black-white flicker - or actually just some solid grey, given that at 240 Hz switching rate there shouldn't be any perceptible black-white transitions anymore. That would be a cue that the monitor can handle 240 Hz also properly at other resolutions than its native 1920x1080 resolution without introducing timing or visual artifacts.

-mario


Thanks!
Elena

On 22 December 2016 at 07:57, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Hi Mario,
just to update,...
after
CTRL + F1 and rebooting I have now a normal ubuntu display. So, no worries.

-> Ok, good. However, i wonder how stable that is, and if it can't come back under certain conditions? The trembling you describe and that "blue screen" are likely related. It could be that on average load on the memory you get trembling, but if there is some spike in memory bandwidth demand, the display controller doesn't get enough date for even the leftmost 3/4 of the display and malfunctions harder and that causes that "blue screen". It's quite unclear to me how these things look. Could you create some photos or a short video of it somewhere?

My suspicion why you got that after a reboot would be that the desktop GUI remembered that you prefer the display running at 240 Hz, ie. it stored that setting in a configuration file. Then during login, the desktop GUI switched the display from the default mode of 60 Hz back to 240 Hz.

If this happens again, and you can't easily recover from it, one way to recover is to press CTRL+ALT+F1 for a text console (sorry, i gave you the wrong key combo, it is not CTRL+F1 but CTRL+ALT+F1), login at the text console, and then type:

rm ~/.config/monitors.xml

to delete the file with the display default video settings. Then go back to the GUI with CTRL+ALT+F7 and login normally. That should start the desktop GUI at a safe default video mode for your display of 60 Hz instead of 240 Hz, after the GUI has forgotten your preferred setting.


However,
echo performance > /sys/class/drm/card0/device/ power_dpm_state
echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level
commands have not had any positive effect on the 240 Hz display. I still have the same trembling/smearing on 1/4th part if the screen.

-> What confuses me here in your post is that single blank space between /sys/class/drm/card0/device/ and the power_dpm_state and power_dpm_force_performance_ level? Is this a copy & paste / formatting error or did you really have a blank space there? In that case the commands would have failed and done nothing except maybe print some error message?

If you apply above commands, what is the output of:

cat
/sys/class/drm/card0/device/ power_dpm_state

and

cat
/sys/class/drm/card0/device/ power_dpm_force_performance_ level


Also the full output of the command dmesg would be interesting to see if the driver reports back any errors during switching of video refresh rate to 60 Hz and back to 240 Hz:

echo 4 > /sys/module/drm/parameters/ debug
xrandr -r 60
xrandr -r 240
dmesg > dmesg_log.txt

Creates a text file dmesg_log.txt with that output in the current directory.


At the same time, PTB does not complain and when I run P
erceptualVBLSyncTest, the yellow lines are concentrated on the top of the screen.

-> Apart from that smeared right 1/4 of your screen, the output of PTB you posted and the figures look perfect. Everything else seems to work optimally and at least our VBLSyncTest apparently works without dropping any frames at 240 Hz. So if that would work for your experiment script as well, you should be good. If not, there are various ways to tweak the script.

-> Another thing you could try is upgrading to the latest version of the Linux kernel, in the hope that the 240 Hz problem doesn't exist in the latest drivers anymore, if you are interested in that?

-> Another thing you could try is keeping the 240 Hz refresh rate, but reduce the display resolution to 1280x1024 if that is sufficient for your purpose, as according to one of your previous posts, that video resolution also supports 240 Hz and maybe the driver handles that better?

From within PTB scripts you can use SetResolution() to change resolution and refresh rate as long as only one display is connected, e.g.,

oldres = SetResolution (0, 1280, 1024, 240);

to set 1280x1024 at 240 Hz, and

SetResolution(0, oldres);

to restore the previous video settings.

-mario



Elena


*****************************
PerceptualVBLSyncTest

Press ENTER key to start the test. The test will stop after 10 seconds
or any keypress...


PTB-INFO: This is Psychtoolbox-3 for GNU/Linux X11, under Matlab 64-Bit (Version 3.0.12 - Build date: May 13 2016).
PTB-INFO: Support status on this operating system release: Linux 4.4.0-53-generic 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: Advanced Micro Devices, Inc. [AMD/ATI] - Tonga PRO [Radeon R9 285/380] GPU found. Trying to establish low-level access...
PTB-INFO: Connected to Advanced Micro Devices, Inc. [AMD/ATI] Tonga PRO [Radeon R9 285/380] GPU with DCE-10.0 display engine [6 heads]. Beamposition timestamping enabled.


PTB-INFO: OpenGL-Renderer is X.Org :: Gallium 0.4 on AMD TONGA (DRM 3.1.0, LLVM 3.8.0) :: 3.0 Mesa 11.2.0
PTB-INFO: VBL startline = 1080 , VBL Endline = 1213
PTB-INFO: Measured monitor refresh interval from beamposition = 4.308817 ms [232.082245 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 = 4.308782 ms [232.084168 Hz]. (50 valid samples taken, stddev=0.003222 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 4.170855 ms [239.759003 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.
>>



On 21 December 2016 at 03:05, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

XX-In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


>1. sudo su
>2. Enter admin password.
>3. echo performance > /sys/class/drm/card0/device/ power_dpm_state

>If step 3 doesn't help, try this:

>4. echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level

>Any change?

I have done steps 1-3, relaunched the terminal window/matlab, but have not noticed any changes in the display.
Then I have done the step 4 and rebooted the computer.

-> So no improvement, and also not any error message in response to your commands?

After the reboot I had a strange pattern on the screen for 3 seconds and then an empty blue screen forever.
It seems that I spoiled something...

-> You can't have spoiled something, at least not with those commands. Those settings are not persistent over a reboot. They apply immediately and get reset to defaults when the machine restarts. When exactly did the screen turn blue? Did it make it to the login window and only turned blue then? Or already before? If you press CTRL + F1, do you get a proper text console? Does it happen on each reboot? What happens if you connect a different monitor?

-mario



Elena



On 20 December 2016 at 10:19, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Indeed, after removing the drivers i have now "X.Org :: Gallium 0.4 on AMD Tonga...'
message. PTB does not generate the errors any more. However, I now have another problem, that I have not had with the amdgpu-pro driver: the right side of the screen (about 1/4 of the screen) is a kind of smeared and trembles. It seems that the generic driver does not fully support 240Hz. On the other hand, I only use the central part of the screen for presentation and the trembling is not seen on the gray background. Is it still unsafe to use 240 Hz refresh mode in this situation?

-> Ok, so the timing and timestamping should be solid if PTB doesn't print any warnings or errors anymore, but that trembling/smear (photo/video would be interesting to judge how those artifacts look) is not nice at all of course. Probably the display controller doesn't get enough memory bandwidth for the fast 240 Hz and the line buffer fifos underflow.

-> Can you post the full output and possibly figures of a run of VBLSyncTest?

We can try to force the driver into choosing a higher performance level, using faster memory clocks, maybe that helps. Try this from a terminal and see if it helps:

1. sudo su
2. Enter admin password.
3. echo performance > /sys/class/drm/card0/device/ power_dpm_state

If step 3 doesn't help, try this:

4. echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level

Any change?

You should run VBLSyncTest, and PerceptualVBLSyncTest to see if they show expected results and if the systm is capable of presenting at 240 fps without dropping frames. Timing-wise it should be safe to use the system at 240 Hz even with the artifacts, if you are certain they don't extend into the display area where you actually show your stimuli. But lets see if we can fix this.

-mario

Elena

On 17 December 2016 at 07:27, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

Not sure what happened on your side, but the driver is not properly uninstalled or not uninstalled at all, otherwise it wouldn't say "OpenGL-Renderer is ATI Technologies Inc. :: AMD Radeon R9 200 Series ::" but something like "X.Org :: Gallium 0.4 on AMD Tonga" in that place. That's also the reason for those error messages. Other than that you managed at least to switch the display to 240 Hz mode, so that's a good step forward.

Can your try again, checking the instructions for uninstallation carefully?
-mario







Hello Mario,
It does not seem to help. I still have the same trembling.
I attached the outputs of dmesg, etc.

Elena

On 16 December 2016 at 06:56, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

Oh also to save some time, after doing this, if you don't get the 240 Hz, also post the output of "ResolutionTest", or of the terminal command "xrandr --verbose".

-mario