dri-devel August 2019

dri-devel@lists.freedesktop.org

318 participants
2338 discussions

[PATCH v5 0/1] drm/syncobj: add syncobj sideband payload for threaded submission
by Lionel Landwerlin 21 Aug '19

21 Aug '19

A bunch of fixes :) Lionel Landwerlin (1): drm/syncobj: add sideband payload drivers/gpu/drm/drm_internal.h | 2 ++ drivers/gpu/drm/drm_ioctl.c | 3 ++ drivers/gpu/drm/drm_syncobj.c | 58 +++++++++++++++++++++++++++++++++- include/drm/drm_syncobj.h | 9 ++++++ include/uapi/drm/drm.h | 17 ++++++++++ 5 files changed, 88 insertions(+), 1 deletion(-) -- 2.23.0.rc1

3 3

[PATCH v2 00/14] Display Stream Compression (DSC) for AMD Navi
by David Francis 21 Aug '19

21 Aug '19

This patchset enables Display Stream Compression (DSC) on DP connectors on Navi ASICs, both SST and DSC. 8k60 and 4k144 support requires ODM combine, an AMD internal feature that may be a bit buggy right now. Patches 1 through 5 enable DSC for SST. Most of the work was already done in the Navi promotion patches; this just hooks it up to the atomic interface. The first two reverts are of temporary changes to block off DSC. The third is of a commit that was accidentally promoted twice. The fourth and last revert fixes a potential issue with ODM combine. Patches 6 and 7 are fixes for bugs that would be exposed by MST DSC. One fix is with the MST code and the other in the DSC code. Patches 8, 9, and 10 are small DRM changes required for DSC MST: FEC, a new bit in the standard; some export definitions; and a previously uninitialized variable. Patches 11 through 14 are the DSC MST policy itself. This includes the code for detecting and validating DSC capabilities, enabling DSC over a link, computing the fair DSC configurations for multiple DSC displays, and adding to atomic state crtcs that might need reprogramming due to DSC. v2: Updating patches 6 and 14 in respoinse to Nick's feedback David Francis (14): Revert "drm/amd/display: skip dsc config for navi10 bring up" Revert "drm/amd/display: navi10 bring up skip dsc encoder config" Revert "drm/amd/display: add global master update lock for DCN2" Revert "drm/amd/display: Fix underscan not using proper scaling" drm/amd/display: Enable SST DSC in DM drm/dp-mst: Use dc and drm helpers to compute timeslots drm/amd/display: Initialize DSC PPS variables to 0 drm/dp-mst: Parse FEC capability on MST ports drm/dp-mst: Export symbols for dpcd read/write drm/dp-mst: Fill branch->num_ports drm/amd/display: Validate DSC caps on MST endpoints drm/amd/display: Write DSC enable to MST DPCD drm/amd/display: MST DSC compute fair share drm/amd/display: Trigger modesets on MST DSC connectors .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 110 +++- .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 48 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 498 +++++++++++++++++- .../display/amdgpu_dm/amdgpu_dm_mst_types.h | 5 + drivers/gpu/drm/amd/display/dc/core/dc.c | 12 +- .../drm/amd/display/dc/core/dc_link_hwss.c | 3 + .../gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c | 3 + .../drm/amd/display/dc/dcn20/dcn20_hwseq.c | 4 - .../gpu/drm/amd/display/dc/dcn20/dcn20_optc.c | 72 +-- .../gpu/drm/amd/display/dc/dcn20/dcn20_optc.h | 3 - .../drm/amd/display/dc/dcn20/dcn20_resource.c | 7 +- .../drm/amd/display/dc/dcn20/dcn20_resource.h | 1 + .../display/dc/dcn20/dcn20_stream_encoder.c | 8 - .../amd/display/dc/inc/hw/timing_generator.h | 2 - drivers/gpu/drm/drm_dp_mst_topology.c | 47 ++ include/drm/drm_dp_mst_helper.h | 5 +- 16 files changed, 708 insertions(+), 120 deletions(-) -- 2.17.1

4 25

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 21 Aug '19

21 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #34 from tempel.julian(a)gmail.com --- Thank you for being still with me on this. I've downgraded to stock packages provided by Arch stable repository, which is: xorg-server 1.20.5 xf86-video-amdgpu 19.0.1 mesa 19.1.4 stock (read: no) xorg config no custom kernel parameters (except of of disabling intel_pstate, see new dmesg.log attached) And I've also installed amd-staging-drm-next (6c7a8d5c0772) just like you. But: The issue is unchanged. To further illustrate the issue, I've recorded a capture of it in the game TESV: Oblivion in D9VK (no difference to WineD3D or Gallium Nine regarding this issue). The capturing process in OBS Studio via Xcomposite breaks pageflipping, but I can turn it on again via TearFree which I enable via hotkey on the fly. The result 100% matches running the game with modesetting DDX or amdgpu.dc=0 (no spikes) vs. xf86-video-amdgpu + amdgpu.dc=1 (nasty spikes). Hitman 2 is a bit different, as it doesn't show render spikes for me either (I think I was first mistaken regarding that difference, sorry for the confusion), but the mouse input just blocks/skips heavily and is even more unplayable than Oblivion/Skyrim etc. I was just writing this while I read your new reply. I'll gladly try what you have suggested. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 21 Aug '19

21 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #33 from Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> --- I haven't seen anything like the video in my testing. It also doesn't seem to happen every time so I'm wondering if something else is going on in the background that's issuing atomic commits. Do you mind posting the relevant portion of a dmesg log after running the following: echo 0x52 > /sys/module/drm/parameters/debug This will generate a ton of debug information and will likely kill your performance, but if you can reproduce the portion of the frametime graph with the red spikes and post that part of the log that would help. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 21 Aug '19

21 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #32 from tempel.julian(a)gmail.com --- Created attachment 145118 --> https://bugs.freedesktop.org/attachment.cgi?id=145118&action=edit issue demonstrated with D9VK frametime graph in game Oblivion -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 21 Aug '19

21 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #31 from tempel.julian(a)gmail.com --- Created attachment 145117 --> https://bugs.freedesktop.org/attachment.cgi?id=145117&action=edit new dmesg log with staging-drm-next kernel default parameters -- You are receiving this mail because: You are the assignee for the bug.

1 0

[RFC 00/11] drm/bridge: dw-hdmi: implement bus-format negotiation and YUV420 support
by Neil Armstrong 21 Aug '19

21 Aug '19

This patchset is based on Boris's "drm: Add support for bus-format negotiation" RFC at [1] patchset to implement : - basic bus-format negotiation for DW-HDMI - advanced HDMI2.0 YUV420 bus-format negotiation for DW-HDMI And the counterpart implementation in the Amlogic Meson VPU dw-hdmi glue : - basic bus-format negotiation to select YUV444 bus-format as DW-HDMI input - YUV420 support when HDMI2.0 YUV420 modeset This is a follow-up from the previous attempts : - "drm/meson: Add support for HDMI2.0 YUV420 4k60" at [2] - "drm/meson: Add support for HDMI2.0 4k60" at [3] [1] https://patchwork.freedesktop.org/patch/msgid/20190808151150.16336-1-boris.… [2] https://patchwork.freedesktop.org/patch/msgid/20190520133753.23871-1-narmst… [3] https://patchwork.freedesktop.org/patch/msgid/1549022873-40549-1-git-send-e… Neil Armstrong (11): fixup! drm/bridge: Add the necessary bits to support bus format negotiation drm/meson: venc: make drm_display_mode const drm/meson: meson_dw_hdmi: switch to drm_bridge_funcs drm/bridge: synopsys: dw-hdmi: add basic bridge_atomic_check drm/bridge: synopsys: dw-hdmi: use negociated bus formats drm/meson: dw-hdmi: stop enforcing input_bus_format drm/bridge: dw-hdmi: allow ycbcr420 modes for >= 0x200a drm/bridge: synopsys: dw-hdmi: add 420 mode format negociation drm/meson: venc: add support for YUV420 setup drm/meson: vclk: add support for YUV420 setup drm/meson: Add YUV420 output support drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 97 +++++++++++++++- drivers/gpu/drm/drm_bridge.c | 6 +- drivers/gpu/drm/meson/meson_dw_hdmi.c | 135 +++++++++++++++++----- drivers/gpu/drm/meson/meson_vclk.c | 93 +++++++++++---- drivers/gpu/drm/meson/meson_vclk.h | 7 +- drivers/gpu/drm/meson/meson_venc.c | 8 +- drivers/gpu/drm/meson/meson_venc.h | 13 ++- drivers/gpu/drm/meson/meson_venc_cvbs.c | 3 +- include/drm/bridge/dw_hdmi.h | 1 + 9 files changed, 295 insertions(+), 68 deletions(-) -- 2.22.0

2 13

Re: [PATCH 1/3] dma_resv: prime lockdep annotations
by Koenig, Christian 21 Aug '19

21 Aug '19

Am 21.08.2019 20:28 schrieb "Thomas Hellström (VMware)" <thomas_os(a)shipmail.org>: On 8/21/19 8:11 PM, Daniel Vetter wrote: > On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware) > <thomas_os(a)shipmail.org> wrote: >> On 8/21/19 6:34 PM, Daniel Vetter wrote: >>> On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote: >>>> On 8/20/19 4:53 PM, Daniel Vetter wrote: >>>>> Full audit of everyone: >>>>> >>>>> - i915, radeon, amdgpu should be clean per their maintainers. >>>>> >>>>> - vram helpers should be fine, they don't do command submission, so >>>>> really no business holding struct_mutex while doing copy_*_user. But >>>>> I haven't checked them all. >>>>> >>>>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which >>>>> looks clean. >>>>> >>>>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(), >>>>> copying from/to userspace happens all in v3d_lookup_bos which is >>>>> outside of the critical section. >>>>> >>>>> - vmwgfx has a bunch of ioctls that do their own copy_*_user: >>>>> - vmw_execbuf_process: First this does some copies in >>>>> vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself. >>>>> Then comes the usual ttm reserve/validate sequence, then actual >>>>> submission/fencing, then unreserving, and finally some more >>>>> copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of >>>>> details, but looks all safe. >>>>> - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be >>>>> seen, seems to only create a fence and copy it out. >>>>> - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be >>>>> found there. >>>>> Summary: vmwgfx seems to be fine too. >>>>> >>>>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the >>>>> copying from userspace before even looking up objects through their >>>>> handles, so safe. Plus the getparam/getcaps ioctl, also both safe. >>>>> >>>>> - qxl only has qxl_execbuffer_ioctl, which calls into >>>>> qxl_process_single_command. There's a lovely comment before the >>>>> __copy_from_user_inatomic that the slowpath should be copied from >>>>> i915, but I guess that never happened. Try not to be unlucky and get >>>>> your CS data evicted between when it's written and the kernel tries >>>>> to read it. The only other copy_from_user is for relocs, but those >>>>> are done before qxl_release_reserve_list(), which seems to be the >>>>> only thing reserving buffers (in the ttm/dma_resv sense) in that >>>>> code. So looks safe. >>>>> >>>>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in >>>>> usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this >>>>> everywhere and needs to be fixed up. >>>>> >>>>> Cc: Alex Deucher <alexander.deucher(a)amd.com> >>>>> Cc: Christian König <christian.koenig(a)amd.com> >>>>> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> >>>>> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> >>>>> Cc: Rob Herring <robh(a)kernel.org> >>>>> Cc: Tomeu Vizoso <tomeu.vizoso(a)collabora.com> >>>>> Cc: Eric Anholt <eric(a)anholt.net> >>>>> Cc: Dave Airlie <airlied(a)redhat.com> >>>>> Cc: Gerd Hoffmann <kraxel(a)redhat.com> >>>>> Cc: Ben Skeggs <bskeggs(a)redhat.com> >>>>> Cc: "VMware Graphics" <linux-graphics-maintainer(a)vmware.com> >>>>> Cc: Thomas Hellstrom <thellstrom(a)vmware.com> >>>>> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> >>>>> --- >>>>> drivers/dma-buf/dma-resv.c | 12 ++++++++++++ >>>>> 1 file changed, 12 insertions(+) >>>>> >>>>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c >>>>> index 42a8f3f11681..3edca10d3faf 100644 >>>>> --- a/drivers/dma-buf/dma-resv.c >>>>> +++ b/drivers/dma-buf/dma-resv.c >>>>> @@ -34,6 +34,7 @@ >>>>> #include <linux/dma-resv.h> >>>>> #include <linux/export.h> >>>>> +#include <linux/sched/mm.h> >>>>> /** >>>>> * DOC: Reservation Object Overview >>>>> @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj) >>>>> &reservation_seqcount_class); >>>>> RCU_INIT_POINTER(obj->fence, NULL); >>>>> RCU_INIT_POINTER(obj->fence_excl, NULL); >>>>> + >>>>> + if (IS_ENABLED(CONFIG_LOCKDEP)) { >>>>> + if (current->mm) >>>>> + down_read(&current->mm->mmap_sem); >>>>> + ww_mutex_lock(&obj->lock, NULL); >>>>> + fs_reclaim_acquire(GFP_KERNEL); >>>>> + fs_reclaim_release(GFP_KERNEL); >>>>> + ww_mutex_unlock(&obj->lock); >>>>> + if (current->mm) >>>>> + up_read(&current->mm->mmap_sem); >>>>> + } >>>>> } >>>>> EXPORT_SYMBOL(dma_resv_init); >>>> I assume if this would have been easily done and maintainable using only >>>> lockdep annotation instead of actually acquiring the locks, that would have >>>> been done? >>> There's might_lock(), plus a pile of macros, but they don't map obviuosly, >>> so pretty good chances I accidentally end up with the wrong type of >>> annotation. Easier to just take the locks quickly, and stuff that all into >>> a lockdep-only section to avoid overhead. >>> >>>> Otherwise LGTM. >>>> >>>> Reviewed-by: Thomas Hellström <thellstrom(a)vmware.com> >>>> >>>> Will test this and let you know if it trips on vmwgfx, but it really >>>> shouldn't. >>> Thanks, Daniel >> One thing that strikes me is that this puts restrictions on where you >> can actually initialize a dma_resv, even if locking orders are otherwise >> obeyed. But that might not be a big problem. > Hm yeah ... the trouble is a need a non-kthread thread so that I have > a current->mm. Otherwise I'd have put it into some init section with a > temp dma_buf. And I kinda don't want to create a fake ->mm just for > lockdep priming. I don't expect this to be a real problem in practice, > since before you've called dma_resv_init the reservation lock doesn't > exist, so you can't hold it. And you've probably just allocated it, so > fs_reclaim is going to be fine. And if you allocate dma_resv objects > from your fault handlers I have questions anyway :-) Coming to think of it, I think vmwgfx sometimes create bos with other bo's reservation lock held. I guess that would trip both the mmap_sem check the ww_mutex check? Dito inside TTM for ghost objects. We even used to have an dma_resv_init() in an atomic section, but that should be gone by now. Anyway, probably have to take my review back since this will certainly go up in flames. Need a better place for this, Christian. /Thomas /Thomas > > So I think this should be safe. > -Daniel

1 0

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 21 Aug '19

21 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #30 from Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> --- (In reply to tempel.julian from comment #29) > The patches by Nicholas are now merged in drm-next-5.4 branch (tested with > recent commit that bases the branch on 5.3-rc3), but the mouse input issue > in certain games is still unaffected. > > I was also able to reproduce it with a different system (also with RX 580) > which features a 60Hz FreeSync display, it definitely makes FreeSync > impossible to use in the aforementioned titles. I still can't reproduce on any setup I've tried. Here is the current setup I have: RX580 1920x1080 @ 144Hz amd-staging-drm-next (6c7a8d5c0772) xf86-video-amdgpu 19.0.1-1 mesa 19.1.4-1 plasma-desktop 5.16.4-1 There are no spikes in the DXVK overlay in Hitman 2 when moving the mouse and no noticeable jitter in input. I am using plasma with the compositor enabled, tearing prevention auto and fullscreen redirection allowed. PageFlip is enabled in xf86-video-amdgpu. I do see stutters in the graph when moving the cursor over the mission tiles on the menu, but this is GFX stuttering - not display. Moving the cursor at the top of the screen in the menu produces no stuttering. FreeSync isn't active since this is DXVK. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH 0/3] dt-bindings: Convert Arm Mali GPUs to DT schema
by Rob Herring 21 Aug '19

21 Aug '19

This series converts the various Arm Mali GPU bindings to use the DT schema format. The Midgard and Bifrost bindings generate warnings on 'interrupt-names' because there's all different ordering. The Utgard binding generates warnings on Rockchip platforms because 'clock-names' order is reversed. Rob Rob Herring (3): dt-bindings: Convert Arm Mali Midgard GPU to DT schema dt-bindings: Convert Arm Mali Bifrost GPU to DT schema dt-bindings: Convert Arm Mali Utgard GPU to DT schema .../bindings/gpu/arm,mali-bifrost.txt | 92 ---------- .../bindings/gpu/arm,mali-bifrost.yaml | 115 ++++++++++++ .../bindings/gpu/arm,mali-midgard.txt | 119 ------------- .../bindings/gpu/arm,mali-midgard.yaml | 165 +++++++++++++++++ .../bindings/gpu/arm,mali-utgard.txt | 129 -------------- .../bindings/gpu/arm,mali-utgard.yaml | 166 ++++++++++++++++++ 6 files changed, 446 insertions(+), 340 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml delete mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml delete mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml -- 2.20.1

4 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2019