>=> 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
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.
=> 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*
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.
-marioThanks!ElenaOn 22 December 2016 at 07:57, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :
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.However,Hi Mario,after CTRL + F1 and rebooting I have now a normal ubuntu display. So, no worries.
just to update,...
-> 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.
echo performance > /sys/class/drm/card0/device/ power_dpm_state
echo high > /sys/class/drm/card0/device/ power_dpm_force_performance_ level
-> 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_ levelerceptualVBLSyncTest, the yellow lines are concentrated on the top of the screen.
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 PElena
-> 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
*****************************
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 :
I have done steps 1-3, relaunched the terminal window/matlab, but have not noticed any changes in the display.>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?
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
ElenaOn 20 December 2016 at 10:19, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :
ElenaIndeed, 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.
-marioOn 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