dri-devel May 2015

dri-devel@lists.freedesktop.org

191 participants
1132 discussions

[Bug 89987] Slow VDPAU (rv770_restrict_performance_levels_before_switch failed)
by bugzilla-daemon＠freedesktop.org 09 Aug '15

09 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=89987 Bug ID: 89987 Summary: Slow VDPAU (rv770_restrict_performance_levels_before_switch failed) Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: chewi(a)gentoo.org Created attachment 115023 --> https://bugs.freedesktop.org/attachment.cgi?id=115023&action=edit dmesg I have a Radeon HD4670 on a Gentoo Linux system. 1080p playback was working fine under 3.17 but has since slowed to a crawl. I have done back to 3.17 to check that it still works despite numerous updates to userspace and it does. 3.18 flat out refuses to work, with vdpauinfo claiming that H.264 is not supported. I know that Radeon video acceleration was in a transition during this period so best to ignore that. Under 3.19.3 and 4.0-rc7, vdpauinfo reports that H.264 is supported but playback is very slow. How slow? Low quality 1080p is very jumpy. High quality 1080p (Blu-ray) barely moves at all. Probably something like 0.1fps. When attempting playback, though mplayer or VLC, the following error appears in dmesg. [drm:rv770_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed This led me to try booting with radeon.dpm=0. Under the high profile, low quality is smooth and high quality improves to just jumpy. Under the dynpm method, both are smooth. I have two displays connected using Zaphod mode, both normally at 1080p. If I disconnect the second, playback is smooth. If I set the second to some low resolution like 720x480 but play 1080p video on the first, playback is smooth. I'm not sure whether this behaviour is a symptom or a cause. I tried enabling DRI3 to see if that would help but no. I can't bisect the kernel because UVD acceleration is new. There has probably not been a commit so far where it did work under this setup. Here's some further info. Card: Advanced Micro Devices, Inc. [AMD/ATI] RV730 XT [Radeon HD 4670] Kernels: 3.19.3 and 4.0-rc7 Mesa: 10.5.2 xorg-server: 1.17.1 xf86-video-ati: 7.5.0 and 5921ba4ca705a0d919515626088f3948cc4848c1 Desktop: XFCE (no compositing) This has similarities to bug #69120 but I believe that to be a different issue because it involves much older kernel versions and a lot has changed since then, plus it used to work for me until 3.18. -- You are receiving this mail because: You are the assignee for the bug.

1 9

[PATCH 1/3] drm/nouveau: Use drm_vblank_on/off consistently
by Daniel Vetter 07 Aug '15

07 Aug '15

In commit 9cba5efab5a8145ae6c52ea273553f069c294482 Author: Mario Kleiner <mario.kleiner.de(a)gmail.com> Date: Tue Jul 29 02:36:44 2014 +0200 drm/nouveau: Dis/Enable vblank irqs during suspend/resume drm_vblank_on/off calls where added around suspend/resume to make sure vblank stay doesn't go boom over that transition. But nouveau already used drm_vblank_pre/post_modeset over modesets. Instead use drm_vblank_on/off everyhwere. The slight change here is that after _off drm_vblank_get will refuse to work right away, but nouveau doesn't seem to depend upon that anywhere outside of the pageflip paths. The longer-term plan here is to switch all kms drivers to drm_vblank_on/off so that common code like pending event cleanup can be done there, while drm_vblank_pre/post_modeset will be purely drm internal for the old UMS ioctl. Note that the drm_vblank_off still seems required in the suspend path since nouveau doesn't explicitly disable crtcs. But on the resume side drm_helper_resume_force_mode should end up calling drm_vblank_on through the nouveau crtc hooks already. Hence remove the call in the resume code. Cc: Mario Kleiner <mario.kleiner.de(a)gmail.com> Cc: Ben Skeggs <bskeggs(a)redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_display.c | 4 ---- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c index 3d96b49fe662..dab24066fa21 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c @@ -708,7 +708,7 @@ static void nv_crtc_prepare(struct drm_crtc *crtc) if (nv_two_heads(dev)) NVSetOwner(dev, nv_crtc->index); - drm_vblank_pre_modeset(dev, nv_crtc->index); + drm_vblank_off(dev, nv_crtc->index); funcs->dpms(crtc, DRM_MODE_DPMS_OFF); NVBlankScreen(dev, nv_crtc->index, true); @@ -740,7 +740,7 @@ static void nv_crtc_commit(struct drm_crtc *crtc) #endif funcs->dpms(crtc, DRM_MODE_DPMS_ON); - drm_vblank_post_modeset(dev, nv_crtc->index); + drm_vblank_on(dev, nv_crtc->index); } static void nv_crtc_destroy(struct drm_crtc *crtc) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 8670d90cdc11..d824023f9fc6 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -620,10 +620,6 @@ nouveau_display_resume(struct drm_device *dev, bool runtime) nv_crtc->lut.depth = 0; } - /* Make sure that drm and hw vblank irqs get resumed if needed. */ - for (head = 0; head < dev->mode_config.num_crtc; head++) - drm_vblank_on(dev, head); - /* This should ensure we don't hit a locking problem when someone * wakes us up via a connector. We should never go into suspend * while the display is on anyways. -- 2.1.4

4 17

[PATCH] drm/exynos/fimc: fix runtime pm support
by Marek Szyprowski 06 Aug '15

06 Aug '15

Once pm_runtime_set_active() gets called, the kernel assumes that given device has already enabled runtime pm and will call pm_runtime_suspend() without matching pm_runtime_resume(). In case of DRM FIMC IPP driver, this will result in calling clk_disable() without respective call to clk_enable(). This patch removes call to pm_runtime_set_active() to ensure that pm_runtime_suspend/resume calls will match. Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c index 842d6b8dc3c4..2a652359af64 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c @@ -1745,7 +1745,6 @@ static int fimc_probe(struct platform_device *pdev) spin_lock_init(&ctx->lock); platform_set_drvdata(pdev, ctx); - pm_runtime_set_active(dev); pm_runtime_enable(dev); ret = exynos_drm_ippdrv_register(ippdrv); -- 1.9.2

3 3

[Bug 86796] Artifacts on the screen. HD8530M
by bugzilla-daemon＠freedesktop.org 03 Aug '15

03 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=86796 Bug ID: 86796 Summary: Artifacts on the screen. HD8530M Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: nicknnn(a)gmail.com Created attachment 110136 --> https://bugs.freedesktop.org/attachment.cgi?id=110136&action=edit Example screen shot with artifacts Artifacts on the screen on notebook asus S301L. The laptop has a muxless video card. I use DRI_PRIME. $ xrandr --listproviders Providers: number : 2 Provider 0: id: 0x76 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 2 associated providers: 1 name:Intel Provider 1: id: 0x51 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 0 associated providers: 1 name:radeon DRI_PRIME=1 LD_LIBRARY_PATH=/opt/mesa-master/lib/ LD_PRELOAD=/opt/mesa-master/lib/dri/radeonsi_dri.so glxgears DRI_PRIME=1 LD_LIBRARY_PATH=/opt/mesa-master/lib/ LD_PRELOAD=/opt/mesa-master/lib/dri/radeonsi_dri.so amoeba Example screen shot as an attachment amoeba.jpg Uname: Linux mj 3.17-1-amd64 #1 SMP Debian 3.17-1~exp1 (2014-10-14) x86_64 GNU/Linux -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 88887] Grim Fandango Remastered segfaults within radeon_llvm_compile->...->llvm::BasicBlock::getTerminator
by bugzilla-daemon＠freedesktop.org 02 Aug '15

02 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=88887 Bug ID: 88887 Summary: Grim Fandango Remastered segfaults within radeon_llvm_compile->...->llvm::BasicBlock::getTermina tor Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: NightNord(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 112998 --> https://bugs.freedesktop.org/attachment.cgi?id=112998&action=edit Backtrace for all threads Crash within #0 0xf62be474 in llvm::BasicBlock::getTerminator() () from /usr/lib32/libLLVM-3.5.so ... #9 0xf723bdae in radeon_llvm_compile () from /usr/lib32/dri/radeonsi_dri.so ... #22 0x081b1014 in zg_RenderContext_DrawIndexedPrimitives () ... Full backtrace attached. Crashes just after an intro movie, 100% reproducable. There is a message in the game's log: "No matching vertex attribute 'vs_TexCoord' in shader 'color_quad' for QuadVertex::TexCoord" just before the movie end. Mesa version: Mesa 10.5.0 devel (on earlier versions too, tested up to 10.3.7) LLVM version: 3.5.1 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X] xf86-video-ati: recent git version -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 88780] Several Unity3D-based games render with "foggy blueish overlay"
by bugzilla-daemon＠freedesktop.org 02 Aug '15

02 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=88780 Bug ID: 88780 Summary: Several Unity3D-based games render with "foggy blueish overlay" Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: kai(a)dev.carbon-project.org QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 112787 --> https://bugs.freedesktop.org/attachment.cgi?id=112787&action=edit Blue overlay with Dreamfall Chapters in the lab scene With the stack detailed below (AFAICT this is *NOT* a regression, because I seem to remember having these hazy blue scenes with older versions of Mesa as well) several Unity3D-based games (e.g. Jagged Alliance: Flashback or Dreamfall Chapters) render either entirely or only some scenes as if there was some fog overlay with a blue hue. For Dreamfall Chapters (from which the attached screenshot originates), it's only for some scenes, sometimes even dependant on the camera angle. For example, in the Queenie scene only some camera angles exhibit this problem, while in the lab scene, you have it constantly. With Dreamfall Chapters this bug can be seen mostly indoors. Games like Jagged Alliance render all 3D scenes with this blue hue overlay. This is, every sector you go into shows this problem. My current stack (Debian testing as a base): GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/d2811c29da libdrm: Git:master/libdrm-2.4.59 LLVM: SVN:trunk/r226934 (3.7 devel) X.Org: Git:master/6672606420 Linux: Git:<git://people.freedesktop.org/~airlied/linux>:drm-fixes/67cf2d3912 Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/> > 9e05820da42549ce9c89d147cf1f8e19 hawaii_ce.bin > c8bab593090fc54f239c8d7596c8d846 hawaii_mc.bin > 3618dbb955d8a84970e262bb2e6d2a16 hawaii_me.bin > c000b0fc9ff6582145f66504b0ec9597 hawaii_mec.bin > 0643ad24b3beff2214cce533e094c1b7 hawaii_pfp.bin > ba6054b7d78184a74602fd81607e1386 hawaii_rlc.bin > 11288f635737331b69de9ee82fe04898 hawaii_sdma.bin > 284429675a5560e0fad42aa982965fc2 hawaii_smc.bin libclc: Git:master/d73f33b736 DDX: Git:master/c9f8f642fd -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 86357] [RadeonSI] GPU lockup with mesa 10.3.3 / kernel 3.17.2
by bugzilla-daemon＠freedesktop.org 02 Aug '15

02 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=86357 Bug ID: 86357 Summary: [RadeonSI] GPU lockup with mesa 10.3.3 / kernel 3.17.2 Product: Mesa Version: 10.3 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: madcatx(a)atlas.cz Created attachment 109569 --> https://bugs.freedesktop.org/attachment.cgi?id=109569&action=edit journalctl crash info, contains both dmesg and Xorg logs After a recent update of my Fedora 21 box I've experienced this crash twice. The entire desktop except for mouse freezes and I cannot even VT switch to console. If the keypress gets registered I end up with a powered down display and a switch back to X results in a completely corrupted screen. If I don't try a VT switch I can still move the mouse but other than that the machine appears dead. It eventually stops responding to ping and the only way out is a hard reboot. I have been using this machine for quite a while and I haven't experienced this before until yesterday. I checked the yum logs but there doesn't seem to be anything directly related to the graphics except maybe for this: Updated xkeyboard-config-2.13-2.fc21.noarch @updates-testing Update 2.13-3.fc21.noarch @updates-testing Updated xorg-x11-font-utils-1:7.5-23.fc21.x86_64 @updates-testing Update 1:7.5-25.fc21.x86_64 @updates-testing Updated xorg-x11-fonts-Type1-7.5-11.fc21.noarch @updates-testing Update 7.5-14.fc21.noarch @updates-testing Updated xorg-x11-server-utils-7.7-9.fc21.x86_64 @updates-testing Update 7.7-10.fc21.x86_64 @updates-testing Updated xorg-x11-xkb-utils-7.7-10.fc21.x86_64 @fedora Relevant packages installed: xorg-x11-drv-ati - 7.5.0-1.fc21 xorg-x11-server-Xorg.x86_64 - 1.16.1-1.fc21 kernel.x86_64 - 3.17.2-300.fc21 Custom-built mesa 10.3.3 with "Fix v5" from "BUG 60879" applied My card is a 7730 LE, PID:VID 1002:aab0 X and kernel apparently caught and logged the problem, relevant journalctl output is attached. It usually takes a few hours for this to happen, the only thing the two crashes I've had so far have in common is a Flash video playing in the background when the system froze. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 89256] [radeonsi][CSGO] many rendering artifacts and more
by bugzilla-daemon＠freedesktop.org 02 Aug '15

02 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=89256 Bug ID: 89256 Summary: [radeonsi][CSGO] many rendering artifacts and more Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: sylvain.bertrand(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Got my hands on counter-strike Global Offensive. I run an up-to-date fedora rawhide on x86_64 (3.20 kernel and mesa 10.5.0). I get a lot of rendering artifacts, GPU lock ups (rare, on ring 0 and 5), VM read faults from the TC block (texture cache I guess) for some VMs... The video settings are set to the minimum (in a 1920x1080 window) My GPU is a R9 280X (TAHITI XT). -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 80922] New: XCOM :Enemy Unknown will crash and kill the output after some time.
by bugzilla-daemon＠freedesktop.org 02 Aug '15

02 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=80922 Priority: medium Bug ID: 80922 Assignee: dri-devel(a)lists.freedesktop.org Summary: XCOM :Enemy Unknown will crash and kill the output after some time. Severity: normal Classification: Unclassified OS: Linux (All) Reporter: half-shot(a)molrams.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 102280 --> https://bugs.freedesktop.org/attachment.cgi?id=102280&action=edit glxinfo Wish I could describe it better but there is no better words. The game will lock up the card and the monitor output will go blank, although once I got lucky and it crashed to the terminal spewing errors about radeon. Due to the fact that the system crashes the only. This crash usually happens during a gameplay sequence and has not happened in a menu as of yet. The crash also will usually recover the first time after loosing visual output for 10 seconds but then will cut out a second (or rarely a third) and not return to the game. Due to it crashing randomly (no specific scene causing it) and always requiring about a hour of play, would it make sense to be a memory issue? It did not occur to me that I would need Dmesg output, if its needed then remind me and I will reproduce another crash with the log file. I also have a apitrace, but it totals 23GB and I do not know which bit would need trimming. System Specs: AMD PhenomII X6 T55 AMD RadeonHD 7950 Mesa 10.3.0-devel (git-370184e) LLVM 3.5.0 (svn) -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 85207] New: agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task
by bugzilla-daemon＠freedesktop.org 02 Aug '15

02 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=85207 Bug ID: 85207 Summary: agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task Product: DRI Version: XOrg CVS Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: adf.lists(a)gmail.com Created attachment 108075 --> https://bugs.freedesktop.org/attachment.cgi?id=108075&action=edit dmesg when Unreal Elemental hangs on start R9270X Sometime running unreal elemental demo it hangs at startup with errors in dmesg attached. This doesn't always happen. Mesa is currently on winsys/radeon: Use a single buffer cache manager again, previously produced with slightly older. Haven't seen on drm-next-3.18-wip (but really need to test more with current mesa) Possibly unrelated, but new for drm-next-3.19-wip I get below when running Unigine Valley - it runs OK. Oct 17 11:15:35 ph4 kernel: radeon 0000:01:00.0: GPU fault detected: 146 0x0af03504 Oct 17 11:15:35 ph4 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00010E57 Oct 17 11:15:35 ph4 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x10035004 Oct 17 11:15:35 ph4 kernel: VM fault (0x04, vmid 8) at page 69207, read from VGT (53) -- You are receiving this mail because: You are the assignee for the bug.

1 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2015