dri-devel July 2017

dri-devel@lists.freedesktop.org

212 participants
1542 discussions

[Bug 99504] Victor Vran and Tropico 5 flicker when refresh rate is above 60 Hz
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=99504 Bug ID: 99504 Summary: Victor Vran and Tropico 5 flicker when refresh rate is above 60 Hz Product: Mesa Version: 17.0 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: freedesktop(a)lanig.email QA Contact: dri-devel(a)lists.freedesktop.org Both games don't go above 60Hz with resolutions over 1080p on my setup but I will report this to the devs. Just for the case you like to reproduce the issue. With the newest driver version from the Padoka PPA, RX 480 and EIZO FS-2735 flickering happens when the refresh rate is set to 119Hz or 143Hz. (Ingame settings in Tropico and xrandr for Victor Vran). As far as I remember this happend also in the beginning, has been fixed at some point(but I am not 100% sure) and now happens again. The desktop doesn't suffer the same issue. OpenGL version string: 3.0 Mesa 17.1.0-devel - padoka PPA -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 99486] AMDGPU/Iceland Kernel 4.9.5 lock-up while playing ETS2
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=99486 Bug ID: 99486 Summary: AMDGPU/Iceland Kernel 4.9.5 lock-up while playing ETS2 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: krejzi(a)email.com Created attachment 129087 --> https://bugs.freedesktop.org/attachment.cgi?id=129087&action=edit Log exctacted from journal at the time of the hang While playing ETS2 (Euro Truck Simulator 2) on a hybrid GPU laptop, where AMD Radeon R7 M340 is the discrete GPU, amdgpu driver hung the system, which required a hard reset. See attached logs for more information. 01:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] [1002:6900] (rev 83) Subsystem: Hewlett-Packard Company Radeon R7 M340 [103c:811c] Flags: bus master, fast devsel, latency 0, IRQ 132 Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at e0000000 (64-bit, prefetchable) [size=2M] I/O ports at 3000 [size=256] Memory at e2000000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at e2040000 [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150] Advanced Error Reporting Capabilities: [270] #19 Capabilities: [2b0] Address Translation Service (ATS) Capabilities: [2c0] Page Request Interface (PRI) Capabilities: [2d0] Process Address Space ID (PASID) Kernel driver in use: amdgpu Kernel modules: amdgpu -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 99343] dEQP-GLES31.functional.shaders.builtin_functions.precision.{min, max}.highp_compute.scalar failures
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=99343 Bug ID: 99343 Summary: dEQP-GLES31.functional.shaders.builtin_functions.preci sion.{min,max}.highp_compute.scalar failures 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: samuel.pitoiset(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Hi, I have noticed that the following dEQP GLES31 tests fail with latest mesa/llvm: dEQP-GLES31.functional.shaders.builtin_functions.precision.min.highp_compute.scalar dEQP-GLES31.functional.shaders.builtin_functions.precision.max.highp_compute.scalar The same tests with lowp instead of highp work fine. Note that it's unrelated to compute because they also fail with vertex shaders. After glancing at the code, it seems like enabling denorms for 32-bit floats fix them. But it's currently only enabled for 64-bit and 16-bit floats for some reasons. Marek, Nicolai, any thoughts about that? I didn't try if these tests pass with Catalyst though, but they do at least on NVIDIA hw. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 99312] Long-running OpenCL kernels cause ring stalls and GPU lockups on Kabini
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=99312 Bug ID: 99312 Summary: Long-running OpenCL kernels cause ring stalls and GPU lockups on Kabini Product: Mesa Version: 13.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: vedran(a)miletic.net QA Contact: dri-devel(a)lists.freedesktop.org Running long lasting OpenCL kernels (e.g. GROMACS with a system of many atoms) using kernel 4.8.15, Mesa git, and LLVM git on Kabini APU: vendor_id : AuthenticAMD cpu family : 22 model : 0 model name : AMD Athlon(tm) 5350 APU with Radeon(tm) R3 stepping : 1 microcode : 0x700010b with GPU: 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Kabini [Radeon HD 8400 / R3 Series] [1002:9830] causes GPU lockups like: [338584.980657] radeon 0000:00:01.0: ring 0 stalled for more than 10351msec [338584.980811] radeon 0000:00:01.0: GPU lockup (current fence id 0x00000000000827c1 last fence id 0x00000000000827c2 on ring 0) [338585.484633] radeon 0000:00:01.0: ring 0 stalled for more than 10855msec [338585.484789] radeon 0000:00:01.0: GPU lockup (current fence id 0x00000000000827c1 last fence id 0x00000000000827c2 on ring 0) [338585.988632] radeon 0000:00:01.0: ring 0 stalled for more than 11359msec [338585.988787] radeon 0000:00:01.0: GPU lockup (current fence id 0x00000000000827c1 last fence id 0x00000000000827c2 on ring 0) Machine does not hang. This is reliably reproducible. Any other info I can provide? -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 99278] kwin corruption when desktop effects enabled
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=99278 Bug ID: 99278 Summary: kwin corruption when desktop effects enabled Product: Mesa Version: 13.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: vedran(a)miletic.net QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 128760 --> https://bugs.freedesktop.org/attachment.cgi?id=128760&action=edit Photo Using Fedora 25 with Mesa 13 and LLVM 3.8 on: 04:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Venus XTX [Radeon HD 8890M / R9 M275X/M375X] [1002:6820] (rev 81) identified as "AMD CAPE VERDE" by Mesa. Photo is attached. This is a dual GPU laptop (Lenovo Z51-70), main GPU being 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) While corruption happens, dmesg | grep radeon does not show anything suspicious, just: [21253.931482] radeon 0000:04:00.0: WB enabled [21253.931484] radeon 0000:04:00.0: fence driver on ring 0 use gpu addr 0x0000000100000c00 and cpu addr 0xffff99e2d0bb1c00 [21253.931485] radeon 0000:04:00.0: fence driver on ring 1 use gpu addr 0x0000000100000c04 and cpu addr 0xffff99e2d0bb1c04 [21253.931486] radeon 0000:04:00.0: fence driver on ring 2 use gpu addr 0x0000000100000c08 and cpu addr 0xffff99e2d0bb1c08 [21253.931486] radeon 0000:04:00.0: fence driver on ring 3 use gpu addr 0x0000000100000c0c and cpu addr 0xffff99e2d0bb1c0c [21253.931487] radeon 0000:04:00.0: fence driver on ring 4 use gpu addr 0x0000000100000c10 and cpu addr 0xffff99e2d0bb1c10 [21253.932296] radeon 0000:04:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffbefe01235a18 [21253.952686] radeon 0000:04:00.0: fence driver on ring 6 use gpu addr 0x0000000100000c18 and cpu addr 0xffff99e2d0bb1c18 [21253.952687] radeon 0000:04:00.0: fence driver on ring 7 use gpu addr 0x0000000100000c1c and cpu addr 0xffff99e2d0bb1c1c Should I test LLVM 3.9/4.0-git? Any other info that could be useful? -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 99152] Shader issue for "Trine 2" comparing Mesa13 to AMDGPU-PRO
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=99152 Bug ID: 99152 Summary: Shader issue for "Trine 2" comparing Mesa13 to AMDGPU-PRO Product: Mesa Version: 13.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: johnz(a)lunarg.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 128567 --> https://bugs.freedesktop.org/attachment.cgi?id=128567&action=edit Image differences of "Trine 2" using Mesa13 vs AMDGPU-PRO Image differences of "Trine 2" using Mesa13 vs AMDGPU-PRO Overview: There are some possible shader issues when comparing screen shots of "Trine 2" with Mesa13 to AMD's AMDGPU-PRO. Hardware and versions: The images were captured Using the Mesa 13.0 branch and AMD's AMDGPU-PRO's 16.30 driver. These image differences were observed on both AMD's Rx470 and R9 Fury graphic cards. Attached Images: Attached are the captured images. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 99151] Shader issue for "Space Run" comparing Mesa13 to AMDGPU-PRO
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=99151 Bug ID: 99151 Summary: Shader issue for "Space Run" comparing Mesa13 to AMDGPU-PRO Product: Mesa Version: 13.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: johnz(a)lunarg.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 128566 --> https://bugs.freedesktop.org/attachment.cgi?id=128566&action=edit Image differences of "Space Run" using Mesa13 vs AMDGPU-PRO Image differences of "Space Run" using Mesa13 vs AMDGPU-PRO Overview: There are some possible shader issues when comparing screen shots of "Space Run" with Mesa13 to AMD's AMDGPU-PRO. Hardware and versions: The images were captured Using the Mesa 13.0 branch and AMD's AMDGPU-PRO's 16.30 driver. These image differences were observed on both AMD's Rx470 and R9 Fury graphic cards. Attached Images: Attached are the captured images. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 98724] garbled output using glDrawElementsIndirect
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=98724 Bug ID: 98724 Summary: garbled output using glDrawElementsIndirect Product: Mesa Version: git Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: logan(a)bacoosta.com QA Contact: dri-devel(a)lists.freedesktop.org I work on an N64 emulator (GLupeN64). I received a report from a user that they had garbled output from the application. They tried it with llvmpipe and it worked. The issue report is here: https://github.com/loganmc10/GLupeN64/issues/102 It includes and apitrace and a screenshot. I had him disable indirect drawing, and in that mode the application will use glDrawElementsBaseVertex instead of glDrawElementsIndirect. He said that that fixed the issue, but it was very slow. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 98604] [VDPAU, radeonsi] Fullscreen flash video fails when hardware acceleration is enabled.
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=98604 Bug ID: 98604 Summary: [VDPAU, radeonsi] Fullscreen flash video fails when hardware acceleration is enabled. 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: rankincj(a)googlemail.com QA Contact: dri-devel(a)lists.freedesktop.org Hardware: R7 360, Linux x86_64 Screen: 1680x1050 To reproduce this bug, play the "Weather" video at http://www.bbc.co.uk/weather using Firefox and Adobe's flash-plugin-11.2.202.643-release.x86_64. Ensure that "Hardware acceleration" is enabled, and then enter "Full screen" mode. On my PC, this results in a black screen with a small, blank rectangle in the top left corner. And then the flash plugin will crash a few minutes later. This does not happen with either i965 (Broadwell) or r600 (HD6450) hardware. Nor does it happen with Chromium and chromium-pepper-flash-23.0.0.162-1.fc24.x86_64 with my R7 360, although chromium-pepper-flash doesn't appear to use libvdpau_radeonsi.so either. -- You are receiving this mail because: You are the assignee for the bug.

1 22

[Bug 98005] VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=98005 Bug ID: 98005 Summary: VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface 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: adf.lists(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Bit late with this one, but I didn't notice initially. It seems there is some timing/sync issue on R9285 with dual instance enabled after c59628d11b134fc016388a170880f7646e100d6f st/va: enable dual instances encode by sync surface Testing with large rawvideo/higher bitrates lucked me out of noticing initially as visually these tend to be OK, though making say 20 and md5summing them will show inconsistencies. I can change the number of "bads" in some tests by flipping my cpus between cpufreq on_demand and perf. At lower sizes/bitrates/transcoding it's possible to get corruption, either in the form of some runs giving abnormally low bitrate with vbr, or sometimes with cbr there is a chance of an out of order frame around an IDR frame. Testing this with gstreamer. -- You are receiving this mail because: You are the assignee for the bug.

1 40

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2017