<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [regression bisected] Stuttering in games caused by commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed""
href="https://bugs.freedesktop.org/show_bug.cgi?id=93147">93147</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[regression bisected] Stuttering in games caused by commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed"
</td>
</tr>
<tr>
<th>Product</th>
<td>DRI
</td>
</tr>
<tr>
<th>Version</th>
<td>DRI git
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>minor
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>DRM/Radeon
</td>
</tr>
<tr>
<th>Assignee</th>
<td>dri-devel@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>dawitbro@sbcglobal.net
</td>
</tr>
<tr>
<th>CC</th>
<td>ville.syrjala@linux.intel.com
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=120187" name="attach_120187" title="dmesg from kernel built at "bad" commit">attachment 120187</a> <a href="attachment.cgi?id=120187&action=edit" title="dmesg from kernel built at "bad" commit">[details]</a></span>
dmesg from kernel built at "bad" commit
Building Linux from drm-next or drm-fixes gives me a kernel which causes what
appears to be stuttering/hesitations in test applications (particularly severe
in 'prboom-plus') which were not present in Linux 4.3.
HARDWARE
GPU: Radeon HD 7850 (Pitcairn)
CPU: 64-bit AMD FX-8320E Eight-Core Processor
chipset: AMD 990FX
mboard: ASUS M5A99FX PRO R2.0
SOFTWARE
xf86-video-ati: 7.6.99+ (git master at commit 10b7c3de, Nov 17 2015)
xorg-server: 1.18.0+ (git master at commit 51984ddd, Nov 18 2015)
mesa: 11.1.0+ (git master at commit d8c26969, Nov 20 2015)
libdrm: 2.4.65+ (git master at commit c3deddd9, Nov 10 2015)
kernel: drm-fixes (at commit 2d591ab1, Nov 20 2015)
distribution: Debian unstable
Reproducing steps:
I apply future Radeon DRM and core DRM code to latest stable Linux kernels, and
I use several applications to test the results. I use a less demanding game,
'prboom-plus', as a kind of canary; I use more demanding games like
'alien-arena' and 'torcs' as well. All 3 of the games mentioned show a kind of
stuttering or hesitation if using the current git HEAD of drm-next or
drm-fixes, but 'prboom-plus' is affected to the point of being extremely
annoying, almost unplayable.
To reproduce, boot Linux 4.3 and play a few moments of 'prboom-plus'; then boot
a kernel built from drm-next or drm-fixes, then play 'prboom-plus' again. The
effects are quite pronounced and obvious. (The effects on 'alien-arena' and
'torcs' are much more subtle, and might easily go unnoticed, though someone
looking for a difference should easily be able to notice.) None of the games
crash, but they are simply affected (to varying degrees) by a kind of
stuttering lag caused by the commit identified below by bisection.
Additional info:
I have reported this against DRI/Radeon but problem commit is touching code in
'drivers/gpu/drm/drm_irq.c', which does not seem limited to affecting only
Radeon. (I am not a developer, so any comment I make about code can probably
be ignored.) I would appreciate if the developers reading this would consider
whether I have reported the bug against the wrong product and/or component, and
make changes as appropriate!
In 'xorg.conf' I usually have "SwapbuffersWait" disabled with a stanza like
this:
Section "Device"
Identifier "Configured Video Device"
Driver "radeon"
Option "DRI" "3"
Option "SwapbuffersWait" "off"
EndSection
Changing the "SwapbuffersWait" setting has no effect on the symptoms of this
bug, however.
Bisection:
[I test future Radeon code in advance by cherry picking from drm-next and
drm-fixes changesets which touch Radeon DRM and core DRM. Because of the
likelihood of error on my part, I never report bugs on one of these
Frankenstein kernels of my own making. If I bisect a bug, I confirm that the
same buggy behavior is present upstream before reporting it.]
I first noticed this problem in early October, when I had made a local branch
from Linux 4.2.3 and cherry picked from DRM 4.3 and DRM 4.4 (up to cf648305).
I noticed the bug described earlier immediately. I didn't have much time to
troubleshoot, and assumed the error was my own, so I made a second local branch
from 4.2.3 and only cherry-picked from DRM 4.3 (up to 30c64664, my previously
working list of commits).
After Linux 4.3 was released, I tried again. I made a local branch based on
4.3 and applied DRM 4.4 up to commit 5481c8fb. The process went very smooth,
but the buggy behavior of my test programs (particularly 'prboom-plus') was
back again. I decided to bisect my 4.3 + DRM 4.4 tree to identify where things
were going wrong.
The HEAD of my tree was clearly "bad" so I had a place to start. I built Linux
4.3 without any cherry picks, and it was "good". After 6 more builds, 'git
bisect' pointed at the following commit:
commit 4dfd64862ff852df7b1198d667dda778715ee88f
Author: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>>
Date: Mon Sep 14 22:43:51 2015 +0300
drm: Use vblank timestamps to guesstimate how many vblanks were missed
Since the problem could still have been only in my Frankenstein local tree, I
built kernels from drm-next at commits 4dfd6486 and 4dfd6486^ (= 1b2eb710). I
found that 4dfd6486 showed the buggy behavior, while 1b2eb710 did not.
I did notice that a regression against this same commit was noticed and
apparently fixed in this commit:
commit fa4270d8e0257b4b76f11baa2866f4313d29aaf5
Author: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>>
Date: Wed Sep 30 19:21:34 2015 +0300
drm: Don't zero vblank timestamps from the irq handler
[...]
This fixes a regression from
4dfd64862ff852df drm: Use vblank timestamps to guesstimate how many
vblanks were missed
This commit was present in my local Frankenstein tree, as well as both drm-next
and drm-fixes, and (obviously) does not fix the bug I am reporting. The
problem
commit no doubt had other effects that were fixed by fa4270d8, but the
stuttering I am seeing was not fixed by it.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>