dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[Bug 108893] Slow redrawing of menu in Gothic 2 under wine
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=108893 Bug ID: 108893 Summary: Slow redrawing of menu in Gothic 2 under wine Product: Mesa Version: 18.2 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: supercoolemail(a)seznam.cz QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 142657 --> https://bugs.freedesktop.org/attachment.cgi?id=142657&action=edit Trace of Gothic 2 menu Menu navigation in Gothic 2 under wine 3.21 and mesa 18.2.5 is very slow. After each action it takes 3-6 seconds to redraw. LIGL_ALWAYS_SOFTWARE=1 workarounds it, so I report it here instead to wine. This slowness was present in earlier version too, but it is sometimes faster (3 seconds per action) which I attributed to wine, but now I have noticed, that settings are totally unusable. Atached apitrace was created this way: when menu items show up, I quickly press arrow down 3 times, arrow up 1 times and then enter without waiting for redraws. Then I wait maybe 15 seconds for game game to catch up. This key sequence goes to exit and confirms it. -- You are receiving this mail because: You are the assignee for the bug.

1 23

[Bug 108824] Invalid handling when GL buffer is bound on one context and invalidated on another
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=108824 Bug ID: 108824 Summary: Invalid handling when GL buffer is bound on one context and invalidated on another 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: baldurk(a)baldurk.org QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 142556 --> https://bugs.freedesktop.org/attachment.cgi?id=142556&action=edit piglit test showing broken behaviour I found some odd behaviour that I think I've tracked down to some incorrect handling of buffer invalidation in radeonsi. The rough order of events is: 1. Create a buffer that's shared between two contexts. Ensure it's bound as a UBO on both. 2. Invalidate the buffer with e.g. glMapBufferRange(GL_MAP_INVALIDATE_BUFFER_BIT) on context A. 3. Context B's buffer bind is now in a bad state. Rendering will have unpredictable results, and invalidating the buffer again on context B may fail. That's a bit vague but that's the general repro that I know for sure. This will then result in unpredictable reads/garbage data, and quite likely you'll eventually hit the assert on src/gallium/drivers/radeonsi/si_descriptors.c:1489 - assert(old_buf_va <= old_desc_va); My understanding is that the radeonsi code will look through all bound buffers whenever an invalidate happens, fixup the descriptors by subtracting the descriptor's VA from the outgoing VA for the old buffer to get the offset, then add it onto the incoming VA and update the descriptor. The problem seems to be that when this happens for a buffer invalidate it only checks the current context's bound buffers - so other contexts don't have their descriptors updated. That means the old VA is still being pointed at, and if an invalidate happens again on the second thread the descriptor is referring to an even older VA than the outgoing VA so there's no longer any sense in the subtract call. I've attached a piglit test which hopefully should drop right in, it runs through the steps above and does a pixel readback to ensure the rendering went correctly. If you remove the readback you can see flickering output. It runs fine with both the readback and the rendering if I switch to swrast. I'm on an RX 480 and tested the bug with both git-61b535437e and 18.2.4 from padoka's PPA. -- You are receiving this mail because: You are the assignee for the bug.

1 16

[Bug 108794] Inconsistent behavior with Separable Shaders (ARB_separate_shader_objects)
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=108794 Bug ID: 108794 Summary: Inconsistent behavior with Separable Shaders (ARB_separate_shader_objects) 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: epigramx(a)yahoo.com QA Contact: dri-devel(a)lists.freedesktop.org When running Cemu, (an OpenGL application under wine), it appears there is inconsistent behavior with their feature "Separable Shaders". a) When BotW runs, and SS is off, the "tent" of some Stables may be invariably culled off the scene (along with a few other textures). b) In contrast, when SS is on, it causes the lighting in some Shrines to be oversaturated. Hardware: AMD R9 290, Intel Haswell Software: Kernel 4.18.19, latest libdrm, current mesa repo source, llvm 8 from their site's repo for debian sid. tl;dr: In any case, there appears to be inconsistent behavior on results of separable shaders being used or not when the same methods seem to work on Windows. I do not have access to the source of the test software to investigate further and I have not debugged mesa calls further (and I probably won't). -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 108711] GPU crash in some opengl 1.x applications on vega gpu
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=108711 Bug ID: 108711 Summary: GPU crash in some opengl 1.x applications on vega gpu Product: Mesa Version: git 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: mittorn(a)sibmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 142435 --> https://bugs.freedesktop.org/attachment.cgi?id=142435&action=edit trace that crashes gpu on replay Running some opengl applications results in random gpu crashes I have made trace with apitrace and can reproduce crash when replaying traces. Not every replay results in crash, so it is some random behaviour this is Ryzen 2400G APU OpenGL renderer string: AMD RAVEN (DRM 3.27.0, 4.18.0-rc7+, LLVM 8.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.0.0-devel (git-552642066f) llvm git 89fcd8b878977c9c467cb5d6e33a3404d2996822 Similar crashes was in mesa 17.x, 18.0, 18.2, 18.3 and amdgpu-pro drivers with 4.16 vanilla and 4.18 amdgpu-drm-next kernels, but i was not able to reproduce it at short time (it needed about 5-10 minutes playing game to crash) [839408.306382] amdgpu 0000:08:00.0: [gfxhub] VMC page fault (src_id:0 ring:158 vmid:1 pasid:32778, for process xash64 pid 6233 thread xash64:cs0 pid 6273 ) [839408.306384] amdgpu 0000:08:00.0: at address 0x0000000000000000 from 27 [839408.306385] amdgpu 0000:08:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x0010153C [839418.327341] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=119603881, emitted seq=119603883 Trace in attachment creaded with llvmpipe, but crashes in some replays second trace, which resulted in crash while recording (broken in the end): http://rgho.st/private/8HvcFZtwT/04b55f00128bc9e81f4cf3c4a205015a -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 108347] [regression, bisected] Performance drop in various games
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=108347 Bug ID: 108347 Summary: [regression, bisected] Performance drop in various games 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: gr.muench(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Tesseract goes down from 402 to 385fps. (Using nir,sisched) I saw other games too with a performance regression. But the impact is smaller. Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD Radeon HD 7900 Series (TAHITI, DRM 3.27.0, 4.19.0-2-amd-staging-drm-next-git, LLVM 8.0.0) (0x6798) Version: 18.3.0 Accelerated: yes Video memory: 3072MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 4.5 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 Memory info (GL_ATI_meminfo): VBO free memory - total: 2876 MB, largest block: 2876 MB VBO free aux. memory - total: 2966 MB, largest block: 2966 MB Texture free memory - total: 2876 MB, largest block: 2876 MB Texture free aux. memory - total: 2966 MB, largest block: 2966 MB Renderbuffer free memory - total: 2876 MB, largest block: 2876 MB Renderbuffer free aux. memory - total: 2966 MB, largest block: 2966 MB Memory info (GL_NVX_gpu_memory_info): Dedicated video memory: 3072 MB Total available memory: 6144 MB Currently available dedicated video memory: 2876 MB OpenGL vendor string: X.Org OpenGL renderer string: AMD Radeon HD 7900 Series (TAHITI, DRM 3.27.0, 4.19.0-2-amd-staging-drm-next-git, LLVM 8.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.0-devel (git-4052624398) OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 4.5 (Compatibility Profile) Mesa 18.3.0-devel (git-4052624398) OpenGL shading language version string: 4.50 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.0-devel (git-4052624398) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 f243980f2c1e8005dab0cbadf52eb4392feb2ecc is the first bad commit commit f243980f2c1e8005dab0cbadf52eb4392feb2ecc Author: Sonny Jiang <sonny.jiang(a)amd.com> Date: Wed Oct 3 11:53:11 2018 -0400 radeonsi:optimizing SET_CONTEXT_REG for shaders VS Signed-off-by: Sonny Jiang <sonny.jiang(a)amd.com> Signed-off-by: Marek Olšák <marek.olsak(a)amd.com> :040000 040000 e32a7539bb1a32c3c9d700651aa50f8dada31b5e 0e04f0305e4e893fdee0b394b5aa2c9c0bf0edaf M src -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 108340] Ambient Occlusion in Two Point Hospital shows black spot artifacts
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=108340 Bug ID: 108340 Summary: Ambient Occlusion in Two Point Hospital shows black spot artifacts Product: Mesa Version: 18.2 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: christos.kotsaris(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Two point hospital works pretty well on my Archlinux system using Mesa 18.2.2, LLVM 7.0, kernel 4.18.12 with max graphical settings. The only setting that has an issue is Ambient Occlusion. With that enabled, when you move the camera around it produces a lot of black spots around the edges of walls and items. With that setting disabled everything displays fine. >From what little search i did, i saw other people reporting this issue on the steam forums of the game but it is not reported here and i think it is an issue with Mesa. For the record i am using an R9 380 card and i saw people reporting the same problem on Polaris cards. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 108318] [Polaris] Glitches in New Super Mario Brothers U in Cemu on Polaris only (recent)
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=108318 Bug ID: 108318 Summary: [Polaris] Glitches in New Super Mario Brothers U in Cemu on Polaris only (recent) Product: DRI Version: DRI 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: johngaltfirstrun(a)gmail.com Created attachment 141980 --> https://bugs.freedesktop.org/attachment.cgi?id=141980&action=edit dmesg from boo This is a semi recent (within the last few months) bug on Polaris in NSMBU. Many polygons (maybe?) have major glitches across the screen, or don't show up at all. This doesn't occur on Tahiti or Pitcairn. I've gone back to 18.2.1 and verified it still exists, so it must be prior. It also exists on both linux 4.18.12 and the amdgpu-staging-drm-next branch. I'll continue attempting to bisect, unless someone else knows exactly what the issue is. There are quite a few GPU faults listed in the attached dmesg, though I'm not sure if they're related to the issue. Glxinfo, Xorg.0.log, as well as a screenshot of the issue. -- You are receiving this mail because: You are the assignee for the bug.

1 14

[Bug 108317] [Polaris] Black Textures on Polaris only in Cemu Zelda Breath of the Wild
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=108317 Bug ID: 108317 Summary: [Polaris] Black Textures on Polaris only in Cemu Zelda Breath of the Wild 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: johngaltfirstrun(a)gmail.com Created attachment 141975 --> https://bugs.freedesktop.org/attachment.cgi?id=141975&action=edit dmesg from boot to the issue. In this game on Polaris, most of the textures are black (see attachment). This doesn't occur on Tahiti or Pitcairn, and happens on both 4.18.x and amdgpu-staging-drm-next. As far as I'm aware, this has always been an issue on Polaris. There doesn't seem to be anything in these logs I was told to submit in #radeon, so please let me know what else I can do for you. I'm comfortable building any packages with patches or additional debugging (if applicable). I've attached dmesg from boot to the issue (nothing I can see), along with glxinfo, Xorg.0.log, and a screenshot of the issue. Thank you. -- You are receiving this mail because: You are the assignee for the bug.

1 26

[Bug 108272] opencl-mesa: Anything using OpenCL segfaults, XFX Radeon RX 580
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=108272 Bug ID: 108272 Summary: opencl-mesa: Anything using OpenCL segfaults, XFX Radeon RX 580 Product: Mesa Version: 18.2 Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: jamespharvey20(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 141931 --> https://bugs.freedesktop.org/attachment.cgi?id=141931&action=edit clinfo seems happy Up to date Arch Linux, including: linux 4.18.12.arch1-1, xf86-video-amdgpu 18.1.0-1, mesa 18.2.2-1, opencl-mesa 18.2.2-1, xorg-server 1.20.1-1, and plasma-desktop 5.13.5-1. (Recently installed system that STARTED with: linux 4.18.9.arch1-1, mesa 18.2.1-1, and opencl-mesa 18.2.1-1.) I have not tried AMDGPU-PRO. (Not really interested anyway, and the Arch AUR package for it is 17.40, which requires downgrading to linux 4.9 and Xorg 1.18.) $ lspci -k | grep VGA 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X] (rev e7) Subsystem: XFX Pine Group Inc. Ellesmere [Radeon RX 470/480/570/570X/580/580X] Kernel driver in use: amdgpu Kernel modules: amdgpu It's the: XFX AMD Radeon RX 580 GTS Black Edition 8GB GDDR5 PCI Express 3.0 clinfo seems happy, see full output attached or here: http://termbin.com/iiow See glxinfo output attached or here: http://termbin.com/lgqd Anything using OpenCL immediately segfaults. Everything that segfaults runs just fine if I uninstall opencl-mesa, and either use opencl-amd (Arch linux package, which extracts OpenCL library from AMDGPU-PRO **18.30** but allows it to run with the open source AMDGPU driver.) Everthing also runs fine if I instead use intel-opencl-runtime to just run off the CPUs. ----- luxmark 3.1 crashes in pipe_radeonsi.so, called by libMesaOpenCL.so.1, called by libOpenCL.so.1. A gdb backtrace with opencl-mesa 18.2.2 that I compiled in debug mode with symbols is attached or here: http://termbin.com/to7v A gdb backtrace with opencl-mesa 18.2.2 (Arch binary, so without buildtype specified and no symbols) is here: http://termbin.com/m1yx Setting environment variable MESA_DEBUG causes no additional output. ----- Granted, IndigoBenchmark_x64_v4.0.64 crashes by calling /usr/lib/libOpenCL.so::clGetPlatformIDs() which is ocl-icd, but without opencl-mesa and instead with opencl-amd, it runs through it just fine. A gdb backtrace is attached or here: http://termbin.com/junz6 -- You are receiving this mail because: You are the assignee for the bug.

1 16

[Bug 108270] [proton] Wolfenstein: The New Order (frame rate issue)
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=108270 Bug ID: 108270 Summary: [proton] Wolfenstein: The New Order (frame rate issue) Product: Mesa Version: 18.2 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: lejimster(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org In the first bunker the frame rate drops heavily and stutters in spots, the frame rate is perfect 60fps before and after this area. I tested the same area on Windows 10 and also Ubuntu with proprietary drivers and they don't suffer from this issue. Tested using Proton 3.7-6 as the game needs a patched wine to run. Hopefully the trace is long enough to see the issue as the frame rate drop doesn't always happen immediately. Apitrace: https://drive.google.com/file/d/1LWRVhJMeXo0h8IbUFBwj8vyTyyml6R5k/view?usp=… Video showing the issue: https://youtu.be/WheSQWf09yM -Arch Linux -RX Vega 56/Ryzen 1700 -mesa 18.3-git -- You are receiving this mail because: You are the assignee for the bug.

1 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019