[SOLVED] Radeon HD3450 Vsync randomly enabling

Xaero252 · 2017-08-11 02:57:59

Edit: Solved! See post #7

So this is a bit perplexing. I can't seem to pinpoint any point where this is actually occuring but it's definitely happening.

I've set up a purpose-driven dedicated Stepmania box using the Stepmania package in the AUR. The game runs at 150-180 fps with the Radeon HD 3450. Periodically, however, the game will suddenly lock to 60fps. The game shows vsync as being disabled, however and dmesg nor the game logs show any events when this occurs. It seems to happen after the game has been left running a while unattended. If I consistently play then it works fine, but as soon as it's left alone for ten minutes or so the framerate locks to 60. This issue PERSISTS until the entire machine is rebooted. If I execute "systemctl restart getty@tty1.service" which results in the X server shutting down as well as the game, and both of those things being restarted; the issue remains. Only after executing "shutdown -r now" and waiting for it to come back fixes the issue.

Here's what I've done so far:

/etc/environment:

export vblank_mode=0
export CLUTTER_VBLANK=none

I have confirmed the above variables are being set with echo $var.

~/.drirc: -- I'm nearly 100% certain this has no impact since I believe the driver is using dri3 not dri2:

<driconf>
    <device screen="0" driver="dri2">
        <application name="Default">
            <option name="vblank_mode" value="0" />
        </application>
    </device>
    <!-- Other devices ... -->
</driconf>

/etc/X11/xorg.conf.d/20-radeon.conf:

Section "Device"
        Identifier  "Radeon HD3450"
        Driver  "radeon"
        Option  "EXAVSync" "off"
        Option "SwapbuffersWait" "false"
EndSection

'
/etc/X11/xorg.conf.d/90-monitor.conf

Section "Screen"
        Identifier "The Screen"
        SubSection "Display"
                Depth   24
                Modes   "640x480"
        EndSubSection
EndSection

Section "ServerLayout"
    Identifier "ServerLayout0"
    Option "StandbyTime" "0"
    Option "SuspendTime" "0"
    Option "OffTime"     "0"
    Option "BlankTime"   "0"
EndSection

I have also:
Changed the CPU governor to "performance" to keep the CPU from changing power states.

This is the extent of configuration I've done. I've also disabled the game's built-in logging mechanism and am logging asynchronous via output redirection to a file, and I've reduced the in-game settings to rule out performance related issues.

Here's the dmesg output -- note I have tried both with this kernel from the AUR as well as the latest kernel from the repos.
https://ptpb.pw/AQ1F

Here's the game log (ignore the missing content as these are warnings during startup and the game runs fine up to and including that point)
https://ptpb.pw/5cTR

Here's the Xorg log:
https://ptpb.pw/pHi7

I am currently testing if disabling radeon's built-in power management via the kernel parameter radeon.dpm=0 helps with the issue.
I'm all ears for any ideas as I've exhausted the resources readily available for this issue. It seems almost completely arbitrary that it "decides" that vsync should be enabled. It seems to be enabled at the driver or display server level, since the game is completely unaware of the change (holding "F3" in the game reveals the status of current options, where it shows "Vsync OFF")

One final caveat is that I have a udev rule that fires any time the connected display(s) change on the machine; it simply mirrors the current display based on the settings in the game using xrandr. I have tested by forcing this udev rule to fire (hotplugging the displays) that it does NOT cause the issue to occur. I have tried repeatedly hotplugging the connection to a capture card on another machine as well as the monitor itself.

As always, any assistance is greatly appreciated,
Xaero

PS:
Why no Vsync you ask?
The game has an interesting limitation in that input is only handled once per frame. The timing window for the "best judgement" in the game is ~20ms long, just over 1 frame at 60fps! If any frames are dropped, it quickly becomes unplayable with vsync on at 60fps. Until this is addressed upstream the only suitable solution is to play with an unlocked framerate, reducing the chances and impact of dropped frames.

Last edited by Xaero252 (2017-08-18 00:37:32)

ooo · 2017-08-11 13:04:59

did you try:

<application name="all">

in .drirc? Although I'm not sure whether "Default" should also work.

The fact that vsync is enabled after game being idle for some time makes me think maybe this could be DPMS related. Did you try disabling it completely with this in your Monitor section, or with xset?

Option "DPMS" "false"

Currently you've only set the delay to zero.

Lone_Wolf · 2017-08-11 13:05:23

	Using the first device section listed.
[    17.921] (**) |   |-->Device "My Graphics Card"

Looks like there are more X configuration files then you posted.

CLUTTER_VBLANK suggests you gnome and / or cinnamon .
Have you tried with a simple WM like openbox or twm ?

Last edited by Lone_Wolf (2017-08-11 13:06:07)

Xaero252 · 2017-08-11 14:00:31

ooo wrote:

did you try:
<application name="all">
in .drirc? Although I'm not sure whether "Default" should also work.
The fact that vsync is enabled after game being idle for some time makes me think maybe this could be DPMS related. Did you try disabling it completely with this in your Monitor section, or with xset?
Option "DPMS" "false"
Currently you've only set the delay to zero.

I was originally disabling DPMS via ~/.xinitrc but wasn't certain it was being obeyed since the screen was still blanking. After putting the options into xorg.conf.d they are certainly being obeyed. I'll disable it entirely as suggested and see if that helps, that's what I originally assumed was the case was that somehow DPMS was causing the problem.
I'll also try changing the application name from Default to all in drirc; however I'm not certain it applies since I believe dri3 is used by default now; at least it is according to the wiki. I can't seem to dig up any information on setting the same value for dri3.

Lone_Wolf wrote:

	Using the first device section listed.
[    17.921] (**) |   |-->Device "My Graphics Card"
Looks like there are more X configuration files then you posted.

CLUTTER_VBLANK suggests you gnome and / or cinnamon .
Have you tried with a simple WM like openbox or twm ?

My apologies; I updated the description of the GPU after posting here;

ls /etc/X11/xorg.conf.d:

[itg@itgpc ~]$ ls /etc/X11/xorg.conf.d/
20-radeon.conf  90-monitor.conf

Resulting xorg log:
https://ptpb.pw/YnuO

The change is visible in a fresh log; I posted a log from when the issue had occured instead of a fresh one.

Additionally, I am not using any DE/WM as this is a dedicated box solely for that game and has no other computing purposes.
I was honestly looking for potential solutions and trying any that arose. One of which happened to be CLUTTER_VBLANK, which after reading probably doesn't apply.

Autologin to tty1 is done via overriding the SystemD service getty@tty1.service:
/etc/systemd/system/getty@tty1.service.d/override.conf

[Service]
Type=simple
ExecStart=
ExecStart=-/usr/bin/agetty --autologin itg --noclear %I $TERM

The command "startx" is run by ~/.bash_profile:

#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc
[[ -z $DISPLAY && $XDG_VTNR -eq 1 ]]
[[ $(fgconsole 2>/dev/null) == 1 ]] && exec startx -- vt1 &> /dev/null 2>&1

Finally the game and display mirroring is applied via ~/.xinitrc:

#!/bin/bash
#Actually start SM here
stepmania > /var/log/stepmania/stepmania.log 2>&1 &

#Turn of keyboard repeat, and give stepmania ample time to start
xset -r
sleep 10

#Here we duplicate the displays

mirrordisp

#wait for stepmania so that Xorg doesn't bootloop
wait

The content for the "mirrordisp" script is as such:

#!/bin/bash

## Let's make Display Resolution obey StepMania! [this won't hotplug though, obviously]
## First we grab the Display vars from SM.ini, then we sanitize them and concatenate them into a display mode
DISPLAY=:0
grep Display ~/.stepmania-5.0/Save/Preferences.ini > /tmp/gameprefs
source /tmp/gameprefs
gameres="${DisplayWidth//[[:cntrl:]]/}x${DisplayHeight//[[:cntrl:]]/}"

#Here we duplicate the displays

xrandr --output DVI-0 --mode $gameres --output DVI-1 --mode $gameres --same-as DVI-0

The above script isn't the prettiest thing but it does function. The hardcoded DISPLAY variable is because I also fire this same script via a udev rule to mirror the display on hotplug. It's desirable for the hotplugging to follow the resolution set by the game, which is currently static at 640x480, but may eventually range between 15khz resolution as well as 640x480 all the way to 1080P. Of course I'll need to make changing the game's resolution edit the Xorg.conf to make things stay "pretty" but that's a task for a later day.

EDIT:
This is what the system load looks like just after boot; I'll update this post later today to see if perhaps something is eating memory or pegging the CPU usage.
http://imgur.com/LO6bmqB

Last edited by Xaero252 (2017-08-11 14:10:59)

ooo · 2017-08-11 15:40:13

Xaero252 wrote:

I'll also try changing the application name from Default to all in drirc; however I'm not certain it applies since I believe dri3 is used by default now; at least it is according to the wiki. I can't seem to dig up any information on setting the same value for dri3.

I couldn't find anything to confirm this, but i vaguely remember looking this up earlier, and driver="dri2" would apply also to drivers using DRI3 IIRC. Also, I think you should still be able to force DRI2 from either xorg.conf, or with LIBGL_DRI3_DISABLE environment variable.

Nevertheless, according to this, you could also use driver="radeon", which should work regardless of the DRI version.

If you run out of ideas, you could also try if you have the same issue with xf86-video-modesetting driver.

Also, I've found out that sometimes running games standalone on X, i.e. without any window manager, could result in some unexpected issues. Therefore you could give Lone_Wolf's suggestion of trying to run the game in some lightweight WM a go.

Xaero252 · 2017-08-11 23:25:47

ooo wrote:

Xaero252 wrote:
I'll also try changing the application name from Default to all in drirc; however I'm not certain it applies since I believe dri3 is used by default now; at least it is according to the wiki. I can't seem to dig up any information on setting the same value for dri3.
I couldn't find anything to confirm this, but i vaguely remember looking this up earlier, and driver="dri2" would apply also to drivers using DRI3 IIRC. Also, I think you should still be able to force DRI2 from either xorg.conf, or with LIBGL_DRI3_DISABLE environment variable.
Nevertheless, according to this, you could also use driver="radeon", which should work regardless of the DRI version.
If you run out of ideas, you could also try if you have the same issue with xf86-video-modesetting driver.
Also, I've found out that sometimes running games standalone on X, i.e. without any window manager, could result in some unexpected issues. Therefore you could give Lone_Wolf's suggestion of trying to run the game in some lightweight WM a go.

Well, I gave the force DPMS to disable in xorg.conf.d a whirl, still locking to 60fps after being left idle.
The system load after ~9 hours of uptime:
http://imgur.com/LNO0LjR
Obviously the load isn't spiraling out of control while left unattended. I'll give a simple WM a whirl, as well as using radeon in drirc and forcing DRI2. If all of that fails I will also try mesa-git and possibly the LTS kernel.
Kind of a bummer as everything about this setup is extremely well optimized, just for vsync to arbitrarily but in and kill it. The mysteries of Linux are half the fun though!

Edit:
I have now tried using the modesetting driver as suggested above. The issue remains however performance is slightly better, so that'll likely stick around.
I'm grabbing the LTS kernel, and I'm going to check mesa-git to see if it has the issue.

EDIT2:

Have no tried:
-Mesa-git
-Linux-LTS
-twm
-Running in Windowed mode instead of fullscreen (effectively no impact since there's no window manager to butt in with decorations, plus I can always use other tools to remove the decoration)

Last edited by Xaero252 (2017-08-14 02:51:55)

Xaero252 · 2017-08-18 00:34:54

Finally solved this issue.
The solution was, as usual, much simpler than anticipated.
Switching from dri3 to dri2 by putting "LIBGL_DRI3_DISABLE=1" in /etc/environment has worked around the issue. Obviously this is a bug that needs to be filled upstream though I'm not sure which party should be held responsible.

Anyways thanks for the suggestions. Marking thread solved.

Last edited by Xaero252 (2017-08-18 00:35:26)

Arch Linux

#1 2017-08-11 02:57:59

[SOLVED] Radeon HD3450 Vsync randomly enabling

#2 2017-08-11 13:04:59

Re: [SOLVED] Radeon HD3450 Vsync randomly enabling

#3 2017-08-11 13:05:23

Re: [SOLVED] Radeon HD3450 Vsync randomly enabling

#4 2017-08-11 14:00:31

Re: [SOLVED] Radeon HD3450 Vsync randomly enabling

#5 2017-08-11 15:40:13

Re: [SOLVED] Radeon HD3450 Vsync randomly enabling

#6 2017-08-11 23:25:47

Re: [SOLVED] Radeon HD3450 Vsync randomly enabling

#7 2017-08-18 00:34:54

Re: [SOLVED] Radeon HD3450 Vsync randomly enabling

Board footer