dri-devel July 2017

dri-devel@lists.freedesktop.org

212 participants
1542 discussions

[Bug 85791] New: nouveau: errors on boot, can't use discrete gpu
by bugzilla-daemon＠bugzilla.kernel.org 03 Dec '18

03 Dec '18

https://bugzilla.kernel.org/show_bug.cgi?id=85791 Bug ID: 85791 Summary: nouveau: errors on boot, can't use discrete gpu Product: Drivers Version: 2.5 Kernel Version: 3.16.4, 3.14.20 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: mezin.alexander(a)gmail.com Regression: No Created attachment 152791 --> https://bugzilla.kernel.org/attachment.cgi?id=152791&action=edit dmesg On boot I see these errors: [ 18.929898] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000002 FAULT at 0x4188ac [ IBUS ] [ 18.931250] nouveau E[ DRM] Pointer to TMDS table invalid [ 18.932395] nouveau E[ DRM] Pointer to flat panel table invalid [ 22.798349] nouveau E[ PGRAPH][0000:01:00.0] HUB_INIT timed out [ 22.798360] nouveau E[ PGRAPH][0000:01:00.0] 409000 - done 0x00000220 [ 22.798373] nouveau E[ PGRAPH][0000:01:00.0] 409000 - stat 0x00000000 0x00000000 0x00000000 0x00000000 [ 22.798384] nouveau E[ PGRAPH][0000:01:00.0] 409000 - stat 0x00000000 0x00000000 0x00000006 0x00000001 [ 22.798389] nouveau E[ PGRAPH][0000:01:00.0] 502000 - done 0x00000300 [ 22.798397] nouveau E[ PGRAPH][0000:01:00.0] 502000 - stat 0x00000000 0x00008c00 0x00000000 0x00000000 [ 22.798404] nouveau E[ PGRAPH][0000:01:00.0] 502000 - stat 0x00000000 0x00000000 0x00000000 0x00000000 [ 22.798406] nouveau E[ PGRAPH][0000:01:00.0] init failed, -16 Full dmesg is attached. When I try to use discrete gpu with DRI_PRIME=1 (after xrandr --setprovideroffloadsink), X crashes. Hardware: 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) 01:00.0 3D controller: NVIDIA Corporation GK107M [GeForce GT 750M] (rev a1) Acer Aspire V5-573G If I remember correctly, some time ago everything worked. -- You are receiving this mail because: You are watching the assignee of the bug.

1 7

[Bug 92936] Tonga powerplay isssues
by bugzilla-daemon＠freedesktop.org 30 Nov '18

30 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=92936 Bug ID: 92936 Summary: Tonga powerplay isssues Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: adf.lists(a)gmail.com Created attachment 119627 --> https://bugs.freedesktop.org/attachment.cgi?id=119627&action=edit dmesg Testing the amdgpu-powerplay brandh I have several issues. The first and possibly the cause of others (so for now I won't do separate bugs) is on boot I see - Can't find requested voltage id in vdd_dep_on_sclk table! Testing Games/demos all is good and perf is as expected. Testing UVD however and perf is way worse than before powerplay. I see in dmesg - [ 1818.011402] Failed to send Message. [ 1818.011407] Failed to send Previous Message. After doing this I also may no longer get good perf from gamed/demos. Trying to force high for the uvd test doesn't help and I notice another issue - /sys/class/drm/card0/device/power_dpm_force_performance_level is auto to start with, if I echo high > it works = GPU gets hotter, but I can't change it back. If I echo auto > ... then cat it, it will still say high and GPU remains hot. Separately when I quit X I may get some new errors in dmesg Nov 12 11:36:50 ph4 kernel: Failed to send Previous Message. Nov 12 11:36:50 ph4 kernel: last message repeated 2 times Nov 12 11:36:50 ph4 kernel: unforce pcie level failed! -- You are receiving this mail because: You are the assignee for the bug.

1 26

[Bug 93649] [radeonsi] Graphics lockup while playing tf2
by bugzilla-daemon＠freedesktop.org 27 Nov '18

27 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=93649 Bug ID: 93649 Summary: [radeonsi] Graphics lockup while playing tf2 Product: Mesa Version: 11.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: matthew(a)mjdsystems.ca QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 120925 --> https://bugs.freedesktop.org/attachment.cgi?id=120925&action=edit Kernel dmesg around the time of the lockup. After a period of time playing the latest version of TF2, my GPU locks up. After the kernel tries to reset, the X becomes stuck and won't work. The rest of the system is fine however. Sometimes, the GPU will reset successfully and continue working, only to lockup later, eventually freezing X. Hardware: GPU: Gigabyte Radeon HD 7970 Ghz edition OC CPU: AMD Phenom ii X6 1100T MB: Asus Crosshair IV Formula Software: Mesa: 11.1.0 DRM: 2.4.65 LLVM: 3.7.0 X: 1.17.4 DDX: 7.6.1 Kernel: 4.3.3 I have a dmesg with debug turned on and a strace of X from around the time it crashes (attached). I reduced the log file to the relevant bits, as they are quite large. I'll retry with latest git, see if it helps anywhere. -- You are receiving this mail because: You are the assignee for the bug.

1 81

[Bug 99195] Random GPU lockup on Fedora 25 Wayland & X sessions with Mobility Radeon HD 5650/5750 Opensource drivers
by bugzilla-daemon＠freedesktop.org 14 Nov '18

14 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=99195 Bug ID: 99195 Summary: Random GPU lockup on Fedora 25 Wayland & X sessions with Mobility Radeon HD 5650/5750 Opensource drivers Product: Mesa Version: 13.0 Hardware: All OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: johnrory.odwyer(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 128649 --> https://bugs.freedesktop.org/attachment.cgi?id=128649&action=edit Extract from journalctl show attempts to boot I have recently started getting random GPU lockups. I have the following GPU: VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Madison [Mobility Radeon HD 5650/5750 / 6530M/6550M] I use the opensource driver on Wayland. Ithink the beginning of the random lockups coincided with upgrade from Mesa 12 to 13 on Fedora 25 but I never experienced any lock up on Fedora 24 with Wayland nor X. It happens with X as well Wayland on Fedora 25. It can happen at boot just when I get past the GDM log in screen or a couple of minutes after. Generally if I get past the first 15 minutes of a session it is stable. -- You are receiving this mail because: You are the assignee for the bug.

1 16

[Bug 93829] [Wine] Lockup with MotoGP 2
by bugzilla-daemon＠freedesktop.org 02 Nov '18

02 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=93829 Bug ID: 93829 Summary: [Wine] Lockup with MotoGP 2 Product: Mesa Version: 11.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: geecko.dev(a)free.fr QA Contact: dri-devel(a)lists.freedesktop.org Current stack: - wine 1.9.1 - mesa 11.1.1 - xf86-video-ati 7.6.1 - xorg-server 1.18.0 - linux 4.3.3 HD 7950 I have been trying to run MotoGP 2 on my desktop. It runs perfectly with all settings maxed out (vsync disabled). After a few minutes of playing the entire computer locks up. It's fairly random. All particles ingame are wrongly colored but I suspect it's a Wine issue. I have it on my laptop with the same stack and Intel graphics. I'll try to gather as much information as I can. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 102401] New: 4.2 RC5
by bugzilla-daemon＠bugzilla.kernel.org 10 Oct '18

10 Oct '18

https://bugzilla.kernel.org/show_bug.cgi?id=102401 Bug ID: 102401 Summary: 4.2 RC5 Product: Drivers Version: 2.5 Kernel Version: Radeon Displayport Audio Warping Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: contrib(a)kliznoe.com Regression: No I'm having issues with Linux 4.2 RC5 with the Displayport audio being deeper then normal. Doesn't seem to happen with 4.1.3 with a backported patch from https://bugzilla.kernel.org/attachment.cgi?id=183611 -- You are receiving this mail because: You are watching the assignee of the bug.

1 20

[RFC v4 00/18] vb2: Handle user cache hints, allow drivers to choose cache coherency
by Sakari Ailus 05 Oct '18

05 Oct '18

Hello, This is a rebased and partially reworked version of the vb2 cache hints support patch series posted by first myself, then Laurent and then myself again. I'm still posting this as RFC primarily because more testing and driver changes will be needed. In particular, a lot of platform drivers assume non-coherent memory but are not properly labelled as such. Please see the end of the message for detailed changes. This set unifies the cache coherency hint flags and corrects cache management in videobuf2 dma-contig and dma-sg memtype implementation. The support for non-coherent memory is completed: support for MMAP buffers is added and begin_cpu_access and end_cpu_access functions are added to DMA ops. Comments are welcome. changes since RFC v3: - Document V4L2_BUF_FLAG_NO_CACHE_SYNC flag behaviour for QBUF and DQBUF for CAPTURE and OUTPUT buffers. - Set queue dma_attrs DMA_ATTR_NON_CONSISTENT flag for omap3isp. - Put dma_sgt in vb2_dc_buf in order to avoid allocating and releasing it separately. It's generally needed anyway. - Buffer preparation DMA direction is generally DMA_TO_DEVICE for both CAPTURE and OUTPUT buffers: V4L2 does not guarantee that the user space could not write to capture buffers as well. Documentation/DMA-API.txt: - Before reading values that have been written by DMA from the device (use the DMA_FROM_DEVICE direction) - After writing values that will be written to the device using DMA (use the DMA_TO_DEVICE) direction - before *and* after handing memory to the device if the memory is DMA_BIDIRECTIONAL Cache maintenance can also be skipped for OUTPUT buffers in buffer finish as the hardware did not write to the buffer. changes since RFC v2: - Nicer looking tests for the need for syncing. - Also set DMA attributes for USERPTR buffers. - Unconditionally assign buf->attrs for MMAP buffers. - Don't call vb2_dc_get_base_sgt() until buf->dev is set. - Provide {begin,end}_cpu_access() dmabuf ops for cache management. - Make similar changes to dma-sg memops to support DMA attributes. Sakari Ailus (13): vb2: Rename confusingly named internal buffer preparation functions vb2: Move buffer cache synchronisation to prepare from queue vb2: Move cache synchronisation from buffer done to dqbuf handler v4l: Unify cache management hint buffer flags vb2: Anticipate queue specific DMA attributes for USERPTR buffers vb2: dma-contig: Assign DMA attrs for a buffer unconditionally vb2: dma-contig: Remove redundant sgt_base field vb2: dma-contig: Don't warn on failure in obtaining scatterlist vb2: dma-contig: Move vb2_dc_get_base_sgt() up vb2: dma-contig: Fix DMA attribute and cache management vb2: dma-contig: Add WARN_ON_ONCE() to check for potential bugs vb2: dma-sg: Let drivers decide DMA attrs of MMAP and USERPTR bufs vb2: Improve struct vb2_mem_ops documentation; alloc and put are for MMAP Samu Onkalo (1): vb2: Don't sync cache for a buffer if so requested Documentation/media/uapi/v4l/buffer.rst | 24 ++-- .../media/uapi/v4l/vidioc-prepare-buf.rst | 5 +- drivers/media/v4l2-core/videobuf2-core.c | 129 ++++++++++++++------- drivers/media/v4l2-core/videobuf2-dma-contig.c | 120 ++++++++++++------- drivers/media/v4l2-core/videobuf2-dma-sg.c | 47 ++++++-- drivers/media/v4l2-core/videobuf2-v4l2.c | 14 ++- drivers/media/v4l2-core/videobuf2-vmalloc.c | 3 +- include/media/videobuf2-core.h | 46 +++++--- include/trace/events/v4l2.h | 3 +- include/uapi/linux/videodev2.h | 7 +- 10 files changed, 263 insertions(+), 135 deletions(-) -- Regards, Sakari Sakari Ailus (17): vb2: Rename confusingly named internal buffer preparation functions vb2: Move buffer cache synchronisation to prepare from queue vb2: Move cache synchronisation from buffer done to dqbuf handler v4l: Unify cache management hint buffer flags vb2: Anticipate queue specific DMA attributes for USERPTR buffers vb2: dma-contig: Assign DMA attrs for a buffer unconditionally vb2: dma-contig: Remove redundant sgt_base field vb2: dma-contig: Don't warn on failure in obtaining scatterlist vb2: dma-contig: Allocate sgt as part of struct vb2_dc_buf vb2: dma-contig: Fix DMA attribute and cache management vb2: dma-contig: Add WARN_ON_ONCE() to check for potential bugs vb2: dma-sg: Let drivers decide DMA attrs of MMAP and USERPTR bufs vb2: Improve struct vb2_mem_ops documentation; alloc and put are for MMAP vb2: Dma direction is always DMA_TO_DEVICE in buffer preparation vb2: Do sync plane cache only for CAPTURE buffers in finish memop docs-rst: Document precise V4L2_BUF_FLAG_NO_CACHE_SYNC flag behaviour v4l: Use non-consistent DMA mappings for hardware that deserves it Samu Onkalo (1): vb2: Don't sync cache for a buffer if so requested Documentation/media/uapi/v4l/buffer.rst | 45 +++-- .../media/uapi/v4l/vidioc-prepare-buf.rst | 5 +- drivers/media/platform/omap3isp/ispvideo.c | 1 + drivers/media/v4l2-core/videobuf2-core.c | 122 ++++++++----- drivers/media/v4l2-core/videobuf2-dma-contig.c | 191 ++++++++++++--------- drivers/media/v4l2-core/videobuf2-dma-sg.c | 85 ++++++--- drivers/media/v4l2-core/videobuf2-v4l2.c | 14 +- drivers/media/v4l2-core/videobuf2-vmalloc.c | 3 +- include/media/videobuf2-core.h | 46 +++-- include/trace/events/v4l2.h | 3 +- include/uapi/linux/videodev2.h | 7 +- 11 files changed, 338 insertions(+), 184 deletions(-) -- 2.7.4

5 26

[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly
by bugzilla-daemon＠freedesktop.org 04 Oct '18

04 Oct '18

https://bugs.freedesktop.org/show_bug.cgi?id=101739 Bug ID: 101739 Summary: An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly 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: krystian.galaj(a)vpltd.com QA Contact: dri-devel(a)lists.freedesktop.org The game is sometimes rendering trees. It has multiple tree mesh models, and when the tree gets close, the game is switching between different LODs/models by rendering both models overlapping on a grid of pixels, as if checkerboard, pixels of old LOD in black fields of it, new one in white. As long as it’s doing that using single-sampled buffers as render targets, all is fine. However in higher quality modes, the game switches to multisampled buffers. When using multisampled buffers, if ATOC is turned on in settings, the game is using alpha-to-coverage technique without polygon sorting to make sure that the grass is rendered correctly. At the same time it’s using depth test and depth write to fill up the depth buffer. In the same execution of fragment shader it sets the output color and alpha value, and the depth buffer value, and it expects the alpha value to cause the color value to end up only in some samples of multisampled texture, and - the important bit - the depth value to end up only in the corresponding samples of the depth buffer. This technique works on DX11 on Windows, on all drivers on Mac OS X, and on NVidia drivers on Linux, but on Mesa Radeonsi drivers on Linux it makes the rendering go bad, rendering most of the tree pixels white until the LOD transition ends. The white is visible on the screen because it is the initial color of the multisampled render target, and for some reason this color is allowed to leak through, which means that in some cases the depth buffer value is set, when the corresponding color buffer value isn’t. Both depth and color buffer have the same number of samples (8), and were created with fixedSamples = true in OpenGL call. It looks as if the depth buffer values in case of Mesa Radeonsi driver were: - correctly not written when the depth test fails for the fragment shader, - correctly written to all samples of the depth buffer when alpha coverage directs the draw to fill them all, but - INCORRECTLY assigned not only to those samples to which alpha coverage directed the fragment output color, but either to all the samples in depth buffer, or to samples in depth buffer that don’t correspond to the samples in color attachment buffer. We encountered the same issue in 2015 in fglrx drivers, contacted AMD team about it, and received confirmation that it is a bug, and that it was fixed. Unfortunately, shortly after that fglrx drivers went out of use. The issue can be easily reproduced in Arma 3 by: - launching Arma 3 game, - switching to High quality or higher to turn on multisampled buffers, - enabling ATOC (alpha to coverage) in Video settings, or making sure it's enabled, - launching first level of Drawdown 2035 campaign, ie. starting a new campaign, bypassing optional tutorial, and observing as the main character walks into the base, the bushes flicker white from time to time as they get closer. The issue is present in Mesa 17.2.0-devel from padoka PPA, on at least Radeon R7 260X/360. -- You are receiving this mail because: You are the assignee for the bug.

1 18

[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!
by bugzilla-daemon＠freedesktop.org 20 Sep '18

20 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=100443 Bug ID: 100443 Summary: DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table! 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: freedesktop(a)lanig.email Created attachment 130529 --> https://bugs.freedesktop.org/attachment.cgi?id=130529&action=edit DMESG excerpt System: Ubuntu 17.04 + Kernel 4.11 RC4 + Padoka PPA AMD Ryzen 7 1700X ASRock AB350 Pro4 Bios v1.40 (because 2.20 breaks ECC) XfX RX 480 RS 2x16GiB Crucial CT2K16G4XFD824A ECC Kit After installing my new motherboard and CPU I just went through the system messages to see how well it's supported or if there are some issues to be sorted out. Unfortunately it looks like there are issues with AMDGPU, at the initialization there are really massive warnings and errors. It starts with these several times: [ 1.482118] AMD-Vi: Event logged [ [ 1.482118] IO_PAGE_FAULT device=0c:00.0 domain=0x0003 address=0x000000f4001e6a00 flags=0x0010] And ends in telling me that something is wrong with the powerplay: [ 1.526878] amdgpu: [powerplay] [AVFS] Something is broken. See log! [ 1.528706] amdgpu: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table! This report has been separated from this one: https://bugs.freedesktop.org/show_bug.cgi?id=100437 -- You are receiving this mail because: You are the assignee for the bug.

1 40

[Bug 101877] R9 390 with multiple monitors always using highest memory clock
by bugzilla-daemon＠freedesktop.org 18 Sep '18

18 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=101877 Bug ID: 101877 Summary: R9 390 with multiple monitors always using highest memory clock Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: hisele(a)siduge.v0yd.nl My MSI r9 390 forces the memory clock to 150000 if I plug in more than one monitor. The card draws 40 watts more power while idle and keeps the fans running all the time. This is happening with both amdgpu and radeon and I can fix the problem by disabling dpm, but this causes some other issues. I read earlier that this behaviour is intended and is a common problem with graphics cards but IIRC a recent driver update fixed this on windows so I'd like to know if there is any chance to also get a fix on linux? -- You are receiving this mail because: You are the assignee for the bug.

1 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2017