dri-devel April 2021

dri-devel@lists.freedesktop.org

317 participants
715 discussions

[PATCH v3 0/4] drm/bridge: ti-sn65dsi86: Support EDID reading
by Stephen Boyd 07 May '21

07 May '21

This patch series cleans up the DDC code a little bit so that it is more efficient time wise and supports grabbing the EDID of the eDP panel over the aux channel. I timed this on a board I have on my desk and it takes about 20ms to grab the EDID out of the panel and make sure it is valid. The first two patches seem less controversial so I stuck them at the beginning. The third patch does the EDID reading and caches it so we don't have to keep grabbing it over and over again. And finally the last patch updates the reply field so that short reads and nacks over the channel are reflected properly instead of treating them as some sort of error that can't be discerned. Stephen Boyd (4): drm/bridge: ti-sn65dsi86: Combine register accesses in ti_sn_aux_transfer() drm/bridge: ti-sn65dsi86: Make polling a busy loop drm/bridge: ti-sn65dsi86: Read EDID blob over DDC drm/bridge: ti-sn65dsi86: Update reply on aux failures drivers/gpu/drm/bridge/ti-sn65dsi86.c | 103 ++++++++++++++++++-------- 1 file changed, 71 insertions(+), 32 deletions(-) Cc: Douglas Anderson <dianders(a)chromium.org> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Jonas Karlman <jonas(a)kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec(a)siol.net> Cc: Sean Paul <seanpaul(a)chromium.org> base-commit: 3650b228f83adda7e5ee532e2b90429c03f7b9ec -- Sent by a computer, using git, on the internet

4 10

[PATCH 1/2] drm/dp: Handle zeroed port counts in drm_dp_read_downstream_info()
by Lyude Paul 07 May '21

07 May '21

While the DP specification isn't entirely clear on if this should be allowed or not, some branch devices report having downstream ports present while also reporting a downstream port count of 0. So to avoid breaking those devices, we need to handle this in drm_dp_read_downstream_info(). So, to do this we assume there's no downstream port info when the downstream port count is 0. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Tested-by: Jérôme de Bretagne <jerome.debretagne(a)gmail.com> Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3416 Fixes: 3d3721ccb18a ("drm/i915/dp: Extract drm_dp_read_downstream_info()") Cc: <stable(a)vger.kernel.org> # v5.10+ --- drivers/gpu/drm/drm_dp_helper.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index cb56d74e9d38..27c8c5bdf7d9 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -682,7 +682,14 @@ int drm_dp_read_downstream_info(struct drm_dp_aux *aux, !(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT)) return 0; + /* Some branches advertise having 0 downstream ports, despite also advertising they have a + * downstream port present. The DP spec isn't clear on if this is allowed or not, but since + * some branches do it we need to handle it regardless. + */ len = drm_dp_downstream_port_count(dpcd); + if (!len) + return 0; + if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE) len *= 4; -- 2.30.2

2 4

[PATCHv2] drm/omap: Fix issue with clocks left on after resume
by Tony Lindgren 07 May '21

07 May '21

On resume, dispc pm_runtime_force_resume() is not enabling the hardware as we pass the pm_runtime_need_not_resume() test as the device is suspended with no child devices. As the resume continues, omap_atomic_comit_tail() calls dispc_runtime_get() that calls rpm_resume() enabling the hardware, and increasing child_count for it's parent device. But at this point device_complete() has not yet been called for dispc. So when omap_atomic_comit_tail() calls dispc_runtime_put(), it won't idle the hardware as rpm_suspend() returns -EBUSY, and the clocks are left on after resume. The parent child count is not decremented as the -EBUSY cannot be easily handled until later on after device_complete(). This can be easily seen for example after suspending Beagleboard-X15 with no displays connected, and by reading the CM_DSS_DSS_CLKCTRL register at 0x4a009120 after resume. After a suspend and resume cycle, it shows a value of 0x00040102 instead of 0x00070000 like it should. Let's fix the issue by calling dispc_runtime_suspend() and dispc_runtime_resume() directly from dispc_suspend() and dispc_resume(). This leaves out the PM runtime related issues for system suspend. We could handle the issue by adding more calls to dispc_runtime_get() and dispc_runtime_put() from omap_drm_suspend() and omap_drm_resume() as suggested by Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com>. But that would just add more inter-component calls and more dependencies to PM runtime for system suspend and does not make things easier in the long. See also earlier commit 88d26136a256 ("PM: Prevent runtime suspend during system resume") and commit ca8199f13498 ("drm/msm/dpu: ensure device suspend happens during PM sleep") for more information. Fixes: ecfdedd7da5d ("drm/omap: force runtime PM suspend on system suspend") Signed-off-by: Tony Lindgren <tony(a)atomide.com> --- Changes since v1: - Updated the description for a typo noticed by Tomi - Added more info about what all goes wrong --- drivers/gpu/drm/omapdrm/dss/dispc.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c b/drivers/gpu/drm/omapdrm/dss/dispc.c --- a/drivers/gpu/drm/omapdrm/dss/dispc.c +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c @@ -182,6 +182,7 @@ struct dispc_device { const struct dispc_features *feat; bool is_enabled; + bool needs_resume; struct regmap *syscon_pol; u32 syscon_pol_offset; @@ -4887,10 +4888,34 @@ static int dispc_runtime_resume(struct device *dev) return 0; } +static int dispc_suspend(struct device *dev) +{ + struct dispc_device *dispc = dev_get_drvdata(dev); + + if (!dispc->is_enabled) + return 0; + + dispc->needs_resume = true; + + return dispc_runtime_suspend(dev); +} + +static int dispc_resume(struct device *dev) +{ + struct dispc_device *dispc = dev_get_drvdata(dev); + + if (!dispc->needs_resume) + return 0; + + dispc->needs_resume = false; + + return dispc_runtime_resume(dev); +} + static const struct dev_pm_ops dispc_pm_ops = { .runtime_suspend = dispc_runtime_suspend, .runtime_resume = dispc_runtime_resume, - SET_LATE_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume) + SET_LATE_SYSTEM_SLEEP_PM_OPS(dispc_suspend, dispc_resume) }; struct platform_driver omap_dispchw_driver = { -- 2.31.1

3 8

[PATCH] drm/i915: Use might_alloc()
by Bernard Zhao 07 May '21

07 May '21

This maybe used lockdep through the fs_reclaim annotations. Signed-off-by: Bernard Zhao <bernard(a)vivo.com> --- drivers/gpu/drm/i915/i915_sw_fence.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c b/drivers/gpu/drm/i915/i915_sw_fence.c index 2744558f3050..cc1b49cabb6c 100644 --- a/drivers/gpu/drm/i915/i915_sw_fence.c +++ b/drivers/gpu/drm/i915/i915_sw_fence.c @@ -341,7 +341,7 @@ static int __i915_sw_fence_await_sw_fence(struct i915_sw_fence *fence, unsigned long flags; debug_fence_assert(fence); - might_sleep_if(gfpflags_allow_blocking(gfp)); + might_alloc(gfp); if (i915_sw_fence_done(signaler)) { i915_sw_fence_set_error_once(fence, signaler->error); @@ -477,7 +477,7 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence *fence, int ret; debug_fence_assert(fence); - might_sleep_if(gfpflags_allow_blocking(gfp)); + might_alloc(gfp); if (dma_fence_is_signaled(dma)) { i915_sw_fence_set_error_once(fence, dma->error); @@ -576,7 +576,7 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence *fence, int ret = 0, pending; debug_fence_assert(fence); - might_sleep_if(gfpflags_allow_blocking(gfp)); + might_alloc(gfp); if (write) { struct dma_fence **shared; -- 2.31.0

4 3

[Bug 207833] New: Brightness control not working on ASUS TUF FA506IU (AMD Ryzen 7 4800H / Nvidia GTX 1660 Ti)
by bugzilla-daemon＠bugzilla.kernel.org 06 May '21

06 May '21

https://bugzilla.kernel.org/show_bug.cgi?id=207833 Bug ID: 207833 Summary: Brightness control not working on ASUS TUF FA506IU (AMD Ryzen 7 4800H / Nvidia GTX 1660 Ti) Product: Drivers Version: 2.5 Kernel Version: 5.6.12-1 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: julen.pardo(a)outlook.es Regression: No Hello, I've just bought an ASUS TUF FA506IU with and AMD Ryzen 7 4800H / Nvidia GTX 1660 Ti setup. Even if this is quite new hardware, I'd say that the only thing that is not working at all is the brightness control. It's not working with the function keys, nor from the energy settings, nor with xbacklight. Actually, it's working a little; I can find a subtle difference between the max value and the last 5 values, but that's it. Setting it to the minimum still makes it way too bright. I've noticed that this could be a range mismatch between "brightness" and "max_brightness", and "actual_brightness". First are in 8 bit ranges, whereas the actual brightness is in 16 bit range. I've tried some luck patching the kernel to return an 8-bit value (https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/d…), but doing just that doesn't work (even if the "actual_brightness" was showing an 8 bit value). In my case, the full path is "/sys/class/backlight/amdgpu_bl1/". I've also tried different acpi_backlight parameters with no luck. I leave the output of lsmod | grep asus: asus_wmi 40960 0 sparse_keymap 16384 1 asus_wmi rfkill 28672 9 asus_wmi,bluetooth,cfg80211 battery 24576 1 asus_wmi wmi 36864 2 asus_wmi,wmi_bmof asus_wireless 20480 0 inxi -F: System: Host: TUF-FA506IU Kernel: 5.6.12-1-MANJARO x86_64 bits: 64 Desktop: KDE Plasma 5.18.5 Distro: Manjaro Linux Machine: Type: Laptop System: ASUSTeK product: TUF Gaming FA506IU_FA506IU v: 1.0 serial: <root required> Mobo: ASUSTeK model: FA506IU v: 1.0 serial: <root required> UEFI: American Megatrends v: FA506IU.302 date: 03/04/2020 Battery: ID-1: BAT1 charge: 47.9 Wh condition: 47.9/48.1 Wh (100%) CPU: Topology: 8-Core model: AMD Ryzen 7 4800H with Radeon Graphics bits: 64 type: MT MCP L2 cache: 4096 KiB Speed: 2405 MHz min/max: 1400/2900 MHz Core speeds (MHz): 1: 1875 2: 2497 3: 1397 4: 1397 5: 1397 6: 1397 7: 1397 8: 1397 9: 1397 10: 1396 11: 2963 12: 1673 13: 1800 14: 1548 15: 1397 16: 1396 Graphics: Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] driver: nvidia v: 440.82 Device-2: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.8 driver: amdgpu,nvidia resolution: 1920x1080~144Hz, 2560x1440~60Hz OpenGL: renderer: AMD RENOIR (DRM 3.36.0 5.6.12-1-MANJARO LLVM 10.0.0) v: 4.6 Mesa 20.0.6 Audio: Device-1: NVIDIA TU116 High Definition Audio driver: snd_hda_intel Device-2: Advanced Micro Devices [AMD/ATI] driver: snd_hda_intel Device-3: Advanced Micro Devices [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor driver: N/A Device-4: Advanced Micro Devices [AMD] Family 17h HD Audio driver: snd_hda_intel Sound Server: ALSA v: k5.6.12-1-MANJARO Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 IF: enp2s0 state: down mac: a8:5e:45:36:94:32 Device-2: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter driver: rtw_pci IF: wlp3s0 state: up mac: 70:66:55:09:8c:e3 Drives: Local Storage: total: 476.94 GiB used: 32.41 GiB (6.8%) ID-1: /dev/nvme0n1 vendor: Kingston model: OM8PCP3512F-AB size: 476.94 GiB Partition: ID-1: / size: 48.97 GiB used: 25.95 GiB (53.0%) fs: ext4 dev: /dev/nvme0n1p5 ID-2: /home size: 108.67 GiB used: 6.46 GiB (5.9%) fs: ext4 dev: /dev/nvme0n1p7 ID-3: swap-1 size: 3.03 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/nvme0n1p8 Sensors: Message: No sensors data was found. Is sensors configured? Info: Processes: 349 Uptime: 27m Memory: 7.20 GiB used: 3.04 GiB (42.2%) Shell: zsh inxi: 3.0.37 -- You are receiving this mail because: You are watching the assignee of the bug.

1 6

[Bug 203905] New: amdgpu:actual_brightness has unreal/wrong value
by bugzilla-daemon＠bugzilla.kernel.org 06 May '21

06 May '21

https://bugzilla.kernel.org/show_bug.cgi?id=203905 Bug ID: 203905 Summary: amdgpu:actual_brightness has unreal/wrong value Product: Drivers Version: 2.5 Kernel Version: 5.1.9 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: bjo(a)nord-west.org Regression: No Radeon R5/R6/R7 Graphics in a Thinkpad A275 has wrong values on actual_brightness of amdgpu_bl0. While max_brightness is 255 and it can be set to 255, actual_brightness reports a 5 digit number like 12470. As a result, tools which want to change the brightness related to actual_brightness fail, as brightness does not accept any 5 digit number, -- You are receiving this mail because: You are watching the assignee of the bug.

1 33

Re: Independent EDID parsing library
by Pekka Paalanen 06 May '21

06 May '21

Adding the previous list of CCs. On Thu, 29 Apr 2021 10:32:58 +0000 "Sharma, Shashank" <Shashank.Sharma(a)amd.com> wrote: > Hello Pekka, Daniel > > As discussed over IRC, I have prepared the first version of the EDID parsing library, which is hosted here: > https://github.com/contactshashanksharma/libedid/tree/master > > This is a simple C library, and I have created this library keeping a compositor's context in mind, so its easy for a compositor to use it. > There are only 2 APIs in this library: > - libedid_process_edid_info: Get EDID information from raw_edid, returns filled struct edid_info ptr > - libedid_destroy_edid_info: Free the EDID information > > I have provided much information in the README file, and have also added two simple test apps, with sample EDID, to test it. > Please have a look and let me know your opinion on this. > > Regards > Shashank

1 1

[PATCH 1/8] drm/arm: Don't set allow_fb_modifiers explicitly
by Daniel Vetter 06 May '21

06 May '21

Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski <paul.kocialkowski(a)bootlin.com> Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here for both komeda and malidp. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: "James (Qian) Wang" <james.qian.wang(a)arm.com> Cc: Liviu Dudau <liviu.dudau(a)arm.com> Cc: Mihail Atanassov <mihail.atanassov(a)arm.com> Cc: Brian Starkey <brian.starkey(a)arm.com> --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 1 - drivers/gpu/drm/arm/malidp_drv.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index aeda4e5ec4f4..ff45f23f3d56 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -247,7 +247,6 @@ static void komeda_kms_mode_config_init(struct komeda_kms_dev *kms, config->min_height = 0; config->max_width = 4096; config->max_height = 4096; - config->allow_fb_modifiers = true; config->funcs = &komeda_mode_config_funcs; config->helper_private = &komeda_mode_config_helpers; diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index d83c7366b348..de59f3302516 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -403,7 +403,6 @@ static int malidp_init(struct drm_device *drm) drm->mode_config.max_height = hwdev->max_line_size; drm->mode_config.funcs = &malidp_mode_config_funcs; drm->mode_config.helper_private = &malidp_mode_config_helpers; - drm->mode_config.allow_fb_modifiers = true; ret = malidp_crtc_init(drm); if (ret) -- 2.31.0

7 19

[PATCH v5 00/20] drm: Fix EDID reading on ti-sn65dsi86; solve some chicken-and-egg problems
by Douglas Anderson 05 May '21

05 May '21

The primary goal of this series is to try to properly fix EDID reading for eDP panels using the ti-sn65dsi86 bridge. Previously we had a patch that added EDID reading but it turned out not to work at bootup. This caused some extra churn at bootup as we tried (and failed) to read the EDID several times and also ended up forcing us to use the hardcoded mode at boot. With this patch series I believe EDID reading is reliable at boot now and we never use the hardcoded mode. This series is the logical successor to the 3-part series containing the patch ("drm/bridge: ti-sn65dsi86: Properly get the EDID, but only if refclk") [1] though only one actual patch is the same between the two. This series starts out with some general / obvious fixes and moves on to some more specific and maybe controversial ones. I wouldn't object to some of the earlier ones landing if they look ready. This patch was developed agains linuxnext (next-20210416) with drm-misc-next (as of 20210423) merged in on a sc7180-trogdor-lazor device. To get things booting for me, I had to use Stephen's patch [2] to keep from crashing but otherwise all the patches I needed were here. Primary change between v2 and v3 is to stop doing the EDID caching in the core. I also added Andrzej's review tags. Between v3 and v4 this series grew a whole lot. I changed it so that the EDID reading is actually driven by the panel driver now as was suggested by Andrzej. While I still believe that the old approach wasn't too bad I'm still switching. Why? The main reason is that I think it's useful in general for the panel code to have access to the DDC bus and to be able to read the EDID. This may allow us to more easily have the panel code support multiple sources of panels--it can read the EDID and possibly adjust timings based on the model ID. It also allows the panel code (or perhaps backlight code?) to send DDC commands if they are need for a particular panel. At the moment, once the panel is provided the DDC bus then existing code will assume that it should be in charge of reading the EDID. While it doesn't have to work that way, it seems sane to build on what's already there. In order to expose the DDC bus to the panel, I had to solve a bunch of chicken-and-egg problems in terms of probe ordering between the bridge and the panel. I've broken the bridge driver into several sub drivers to make this happen. At the moment the sub-drivers are just there to solve the probe problem, but conceivably someone could use them to break the driver up in the future if need be. Between v4 and v5, high-level view of changes. - Some of the early patches landed, so dropped from series. - New pm_runtime_disable() fix (fixed a patch that already landed). - Added Bjorn's tags to most patches - Fixed problems when building as a module. - Reordered debugfs patch and fixed error handling there. - Dropped last patch. I'm not convinced it's safe w/out more work. I apologize in advance for the length of this series. Hopefully you can see that there are only so many because they're broken up into nice and reviewable bite-sized-chunks. :-) *** NOTE ***: my hope is to actually land patches that have been reviewed sometime mid-to-late next week. Please shout if you think this is too much of a rush and you know of someone who is planning to review that needs more time. [1] https://lore.kernel.org/r/20210304155144.3.I60a7fb23ce4589006bc95c64ab8d15c… [2] https://lore.kernel.org/r/161706912161.3012082.17313817257247946143@swboyd.… Changes in v5: - Missing pm_runtime_disable() patch new for v5. - Reordered to debugfs change to avoid transient issue - Don't print debugfs creation errors. - Handle NULL from debugfs_create_dir() which is documented possible. - Rebased atop the pm_runtime patch, which got reordered. - Fix module compile problems (Bjorn + kbuild bot) - Remove useless MODULE_DEVICE_TABLE (Bjorn). - Fix module compile problems (Bjorn + kbuild bot) - Remove useless MODULE_DEVICE_TABLE (Bjorn). Douglas Anderson (20): drm/panel: panel-simple: Add missing pm_runtime_disable() calls drm/bridge: ti-sn65dsi86: Rename the main driver data structure drm/bridge: ti-sn65dsi86: More renames in prep for sub-devices drm/bridge: ti-sn65dsi86: Use devm to do our runtime_disable drm/bridge: ti-sn65dsi86: Clean debugfs code drm/bridge: ti-sn65dsi86: Add local var for "dev" to simplify probe drm/bridge: ti-sn65dsi86: Cleanup managing of drvdata drm/bridge: ti-sn65dsi86: Move all the chip-related init to the start drm/bridge: ti-sn65dsi86: Break GPIO and MIPI-to-eDP bridge into sub-drivers drm/panel: panel-simple: Get rid of hacky HPD chicken-and-egg code drm/bridge: ti-sn65dsi86: Use pm_runtime autosuspend drm/bridge: ti-sn65dsi86: Code motion of refclk management functions drm/bridge: ti-sn65dsi86: If refclk, DP AUX can happen w/out pre-enable drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev i2c: i2c-core-of: Fix corner case of finding adapter by node drm/panel: panel-simple: Remove extra call: drm_connector_update_edid_property() drm/panel: panel-simple: Power the panel when reading the EDID drm/panel: panel-simple: Cache the EDID as long as we retain power drm/bridge: ti-sn65dsi86: Don't read EDID blob over DDC arm64: dts: qcom: Link the panel to the bridge's DDC bus arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 1 + drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 767 ++++++++++++------- drivers/gpu/drm/panel/panel-simple.c | 49 +- drivers/i2c/i2c-core-of.c | 17 +- 5 files changed, 538 insertions(+), 297 deletions(-) -- 2.31.1.498.g6c1eba8ee3d-goog

4 35

[RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal
by Marek Olšák 04 May '21

04 May '21

Hi, This is our initial proposal for explicit fences everywhere and new memory management that doesn't use BO fences. It's a redesign of how Linux graphics drivers work, and it can coexist with what we have now. *1. Introduction* (skip this if you are already sold on explicit fences) The current Linux graphics architecture was initially designed for GPUs with only one graphics queue where everything was executed in the submission order and per-BO fences were used for memory management and CPU-GPU synchronization, not GPU-GPU synchronization. Later, multiple queues were added on top, which required the introduction of implicit GPU-GPU synchronization between queues of different processes using per-BO fences. Recently, even parallel execution within one queue was enabled where a command buffer starts draws and compute shaders, but doesn't wait for them, enabling parallelism between back-to-back command buffers. Modesetting also uses per-BO fences for scheduling flips. Our GPU scheduler was created to enable all those use cases, and it's the only reason why the scheduler exists. The GPU scheduler, implicit synchronization, BO-fence-based memory management, and the tracking of per-BO fences increase CPU overhead and latency, and reduce parallelism. There is a desire to replace all of them with something much simpler. Below is how we could do it. *2. Explicit synchronization for window systems and modesetting* The producer is an application and the consumer is a compositor or a modesetting driver. *2.1. The Present request* As part of the Present request, the producer will pass 2 fences (sync objects) to the consumer alongside the presented DMABUF BO: - The submit fence: Initially unsignalled, it will be signalled when the producer has finished drawing into the presented buffer. - The return fence: Initially unsignalled, it will be signalled when the consumer has finished using the presented buffer. Deadlock mitigation to recover from segfaults: - The kernel knows which process is obliged to signal which fence. This information is part of the Present request and supplied by userspace. - If the producer crashes, the kernel signals the submit fence, so that the consumer can make forward progress. - If the consumer crashes, the kernel signals the return fence, so that the producer can reclaim the buffer. - A GPU hang signals all fences. Other deadlocks will be handled like GPU hangs. Other window system requests can follow the same idea. Merged fences where one fence object contains multiple fences will be supported. A merged fence is signalled only when its fences are signalled. The consumer will have the option to redefine the unsignalled return fence to a merged fence. *2.2. Modesetting* Since a modesetting driver can also be the consumer, the present ioctl will contain a submit fence and a return fence too. One small problem with this is that userspace can hang the modesetting driver, but in theory, any later present ioctl can override the previous one, so the unsignalled presentation is never used. *3. New memory management* The per-BO fences will be removed and the kernel will not know which buffers are busy. This will reduce CPU overhead and latency. The kernel will not need per-BO fences with explicit synchronization, so we just need to remove their last user: buffer evictions. It also resolves the current OOM deadlock. *3.1. Evictions* If the kernel wants to move a buffer, it will have to wait for everything to go idle, halt all userspace command submissions, move the buffer, and resume everything. This is not expected to happen when memory is not exhausted. Other more efficient ways of synchronization are also possible (e.g. sync only one process), but are not discussed here. *3.2. Per-process VRAM usage quota* Each process can optionally and periodically query its VRAM usage quota and change domains of its buffers to obey that quota. For example, a process allocated 2 GB of buffers in VRAM, but the kernel decreased the quota to 1 GB. The process can change the domains of the least important buffers to GTT to get the best outcome for itself. If the process doesn't do it, the kernel will choose which buffers to evict at random. (thanks to Christian Koenig for this idea) *3.3. Buffer destruction without per-BO fences* When the buffer destroy ioctl is called, an optional fence list can be passed to the kernel to indicate when it's safe to deallocate the buffer. If the fence list is empty, the buffer will be deallocated immediately. Shared buffers will be handled by merging fence lists from all processes that destroy them. Mitigation of malicious behavior: - If userspace destroys a busy buffer, it will get a GPU page fault. - If userspace sends fences that never signal, the kernel will have a timeout period and then will proceed to deallocate the buffer anyway. *3.4. Other notes on MM* Overcommitment of GPU-accessible memory will cause an allocation failure or invoke the OOM killer. Evictions to GPU-inaccessible memory might not be supported. Kernel drivers could move to this new memory management today. Only buffer residency and evictions would stop using per-BO fences. *4. Deprecating implicit synchronization* It can be phased out by introducing a new generation of hardware where the driver doesn't add support for it (like a driver fork would do), assuming userspace has all the changes for explicit synchronization. This could potentially create an isolated part of the kernel DRM where all drivers only support explicit synchronization. Marek

12 104

← Newer
1
...
15
16
17
18
19
20
21
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2021