| Bug ID | 84662 |
|---|---|
| Summary | Long pauses with Unreal demo Elemental on R9270X since : Alwa= ys 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=C3=A4nzer <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 &q= uot;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=20 https://bugs.freedesktop.org/show_bug.c= gi?id=3D82050 I bisected to the same commit in that bug, but applying the mesa patch https://bugs.freedesktop.org/show_b= ug.cgi?id=3D82050#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 f= or me.
Created attachment 107326 [details]
gallium hud on good - longer pause matches bump on vram/gtt graphs
Created attachment 107327 [details]
gallium hud on bad showing different vram gtt usage
(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.
(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; }
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 ;)
(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 >=20 > 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 happen= s for > you in HUD when you just comment out this in r600_buffer_common.c: >=20 > default: > /* Not listing GTT here improves performance in some apps. */ > res->domains =3D RADEON_DOMAIN_VRAM; > // flags |=3D RADEON_FLAG_GTT_WC; > break; > } It looks roughly the same as the pic posted.
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.
I experience the same freezes (1-1.3 sec) every 10 sec in any Valve Source engine-based games.
kernel 3.17-rc7, mesa 10.3, llvm 3.5.0 Can provide any additional info on request.
(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.
Created attachment 107391 [details] [review] Make Mesa behave as if the kernel was older (In reply to Andy Furniss from comme= nt #3) > gallium hud on bad showing different vram gtt us= age That's very interesting indeed =E2=80=94 on the 'good' screenshot, requeste= d 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 comm= it as the Unigine stutters? The attached patch makes Mesa behave the same with current kernels as it do= es with older ones which don't have the bisected commit. Does that avoid the problem?
(In reply to Michel D=C3=A4nzer from comment #12) > Created attachment 107391 [details] [review] [review] > Make Mesa behave as if the kernel was older >=20 > (In reply to Andy Furniss from = comment #3) > > gallium hud on bad showing different vram gtt usage >=20 > That's very interesting indeed =E2=80=94 on the 'good' screenshot, req= uested and > actual VRAM usage match up almost perfectly, but on the 'bad' one, the= re's a > large discrepancy. >=20 > With a current kernel, does the bad behaviour start with the same Mesa > commit as the Unigine stutters? >=20 > 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 a= void > the problem? More testing - incomplete but will post initial findings as I don't know wh= en I'll finish. I managed to get older mesa to build with new llvm by applying the build fi= xes. 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, t= his was with a kernel on the "bad" HPD kernel commit. Will test more over time.
Created attachment 107438 [details] 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)
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
Created attachment 107451 [details] [review] ttm: Don't evict BOs outside of requested placement range Does this kernel patch help?
(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.
(In reply to Michel D=C3=A4nzer from comment #17) > Created attachment 107451 [details] [review] [review] > ttm: Don't evict BOs outside of requested placement range >=20 > 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 =3D 1m23s
(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...
(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.
(In reply to Andy Furniss from comment #13) > (In reply to Michel D=C3=A4nzer from comment #12) > > Created attachment 107391 [details] [review] [review] [review] > > Make Mesa behave as if the kernel was older > > The attached patch makes Mesa behave the sa= me with current kernels as it > > does with older ones which don't have the bisected commit. Does t= hat avoid > > the problem? >=20 > No, the patch makes no difference. It seems I wasn't testing it - so the answer now is yes it does - in fact t= he goods I get with it on current kernels are better =3D less stutters than the goods I saw during the kernel bisect.
