dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[Bug 111806] VDPAU broken in radeonsi by commit 0692ae34e939845e5185d3bdd33ddfe4afcdb995
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111806 Bug ID: 111806 Summary: VDPAU broken in radeonsi by commit 0692ae34e939845e5185d3bdd33ddfe4afcdb995 Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: makosoft(a)googlemail.com QA Contact: dri-devel(a)lists.freedesktop.org VDPAU support appears to be broken on radeonsi as of git commit 0692ae34e939845e5185d3bdd33ddfe4afcdb995 "ac: move ac_get_num_physical_sgprs into radeon_info". Trying to play back videos using MPV 0.29.1 with it enabled fails with the following error within libvdpau_radeon: "LLVM failed to compile a shader correctly: SGPR:VGPR usage is 56:20, but the hw limit is 0:0" (or 0:256 without the subsequent commit that does the same thing with ac_get_num_physical_vgprs). I assume that information about the limits isn't getting set properly for some reason. Tested with a Radeon HD 7770 on Linux 5.2 with mpv 0.29.1, ffmpeg 4.2.1, the radeon kernel driver, and xf86-video-ati 19.0.1. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 111802] SegFault missing slots in framebuffer
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111802 Bug ID: 111802 Summary: SegFault missing slots in framebuffer Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: not set Priority: not set Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: jeroen(a)blender.org QA Contact: dri-devel(a)lists.freedesktop.org This fault has been detected when using Blender (2.80 or master branch) Steps to reproduce the error: 1. Start Blender 2. Go to edit mode (press tab) 3. Start Merge vertices tool (press ALT-M) 4. Select any mode (press ENTER) And a segmentation fault happens. This has been tested on Mesa 18.2.2, 19.0.8 and 19.3.0~dev. The root cause is that you have a framebuffer with multiple color slots with empty slots in between. If there is an empty color slot between the color slots, all textures after this slot are apparently skipped/discarded. Our work around is to reuse empty slots with other slots. `gpu_framebuffer_update_attachments_and_fill_empty_slots` in https://developer.blender.org/diffusion/B/browse/master/source/blender/gpu/… This issue also existed in the official AMD drivers, but has been solved to our knowledge. https://developer.blender.org/T70187 -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 111791] mesa-19.2-rc4: Fails to execute OpenCL kernel (ac_rtld error: !s->is_rx) on AMD64 and armhf at least
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111791 Bug ID: 111791 Summary: mesa-19.2-rc4: Fails to execute OpenCL kernel (ac_rtld error: !s->is_rx) on AMD64 and armhf at least Product: Mesa Version: 19.2 Hardware: All OS: Linux (All) Status: NEW Severity: critical Priority: not set Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: luis.p.mendes(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Cannot execute OpenCL kernel (https://github.com/huytd/opencl-benchmark) on GPU with mesa 19.2-rc4 and libclc with AMD RX 550, AMD RX 460, neither on AMD64, nor on armhf. Kernels fails with: ac_rtlf error: !s->is_rx LLVM failed to upload shader This also also happens with Aparapi kernels (https://github.com/Syncleus/aparapi-examples) - test 15 or 16, or others. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 111784] Hang when using glWaitSync with multithreaded shared GL contexts
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111784 Bug ID: 111784 Summary: Hang when using glWaitSync with multithreaded shared GL contexts Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: emmanueldurand(a)protonmail.com Created attachment 145472 --> https://bugs.freedesktop.org/attachment.cgi?id=145472&action=edit Output of dmesg I develop a tool which uses a separate thread for uploading textures to the GPU, in parallel to the rendering thread. These two threads are synchronized using OpenGL fences, which prevents the rendering to happen while a texture is being copied from a PBO. On recent AMD hardware (tested on a Vega 56 and a Radeon VII) this setup hangs almost instantaneously. From my tests it seems that it waits for a glWaitSync to finish. The exact same code runs flawlessly on Intel (Mesa driver) and Nvidia (proprietary driver). I managed to somewhat reproduce the issue in a simpler code, which merely creates two shared OpenGL contexts and does nothing except creating fences and waiting for the other thread. This example hangs with AMDGPU driver, but once again runs fine on Intel (Mesa driver) and Nvidia (proprietary driver). I'll attach the code to this thread, and it can be found here too: https://gitlab.com/sat-metalab/splash/blob/fix/radeon_test/tests/sandbox/ra…. -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 111669] Navi GPU hang in Minecraft
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111669 Bug ID: 111669 Summary: Navi GPU hang in Minecraft Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: not set Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: git(a)dougty.com QA Contact: dri-devel(a)lists.freedesktop.org When playing Minecraft, being in a certain area of my world at night causes my GPU to hang. I'm using Optifine and Sildur's shaders. Sep 12 01:38:42 xxx kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! Sep 12 01:38:47 xxx kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! Sep 12 01:38:47 xxx kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! Sep 12 01:38:47 xxx kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=19965, emitted seq=19967 Sep 12 01:38:47 xxx kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process java pid 1375 thread java:cs0 pid 1433 CPU: 3700X GPU: Sapphire 5700XT (reference) Motherboard: Gigabyte X570-I (BIOS F4) Kernel: 5.3.0-rc8-mainline Mesa: 19.3.0_devel.115190.f83f9d7daa0 LLVM: 10.0.0_r326348.d7d8bb937ad OpenGL string (as seen ingame): 4.5 (Compatibility Profile) Mesa 19.3.0-devel (git-f83f9d7daa), X.Org, AMD NAVI10 (DRM 3.33.0, 5.3.0-rc8-mainline, LLVM 10.0.0) I get the hang extremely reliably when in this specific spot at night, but only this one apitrace recreates the hang when I replay it. Apologies for the filesize. https://drive.google.com/open?id=16wAmCa27o2xxv3bFXnR6rGXAum0Wci_5 When the hangs occur, my screen freezes but everything is still running in the background, and I need to use REISUB hotkeys in order to reboot. Occurs with both PCIe 4.0 and 3.0 set in the BIOS. Please let me know if any more info is needed. Thank you. -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 111622] VAAPI vaDeriveImage returns VA_STATUS_ERROR_OPERATION_FAILED
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111622 Bug ID: 111622 Summary: VAAPI vaDeriveImage returns VA_STATUS_ERROR_OPERATION_FAILED Product: Mesa Version: 19.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: reject5514(a)naver.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 145311 --> https://bugs.freedesktop.org/attachment.cgi?id=145311&action=edit Sample C code to reproduce error Operating System: archlinux 5.2.13-arch1-1-ARCH GPU: Radeon RX 570 Mesa version: 19.1.6 Libva version: 2.5.0 vaDeriveImage() VAAPI returns VA_STATUS_ERROR_OPERATION_FAILED when radeonsi_drv_video.so used as driver. It runs successfully with i965_drv_video.so on intel integrated GPU. https://bugs.freedesktop.org/show_bug.cgi?id=110850 related to this. I found by debugging that error return occurs in the vlVaDeriveImage function. //vlVaDeriveImage function is in src/gallium/state_trackers/va/image.c if (surf->buffer->interlaced) return VA_STATUS_ERROR_OPERATION_FAILED; Is there a problem with interlaced video in Mesa? I don't know much about computer graphics and how Mesa works, but Intel driver has no problem about it, so I think it's a bug. Sample C code attached to reproduce error. This code was written by referring to the VLC's VAAPI source code. Compile command: gcc -o va va.c -lX11 -lva -lva-x11 -g Result on Radeon GPU system: libva info: VA-API version 1.5.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_5 libva info: va_openDriver() returns 0 vendor string : Mesa Gallium driver 19.1.6 for Radeon RX 570 Series (POLARIS10, DRM 3.32.0, 5.2.13-arch1-1-ARCH, LLVM 8.0.1) vaDeriveImage error : operation failed Result on Intel GPU system: libva info: VA-API version 1.5.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_3 libva info: va_openDriver() returns 0 vendor string : Intel i965 driver for Intel(R) Broadwell - 2.3.0 vaDeriveImage : success (no error) -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 111591] [radeonsi/Navi] The Bard's Tale IV causes a GPU hang
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111591 Bug ID: 111591 Summary: [radeonsi/Navi] The Bard's Tale IV causes a GPU hang Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: shtetldik(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org When running the Bard's Tale IV, in the beginning of the game, if I turn around, it consistently is causing a GPU hang. And I see this in dmesg: [ 4246.501534] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! [ 4251.365674] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=178390, emitted seq=178392 [ 4251.365740] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process BardsTale4-Linu pid 7251 thread BardsTale4:cs0 pid 7292 [ 4251.365742] [drm] GPU recovery disabled. GPU: Sapphire Pulse RX 5700 XT Kernel: 5.3.0-rc8+ OpenGL renderer string: AMD NAVI10 (DRM 3.33.0, 5.3.0-rc8+, LLVM 10.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.3.0-devel (git-87fa8d9ebc) Game version: GOG, release 1.0.0 (version 4.20.1 / 32050). -- You are receiving this mail because: You are the assignee for the bug.

1 19

[Bug 111527] obs-studio + latest mesa on amdgpu/vega64 leaks kernel memory rapidly
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111527 Bug ID: 111527 Summary: obs-studio + latest mesa on amdgpu/vega64 leaks kernel memory rapidly Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: john(a)pointysoftware.net QA Contact: dri-devel(a)lists.freedesktop.org As of at least mesa 19.3/bfac462d929 on a Vega 64: Running obs-studio, even without starting a broadcast, will begin a seemingly exponential memory leak. It will be fine for a few minutes, until it rapidly begins consuming what appears to be kernel memory (nothing attributed to app, but total usage skyrockets). With 32G of ram I exhaust system memory after about three minutes, but the OOM killer doesn't know what to take down as OBS itself remains low in the list. This can then murder the whole system. However, killing OBS causes most of the memory to be freed. I say most because after reproducing on a fresh boot, there were apparently a few gigabytes of unaccounted for memory that never returned. Subsequent repros of the bug on that same boot returned to the same baseline, however. Some caching mechanism gone wrong? I've noticed this going back at least a few weeks, but haven't a proper bisect. It should be very easy to reproduce, and happens on both Vega 64 systems I have available. Steps to reproduce, may not all be necessary but I confirmed this does it from a fresh state: - Launch obs-studio - Enable Studio Mode by clicking the button the right - Add two sources: "desktop capture" (select any monitor) and a single "Image" source (any image) - Press Fade/Cut up top to make that state live. No need to actually start recording/broadcasting. - Wait a few minutes or until your system hangs. Memory usage will appear stable for at least a full minute before taking off unprompted. It will not be attributed to the app, however, being apparently kernel memory. Reproduces with 19.3 - bfac462d929 Does not reproduce with 19.1.4 Kernel versions 5.2.8/5.2.11 same behavior -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 111372] Dual-monitor desktop environment crash with certain monitor positions
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111372 Bug ID: 111372 Summary: Dual-monitor desktop environment crash with certain monitor positions Product: Mesa Version: unspecified 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: theodorettshaw(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 145032 --> https://bugs.freedesktop.org/attachment.cgi?id=145032&action=edit Monitor placement crash/working cutoff There's an issue with certain desktop environments crashing on startup when the monitors of a multi-display system are in certain positions. In my case, I have two monitors, and my desktop environment crashes with the error cinnamon: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. when my secondary monitor is positioned to the left of the primary monitor. An example placement can be seen in the attached image. This is roughly the cutoff; moving the secondary monitor, the Philips, any farther left and restarting the DE will result in a crash. Keeping it further right and restarting the DE results in no issues. The secondary monitor can be either above or below the primary monitor with the same results. This error also occurs if the secondary monitor is too far left when the DE starts on system startup. Switching which monitor is the primary and secondary results in the same issue, with a crash if the new secondary is too far left. I'm using Linux Mint 19.2, Cinnamon 4.2.3, and kernel version 5.0.0-23-generic, though I've tried several different kernel versions. I'm using an RX480. The issue has been confirmed by others at https://github.com/linuxmint/cinnamon/issues/8754 and a very similar and likely linked issue at https://bugs.launchpad.net/ubuntu/+source/cinnamon/+bug/1837087 . glxinfo output can be found at https://pastebin.com/RGnAR320 and I'm happy to provide any other information needed, though I may need some pointers on something like recompiling Mesa in debug mode and getting a trace stack. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 111332] Long running application causes assert in amdgpu_bo.c 'bo->cpu_map_count > 0' failed
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=111332 Bug ID: 111332 Summary: Long running application causes assert in amdgpu_bo.c 'bo->cpu_map_count > 0' failed Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: freedesktop(a)harrisonconsoles.com We have an OpenGL application that runs 24/7. After 4-5 days the application quits with this error in the syslog. ../amdgpu/amdgpu_bo.c:443: amdgpu_bo_cpu_map: Assertion `bo->cpu_map_count > 0' failed. The system is running Debian 10 buster (kernel 4.19.0) libdrm 2.4.99 built from source (gitlab.freedesktop.org) There seems to be a patch to fix this problem here https://patchwork.freedesktop.org/patch/258005/ But there has been no activity on this patch in a while and it has not been merged. I will start a test of this patch and will verify if it works for me, but it will take 5 days to confirm. Any chance of getting this patch merged? Thanks, Todd -- You are receiving this mail because: You are the assignee for the bug.

1 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019