[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #143 from Aaron B --- So, what to do with this bug report? Keep it open, and when you guys think it may be fixed with a commit, just ask here? I just re-built Mesa with today's commits, and it's just back to crashing like crazy. :) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/8ce2a626/attachment.html>
[Bug 84663] New: high cpu usage, poor performance in Borderlands 2 with radeonsi, PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=84663 Bug ID: 84663 Summary: high cpu usage, poor performance in Borderlands 2 with radeonsi, PRIME Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: haagch at frickel.club Created attachment 107328 --> https://bugs.freedesktop.org/attachment.cgi?id=107328&action=edit sysprof recording from borderlands 2 only 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wimbledon XT [Radeon HD 7970M] (rev ff) xorg stable, mesa git, linux 3.17-rc7. I have had something similar in some games I think, but most recently with Borderlands 2. Here is a random screenshot with the HUD fps display from someone with a HD 7870 that shows that it runs mostly with 60 fps: https://i.imgur.com/qH0sBkl.jpg And here is a short clip of how it runs for me that shows it runs with 20-30 fps: https://www.youtube.com/watch?v=ZeZreRntt3k Radeontop says that the gpu is only used to ~30%. While running Borderlands 2 the CPU usage is always at 100+% on my i7 3632qm. I was undecided whether to report this here, but the difference is quite large so I thought I'd give it a try because I think the game itself is not supposed to use this much cpu time, so maybe it has something to do with the driver. Theories: < glennk> guessing from that output that the game engine uses a lot of occlusion queries and is stalling on them I haven't really found anything to test that yet. < agd5f> haagch, hybrid laptops have to do a lot of extra copying to get the frame from the rendering GPU to the display GPU I hope that the overhead is not *that* large because losing 70+% of gpu time would make it kind of useless for the affected games. Fortunately many (most?) games run much better, for example unigine valley shows good gpu usage: https://www.youtube.com/watch?v=sLWvYJlfvWM which makes me believe that there is a specific bottleneck. Attached is a sysprof profile of borderlands 2 but I don't know which of it is normal (like 25% total cpu time for glDrawRangeElements?). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/61826d27/attachment.html>
[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init
https://bugzilla.kernel.org/show_bug.cgi?id=85491 --- Comment #9 from Zermond --- Created attachment 152411 --> https://bugzilla.kernel.org/attachment.cgi?id=152411&action=edit journalctl with 3.17 kernel -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init
https://bugzilla.kernel.org/show_bug.cgi?id=85491 --- Comment #8 from Zermond --- Created attachment 152401 --> https://bugzilla.kernel.org/attachment.cgi?id=152401&action=edit dmesg with 3.17 kernel -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init
https://bugzilla.kernel.org/show_bug.cgi?id=85491 --- Comment #7 from Zermond --- (In reply to Alex Deucher from comment #6) > (In reply to Zermond from comment #5) > > (In reply to Alex Deucher from comment #4) > > > Can you narrow down when the problem started? Even better, can you > > > bisect? > > > > As soon as I updated the kernel. At version 3.11, everything was fine with > > version 3.16 of the problem. > > Can you narrow it down any more than that? Does 3.12 work ok? 3.13? etc. I'm sorry, I do not know how to use the old kernel. I installed 3.17, but it also did not work. I installed the boot loader to the kernel boot 3.17 1 level and made dmesg, journalctl -xn I am attached. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #78 from Andy Furniss --- (In reply to Andy Furniss from comment #77) > Ok, I'm going to open a new bug for this one when I have time to test more. Bisected to the same kernel commit as this one, but did a new bug - https://bugs.freedesktop.org/show_bug.cgi?id=84662 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/769ed368/attachment.html>
[Bug 84662] 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 --- Comment #3 from Andy Furniss --- Created attachment 107327 --> https://bugs.freedesktop.org/attachment.cgi?id=107327&action=edit gallium hud on bad showing different vram gtt usage -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/4e100ee2/attachment.html>
[Bug 84662] 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 --- Comment #2 from Andy Furniss --- 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 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/58af1718/attachment.html>
[Bug 84662] 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 --- Comment #1 from Andy Furniss --- Created attachment 107325 --> https://bugs.freedesktop.org/attachment.cgi?id=107325&action=edit dmesg on bad commit -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/138710c9/attachment.html>
[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 at lists.freedesktop.org Reporter: adf.lists at 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 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. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/6d67d42e/attachment.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 ?ukasz Krzy?ak changed: What|Removed |Added Attachment #106562|0 |1 is obsolete|| --- Comment #106 from ?ukasz Krzy?ak --- Created attachment 107323 --> https://bugs.freedesktop.org/attachment.cgi?id=107323&action=edit kernel log with tahiti-fix after starting and killing Xorg.bin -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/4b330a81/attachment-0001.html>
[Bug 78788] [Radeon\VCE] Performance regression after using VCE
https://bugs.freedesktop.org/show_bug.cgi?id=78788 Iaroslav Andrusyak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Iaroslav Andrusyak --- with kernel 3.17.0-rc7 all works fine. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/72d9052f/attachment.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 ?ukasz Krzy?ak changed: What|Removed |Added Attachment #106563|0 |1 is obsolete|| --- Comment #105 from ?ukasz Krzy?ak --- Created attachment 107322 --> https://bugs.freedesktop.org/attachment.cgi?id=107322&action=edit startx out with -verbose 9, fix v5 + printf's -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/9995db18/attachment.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #104 from ?ukasz Krzy?ak ---
I've tested tahiti-fix.patch for kernel with version 3.16-3, it does not help.
I've added debug info to it:
radeonsi cgts_tcc_disable: -268435456
that's the value of register for my card.
patch v5 also doesn't resolve problem, after adding additional prinf's it seems
that si_init_config goes into:
if (rb_mask && util_bitcount(rb_mask) >= num_rb) {
so si_write_harvested_raster_configs is not called
after commenting out that if, xorg logs from si_write_harvested_raster_configs
shows:
Original raster_config = 0x2a00126a, rb_mask = 0xff
attachments:
- startx-0410-2.out - output of startx with -verbose 9, tahiti-fix kernel,
mesa-git (c74be01e80fcdd7feabc0f27df4aebe66abb626e) with patchv5 + additional
fprintf's
- kernel-0410-2.out - dmesg, additional debug in tahiti-fix: radeonsi
cgts_tcc_disable
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/5c0bebb3/attachment.html>
[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off
https://bugzilla.kernel.org/show_bug.cgi?id=83331 --- Comment #9 from Klaus Kusche --- Anything else I can try? Any debug outputs I could add? I think we are hunting two different problems: 1.) Why does the internal display crash after a dpms standby/suspend/off? This is extremely annoying, because it happens all the time while giving my presentations in the lecture halls, and with all the students in front of me, blindly fixing things is irritating. Without knowing the code, I'd assume that this should be easy to find: What's the difference in code paths between "dpms on" and "xrandr off+auto"? "xrandr off+auto" obviously does something more than "dpms on"? Couldn't this be simply added to "dpms on", too? Note that just "xrandr auto" alone does not fix the crashed display, a "xrandr off" is needed first. 2.) Why do the switch from VGA to framebuffer during boot and an "xrandr off+auto" both take ages (> 5 sec)? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 84614] radeon gpu crash /kernel crash when using dynamic light in borderlands 2
https://bugs.freedesktop.org/show_bug.cgi?id=84614 --- Comment #3 from filipp.andjelo at gmail.com --- Almost the same problem here, full system crash, but I can't even reach the main menu. System is completely dead on the first rendering frame of the scene you see in the main menu. Running HD7850 on linux 3.16.3, mesa 10.3 and llvm 3.5 (all stock) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/29d7583c/attachment.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #14 from Andy Furniss --- (In reply to Alexandre Demers from comment #13) > (In reply to Jos? Su?rez from comment #12) > > I compiled 3.17rc7 with the packet0 patch. You can find a dmesg log just > > above this message. > > > > Running firefox with RADEON_DUMP_CS=1 didn't produce any dump. Is it because > > I need the mesa dbg packages (not currently installed)? I guess it should > > appear on the console output, right? Or is it writen to a file? (Sorry about > > those noob questions. First time debugging this kind of problem...) > > It seems pretty much the same "signature" as the CS dump I had attached. > > The CS dump is written in your dmesg log or systemd journal if I remember > correctly. > > On my side, I've been playing with a 3.16 with the patch applied and I've > been unable to get a Packet0 error. So, it seems to have been introduced > somewhere between 3.16 and 3.17-rc7. I'll try to bisect as soon as I'll have > time (maybe not before next week). FWIW I just grepped my kern.log for Packet0 and have 47 between Jul 4 and now. Doing grep Packet0 /var/log/kern.log -B 860 | grep Microcode Only comes up with pitcairn (lowercase = new firmware = 3.17) -- You are receiving this mail because: You are the assignee for the bug. -- next part ------ An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/33da63d0/attachment.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #13 from Alexandre Demers --- (In reply to Jos? Su?rez from comment #12) > I compiled 3.17rc7 with the packet0 patch. You can find a dmesg log just > above this message. > > Running firefox with RADEON_DUMP_CS=1 didn't produce any dump. Is it because > I need the mesa dbg packages (not currently installed)? I guess it should > appear on the console output, right? Or is it writen to a file? (Sorry about > those noob questions. First time debugging this kind of problem...) It seems pretty much the same "signature" as the CS dump I had attached. The CS dump is written in your dmesg log or systemd journal if I remember correctly. On my side, I've been playing with a 3.16 with the patch applied and I've been unable to get a Packet0 error. So, it seems to have been introduced somewhere between 3.16 and 3.17-rc7. I'll try to bisect as soon as I'll have time (maybe not before next week). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/876fe29c/attachment-0001.html>
[Bug 84648] Lag/Pause When VRAM->GTT or GTT->VRAM transfer occur
https://bugs.freedesktop.org/show_bug.cgi?id=84648 Mathieu Belanger changed: What|Removed |Added Attachment #107298|0 |1 is obsolete|| --- Comment #1 from Mathieu Belanger --- Created attachment 107299 --> https://bugs.freedesktop.org/attachment.cgi?id=107299&action=edit Gallium hud screenshot -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/79cbcd7c/attachment.html>
[Bug 84648] New: Lag/Pause When VRAM->GTT or GTT->VRAM transfer occur
https://bugs.freedesktop.org/show_bug.cgi?id=84648 Bug ID: 84648 Summary: Lag/Pause When VRAM->GTT or GTT->VRAM transfer occur Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: b747xx at gmail.com Created attachment 107298 --> https://bugs.freedesktop.org/attachment.cgi?id=107298&action=edit HUD showing FPS drop and mem transfer I got an lag / pause (stopping for one to +- 5 seconds) when I get transfer of memory from the VRAM to GTT and the opposite, the GTT to VRAM. It append only on Minecraft (No problem with EVE-Online & Source Engine games), even sometime when it is not on the screen, and in that case, the whole X ui stay locked until the transfer finish. It usually go fine until the VRAM reach between 280-300MB and it start playing with the GTT. The bug Append with: Kernel 3.17-rc2+ (did not test the RC1, 3.16 was fine) Mesa GIT newer than somewhere in the beginning of september. Note that these don't need to be recent for the two. A old kernel with a new Mesa and a new Kernel with a old Mesa recreate the problem. Having the latest GIT of the two don't fix the problem. (I did in fact update libdrm, llvm, mesa, xf86 after upgrading the kernel to rc2, thinking something changed and was requiring a newer mesa. I have attached a screenshot with the Gallium hud showing the FPS and memory. PS : I thought initially that it was the same as BUG #82050 but got requested to file another bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141004/b5c43a6d/attachment.html>
