dri-devel July 2017

dri-devel@lists.freedesktop.org

212 participants
1542 discussions

[Bug 69120] New: With dpm=1 vdpau is not usable
by bugzilla-daemon＠freedesktop.org 20 Jul '18

20 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=69120 Priority: medium Bug ID: 69120 Assignee: dri-devel(a)lists.freedesktop.org Summary: With dpm=1 vdpau is not usable Severity: normal Classification: Unclassified OS: Linux (All) Reporter: john.ettedgui(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 9.2 Component: Drivers/Gallium/r600 Product: Mesa Hello, with radeon.dpm=0 (or not set), vdpau output works very fine. But if I switch to radeon.dpm=1 it becomes unusable. mplayer tells me that my computer is too slow, video stutters to a crazy extent, same in xbmc. With dpm set to 1, I am still able to watch videos "normally" if not using vdpau. I have a Radeon 4670, Linux 3.11, Mesa 9.2 and Radeon 1:7.2.0. I tried to change power_dpm_state and power_dpm_force_performance_level to see if it would help. power_dpm_state stays at performance but even if I set power_dpm_force_performance_level to high, but it always reverts to auto... This doesn't help at all... I am not sure what else to attach. Thank you -- You are receiving this mail because: You are the assignee for the bug.

1 29

[Bug 95329] Metro 2033 Redux benchmark fails to start
by bugzilla-daemon＠freedesktop.org 10 Jul '18

10 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=95329 Bug ID: 95329 Summary: Metro 2033 Redux benchmark fails to start 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: 0xe2.0x9a.0x9b(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Mesa: 11.3.0-devel (git-57763ee) GPU: R9 390 (dynamic power management: disabled) Linux kernel: 4.5.0 Kernel module: radeon Steps to reproduce the issue: 1) cd ".steam/root/steamapps/common/Metro 2033 Redux" 2) mv metro metro.bin 3) ln -s benchmark.sh metro 4) Edit benchmark.sh and replace "./metro" with "./metro.bin" 5) Copy the file "user.cfg" (attached to this bug report) to directory "110000106d2b5d5" 6) Start the Steam client from command-line 7) Start Metro 2033 Redux from the Steam client Segmentation fault (core dumped) ./metro.bin -benchmark benchmarks\\benchmark33 -bench_runs 1 -output_file benchmark.log -close_on_finish Notes: - Running "gdb metro.bin core" does not provide useful information - AMD drivers (fglrx) are working OK - Step 5 is maybe optional, but I haven't verified this Running "valgrind --tool=callgrind" for about an hour seems to indicate that the issue may be linked to very slow shader compilation, but this is inconclusive. AMD drivers (fglrx) start the benchmark much faster. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 90481] Radeon R9 270X gpu lockup in game spec ops: the line.
by bugzilla-daemon＠freedesktop.org 04 Jul '18

04 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=90481 Bug ID: 90481 Summary: Radeon R9 270X gpu lockup in game spec ops: the line. Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: vim(a)xmail.net Created attachment 115834 --> https://bugs.freedesktop.org/attachment.cgi?id=115834&action=edit kernel log with drm.debug=1 Playing in spec ops: the line from steam causes gpu lockup. Behaviour differs. Firstly system freeze, after a few seconds screen becomes black. Sometimes works only sysrq, sometimes i can switch to VT and log in (screen still is black, but sudo reboot works). Sometimes it unfreeze and everything works again. System: Fedora 22 x86_64 kernel: 4.0.2-300.fc22.x86_64 mesa: 10.5.4-1.20150505.fc22 xorg-server: 1.17.1-11.fc22 libdrm: 2.4.61-3.fc22 xorg-x11-drv-ati.x86_64: 7.5.0-3.fc22 window manager: kwin-5.3.0-2.fc22 video card Radeon R9 270X OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.5.4 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.5.4 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.5.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions: reproduce always. After 15-40 minutes of playing. -- You are receiving this mail because: You are the assignee for the bug.

1 28

[Bug 101900] No HDMI audio on Polaris
by bugzilla-daemon＠freedesktop.org 26 Jun '18

26 Jun '18

https://bugs.freedesktop.org/show_bug.cgi?id=101900 Bug ID: 101900 Summary: No HDMI audio on Polaris Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: direx(a)betriebsdirektor.de Created attachment 132868 --> https://bugs.freedesktop.org/attachment.cgi?id=132868&action=edit dmesg I am using the current amd-staging-4.11 tree with DC/DAL and HDMI audio is still not working on my RX480. I have already experimented with the amdgpu.audio parameter, but it does not change anything. alsamixer shows 6 different SPDIF devices for "HDA ATI HDMI" and they are all unmuted. Still HDMI audio is not working at all. The dmesg actually looks promising, as dc_link_detect detects my AVR and quite a few sound modes with different channel numbers. -- You are receiving this mail because: You are the assignee for the bug.

1 44

[PATCH libdrm v2 1/5] xf86drm: implement drmGetMinorNameForFD for non-sysfs
by Jonathan Gray 26 Jun '18

26 Jun '18

Implement drmGetMinorNameForFD for systems without sysfs by adapting drm_get_device_name_for_fd() from the Mesa loader. v2: use type parameter to select dev name instead of always using DRM_DEV_NAME Signed-off-by: Jonathan Gray <jsg(a)jsg.id.au> --- xf86drm.c | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/xf86drm.c b/xf86drm.c index f117716..f93ebc0 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -2818,7 +2818,40 @@ static char *drmGetMinorNameForFD(int fd, int type) out_close_dir: closedir(sysdir); #else -#warning "Missing implementation of drmGetMinorNameForFD" + struct stat sbuf; + char buf[PATH_MAX + 1]; + const char *dev_name; + unsigned int maj, min; + int n; + + if (fstat(fd, &sbuf)) + return NULL; + + maj = major(sbuf.st_rdev); + min = minor(sbuf.st_rdev); + + if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) + return NULL; + + switch (type) { + case DRM_NODE_PRIMARY: + dev_name = DRM_DEV_NAME; + break; + case DRM_NODE_CONTROL: + dev_name = DRM_CONTROL_DEV_NAME; + break; + case DRM_NODE_RENDER: + dev_name = DRM_RENDER_DEV_NAME; + break; + default: + return NULL; + }; + + n = snprintf(buf, sizeof(buf), dev_name, DRM_DIR_NAME, min); + if (n == -1 || n >= sizeof(buf)) + return NULL; + + return strdup(buf); #endif return NULL; } -- 2.10.2

3 13

[PATCH i-g-t v2 0/7] igt: Add support for testing writeback connectors
by Liviu Dudau 25 Jun '18

25 Jun '18

We're trying to introduce support for writeback connectors, a way to expose in DRM the hardware functionality from display engines that allows to write back into memory the result of the DE's composition of supported planes. Generic DRM support is available here [1] and will be merged once this patchset gets approved for inclusion into igt. VC4 support for writeback is added here [2] and for mali-dp is added here [3]. Changelog: - v2: Rebased on top of a844ccbdbab9fd16c37de81281c6281bc800e97a - v1: Original (re)submission [4] Many thanks, Liviu [1] https://lists.freedesktop.org/archives/dri-devel/2017-May/141796.html [2] https://lists.freedesktop.org/archives/dri-devel/2017-June/143337.html [3] https://lists.freedesktop.org/archives/dri-devel/2017-May/141799.html [4] https://lists.freedesktop.org/archives/intel-gfx/2017-July/132344.html Brian Starkey (7): igt: lib/igt_crc: Split out CRC functionality lib/igt_kms: Add writeback support in lib/ kms_writeback: Add initial writeback tests lib: Add function to hash a framebuffer kms_writeback: Add writeback-check-output lib/igt_kms: Add igt_output_clone_pipe for cloning kms_writeback: Add tests using a cloned output lib/Makefile.sources | 2 + lib/igt_aux.c | 1 + lib/igt_chamelium.h | 1 + lib/igt_crc.c | 563 ++++++++++++++++++++++++++++++++++++++ lib/igt_crc.h | 125 +++++++++ lib/igt_debugfs.c | 547 ------------------------------------ lib/igt_debugfs.h | 81 ------ lib/igt_fb.c | 65 +++++ lib/igt_fb.h | 5 + lib/igt_kms.c | 172 +++++++++--- lib/igt_kms.h | 26 ++ tests/Makefile.sources | 1 + tests/chamelium.c | 1 + tests/kms_atomic_transition.c | 1 + tests/kms_ccs.c | 1 + tests/kms_chv_cursor_fail.c | 1 + tests/kms_crtc_background_color.c | 1 + tests/kms_cursor_crc.c | 1 + tests/kms_cursor_legacy.c | 1 + tests/kms_draw_crc.c | 1 + tests/kms_fbc_crc.c | 1 + tests/kms_flip_tiling.c | 1 + tests/kms_frontbuffer_tracking.c | 1 + tests/kms_mmap_write_crc.c | 1 + tests/kms_mmio_vs_cs_flip.c | 1 + tests/kms_pipe_color.c | 1 + tests/kms_pipe_crc_basic.c | 1 + tests/kms_plane.c | 1 + tests/kms_plane_lowres.c | 1 + tests/kms_plane_multiple.c | 1 + tests/kms_plane_scaling.c | 1 + tests/kms_pwrite_crc.c | 1 + tests/kms_rotation_crc.c | 1 + tests/kms_universal_plane.c | 1 + tests/kms_writeback.c | 541 ++++++++++++++++++++++++++++++++++++ tools/intel_display_crc.c | 1 + 36 files changed, 1487 insertions(+), 666 deletions(-) create mode 100644 lib/igt_crc.c create mode 100644 lib/igt_crc.h create mode 100644 tests/kms_writeback.c -- 2.13.2

2 8

[PATCH wq#for-linus] drm: fix a fallout from slow-work -> wq conversion
by Tejun Heo 19 Jun '18

19 Jun '18

Commit 991ea75c (drm: use workqueue instead of slow-work), which made drm to use wq instead of slow-work, didn't account for the return value difference between delayed_slow_work_enqueue() and queue_delayed_work(). The former returns 0 on success and -errno on failures while the latter never fails and only uses the return value to indicate whether the work was already pending or not. This misconversion triggered spurious error messages. Remove the now unnecessary return value check and error message. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Markus Trippelsdorf <markus(a)trippelsdorf.de> Cc: David Airlie <airlied(a)linux.ie> Cc: dri-devel(a)lists.freedesktop.org --- Markus, it's almost trivial but it would be great if you can test this one too. David, may I route this wq#for-linus? Thanks. drivers/gpu/drm/drm_crtc_helper.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 4598130..211ed7e 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work) struct drm_connector *connector; enum drm_connector_status old_status, status; bool repoll = false, changed = false; - int ret; mutex_lock(&dev->mode_config.mutex); list_for_each_entry(connector, &dev->mode_config.connector_list, head) { @@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work) dev->mode_config.funcs->output_poll_changed(dev); } - if (repoll) { - ret = queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD); - if (ret) - DRM_ERROR("delayed enqueue failed %d\n", ret); - } + if (repoll) + queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD); } void drm_kms_helper_poll_disable(struct drm_device *dev)

4 4

[Bug 100687] KWin won't draw Aurorae themes under EGL
by bugzilla-daemon＠freedesktop.org 14 Jun '18

14 Jun '18

https://bugs.freedesktop.org/show_bug.cgi?id=100687 Bug ID: 100687 Summary: KWin won't draw Aurorae themes under EGL Product: Mesa Version: 12.0 Hardware: Other OS: All Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: sonichedgehog_hyperblast00(a)yahoo.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 130849 --> https://bugs.freedesktop.org/attachment.cgi?id=130849&action=edit Screenshot I initially reported this bug with openSUSE and the KDE teams. It was ultimately concluded that it's a problem with Mesa or the Radeon driver. As such I was encouraged to post about it here as well. Links to the other bug reports: https://bugzilla.opensuse.org/show_bug.cgi?id=1033598 https://bugs.kde.org/show_bug.cgi?id=378663 In summary: This is a problem that affects Linux users running the KDE desktop. After a recent openSUSE Tumbleweed snapshot, I found that KWin no longer renders Aurorae themes. Other themes work fine however, and this only affects Aurorae ones... Plasma also has no issues rendering desktop elements. The problem happens both with and without desktop effects enabled. The space where the titlebar and border should be becomes completely empty, with no graphics or text or buttons showing. However the blur effect is still functional in those areas, and clicking and dragging on any window component works correctly (even if they're invisible). Today I found the culprit as well as a workaround, thanks to Martin Gräßlin in the same report on the KDE bug tracker. The issue only happens when using egl instead of glx as the backend of KWin. This can be modified by opening ~/.config/kwinrc in a text editor and changing: GLPlatformInterface=egl to GLPlatformInterface=glx Anyone with a Radeon card should be able to reproduce this, by doing the reverse of the above and switching their KDE desktop to egl. I understand the driver developers need to figure out what's breaking it, which hopefully won't be difficult using this test case. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 28771] New: Vsync always on
by bugzilla-daemon＠freedesktop.org 12 Jun '18

12 Jun '18

https://bugs.freedesktop.org/show_bug.cgi?id=28771 Summary: Vsync always on Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: sa(a)whiz.se With kernel 2.6.35, there doesn't seem to be a way to turn off vsync/vblank. E.g. "vblank_mode=0 glxgears" has no effect. This seems to be the same for both r300c and r300g. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: 801e83227a59a29eea425ea612083bbf2b536c30 -- xserver: 1.8.1.901 -- mesa: a5c44986a3f19936df448fe4ae47ca77ece9b0ce -- drm: 6ea2bda5f5ec8f27359760ce580fdad3df0464df -- kernel: 2.6.35-rc3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 38

[Bug 73931] New: rmmod radeon and kernel crash
by bugzilla-daemon＠bugzilla.kernel.org 08 Jun '18

08 Jun '18

https://bugzilla.kernel.org/show_bug.cgi?id=73931 Bug ID: 73931 Summary: rmmod radeon and kernel crash Product: Drivers Version: 2.5 Kernel Version: 3.14 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: pali.rohar(a)gmail.com Regression: No Created attachment 132051 --> https://bugzilla.kernel.org/attachment.cgi?id=132051&action=edit rmmod_radeon_kernel_panic After calling rmmod radeon, kernel show lots of error lines and then crash. It looks like that radeon module does not cleanup hwmon interface at exit. After calling rmmod radeon there is still hwmon interface: $ readlink /sys/class/hwmon/hwmon1 ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon/hwmon1 And after calling ls, or cat in hwmon1 kernel crash... See attachment from syslog. $ lspci -nn 01:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M] [1002:6660] -- You are receiving this mail because: You are watching the assignee of the bug.

1 11

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2017