[Bug 85454] New: Unigine Sanctuary with Wine crashes on Mesa Git
https://bugs.freedesktop.org/show_bug.cgi?id=85454 Bug ID: 85454 Summary: Unigine Sanctuary with Wine crashes on Mesa Git 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: commendsarnex at gmail.com Created attachment 108416 --> https://bugs.freedesktop.org/attachment.cgi?id=108416=edit backtrace Hi guys, When testing the Unigine Sanctuary windows benchmark, it crashes during the inital loading screen with normal wined3d, with a crash in radeonsi.so. With gallium nine, it works perfectly with no crashes. I am using Mesa Git on a Radeon HD 7950. I can test any patches. The backtrace is attached. Thanks! -- 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/20141025/68b3aa86/attachment.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #108 from madcatx at atlas.cz --- Created attachment 108412 --> https://bugs.freedesktop.org/attachment.cgi?id=108412=edit glxgears output with "Fix v5" in place on 7730 LE -- 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/20141025/58e6d4ce/attachment.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #107 from madcatx at atlas.cz --- I finally updated to pre-release Fedora 21 which packages mesa 10.3. The "v5 fix" seems to work OK with my 7730 LE (Verde chip). glxgears output attached. (Is there any reason why would the desktop animations feel much smoother and snappier than with the old hackofix?) -- 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/20141025/34e88a92/attachment.html>
[Bug 86891] New: AMD/ATI Tahiti XT 7970 - long lags/stutters in games
https://bugzilla.kernel.org/show_bug.cgi?id=86891 Bug ID: 86891 Summary: AMD/ATI Tahiti XT 7970 - long lags/stutters in games Product: Drivers Version: 2.5 Kernel Version: >=3.17 until 3.18rc1 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: bu9zilla at gmail.com Regression: No Created attachment 155001 --> https://bugzilla.kernel.org/attachment.cgi?id=155001=edit Kernel config of 3.18rc1 Since kernel Version 3.17 and greater (last tested with kernel-3.18rc1) i'm encounter very long stutters/lags (1-2sec) when i'm gaming various games. (eg borderlands2) Usually i'm doing a unigine valley benchmark test after i install a new kernel to see how much more performance i get and usually the benchmarks are very promising. (FPS continuous rises) :) However since kernel-3.17 i get really long stutters/lags in my tests. FPS doesn't really go done, they rise even more (max fps), but i also always get really serious stutters, where i have to wait about 1-2 sec until the graphic's continue to render. This is really annoying. Besides getting higher max fps in Unigine i also get new lowest min fps. Below a short overview of my benchmark tests (with date): Linux 3.16.2-gentoo x86_64 - 20140914 FPS: 17.4 Score: 727 Min FPS: 8.2 Max FPS: 28.1 Linux 3.17.0-rc6 x86_64 - 20140927 FPS: 16.2 Score: 680 Min FPS: 4.2 Max FPS: 32.1 Linux 3.18.0-rc1 x86_64 - 20141025 FPS: 15.9 Score: 666 Min FPS: 3.2 Max FPS: 34.4 Today's test (same software stack, just different kernels) Linux 3.18.0-rc1 x86_64 Linux 3.16.3-gentoo x86_64 FPS: 15.9 18.7 Score: 666 782 Min FPS: 3.28.3 Max FPS: 34.4 30.5 Usually downgrading to kernel-3.16 always solves the problem for me which is why i think the problem has todo with the kernel side of the ati driver. I've also tried the new firmware blobs for my graphics card (TAHITI_ce.bin -> tahiti_ce.bin, ...), they didn't make any differences. My system: Graphic related packages installed: media-libs/mesa-10.3.1 sys-devel/llvm-3.5.0 sys-kernel/linux-firmware-20140902 x11-drivers/xf86-video-ati-7.5.0 x11-libs/libdrm-2.4.58 asterix michael # emerge --info Portage 2.2.14 (python 3.3.5-final-0, default/linux/amd64/13.0, gcc-4.8.3, glibc-2.19-r1, 3.16.3-gentoo x86_64) = System uname: Linux-3.16.3-gentoo-x86_64-AMD_FX-tm-8350_Eight-Core_Processor-with-gentoo-2.2 KiB Mem:16356140 total, 11196304 free KiB Swap:8388600 total, 8388600 free Timestamp of tree: Sat, 25 Oct 2014 04:30:01 + ld GNU ld (Gentoo 2.24 p1.4) 2.24 app-shells/bash: 4.3_p30 dev-lang/perl:5.20.1-r1 dev-lang/python: 2.7.8, 3.3.5-r1 dev-util/cmake: 3.0.2 dev-util/pkgconfig: 0.28-r2 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.13.1 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6, 1.14.1 sys-devel/binutils: 2.24-r3 sys-devel/gcc:4.8.3 sys-devel/gcc-config: 1.8 sys-devel/libtool:2.4.2-r1 sys-devel/make: 4.1-r1 sys-kernel/linux-headers: 3.17 (virtual/os-headers) sys-libs/glibc: 2.19-r1 Repositories: gentoo local sunrise x11 tox-overlay ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* - at EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=bdver2 -mprefer-avx128"
[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance
https://bugs.freedesktop.org/show_bug.cgi?id=82201 --- Comment #42 from Sebastian Parborg --- I also get the "Invalid ROM contents" message btw. -- 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/20141025/843a3c1b/attachment.html>
[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance
https://bugs.freedesktop.org/show_bug.cgi?id=82201 --- Comment #41 from Sebastian Parborg --- For me, it first stated happening when I updated mesa. But now it seems to happen at random. BTW I have managed to get the GPU to reclock again by booting with fglrx and running Unigine Heaven till I hear the fans spin up. After I then reboot to radeon I have got it to reclock again. This combo has worked for me three of three times now. At first I just thought that simply bootin with fglrx solved it. But as that didn't work 100% of the time, I thought that perhaps simply booting with it was not enough. However the test pool size is quite small so I might just have gotten lucky so far with the Heaven method. Can you check if you get the same result, but with windows? -- 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/20141025/51716c47/attachment.html>
[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance
https://bugs.freedesktop.org/show_bug.cgi?id=82201 --- Comment #40 from Kai --- (In reply to Sebastian Parborg from comment #38) > However I do not have windows installed at all. So I think we can rule that > one out. > > For me it seem like the card loses the ability to reclock after a while. > However I have regained the reclocking ability by rebooting to use fgrlx and > then reboot back to use radeon... > > I'm just as confused as you are why it stops working. :S (In reply to Sebastian Parborg from comment #39) > I take the fglrx stuff back. Seems like I were lucky the times that it > worked... Sounds right. It has been so annoying to not be able to come up with at least one 100 % case. For me the non-reclocking GPU happens relatively reliable after coming off a Windows boot or after installing a new initrd (preferably for a new kernel, but regular updates can trigger it as well). Then the most "reliable" way to get back a reclocking GPU is: - execute: echo 1 > /sys/bus/pci/devices//rom && cat /sys/bus/pci/devices//rom > /tmp/vbios.dump && echo 0 > /sys/bus/pci/devices//rom - reboot and when I'm prompted for the BIOS/UEFI password, which I've set for system boots, press the power button for a few seconds until the system powers off. - boot normally - in case the GPU doesn't reclock yet: repeat This is so esoteric and sounds completely arbitrary. I have no clue what stars need to align to get a reclocking GPU. If I have one, the performance is good in various games. Also, on every boot I'm seeing a line "radeon :01:00.0: Invalid ROM contents": [ 18.843246] [drm] initializing kernel modesetting (HAWAII 0x1002:0x67B1 0x1682:0x9295). [ 18.843260] [drm] register mmio base: 0xF7E0 [ 18.843261] [drm] register mmio size: 262144 [ 18.843267] [drm] doorbell mmio base: 0xF000 [ 18.843269] [drm] doorbell mmio size: 8388608 [ 18.843293] radeon :01:00.0: Invalid ROM contents [ 18.843351] ATOM BIOS: C67111 [ 18.843405] radeon :01:00.0: VRAM: 4096M 0x - 0x (4096M used) [ 18.843408] radeon :01:00.0: GTT: 1024M 0x0001 - 0x00013FFF [ 18.843410] [drm] Detected VRAM RAM=4096M, BAR=256M [ 18.843411] [drm] RAM width 512bits DDR [ 18.843475] [TTM] Zone kernel: Available graphics memory: 8215252 kiB [ 18.843477] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 18.843479] [TTM] Initializing pool allocator [ 18.843485] [TTM] Initializing DMA pool allocator [ 18.843508] [drm] radeon: 4096M of VRAM memory ready [ 18.843510] [drm] radeon: 1024M of GTT memory ready. [ 18.843526] [drm] Loading hawaii Microcode [ 19.238535] [drm] Internal thermal controller with fan control [ 19.238598] [drm] probing gen 2 caps for device 8086:151 = 261ad03/e But since that happens with and without a reclocking GPU, it's probably unrelated. For me, the problem has become less often to occur with recent kernels (3.17.0 and currently 3.18-rc1), but it still happens. -- 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/20141025/4dab6640/attachment.html>
[PATCH] regulator: stub out devm_regulator_get_exclusive
On Fri, Oct 24, 2014 at 05:57:24PM -0400, Rob Clark wrote: > Oh, you are only looking at the one in mdp4_kms_init(), which could > possibly be a simple regulator_get(). Look instead at the ones in > hdmi_init(), where I need to know whether to defer or not. At one No, I saw that - looking at the code in hdmi_init() it's using normal devm_regulator_get() correctly (it appears to be open coding devm_regulator_bulk_get() and likewise for the enables and disables but that's a lot less serious). I can't see anything actively broken with that code other than the error handling on failed enable. > point I was having a problem getting dummy regulators with > regulator_get() but that could have been a symptom of another problem. > I will re-try regulator_get() next time I am working on the kernel > part of the driver.. It's a bug elsewhere, if you are getting a dummy regulator on a DT system it means that you don't have a regulator set up for that supply so the core is just assuming that it's always on. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141025/29f5b551/attachment-0001.sig>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #246 from Mateusz Jo?czyk --- (In reply to Alex Deucher from comment #244) > Created attachment 106085 [details] [review] > workaround for basic enablement > > As per feedback from the last few comments the attached patch forces the > performance level to high rather than auto which should fix the stability > issues and lower power usage due to clockgating, etc. and enables dpm by > default for rv6xx. Is this patch going to be mainlined? (or was it mainlined already?) -- 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/20141025/6f525b68/attachment.html>
