Created attachment 112675 [details] 20150122_fifo_just_slowdown.log I'm experiencing slowdowns of the system usually on heavy usage of Chromium (running another app that use the GPU like Kodi or image editor will hasten the appearance of the slowdowns). The easiest way to reproduce is to open few tabs with allot of images. Although before 3.19 I had GPU hangs ( https://bugs.freedesktop.org/show_bug.cgi?id=83677 ) I did still encountered the slowdowns when using i915 kernel parameters to suppress the hangs so at least for me it's not a regression (at least from kernel 3.15). system: Acer C720, Haswell GT1, 2995U kernel: 3.19rc5 xf86-video-intel: 2.99.916 mesa: 10.4.2 xorg-server: 1.16.3 distro: Arch Linux x86_64 attached logs: 20150122_fifo_just_slowdown.log: journald output for the time frame of the slowdown 20150122_fifo.log : full journald output 20150122_Xorg.0.log: Xorg.0.log
Created attachment 112676 [details] 20150122_fifo.log
Created attachment 112677 [details] 20150122_Xorg.0.log
Created attachment 112687 [details] [review] Be more selective when caching back buffers This is the idea I had, but then realised you had TearFree. I still think it applies though. I have only compiled tested it. What would be very useful would be an Xorg.0.log with xf86-video-intel compiled with ./configure --enable-debug=full. I need to try and work out how it generated 2 buffers for the same surface with different strides - that shouldn't be possible!
* 1st test: xf86-video-intel-2.99.916 with flag --enable-debug=full It looks like adding the flag created another issue, X on vt1 crashing when I change to vt2. This test is just to show the X is crashing. logs: 20150123-01-xorg_fast_crash-journal.log 20150123-01-xorg_fast_crash-Xorg.0.log.log (7MB on Dropbox) * 2nd test: xf86-video-intel-2.99.916 with flag --enable-debug=full In this test I opened multiple tabs in Chromium with allot of images that I hope overloaded the GPU and generated the wanted debug info. logs: 20150123-02-gpu_slowdown-journal.log 20150123-02-gpu_slowdown-Xorg.3.log.log (100MB) * 3rd test: xf86-video-intel-2.99.916 with flag --enable-debug=full and with patch 0001-sna-dri2-Only-preserve-back-buffers-with-the-same-pi.patch Same as 2nd test but with the patch added. 20150123-03_with_patch-gpu_slowdown-journal.log 20150123-03_with_patch-gpu_slowdown-Xorg.0.log.log (50MB) I just archived the logs and uploaded the archive to Dropbox as even compressed the larger log still was above 3MB. https://www.dropbox.com/s/ve6oxegs21u22um/20150123-logs.tar.gz?dl=0
(In reply to dhead666 from comment #4) > * 1st test: xf86-video-intel-2.99.916 with flag --enable-debug=full > It looks like adding the flag created another issue, X on vt1 crashing when > I change to vt2. > This test is just to show the X is crashing. > logs: > 20150123-01-xorg_fast_crash-journal.log > 20150123-01-xorg_fast_crash-Xorg.0.log.log (7MB on Dropbox) There's a broken DBG there in 2.99.916. > * 2nd test: xf86-video-intel-2.99.916 with flag --enable-debug=full > In this test I opened multiple tabs in Chromium with allot of images that I > hope overloaded the GPU and generated the wanted debug info. > logs: > 20150123-02-gpu_slowdown-journal.log > 20150123-02-gpu_slowdown-Xorg.3.log.log (100MB) Hmm. We never did a forced crtc flip (i.e. all the front/back pitches were the same). I am not sure if you managed to reproduce the slowdown exactly. My guess is that you need fullscreen chromium? > * 3rd test: xf86-video-intel-2.99.916 with flag --enable-debug=full and with > patch 0001-sna-dri2-Only-preserve-back-buffers-with-the-same-pi.patch > Same as 2nd test but with the patch added. > 20150123-03_with_patch-gpu_slowdown-journal.log > 20150123-03_with_patch-gpu_slowdown-Xorg.0.log.log (50MB) All front/back pitches were equal. Again there was no forced crtc flips.
Any log output I can look for?
The function used to do a swap when back/front have different pitches is called sna_crtc_flip(). I would work with the normal ddx and verify the reproduction steps.
Created attachment 112716 [details] 20150123-04-gpu_slowdown-journal.log I hope this one is better. 4th test: xf86-video-intel-2.99.916 with flag --enable-debug=full Same as 2nd test multiple tabs in Chromium. logs: 20150123-04-gpu_slowdown-journal.log (attached) 20150123-04-gpu_slowdown-Xorg.0.log.log (540MB Dropbox) https://dl.dropboxusercontent.com/u/6902100/intel/20150123-04-gpu_slowdown-Xorg.0.log.log.tar.xz
Sorry, still no evidence of that earlier flipping between two of different strides. In the last dmesg though, you do appear to have hit a non-i915.ko memleak, could that be related to the slowdowns?
dhead666 (myfoolishgames@gmail.com), sorry about neglecting this for too long time. Is this still a problem for you? Can you please try to reproduce with the latest components? Chris - if you have new info related this, let us know.
(In reply to Jari Tahvanainen from comment #10) I shelved that laptop and stopped using it a while ago so I don't mind if this bug report would be closed. p.s. The reason for shelving the machine was that the battery was inflated, googling told me that I'm not the only one so maybe the reason is bad charging circuit (trickle charging when battery full as the machine was constantly connected to power for a couple of weeks) so I don't believe I would ever use it.
thanks for the reply and update, will be closing this one
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.