dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[Bug 110140] Green bottom half of video frame when using JPEG acceleration (vcn_v1_0_jpeg_ring_emit_fence() WARNING)
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=110140 Bug ID: 110140 Summary: Green bottom half of video frame when using JPEG acceleration (vcn_v1_0_jpeg_ring_emit_fence() WARNING) Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: zajec5(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org I use HP EliteBook 745 G5 with Ryzen 5 PRO 2500U. When using Chromium and HTML5 based video chat: https://meet.jit.si/amdtest I see image from my webcam corrupted (bottom half is all green). It only happens with Chromium's setting "Use hardware acceleration when available" enabled which appears to involve some JPEG hardware acceleration. With above web chat page opened I see about 10 kernel WARNINGs per second: [ 290.169611] WARNING: CPU: 0 PID: 374 at drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c:1669 vcn_v1_0_jpeg_ring_emit_fence+0xc2f/0xc40 [amdgpu] [ 290.169615] Modules linked in: ccm(E) fuse(E) rfcomm(E) af_packet(E) bnep(E) hid_logitech_hidpp(E) btusb(E) btrtl(E) btbcm(E) btintel(E) hid_logitech_dj(E) hid_generic(E) bluetooth(E) cp210x(E) usbserial(E) ecdh_generic(E) usbhid(E) uvcvideo(E) videobuf2_vmalloc(E) videobuf2_memops(E) videobuf2_v4l2(E) videodev(E) videobuf2_common(E) nf_nat_tftp(E) nf_conntrack_tftp(E) xt_CT(E) xt_tcpudp(E) ip6t_rpfilter(E) ip6t_REJECT(E) nf_reject_ipv6(E) ipt_REJECT(E) nf_reject_ipv4(E) xt_conntrack(E) ebtable_nat(E) ip6table_nat(E) nf_nat_ipv6(E) ip6table_mangle(E) ip6table_raw(E) ip6table_security(E) iptable_nat(E) nf_nat_ipv4(E) nf_nat(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) libcrc32c(E) ip_set(E) nfnetlink(E) ebtable_filter(E) ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E) ip_tables(E) x_tables(E) bpfilter(E) snd_hda_codec_conexant(E) snd_hda_codec_generic(E) ledtrig_audio(E) snd_hda_codec_hdmi(E) snd_hda_intel(E) [ 290.169671] snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) arc4(E) edac_mce_amd(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) msr(E) iwlmvm(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) mac80211(E) iwlwifi(E) aesni_intel(E) aes_x86_64(E) crypto_simd(E) realtek(E) cryptd(E) glue_helper(E) hp_wmi(E) joydev(E) pcspkr(E) sparse_keymap(E) wmi_bmof(E) sp5100_tco(E) cfg80211(E) k10temp(E) i2c_piix4(E) ipmi_devintf(E) r8169(E) rfkill(E) ipmi_msghandler(E) libphy(E) ucsi_acpi(E) typec_ucsi(E) thermal(E) typec(E) battery(E) hp_wireless(E) pinctrl_amd(E) ac(E) button(E) pcc_cpufreq(E) acpi_cpufreq(E) amdgpu(E) i2c_algo_bit(E) gpu_sched(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) ttm(E) serio_raw(E) xhci_pci(E) ehci_pci(E) xhci_hcd(E) drm(E) ehci_hcd(E) usbcore(E) wmi(E) video(E) i2c_hid(E) l2tp_ppp(E) l2tp_netlink(E) l2tp_core(E) ip6_udp_tunnel(E) udp_tunnel(E) pppox(E) ppp_generic(E) [ 290.169730] slhc(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) efivarfs(E) [ 290.169745] CPU: 0 PID: 374 Comm: vcn_jpeg Tainted: G W E 5.0.0-rc1+ #6 [ 290.169747] Hardware name: HP HP EliteBook 745 G5/83D5, BIOS Q81 Ver. 01.03.01 07/26/2018 [ 290.169822] RIP: 0010:vcn_v1_0_jpeg_ring_emit_fence+0xc2f/0xc40 [amdgpu] [ 290.169825] Code: c0 e8 15 74 db ff 48 8b 83 38 02 00 00 e9 ea f4 ff ff 48 c7 c7 20 0f 67 c0 e8 fd 73 db ff 48 8b 83 38 02 00 00 e9 6e f4 ff ff <0f> 0b e9 ee f3 ff ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 [ 290.169827] RSP: 0018:ffffab50022fbdc8 EFLAGS: 00010202 [ 290.169830] RAX: ffffffffc04f6500 RBX: ffff8fba5655c5a8 RCX: 0000000000000001 [ 290.169831] RDX: 00000000000007f9 RSI: 000000000076e040 RDI: ffff8fba5655c5a8 [ 290.169833] RBP: ffff8fba56550000 R08: ffffab5001c1d000 R09: ffffab5001c1d000 [ 290.169834] R10: ffffab5001c1d000 R11: ffffab5001c1d000 R12: 0000000000000000 [ 290.169836] R13: 000000000076e040 R14: 00000000000007f9 R15: ffff8fba5b43ea10 [ 290.169839] FS: 0000000000000000(0000) GS:ffff8fba5fc00000(0000) knlGS:0000000000000000 [ 290.169840] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 290.169842] CR2: 00007f8cc86e0008 CR3: 00000003f9e76000 CR4: 00000000003406f0 [ 290.169844] Call Trace: [ 290.169920] amdgpu_ib_schedule+0x29d/0x560 [amdgpu] [ 290.169996] amdgpu_job_run+0xfd/0x170 [amdgpu] [ 290.170004] drm_sched_main+0xdf/0x250 [gpu_sched] [ 290.170014] ? wait_woken+0x80/0x80 [ 290.170019] ? drm_sched_stop+0x130/0x130 [gpu_sched] [ 290.170023] kthread+0x116/0x130 [ 290.170027] ? kthread_create_worker_on_cpu+0x40/0x40 [ 290.170034] ret_from_fork+0x27/0x50 [ 290.170040] ---[ end trace ffe1a144a94cb37d ]--- This problem occurs with kernels: 4.20.12 5.0.0 5.0.0-rc1 from agd5f's amd-staging-drm-next (2019-03-16) I use Mesa 18.3.4. -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 110137] drirc adaptive sync, vrr, freesync blacklisting documentation
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=110137 Bug ID: 110137 Summary: drirc adaptive sync, vrr, freesync blacklisting documentation Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: grmat(a)sub.red QA Contact: dri-devel(a)lists.freedesktop.org Hi, using qutebrowser in fullscreen mode breaks the video output with VRR enabled because it refreshes very unsteadily, which is typical for a browser. Some browsers are blacklisted in the drirc. I've added the following lines to the drirc, but it doesn't disable VRR for a fullscreen qutebrowser window.: <application name="qutebrowser" executable="qutebrowser"> <option name="adaptive_sync" value="false" /> </application> Is there any documentation about how the matching works? -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 110130] ring gfx timeout when playing warcraft 3
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=110130 Bug ID: 110130 Summary: ring gfx timeout when playing warcraft 3 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: haagch(a)frickel.club QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 143678 --> https://bugs.freedesktop.org/attachment.cgi?id=143678&action=edit kernel log Vega 64, Linux 5.0, mesa git 1ea42894c70, llvm git https://github.com/llvm-mirror/llvm/commit/d8706fcd747 Unfortunately hard to reproduce: Play custom maps in warcraft 3 (started with -opengl) in wine (4.1) for a few hours and maybe it'll happen. Interestingly amdgpu thinks kwin is the culprit: Mär 14 23:58:30 c-pc kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=5170371, emitted seq=5170373 Mär 14 23:58:30 c-pc kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process kwin_x11 pid 999 thread kwin_x11:cs0 pid 1396 I've also seen it say steam instead of kwin. Other games do not seem to trigger this. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 109794] LLVM not properly shutdown in `si_pipe.c`?
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=109794 Bug ID: 109794 Summary: LLVM not properly shutdown in `si_pipe.c`? Product: Mesa Version: git 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: zegentzy(a)protonmail.com QA Contact: dri-devel(a)lists.freedesktop.org tl;dr; Shouldn't we be calling `LLVMShutdown()` somewhere? I had a program which was calling: ``` eglInitialize(disp, &majoir, &minor); eglTerminate(disp); eglInitialize(disp, &majoir, &minor); ``` Which lead to mesa outputting the following before continuing on normally during the second call to `eglInitalize`: ``` mesa: for the -simplifycfg-sink-common option: may only occur zero or one times! mesa: for the -global-isel-abort option: may only occur zero or one times! ``` This prompted an investigation me to investigate, and with the aid of @imirkin, I think I got the cause. You see, in an `eglInitialize` call `radeonsi_dri.so` gets loaded, which also loads in `libLLVM-9svn.so`, and eventually `ac_init_llvm_once()` gets called more than once. That's OK, for as the name implies, it only happens once. Issue is, when `eglTerminate` is called, `radeonsi_dri.so` gets unloaded, but not `libLLVM-9svn.so`. This means that the next time we all `eglInitialize`, LLVM's `ManagedStatic`s will be preserved, but not our static var `ac_init_llvm_target_once_flag`. We can fix this by calling `LLVMShutdown` before unloading `radeonsi_dri.so`, that way LLVM's `ManagedStatic`s are also reset. Alas, I'm not familiar enough with the mesa codebase, so I got no clue where the appropriate place to plop this function is. Any aid would be well appreciated. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 109793] I420/IYUV is not advertised in vaQueryImageFormats()
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=109793 Bug ID: 109793 Summary: I420/IYUV is not advertised in vaQueryImageFormats() Product: Mesa Version: 18.2 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: andrescj(a)chromium.org QA Contact: dri-devel(a)lists.freedesktop.org According to https://gitlab.freedesktop.org/mesa/mesa/commit/b0a44f10, vaGetImage() can convert from an internal format of NV12 to a IYUV image. However, vaQueryImageFormats() does not report I420 or IYUV as a supported image format, and it seems it should (I tried this on a AMD STONEY device). -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 109783] YUV422 support not advertised for VAProfileJPEGBaseline decoding
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=109783 Bug ID: 109783 Summary: YUV422 support not advertised for VAProfileJPEGBaseline decoding Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: andrescj(a)chromium.org QA Contact: dri-devel(a)lists.freedesktop.org Hi. I'm trying to detect the VAAPI JPEG decoder capabilities using vaQueryConfigAttributes(). I'm getting VA_RT_FORMAT_YUV420 as the only value for VAConfigAttribRTFormat when the profile is VAProfileJPEGBaseline and the entrypoint is VAEntrypointVLD. However, based on [1], it seems that the JPEG decoder would be happy to decode YUV422 images (in fact, YUV422 decoding works when I call vaCreateSurfaces() with VA_RT_FORMAT_YUV422). Note that when I use vaQuerySurfaceAttributes(), I only get NV12 for VASurfaceAttribPixelFormat, so YUV422 is also not advertised there. Is this intended behavior? [1] https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/state_trac… -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 109763] [radeonsi] Enable framerate capping
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=109763 Bug ID: 109763 Summary: [radeonsi] Enable framerate capping 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: shtetldik(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org It can be beneficial to enable framerate capping, to reduce power consumption and hardware wear out in case when user can be satisfied with certain max framerate. There is a similar DRI bug: https://bugs.freedesktop.org/show_bug.cgi?id=100389 But not sure what the right place is for such capping to occur, so opening one for radeonsi. -- You are receiving this mail because: You are the assignee for the bug.

1 15

[Bug 109608] Regression from llvm-6: llvm-7 replaces 'undef' with 'NaN', and generates NaN at the assembler level - This issue generates black screen on some fragment shaders.
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=109608 Bug ID: 109608 Summary: Regression from llvm-6: llvm-7 replaces 'undef' with 'NaN', and generates NaN at the assembler level - This issue generates black screen on some fragment shaders. 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: patrick9876(a)free.fr QA Contact: dri-devel(a)lists.freedesktop.org The issue is not related to mesa itself but at the LLVM optimization stage: LLVMRunPassManager(). This bug report is mostly for tracking purposes. Here are two fragment shaders affected: https://www.shadertoy.com/view/ltl3WS and https://www.shadertoy.com/view/MdVcRd Here is the LLVM bug report: https://bugs.llvm.org/show_bug.cgi?id=40690 -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 109466] Frozen display with Radeon RX 580 and Open Source Drivers under GNU/Linux Debian Sid
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=109466 Bug ID: 109466 Summary: Frozen display with Radeon RX 580 and Open Source Drivers under GNU/Linux Debian Sid Product: Mesa Version: 18.3 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: yann.kervran(a)free.fr QA Contact: dri-devel(a)lists.freedesktop.org Hello, I experience some troubles with my computer when I try to make 3D : all the display freeze and I can no longer access to any input (keyboard or mouse). >From time to time, I can move the mouse, but can’t do anything with it. I can’t switch to another TTY but can access with SSH. It happens with any 3D software but seems to come quicker with games, with no consistency in the timing or happening conditions: sometimes it takes 1mn, sometimes 10. I have experienced it with Blender (last 2.80 branch) and Super Tux Kart, for instance. Here is below informations about the crash and my computer. I am under Debian Sid, with XFCE desktop. Feel free to ask me for details, with eventually the commands to pass to get the info you need. All the best from snowy France --- dmesg output at the crash : [ 4600.707439] gmc_v8_0_process_interrupt: 5 callbacks suppressed [ 4600.707448] amdgpu 0000:01:00.0: GPU fault detected: 147 0x0c004801 for process supertuxkart pid 3736 thread supertuxka:cs0 pid 3737 [ 4600.707458] amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x01105D80 [ 4600.707464] amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x04048001 [ 4600.707472] amdgpu 0000:01:00.0: VM fault (0x01, vmid 2, pasid 32770) at page 17849728, read from 'TC4' (0x54433400) (72) [ 5118.249900] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=471393, emitted seq=471395 [ 5118.249909] [drm] GPU recovery disabled. infos about my computer : --- $ uname -a Linux groskoui 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 (2019-01-17) x86_64 GNU/Linux --- $ glxinfo -B name of display: :0.0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 4.19.0-2-amd64, LLVM 7.0.1) (0x67df) Version: 18.3.2 Accelerated: yes Video memory: 8192MB 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: 7976 MB, largest block: 7976 MB VBO free aux. memory - total: 8183 MB, largest block: 8183 MB Texture free memory - total: 7976 MB, largest block: 7976 MB Texture free aux. memory - total: 8183 MB, largest block: 8183 MB Renderbuffer free memory - total: 7976 MB, largest block: 7976 MB Renderbuffer free aux. memory - total: 8183 MB, largest block: 8183 MB Memory info (GL_NVX_gpu_memory_info): Dedicated video memory: 8192 MB Total available memory: 16384 MB Currently available dedicated video memory: 7976 MB OpenGL vendor string: X.Org OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 4.19.0-2-amd64, LLVM 7.0.1) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.2 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.2 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.2 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 109382] RX Vega M GL performance and stuttering issues
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=109382 Bug ID: 109382 Summary: RX Vega M GL performance and stuttering issues Product: Mesa Version: 18.3 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: princetonf(a)optonline.net QA Contact: dri-devel(a)lists.freedesktop.org OpenGL renderer string: AMD VEGAM (DRM 3.27.0, 4.20.3-arch1-1-ARCH, LLVM 7.0.0) Dell XPS 9575 AMD's discrete GPU on the Kaby Lake architecture performs significantly worse under Linux than under Windows. Below are some rudimentary data I've collected: Game Linux Windows TF2 30-50 FPS 60-100 FPS Borderlands 2 30-43 FPS 42-52 FPS Minecraft 60+ FPS 40-50 FPS CSGO 40-55 FPS 60+ FPS Notably, Minecraft is the exception, performing much better under Linux for some reason. All of the Source engine games (CSGO, TF2) I tested also had a very severe stutter, which would happen every other second. -- You are receiving this mail because: You are the assignee for the bug.

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019