[Bug 84662] New: Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU
https://bugs.freedesktop.org/show_bug.cgi?id=84662
Bug ID: 84662 Summary: Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: adf.lists@gmail.com
R9270X PCIE 2.0 2 gig vram 4 gig ram.
Unreal demo Elemental only recently started working with git llvm/mesa, do no bisection done on these.
The demo even when working is very broken - constant 1/4 sec stutters with a couple of 1/2 - 1 sec.
But after -
commit 4439d469706699b4e69ef410ebc9115339f6e9e6 Author: Michel Dänzer michel.daenzer@amd.com Date: Thu Jul 31 18:43:49 2014 +0900
drm/radeon: Always flush the HDP cache before submitting a CS to the GPU
This ensures the GPU sees all previous CPU writes to VRAM, which makes it safe:
* For userspace to stream data from CPU to GPU via VRAM instead of GTT * For IBs to be stored in VRAM instead of GTT * For ring buffers to be stored in VRAM instead of GTT, if the HPD flush is performed via MMIO
There are far longer pauses of many seconds - run time to unreal logo on "good" is 3:45 on bad best 5:39 can be longer.
Screens to be attached show quite different vram/gtt usage between good and bad.
Related to
https://bugs.freedesktop.org/show_bug.cgi?id=82050
I bisected to the same commit in that bug, but applying the mesa patch
https://bugs.freedesktop.org/show_bug.cgi?id=82050#c19
doesn't help here.
CONFIG_CMA is not set.
Tried kernel org 3.17-rc7 as it was reported in above as working, but not for me.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #1 from Andy Furniss adf.lists@gmail.com --- Created attachment 107325 --> https://bugs.freedesktop.org/attachment.cgi?id=107325&action=edit dmesg on bad commit
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #2 from Andy Furniss adf.lists@gmail.com --- Created attachment 107326 --> https://bugs.freedesktop.org/attachment.cgi?id=107326&action=edit gallium hud on good - longer pause matches bump on vram/gtt graphs
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #3 from Andy Furniss adf.lists@gmail.com --- Created attachment 107327 --> https://bugs.freedesktop.org/attachment.cgi?id=107327&action=edit gallium hud on bad showing different vram gtt usage
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #4 from Andy Furniss adf.lists@gmail.com --- (In reply to Andy Furniss from comment #0)
I bisected to the same commit in that bug, but applying the mesa patch
https://bugs.freedesktop.org/show_bug.cgi?id=82050#c19
doesn't help here.
It seems that with current llvm/mesa that patch doesn't help Unigine Valley anymore.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #5 from smoki smoki00790@gmail.com --- (In reply to Andy Furniss from comment #3)
Created attachment 107327 [details] gallium hud on bad showing different vram gtt usage
Hmm whatever GTT starts fueling fps gows down to crawl... I can't run Elemental on Kabini have just 1-3 fps :D , but i am curios what happens for you in HUD when you just comment out this in r600_buffer_common.c:
default: /* Not listing GTT here improves performance in some apps. */ res->domains = RADEON_DOMAIN_VRAM; // flags |= RADEON_FLAG_GTT_WC; break; }
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #6 from smoki smoki00790@gmail.com --- I mean only that line of course:
// flags |= RADEON_FLAG_GTT_WC;
Just checked on valley so yeah, seems like anything about GTT does not like to be mentioned there as default ;)
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #7 from Andy Furniss adf.lists@gmail.com --- (In reply to smoki from comment #5)
(In reply to Andy Furniss from comment #3)
Created attachment 107327 [details] gallium hud on bad showing different vram gtt usage
Hmm whatever GTT starts fueling fps gows down to crawl... I can't run Elemental on Kabini have just 1-3 fps :D , but i am curios what happens for you in HUD when you just comment out this in r600_buffer_common.c:
default: /* Not listing GTT here improves performance in some apps. */ res->domains = RADEON_DOMAIN_VRAM; // flags |= RADEON_FLAG_GTT_WC; break; }
It looks roughly the same as the pic posted.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #8 from smoki smoki00790@gmail.com ---
And about Valley? If that is also the same, i don't know (might be dedicated vram does not trigger this or something) that one made a noticable difference for me :) Guessing you run all this without composite, because there as unsolvable sttuter for me with Unigine Valley on Linux and Windows with Aero, so when i comment out this it runs the same as in Windows - fist round only two slight sttuters (normal ones), then second time there is no stuter.
Tried now in Xonotic ultimate there is also one moment scene case where this show much less fps drop for me, that is also the case when gtt get fueled.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #9 from Chernovsky Oleg adonai@xaker.ru --- I experience the same freezes (1-1.3 sec) every 10 sec in any Valve Source engine-based games.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #10 from Chernovsky Oleg adonai@xaker.ru --- kernel 3.17-rc7, mesa 10.3, llvm 3.5.0
Can provide any additional info on request.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #11 from smoki smoki00790@gmail.com --- (In reply to Chernovsky Oleg from comment #9)
I experience the same freezes (1-1.3 sec) every 10 sec in any Valve Source engine-based games.
Well open a new bug, sttuter/freezes can be of varios cause... hardware combinations, APU or dedicated card, on AMD procesor on Intel so what governor used, composite or not, vblank on or not, spilling freezes, some particular effect unoptimized, etc... so various causes could be, this one is i think only about GTT load and fps drop because of that, so if you are sure it is because of that (check with GALLIUM_HUD=fps,GTT-usage) than that is the same bug.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #12 from Michel Dänzer michel@daenzer.net --- Created attachment 107391 --> https://bugs.freedesktop.org/attachment.cgi?id=107391&action=edit Make Mesa behave as if the kernel was older
(In reply to Andy Furniss from comment #3)
gallium hud on bad showing different vram gtt usage
That's very interesting indeed — on the 'good' screenshot, requested and actual VRAM usage match up almost perfectly, but on the 'bad' one, there's a large discrepancy.
With a current kernel, does the bad behaviour start with the same Mesa commit as the Unigine stutters?
The attached patch makes Mesa behave the same with current kernels as it does with older ones which don't have the bisected commit. Does that avoid the problem?
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #13 from Andy Furniss adf.lists@gmail.com --- (In reply to Michel Dänzer from comment #12)
Created attachment 107391 [details] [review] Make Mesa behave as if the kernel was older
(In reply to Andy Furniss from comment #3)
gallium hud on bad showing different vram gtt usage
That's very interesting indeed — on the 'good' screenshot, requested and actual VRAM usage match up almost perfectly, but on the 'bad' one, there's a large discrepancy.
With a current kernel, does the bad behaviour start with the same Mesa commit as the Unigine stutters?
I can't go back that far with Elemental due to llvm asserts.
The attached patch makes Mesa behave the same with current kernels as it does with older ones which don't have the bisected commit. Does that avoid the problem?
No, the patch makes no difference.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #14 from Andy Furniss adf.lists@gmail.com --- (In reply to Michel Dänzer from comment #12)
Created attachment 107391 [details] [review] Make Mesa behave as if the kernel was older
(In reply to Andy Furniss from comment #3)
gallium hud on bad showing different vram gtt usage
That's very interesting indeed — on the 'good' screenshot, requested and actual VRAM usage match up almost perfectly, but on the 'bad' one, there's a large discrepancy.
With a current kernel, does the bad behaviour start with the same Mesa commit as the Unigine stutters?
The attached patch makes Mesa behave the same with current kernels as it does with older ones which don't have the bisected commit. Does that avoid the problem?
More testing - incomplete but will post initial findings as I don't know when I'll finish.
I managed to get older mesa to build with new llvm by applying the build fixes.
With mesa on the commit before r600g,radeonsi: Set RADEON_GEM_NO_CPU_ACCESS flag for tiled BOs (I don't know yet exactly what mesa commit changed things)
I can with your patch or the stream revert get "good" behavior, this was with a kernel on the "bad" HPD kernel commit.
Will test more over time.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #15 from Chernovsky Oleg adonai@xaker.ru --- Created attachment 107438 --> https://bugs.freedesktop.org/attachment.cgi?id=107438&action=edit bad gtt usage (Borderlands 2)
(In reply to smoki from comment #11)
(In reply to Chernovsky Oleg from comment #9)
I experience the same freezes (1-1.3 sec) every 10 sec in any Valve Source engine-based games.
Well open a new bug, sttuter/freezes can be of varios cause... hardware combinations, APU or dedicated card, on AMD procesor on Intel so what governor used, composite or not, vblank on or not, spilling freezes, some particular effect unoptimized, etc... so various causes could be, this one is i think only about GTT load and fps drop because of that, so if you are sure it is because of that (check with GALLIUM_HUD=fps,GTT-usage) than that is the same bug.
I know what I'm talking about. It's this bug, so I've written here.
Here's the proof (Unreal Engine 3, though, I can provide it with any Valve game at will). Spikes on the GTT usage have corresponding falls of the FPS.
Radeon R7 260X (BONAIRE)
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #16 from Aaron B aaronbottegal@gmail.com --- Don't know what you guys are testing for exactly, but here's my chart for your consumption. R9 270X 2GB. Where I screen shot, the demo also just freezes. But, that's another issue for later. Here you go. I also have long pauses and freezes and everything.
http://i.imgur.com/K5uMaAr.jpg
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #17 from Michel Dänzer michel@daenzer.net --- Created attachment 107451 --> https://bugs.freedesktop.org/attachment.cgi?id=107451&action=edit ttm: Don't evict BOs outside of requested placement range
Does this kernel patch help?
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #18 from Andy Furniss adf.lists@gmail.com --- (In reply to Andy Furniss from comment #14)
With mesa on the commit before r600g,radeonsi: Set RADEON_GEM_NO_CPU_ACCESS flag for tiled BOs (I don't know yet exactly what mesa commit changed things)
I can with your patch or the stream revert get "good" behavior, this was with a kernel on the "bad" HPD kernel commit.
Will test more over time.
I haven't tried the patch yet. will do but I got some strange results last thing yesterday which will make me hesitant about declaring any patch good or bad.
I started resetting around in mesa and noticed unexpected goods - so I tried head and got a good noth with and without 1st patch.
Rebooted into 3.17-rc7 still good.
Did some recompiling of llvm/mesa as I had changed my normal setup slightly - got bad.
Repeated resetting mesa to older + patch got good, reset to head again, bad. Applied patch on head good, reversed patch on head - still good.
I am wondering at this time whether card is in some nice state so power cycle - still good. Boot into 3.18 still good, clean & recompile the same mesa without doing anything else - bad again. Still bad after power cycles.
I always make distclean + git clean -dfx when doing anything other than applying or reversing a patch.
So it seems that there is some randomness whether I am good or bad between mesa build/installs.
This does not however tally with my kernel bisect which seemed to go flawlessly.
I assume there is no card state that can survive power off.
So currently a bit confused - as reported by Christoph in the other bug, it is possible to have good with vanilla mesa/kernel, but apparently for me the "same" mesa can also be bad.
I did try more clean/rebuild cycles including single thread but am currently still bad.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #19 from Andy Furniss adf.lists@gmail.com --- (In reply to Michel Dänzer from comment #17)
Created attachment 107451 [details] [review] ttm: Don't evict BOs outside of requested placement range
Does this kernel patch help?
agd5f drm-next-3.18-wip + patch is still bad.
Bad can be a bit variable, but I would call it as one of the better bads and the vram usage is closer to a good - pic to follow.
Another observation - On good or bad the demo takes a while to get going.
Time to start of normal rendering on this patched kernel is around 2m5s
If I wiggle the window around while it's loading/stuck = 1m23s
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #20 from Andy Furniss adf.lists@gmail.com --- Created attachment 107493 --> https://bugs.freedesktop.org/attachment.cgi?id=107493&action=edit vram usage with Don't evict BOs outside of requested placement range
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #21 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to Andy Furniss from comment #18)
(In reply to Andy Furniss from comment #14)
With mesa on the commit before r600g,radeonsi: Set RADEON_GEM_NO_CPU_ACCESS flag for tiled BOs (I don't know yet exactly what mesa commit changed things)
I can with your patch or the stream revert get "good" behavior, this was with a kernel on the "bad" HPD kernel commit.
Will test more over time.
I haven't tried the patch yet. will do but I got some strange results last thing yesterday which will make me hesitant about declaring any patch good or bad.
I started resetting around in mesa and noticed unexpected goods - so I tried head and got a good noth with and without 1st patch.
Rebooted into 3.17-rc7 still good.
Did some recompiling of llvm/mesa as I had changed my normal setup slightly
- got bad.
Repeated resetting mesa to older + patch got good, reset to head again, bad. Applied patch on head good, reversed patch on head - still good.
I am wondering at this time whether card is in some nice state so power cycle - still good. Boot into 3.18 still good, clean & recompile the same mesa without doing anything else - bad again. Still bad after power cycles.
I always make distclean + git clean -dfx when doing anything other than applying or reversing a patch.
So it seems that there is some randomness whether I am good or bad between mesa build/installs.
This does not however tally with my kernel bisect which seemed to go flawlessly.
I assume there is no card state that can survive power off.
So currently a bit confused - as reported by Christoph in the other bug, it is possible to have good with vanilla mesa/kernel, but apparently for me the "same" mesa can also be bad.
I did try more clean/rebuild cycles including single thread but am currently still bad.
I'm also seeing this behavior while bisecting a different bug on a 7950... Probably related...
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #22 from Andy Furniss adf.lists@gmail.com --- (In reply to Alexandre Demers from comment #21)
So currently a bit confused - as reported by Christoph in the other bug, it is possible to have good with vanilla mesa/kernel, but apparently for me the "same" mesa can also be bad.
I did try more clean/rebuild cycles including single thread but am currently still bad.
I'm also seeing this behavior while bisecting a different bug on a 7950... Probably related...
It seems like current mesa doesn't build/install properly when patched without being totally clean.
The mesa patch in this bug on an already built tree does provoke -
make[3]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/drivers/radeon' CC r600_buffer_common.lo CCLD libradeon.la
but radeonsi_dri.so is not changed after make install.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #23 from Andy Furniss adf.lists@gmail.com --- (In reply to Andy Furniss from comment #13)
(In reply to Michel Dänzer from comment #12)
Created attachment 107391 [details] [review] [review] Make Mesa behave as if the kernel was older
The attached patch makes Mesa behave the same with current kernels as it does with older ones which don't have the bisected commit. Does that avoid the problem?
No, the patch makes no difference.
It seems I wasn't testing it - so the answer now is yes it does - in fact the goods I get with it on current kernels are better = less stutters than the goods I saw during the kernel bisect.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #24 from Michel Dänzer michel@daenzer.net --- (In reply to Andy Furniss from comment #22)
It seems like current mesa doesn't build/install properly when patched without being totally clean.
The mesa patch in this bug on an already built tree does provoke -
make[3]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/drivers/radeon' CC r600_buffer_common.lo CCLD libradeon.la
but radeonsi_dri.so is not changed after make install.
How about lib/gallium/radeonsi_dri.so in the build tree? That gets updated correctly for me. I don't use make install though, and I'm using an out-of-tree build, so maybe it's related to one of those. Anyway, please file another report about that.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #25 from Michel Dänzer michel@daenzer.net --- Created attachment 107542 --> https://bugs.freedesktop.org/attachment.cgi?id=107542&action=edit r600g,radeonsi: Use staging texture for transfers if any miplevel is tiled
https://bugs.freedesktop.org/show_bug.cgi?id=84662
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #107391|0 |1 is obsolete| |
--- Comment #26 from Michel Dänzer michel@daenzer.net --- Created attachment 107543 --> https://bugs.freedesktop.org/attachment.cgi?id=107543&action=edit winsys/radeon: Use separate caching buffer manager for each set of flags
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #27 from Michel Dänzer michel@daenzer.net --- Created attachment 107544 --> https://bugs.freedesktop.org/attachment.cgi?id=107544&action=edit drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM
Please try current Mesa with no patches except for the two I just attached, plus this kernel patch together with the previous kernel patch.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #28 from Andy Furniss adf.lists@gmail.com --- (In reply to Michel Dänzer from comment #24)
(In reply to Andy Furniss from comment #22)
It seems like current mesa doesn't build/install properly when patched without being totally clean.
The mesa patch in this bug on an already built tree does provoke -
make[3]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/drivers/radeon' CC r600_buffer_common.lo CCLD libradeon.la
but radeonsi_dri.so is not changed after make install.
How about lib/gallium/radeonsi_dri.so in the build tree? That gets updated correctly for me. I don't use make install though, and I'm using an out-of-tree build, so maybe it's related to one of those. Anyway, please file another report about that.
No, so it seems like it's make that fails to update that for me unless I have distcleaned.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #29 from Andy Furniss adf.lists@gmail.com --- (In reply to Michel Dänzer from comment #27)
Created attachment 107544 [details] [review] drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM
Please try current Mesa with no patches except for the two I just attached, plus this kernel patch together with the previous kernel patch.
With these it's better but still a bad. There are still pauses but they are a bit shorter, the start time without intervention is still around 2min. Start time on a good is around 1 min (assuming first run or mem caches flushed).
Hud wise - pic to follow the vram req/used match well, but the gtt is still different from a good.
On the upside - Unigine Valley is the best I've ever seen it - way better than what I've called as good in the past.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #30 from Andy Furniss adf.lists@gmail.com --- Created attachment 107560 --> https://bugs.freedesktop.org/attachment.cgi?id=107560&action=edit Hud with 2 kernel and 2 mesa patches better but still bad.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #31 from Andreas Hartmetz ahartmetz@gmail.com --- The second kernel patch "radeon-NO_CPU_ACCESS-placement.diff" does not apply to 3.17. Michel, looks like the patch is against some version only you have? Andy, I think you didn't apply at least the second kernel patch because it's simply not possible, most likely you ignored that all hunks failed.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #32 from Andreas Hartmetz ahartmetz@gmail.com --- OK, looks like the patch will apply to current Linux drm-next. Should have read comment 19. Sorry.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #33 from Andy Furniss adf.lists@gmail.com --- (In reply to Andy Furniss from comment #29)
(In reply to Michel Dänzer from comment #27)
Created attachment 107544 [details] [review] [review] drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM
Please try current Mesa with no patches except for the two I just attached, plus this kernel patch together with the previous kernel patch.
With these it's better but still a bad. There are still pauses but they are a bit shorter, the start time without intervention is still around 2min. Start time on a good is around 1 min (assuming first run or mem caches flushed).
Hud wise - pic to follow the vram req/used match well, but the gtt is still different from a good.
On the upside - Unigine Valley is the best I've ever seen it - way better than what I've called as good in the past.
I see the patches are on the list now, so just in case it wasn't expected -
Running patched kernel with unpatched mesa causes signal 7 when running games.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #34 from Luzipher luziphermcleod@yahoo.ie --- As todays commit 7b4276d7acf2e0f77044cb50caa6ad936fa78786, "r600g,radeonsi: Always use GTT again for PIPE_USAGE_STREAM buffers", refers to this bug: The patch helps tremendously against stuttering (~0.5s pause irregularly about twice a minute) in Borderlands 2. Kernel is an unmodified agd5f 3.18-next, hardware r9 290x.
Thanks !
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #35 from Chernovsky Oleg adonai@xaker.ru --- (In reply to Luzipher from comment #34)
The patch helps tremendously against stuttering (~0.5s pause irregularly about twice a minute) in Borderlands 2
So are the stutters completely gone or just became smaller?
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #36 from José Suárez j.suarez.agapito@gmail.com --- (In reply to Luzipher from comment #34)
As todays commit 7b4276d7acf2e0f77044cb50caa6ad936fa78786, "r600g,radeonsi: Always use GTT again for PIPE_USAGE_STREAM buffers", refers to this bug: The patch helps tremendously against stuttering (~0.5s pause irregularly about twice a minute) in Borderlands 2. Kernel is an unmodified agd5f 3.18-next, hardware r9 290x.
Thanks !
That mesa patch also reduced my stutter in BL2. Right now (I have just tested 5 minutes) I only get short lags when the game must load new areas/models (e.g. making a turn or entering new map zones). I'm on 3.17 rc7 (Radeon HD 7870).
The stutter was also very noticeable in EuroTruck Simulator 2, making the game almost unplayable. There still a few stutters in this game, so I would say the stutter is not completely gone (even though my BL2 experience is good).
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #37 from Michel Dänzer michel@daenzer.net --- Comments about Borderlands 2 should go to bug 84570.
(In reply to Andy Furniss from comment #33)
Running patched kernel with unpatched mesa causes signal 7 when running games.
I fixed that in the kernel patch I posted to the dri-devel list.
So I finally convinced myself that using VRAM for PIPE_USAGE_STREAM buffers is not a good idea, at least not at this time, and pushed the Mesa change which makes those use GTT again. But while trying to avoid that, I found and fixed a fair number of other issues, so hopefully the end result will be even better than before. :)
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #38 from Michel Dänzer michel@daenzer.net --- (In reply to José Suárez from comment #36)
The stutter was also very noticeable in EuroTruck Simulator 2, making the game almost unplayable. There still a few stutters in this game, so I would say the stutter is not completely gone (even though my BL2 experience is good).
Please file your own report about EuroTruck Simulator 2, preferably with GALLIUM_HUD screenshots like here.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #39 from Michel Dänzer michel@daenzer.net --- Resolving, please reopen if there are remaining issues with the Elemental demo.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
Andy Furniss adf.lists@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |---
--- Comment #40 from Andy Furniss adf.lists@gmail.com --- (In reply to Michel Dänzer from comment #39)
Resolving, please reopen if there are remaining issues with the Elemental demo.
It's still not right for me and never has been.
I haven't had much time to test recently, but what testing I did it seems that some of it may be when it loads from disk/disk cache. Maybe because I only have 4G RAM it's worse for me - but then I don't know why it still messes up from cache.
Last night I updated kernel to agd5f 3.19-wip and current mesa, after applying the mesa patches I got a lockup/crash. I hadn't retarted X though so glamor was using vanilla. I didn't crash instantly - first run was OK, and I haven't had time yet to see if it's just something new with different mesa/kernel, or if the patches + 3.19 are the cause.
Are the mesa patches still valid?
I'll attach the log, initially it was just that elemental didn't start, I was still OK, could switch desktops and use top to see it was maxing a single core, after a while I tried to start sysprof, which segfaulted, after that I was unstable eg. free hung and I tried to quit X but hung then I SysRqd.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #41 from Andy Furniss adf.lists@gmail.com --- Created attachment 107863 --> https://bugs.freedesktop.org/attachment.cgi?id=107863&action=edit Kernel errors with mesa patched + agd5f drm-next-3.19
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #42 from Michel Dänzer michel@daenzer.net --- (In reply to Andy Furniss from comment #40)
It's still not right for me and never has been.
Define 'right'. What's the target we're aiming for here?
Last night I updated kernel to agd5f 3.19-wip and current mesa, after applying the mesa patches I got a lockup/crash.
Please file another report about that.
Are the mesa patches still valid?
They're in Git master now.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #43 from Andy Furniss adf.lists@gmail.com --- (In reply to Michel Dänzer from comment #42)
(In reply to Andy Furniss from comment #40)
It's still not right for me and never has been.
Define 'right'. What's the target we're aiming for here?
Last night I updated kernel to agd5f 3.19-wip and current mesa, after applying the mesa patches I got a lockup/crash.
Please file another report about that.
Haven't had much time, but I have failed to reproduce so far with updated mesa (and I am making sure to restart X now so glamor is not running different code)
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #44 from Andy Furniss adf.lists@gmail.com --- (In reply to Michel Dänzer from comment #42)
(In reply to Andy Furniss from comment #40)
It's still not right for me and never has been.
Define 'right'. What's the target we're aiming for here?
It's still stuttery, but it could be my 4G mem/the way the game loads.
If I run from clean most of the stutters/long start time correspond with "vmstat 1" showing disk activity. It seems having 4 gig (swap is off to avoid extra disk use) it seems I don't have enough ram to disk cache the whole demo. If I stop it after a while I can get the first bit cached (ie. I can run it without vmstat 1 showing anything), but it's still stuttery in the places where it would be loading from disk were it first run.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #45 from Andy Furniss adf.lists@gmail.com --- (In reply to Andy Furniss from comment #43)
(In reply to Michel Dänzer from comment #42)
(In reply to Andy Furniss from comment #40)
It's still not right for me and never has been.
Define 'right'. What's the target we're aiming for here?
Last night I updated kernel to agd5f 3.19-wip and current mesa, after applying the mesa patches I got a lockup/crash.
Please file another report about that.
Haven't had much time, but I have failed to reproduce so far with updated mesa (and I am making sure to restart X now so glamor is not running different code)
Ignore that, I just reproduced it, will file a new bug, though I am a few days old on mesa/kernel now.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #46 from Michel Dänzer michel@daenzer.net --- (In reply to Andy Furniss from comment #44)
If I stop it after a while I can get the first bit cached (ie. I can run it without vmstat 1 showing anything), but it's still stuttery in the places where it would be loading from disk were it first run.
Sounds like it's loading new content in those places. Doesn't that cause stutter with other drivers?
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #47 from Andy Furniss adf.lists@gmail.com --- (In reply to Michel Dänzer from comment #46)
(In reply to Andy Furniss from comment #44)
If I stop it after a while I can get the first bit cached (ie. I can run it without vmstat 1 showing anything), but it's still stuttery in the places where it would be loading from disk were it first run.
Sounds like it's loading new content in those places. Doesn't that cause stutter with other drivers?
Hard for me to test fglrx on my setup, but soon I should have more ram to play with.
The recent changes to to agd5f 3.19-wip seem to have provoked a new issue - haven't had time to find a commit yet.
Will attach a screen showing that near the end of the demo there is a new really long pause (graph doesn't really show length, but it was around 10 sec) that corresponds to a big move from vram to gtt.
Other demos eg. valley don't show any issues and run well.
IIRC there is already a bug somewhere about the rendering issue (common to most unreal demos) that makes part of the logo black in the screen shot.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #48 from Andy Furniss adf.lists@gmail.com --- Created attachment 108866 --> https://bugs.freedesktop.org/attachment.cgi?id=108866&action=edit new issue long pause at end of demo
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #49 from Andy Furniss adf.lists@gmail.com --- (In reply to Andy Furniss from comment #48)
Created attachment 108866 [details] new issue long pause at end of demo
Caused by drm/mm: Remove DRM_MM_SEARCH_BEST
https://bugs.freedesktop.org/show_bug.cgi?id=84662
Benjamin Bellec b.bellec@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |b.bellec@gmail.com
--- Comment #50 from Benjamin Bellec b.bellec@gmail.com --- I think I'm hitting a similar issue on a RV770 (Radeon HD4850) hardware, while playing the game Left 4 Dead 2.
I was on Fedora 19 (kernel 3.14) and upgraded to Fedora 21 (kernel 3.17). Since this time, the game became unplayable due to GPU lockup. See the dmesg in attachement.
Here is the summary of the tests I then performed on a fresh Fedora 20 install : kernel 3.11 + mesa 10.5-devel + sb = OK kernel 3.17 + mesa 10.5-devel + sb = BAD kernel 3.17 + mesa 10.5-devel + nosb = OK kernel 3.17 + mesa 10.3.3 + sb = BAD (worse, 3 times more lockup)
I'm not skilled to compile/install a custom kernel, so I will just try to download a 3.16 kernel from koji when the site will be up again, in order to see if the issue appeared with 3.17.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #51 from Benjamin Bellec b.bellec@gmail.com --- Created attachment 111191 --> https://bugs.freedesktop.org/attachment.cgi?id=111191&action=edit dmesg while playing L4D2 on a RV770 with kernel 3.17.7
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #52 from Benjamin Bellec b.bellec@gmail.com --- Sorry, after testing several kernel, my issue is actually related to the 3.14 series. I will open another bug for that.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #53 from Michel Dänzer michel@daenzer.net --- The latest version of the Elemental demo (and many other UE4 demos, in fact) seems to run much smoother in general for me. Andy, how's that for you?
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #54 from Andy Furniss adf.lists@gmail.com --- Created attachment 111966 --> https://bugs.freedesktop.org/attachment.cgi?id=111966&action=edit elemental stalls near end with large vram -> gtt move
Generally the new version is a bit better, it's still not right, it has glitches but they are shorter.
I have 8 Gig ram now so can run from tmpfs to exclude the glitching being caused by disk activity.
There is sometimes a new issue very near the end where there is a chance of a multi second stall corresponding to vram -> gtt move as in the screenshot.
This didn't happen at all the first couple of times I tested.
The third time only 200meg was moved the fourth is this shot.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #55 from Michel Dänzer michel@daenzer.net --- Does http://cgit.freedesktop.org/mesa/mesa/commit/?id=a338dc01866ce50bf7555ee8dc0... help for this by any chance?
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #56 from Andy Furniss adf.lists@gmail.com --- (In reply to Michel Dänzer from comment #55)
Does http://cgit.freedesktop.org/mesa/mesa/commit/ ?id=a338dc01866ce50bf7555ee8dc08491c7f63b585 help for this by any chance?
No, it's the same on current Mesa head.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
--- Comment #57 from Michel Dänzer michel@daenzer.net --- I'm currently getting a "run time to unreal logo" of just over three minutes on my Kaveri. How about you, Andy? You said 3:45 is "good", so if it's below that now, this report can be resolved, right? :)
AFAICT the remaining pauses are mostly due to delayed shader compiles, which Marek has been working on reducing.
https://bugs.freedesktop.org/show_bug.cgi?id=84662
Andy Furniss adf.lists@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED
--- Comment #58 from Andy Furniss adf.lists@gmail.com --- (In reply to Michel Dänzer from comment #57)
I'm currently getting a "run time to unreal logo" of just over three minutes on my Kaveri. How about you, Andy? You said 3:45 is "good", so if it's below that now, this report can be resolved, right? :)
AFAICT the remaining pauses are mostly due to delayed shader compiles, which Marek has been working on reducing.
Yes, this should be resolved -
I can't test 270X as it died and I now have a Tonga (so can't compare times/glitching due to low clocks.
IIRC the "big" glitches were fixed with only smaller ones remaining.
Since I got the Tonga I tried with fglrx and there are some glitches with that, so maybe the demo its self is "special".
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org