dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[PATCH 0/7] dma-resv fence DAG fixes
by Daniel Vetter 07 Jul '21

07 Jul '21

Hi all, Finally I think I got them all in trying to audit all drivers for how they deal with dma-resv dependencies in their command submission ioctl. This series is incomplete, it also needs a few things from Christian - nouveau fix for waiting for all fences - various patches for fixing up dma-buf/resv functions to always wait for all fences (dma-buf poll, is_signalled, ...) - I do include the one msm patch from Christian here since there was another issue in msm that needed fixing, and to make sure we have the complete set for msm Two main things: - fix drivers that currently can break the DAG. I opted for the dumbest possible way and not for rolling out dma_fence_chain - this can be fixed later on if needed. - allow shared fences to be decoupled from the exclusive slot, which mostly means we can't skip waiting for the exclusive fence if there's shared fences present, we have to wait for all fences. This is a semantic change compared to what we've had thus far, but really makes a ton of sense given where things are heading towards. Note that this means the import/export patches from Jason need to be adjusted too to fit. Plus some docs for dma-resv, they've been rather lacking. Testing and review highly welcome. Christian König (1): drm/msm: always wait for the exclusive fence Daniel Vetter (6): drm/msm: Don't break exclusive fence ordering drm/etnaviv: Don't break exclusive fence ordering drm/i915: delete exclude argument from i915_sw_fence_await_reservation drm/i915: Always wait for the exclusive fence drm/i915: Don't break exclusive fence ordering dma-resv: Give the docs a do-over drivers/dma-buf/dma-resv.c | 22 +++- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +- drivers/gpu/drm/i915/display/intel_display.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +- drivers/gpu/drm/i915/i915_sw_fence.c | 10 +- drivers/gpu/drm/i915/i915_sw_fence.h | 1 - drivers/gpu/drm/msm/msm_gem.c | 16 ++- drivers/gpu/drm/msm/msm_gem_submit.c | 3 +- include/linux/dma-resv.h | 104 +++++++++++++++++- 10 files changed, 142 insertions(+), 36 deletions(-) -- 2.32.0

5 17

Re: [Linaro-mm-sig] [PATCH v4 0/2] Add p2p via dmabuf to habanalabs
by Daniel Vetter 07 Jul '21

07 Jul '21

On Tue, Jul 06, 2021 at 02:21:10PM +0200, Christoph Hellwig wrote: > On Tue, Jul 06, 2021 at 10:40:37AM +0200, Daniel Vetter wrote: > > > Greg, I hope this will be good enough for you to merge this code. > > > > So we're officially going to use dri-devel for technical details review > > and then Greg for merging so we don't have to deal with other merge > > criteria dri-devel folks have? > > > > I don't expect anything less by now, but it does make the original claim > > that drivers/misc will not step all over accelerators folks a complete > > farce under the totally-not-a-gpu banner. > > > > This essentially means that for any other accelerator stack that doesn't > > fit the dri-devel merge criteria, even if it's acting like a gpu and uses > > other gpu driver stuff, you can just send it to Greg and it's good to go. > > > > There's quite a lot of these floating around actually (and many do have > > semi-open runtimes, like habanalabs have now too, just not open enough to > > be actually useful). It's going to be absolutely lovely having to explain > > to these companies in background chats why habanalabs gets away with their > > stack and they don't. > > FYI, I fully agree with Daniel here. Habanlabs needs to open up their > runtime if they want to push any additional feature in the kernel. > The current situation is not sustainable. Before anyone replies: The runtime is open, the compiler is still closed. This has become the new default for accel driver submissions, I think mostly because all the interesting bits for non-3d accelerators are in the accel ISA, and no longer in the runtime. So vendors are fairly happy to throw in the runtime as a freebie. It's still incomplete, and it's still useless if you want to actually hack on the driver stack. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 5

[PATCH 0/2] Update to new HuC for TGL+ and enable GuC/HuC on ADL-P
by John.C.Harrison＠Intel.com 07 Jul '21

07 Jul '21

From: John Harrison <John.C.Harrison(a)Intel.com> There is a new HuC version available for TGL and compatible platforms, so switch to using it. Also, there is now a GuC and HuC for ADL-P, so use those too. Signed-off-by: John Harrison <John.C.Harrison(a)Intel.com> John Harrison (2): drm/i915/huc: Update TGL and friends to HuC 7.9.3 drm/i915/adlp: Add ADL-P GuC/HuC firmware files drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) -- 2.25.1

3 5

Re: page pools, was Re: [PATCH v9 1/5] drm: Add a sharable drm page-pool implementation
by Christian König 07 Jul '21

07 Jul '21

Am 07.07.21 um 09:14 schrieb Christoph Hellwig: > On Wed, Jul 07, 2021 at 09:10:26AM +0200, Christian K??nig wrote: >> Well, the original code all this is based on already had the comment that >> this really belong into the page allocator. >> >> The key point is traditionally only GPUs used uncached and write-combined >> memory in such large quantities that having a pool for them makes sense. >> >> Because of this we had this separately to reduce the complexity in the page >> allocator to handle another set of complexity of allocation types. >> >> For the upside, for those use cases it means huge performance improvements >> for those drivers. See the numbers John provided in the cover letter. >> >> But essentially at least I would be totally fine moving this into the page >> allocator, but moving it outside of TTM already helps with this goal. So >> this patch set is certainly a step into the right direction. > Unless I'm badly misreading the patch and this series there is nothing > about cache attributes in this code. It just allocates pages, zeroes > them, eventually hands them out to a consumer and registers a shrinker > for its freelist. > > If OTOH it actually dealt with cachability that should be documented > in the commit log and probably also the naming of the implementation. Mhm, good point. In this case all left is the clearing overhead from the allocation hot path to the free path and I'm not really sure why the core page allocator shouldn't do that as well. Regards, Christian.

1 0

[PATCH v3 0/7] drm/panfrost: drm/panfrost: Add a new submit ioctl
by Boris Brezillon 07 Jul '21

07 Jul '21

Hello, This is an attempt at providing a new submit ioctl that's more Vulkan-friendly than the existing one. This ioctl 1/ allows passing several out syncobjs so we can easily update several fence/semaphore in a single ioctl() call 2/ allows passing several jobs so we don't have to have one ioctl per job-chain recorded in the command buffer 3/ supports disabling implicit dependencies as well as non-exclusive access to BOs, thus removing unnecessary synchronization I've also been looking at adding {IN,OUT}_FENCE_FD support (allowing one to pass at most one sync_file object in input and/or creating a sync_file FD embedding the render out fence), but it's not entirely clear to me when that's useful. Indeed, we can already do the sync_file <-> syncobj conversion using the SYNCOBJ_{FD_TO_HANDLE,HANDLE_TO_FD} ioctls if we have to. Note that, unlike Turnip, PanVk is using syncobjs to implement vkQueueWaitIdle(), so the syncobj -> sync_file conversion doesn't have to happen for each submission, but maybe there's a good reason to use sync_files for that too. Any feedback on that aspect would be useful I guess. Any feedback on this new ioctl is welcome, in particular, do you think other things are missing/would be nice to have for Vulkan? Regards, Boris P.S.: basic igt tests for these new ioctls re available there [1] [1]https://gitlab.freedesktop.org/bbrezillon/igt-gpu-tools/-/tree/panfrost-b… Changes in v3: * Fix a deadlock in the submitqueue logic * Limit the number of submitqueue per context to 16 Boris Brezillon (7): drm/panfrost: Pass a job to panfrost_{acquire,attach}_object_fences() drm/panfrost: Move the mappings collection out of panfrost_lookup_bos() drm/panfrost: Add BO access flags to relax dependencies between jobs drm/panfrost: Add the ability to create submit queues drm/panfrost: Add a new ioctl to submit batches drm/panfrost: Advertise the SYNCOBJ_TIMELINE feature drm/panfrost: Bump minor version to reflect the feature additions drivers/gpu/drm/panfrost/Makefile | 3 +- drivers/gpu/drm/panfrost/panfrost_device.h | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 463 ++++++++++++++---- drivers/gpu/drm/panfrost/panfrost_job.c | 89 ++-- drivers/gpu/drm/panfrost/panfrost_job.h | 10 +- .../gpu/drm/panfrost/panfrost_submitqueue.c | 136 +++++ .../gpu/drm/panfrost/panfrost_submitqueue.h | 27 + include/uapi/drm/panfrost_drm.h | 103 ++++ 8 files changed, 689 insertions(+), 144 deletions(-) create mode 100644 drivers/gpu/drm/panfrost/panfrost_submitqueue.c create mode 100644 drivers/gpu/drm/panfrost/panfrost_submitqueue.h -- 2.31.1

3 22

[PATCH v6 00/10] drm/vc4: hdmi: Support the 4k @ 60Hz modes
by Maxime Ripard 07 Jul '21

07 Jul '21

Hi, Here is a series that enables the higher resolutions on the HDMI0 Controller found in the BCM2711 (RPi4). In order to work it needs a few adjustments to config.txt, most notably to enable the enable_hdmi_4kp60 option. Let me know what you think, Maxime --- Changes from v5: - Fixed unused variables warning Changes from v4: - Removed the patches already applied - Added various fixes for the issues that have been discovered on the downstream tree Changes from v3: - Rework the encoder retrieval code that was broken on the RPi3 and older - Fix a scrambling enabling issue on some display Changes from v2: - Gathered the various tags - Added Cc stable when relevant - Split out the check to test whether the scrambler is required into an helper - Fixed a bug where the scrambler state wouldn't be tracked properly if it was enabled at boot Changes from v1: - Dropped the range accessors - Drop the mention of force_turbo - Reordered the SCRAMBLER_CTL register to match the offset - Removed duplicate HDMI_14_MAX_TMDS_CLK define - Warn about enable_hdmi_4kp60 only if there's some modes that can't be reached - Rework the BVB clock computation Maxime Ripard (10): drm/vc4: hdmi: Remove the DDC probing for status detection drm/vc4: hdmi: Fix HPD GPIO detection drm/vc4: Make vc4_crtc_get_encoder public drm/vc4: crtc: Add encoder to vc4_crtc_config_pv prototype drm/vc4: crtc: Rework the encoder retrieval code (again) drm/vc4: crtc: Add some logging drm/vc4: Leverage the load tracker on the BCM2711 drm/vc4: hdmi: Raise the maximum clock rate drm/vc4: hdmi: Enable the scrambler on reconnection drm/vc4: Increase the core clock based on HVS load drivers/gpu/drm/vc4/vc4_crtc.c | 60 ++++++++------ drivers/gpu/drm/vc4/vc4_debugfs.c | 7 +- drivers/gpu/drm/vc4/vc4_drv.h | 9 ++- drivers/gpu/drm/vc4/vc4_hdmi.c | 20 +++-- drivers/gpu/drm/vc4/vc4_kms.c | 126 +++++++++++++++++++++++++----- drivers/gpu/drm/vc4/vc4_plane.c | 5 -- 6 files changed, 164 insertions(+), 63 deletions(-) -- 2.31.1

1 10

[PATCH 2/2] drivers/gpu/drm/i915/display/intel_display_power.c: Repair typo in function name
by zhaoxiao 07 Jul '21

07 Jul '21

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/display/intel_display_power.c:2300: warning: expecting prototype for intel_display_power_put_async(). Prototype was for __intel_display_power_put_async() instead Signed-off-by: zhaoxiao <zhaoxiao(a)uniontech.com> --- drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index 4298ae684d7d..c37e14f2df90 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -2285,7 +2285,7 @@ intel_display_power_put_async_work(struct work_struct *work) } /** - * intel_display_power_put_async - release a power domain reference asynchronously + * __intel_display_power_put_async - release a power domain reference asynchronously * @i915: i915 device instance * @domain: power domain to reference * @wakeref: wakeref acquired for the reference that is being released -- 2.20.1

1 0

[PATCH 1/2] drivers/gpu/drm/i915/gt/intel_engine_cs.c: Repair typo in function name
by zhaoxiao 07 Jul '21

07 Jul '21

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/gt/intel_engine_cs.c:882: warning: expecting prototype for intel_engines_init_common(). Prototype was for engine_init_common() instead drivers/gpu/drm/i915/gt/intel_engine_cs.c:959: warning: expecting prototype for intel_engines_cleanup_common(). Prototype was for intel_engine_cleanup_common() instead Signed-off-by: zhaoxiao <zhaoxiao(a)uniontech.com> --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 7f03df236613..01b4dc041a72 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -868,7 +868,7 @@ create_kernel_context(struct intel_engine_cs *engine) } /** - * intel_engines_init_common - initialize cengine state which might require hw access + * engine_init_common - initialize cengine state which might require hw access * @engine: Engine to initialize. * * Initializes @engine@ structure members shared between legacy and execlists @@ -949,7 +949,7 @@ int intel_engines_init(struct intel_gt *gt) } /** - * intel_engines_cleanup_common - cleans up the engine state created by + * intel_engine_cleanup_common - cleans up the engine state created by * the common initiailizers. * @engine: Engine to cleanup. * -- 2.20.1

1 0

[PATCH v4] Documentation: gpu: Mention the requirements for new properties
by Maxime Ripard 07 Jul '21

07 Jul '21

New KMS properties come with a bunch of requirements to avoid each driver from running their own, inconsistent, set of properties, eventually leading to issues like property conflicts, inconsistencies between drivers and semantics, etc. Let's document what we expect. Cc: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Cc: Alexandre Torgue <alexandre.torgue(a)foss.st.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: Alison Wang <alison.wang(a)nxp.com> Cc: Alyssa Rosenzweig <alyssa.rosenzweig(a)collabora.com> Cc: Andrew Jeffery <andrew(a)aj.id.au> Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Anitha Chrisanthus <anitha.chrisanthus(a)intel.com> Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> Cc: Ben Skeggs <bskeggs(a)redhat.com> Cc: Boris Brezillon <bbrezillon(a)kernel.org> Cc: Brian Starkey <brian.starkey(a)arm.com> Cc: Chen Feng <puck.chen(a)hisilicon.com> Cc: Chen-Yu Tsai <wens(a)csie.org> Cc: Christian Gmeiner <christian.gmeiner(a)gmail.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Chun-Kuang Hu <chunkuang.hu(a)kernel.org> Cc: Edmund Dea <edmund.j.dea(a)intel.com> Cc: Eric Anholt <eric(a)anholt.net> Cc: Fabio Estevam <festevam(a)gmail.com> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Haneen Mohammed <hamohammed.sa(a)gmail.com> Cc: Hans de Goede <hdegoede(a)redhat.com> Cc: "Heiko Stübner" <heiko(a)sntech.de> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Hyun Kwon <hyun.kwon(a)xilinx.com> Cc: Inki Dae <inki.dae(a)samsung.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Jernej Skrabec <jernej.skrabec(a)siol.net> Cc: Jerome Brunet <jbrunet(a)baylibre.com> Cc: Joel Stanley <joel(a)jms.id.au> Cc: John Stultz <john.stultz(a)linaro.org> Cc: Jonas Karlman <jonas(a)kwiboo.se> Cc: Jonathan Hunter <jonathanh(a)nvidia.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Joonyoung Shim <jy0922.shim(a)samsung.com> Cc: Jyri Sarha <jyri.sarha(a)iki.fi> Cc: Kevin Hilman <khilman(a)baylibre.com> Cc: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski(a)canonical.com> Cc: Kyungmin Park <kyungmin.park(a)samsung.com> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: Liviu Dudau <liviu.dudau(a)arm.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Ludovic Desroches <ludovic.desroches(a)microchip.com> Cc: Marek Vasut <marex(a)denx.de> Cc: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Cc: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: Maxime Coquelin <mcoquelin.stm32(a)gmail.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Melissa Wen <melissa.srw(a)gmail.com> Cc: Neil Armstrong <narmstrong(a)baylibre.com> Cc: Nicolas Ferre <nicolas.ferre(a)microchip.com> Cc: "Noralf Trønnes" <noralf(a)tronnes.org> Cc: NXP Linux Team <linux-imx(a)nxp.com> Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko(a)epam.com> Cc: Patrik Jakobsson <patrik.r.jakobsson(a)gmail.com> Cc: Paul Cercueil <paul(a)crapouillou.net> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.com> Cc: Pengutronix Kernel Team <kernel(a)pengutronix.de> Cc: Philippe Cornu <philippe.cornu(a)foss.st.com> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Qiang Yu <yuq825(a)gmail.com> Cc: Rob Clark <robdclark(a)gmail.com> Cc: Robert Foss <robert.foss(a)linaro.org> Cc: Rob Herring <robh(a)kernel.org> Cc: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Roland Scheidegger <sroland(a)vmware.com> Cc: Russell King <linux(a)armlinux.org.uk> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Sandy Huang <hjc(a)rock-chips.com> Cc: Sascha Hauer <s.hauer(a)pengutronix.de> Cc: Sean Paul <sean(a)poorly.run> Cc: Seung-Woo Kim <sw0312.kim(a)samsung.com> Cc: Shawn Guo <shawnguo(a)kernel.org> Cc: Simon Ser <contact(a)emersion.fr> Cc: Stefan Agner <stefan(a)agner.ch> Cc: Steven Price <steven.price(a)arm.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Tian Tao <tiantao6(a)hisilicon.com> Cc: Tomeu Vizoso <tomeu.vizoso(a)collabora.com> Cc: Tomi Valkeinen <tomba(a)kernel.org> Cc: VMware Graphics <linux-graphics-maintainer(a)vmware.com> Cc: Xinliang Liu <xinliang.liu(a)linaro.org> Cc: Xinwei Kong <kong.kongxinwei(a)hisilicon.com> Cc: Yannick Fertre <yannick.fertre(a)foss.st.com> Cc: Zack Rusin <zackr(a)vmware.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- Changes from v3: - Roll back to the v2 - Add Simon and Pekka in Cc Changes from v2: - Take into account the feedback from Laurent and Lidiu to no longer force generic properties, but prefix vendor-specific properties with the vendor name Changes from v1: - Typos and wording reported by Daniel and Alex --- Documentation/gpu/drm-kms.rst | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..c28b464dd397 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -463,6 +463,25 @@ KMS Properties This section of the documentation is primarily aimed at user-space developers. For the driver APIs, see the other sections. +Requirements +------------ + +KMS drivers might need to add extra properties to support new features. +Each new property introduced in a driver need to meet a few +requirements, in addition to the one mentioned above.: + +- It must be standardized, with some documentation to describe how the + property can be used. + +- It must provide a generic helper in the core code to register that + property on the object it attaches to. + +- Its content must be decoded by the core and provided in the object's + associated state structure. That includes anything drivers might want to + precompute, like :c:type:`struct drm_clip_rect <drm_clip_rect>` for planes. + +- An IGT test must be submitted where reasonable. + Property Types and Blob Property Support ---------------------------------------- -- 2.31.1

4 7

Re: page pools, was Re: [PATCH v9 1/5] drm: Add a sharable drm page-pool implementation
by Christian König 07 Jul '21

07 Jul '21

Am 07.07.21 um 08:38 schrieb Christoph Hellwig: > On Wed, Jun 30, 2021 at 01:34:17AM +0000, John Stultz wrote: >> This adds a shrinker controlled page pool, extracted >> out of the ttm_pool logic, and abstracted out a bit >> so it can be used by other non-ttm drivers. > Can you explain in detail why you need a differnt page pool over the one > maintained by the page allocator? Fragmenting the memory into all kinds > of pools has lots of downsides, so the upsides need to be explained in > detail. Well, the original code all this is based on already had the comment that this really belong into the page allocator. The key point is traditionally only GPUs used uncached and write-combined memory in such large quantities that having a pool for them makes sense. Because of this we had this separately to reduce the complexity in the page allocator to handle another set of complexity of allocation types. For the upside, for those use cases it means huge performance improvements for those drivers. See the numbers John provided in the cover letter. But essentially at least I would be totally fine moving this into the page allocator, but moving it outside of TTM already helps with this goal. So this patch set is certainly a step into the right direction. Regards, Christian.

1 0

← Newer
1
...
72
73
74
75
76
77
78
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021