| Bug ID | 93147 |
|---|---|
| Summary | [regression bisected] Stuttering in games caused by commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed" |
| Product | DRI |
| Version | DRI git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | minor |
| Priority | medium |
| Component | DRM/Radeon |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | dawitbro@sbcglobal.net |
| CC | ville.syrjala@linux.intel.com |
Created attachment 120187 [details] 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ä <ville.syrjala@linux.intel.com> 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ä <ville.syrjala@linux.intel.com> 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.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
