dri-devel July 2018

dri-devel@lists.freedesktop.org

277 participants
1883 discussions

[PATCH for v4.19] drm_dp_cec.c: fix formatting typo: %pdH -> %phD
by Hans Verkuil 28 Jul '18

28 Jul '18

This caused a kernel oops since %pdH interpreted the pointer as a struct file. Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> --- drivers/gpu/drm/drm_dp_cec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c index 87b67cc1ea58..a6cac47f6248 100644 --- a/drivers/gpu/drm/drm_dp_cec.c +++ b/drivers/gpu/drm/drm_dp_cec.c @@ -157,7 +157,7 @@ static void drm_dp_cec_adap_status(struct cec_adapter *adap, if (drm_dp_read_desc(aux, &desc, true)) return; - seq_printf(file, "OUI: %*pdH\n", + seq_printf(file, "OUI: %*phD\n", (int)sizeof(id->oui), id->oui); seq_printf(file, "ID: %*pE\n", (int)strnlen(id->device_id, sizeof(id->device_id)), -- 2.18.0

2 1

[PATCH v2 0/5] Implement CRC and Add necessary infrastructure
by Haneen Mohammed 28 Jul '18

28 Jul '18

This patchset implement CRC debugfs API and add the necessary infrastructure required to enable to compute and add CRCs entries. 1. add functions to map/unmap buffers to kernel address space. 2. map/unmap buffers in the prepare/cleanup_fb hooks. 3. compute crc using crc32 on the visible portion of the buffer with appropriate synchronization methods. Haneen Mohammed (5): drm/vkms: Add functions to map/unmap GEM backing storage drm/vkms: map/unmap buffers in [prepare/cleanup]_fb hooks drm/vkms: Add atomic_helper_check_plane_state drm/vkms: subclass CRTC state drm/vkms: Implement CRC debugfs API drivers/gpu/drm/vkms/Makefile | 2 +- drivers/gpu/drm/vkms/vkms_crtc.c | 111 +++++++++++++++++++++++++++--- drivers/gpu/drm/vkms/vkms_drv.c | 1 + drivers/gpu/drm/vkms/vkms_drv.h | 41 +++++++++++ drivers/gpu/drm/vkms/vkms_gem.c | 73 +++++++++++++++++++- drivers/gpu/drm/vkms/vkms_plane.c | 75 +++++++++++++++++++- 6 files changed, 290 insertions(+), 13 deletions(-) -- 2.17.1

2 17

[Bug 107175] [CI][SKL][IOMMU] i915: probe of 0000:00:02.0 failed with error -25
by bugzilla-daemon＠freedesktop.org 28 Jul '18

28 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=107175 Chris Wilson <chris(a)chris-wilson.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #2 from Chris Wilson <chris(a)chris-wilson.co.uk> --- The probe fail message isn't currently being flagged as an issue (and it shouldn't be), lets hope it continues. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[git pull] amdkfd next 4.19
by Oded Gabbay 28 Jul '18

28 Jul '18

Hi Dave, This is amdkfd pull for 4.19. The major changes are: - Add Raven support. Raven refers to Ryzen APUs with integrated GFXv9 GPU. - Integrate GPU reset support In addition, there are a couple of small fixes and improvements, such as: - Better handling and reporting to user of VM faults - Fix race upon context restore - Allow the user to use specific Compute Units - Basic power management Thanks, Oded The following changes since commit 6d52aacd92c60331ec8c3117522f4301b5195e28: Merge branch 'drm-next-4.19' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-07-27 12:31:48 +1000) are available in the git repository at: git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-next-2018-07-28 for you to fetch changes up to b5aa3f4aef724e9c0f626dcf69948b22efcc5176: drm/amdkfd: Call kfd2kgd.set_compute_idle (2018-07-16 19:10:37 -0400) ---------------------------------------------------------------- Arnd Bergmann (1): drm/admkfd use modern ktime accessors Felix Kuehling (6): drm/amdkfd: Reliably prevent reclaim-FS while holding DQM lock drm/amdkfd: Stop using GFP_NOIO explicitly drm/amd: Add CU-masking ioctl definition to kfd_ioctl.h drm/amdkfd: Add CU-masking ioctl to KFD drm/amdgpu: Add kfd2kgd.set_compute_idle interface drm/amdkfd: Call kfd2kgd.set_compute_idle Jay Cornwall (1): drm/amdkfd: Fix race between scheduler and context restore Lan Xiao (1): drm/amdkfd: fix zero reading of VMID and PASID for Hawaii Moses Reuben (1): drm/amdkfd: send SIGSEGV to process upon KFD_EVENT_TYPE_MEMORY Shaoyun Liu (13): drm/amd: Add gpu reset interfaces between amdgpu and amdkfd drm/amd: Add kfd ioctl defines for hw_exception event drm/amdkfd: Add gpu reset interface and place holder drm/amdgpu: Call KFD reset handlers during GPU reset drm/amdkfd: Implement GPU reset handlers in KFD drm/amdgpu: Enable the gpu reset from KFD drm/amdkfd: Implement hang detection in KFD and call amdgpu drm/amdgpu: Don't use shadow BO for compute context drm/amdgpu: Check NULL pointer for job before reset job's ring drm/amdkfd: Fix kernel queue 64 bit doorbell offset calculation drm/amdgpu: Avoid invalidate tlbs when gpu is on reset drm/amdgpu: Avoid destroy hqd when GPU is on reset drm/amdkfd: Add debugfs interface to trigger HWS hang Wei Lu (1): drm/amdkfd: Fix error codes in kfd_get_process Yong Zhao (10): drm/amdkfd: Introduce KFD module parameter halt_if_hws_hang drm/amdkfd: Use module parameters noretry as the internal variable name drm/amdkfd: Replace mqd with mqd_mgr as the variable name for mqd_manager drm/amdkfd: Clean up reference of radeon drm/amdkfd: Consolidate duplicate memory banks info in topology drm/amdkfd: Make SDMA engine number an ASIC-dependent variable drm/amdkfd: Avoid flooding dmesg on Raven due to IOMMU issues drm/amdkfd: Workaround to accommodate Raven too many PPR issue drm/amdkfd: Optimize out some duplicated code in kfd_signal_iommu_event() drm/amdkfd: Enable Raven for KFD shaoyunl (2): drm/amdgpu: save vm fault information for amdkfd drm/amdkfd: Handle VM faults in KFD drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 35 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 10 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 27 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 9 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 8 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 14 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 13 +- drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 33 +- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 33 +- drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c | 54 ++- drivers/gpu/drm/amd/amdkfd/cik_int.h | 7 +- drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h | 458 +++++++++++---------- .../gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx8.asm | 18 +- .../gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx9.asm | 16 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 69 +++- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 57 ++- drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c | 1 - drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.h | 37 ++ drivers/gpu/drm/amd/amdkfd/kfd_debugfs.c | 48 +++ drivers/gpu/drm/amd/amdkfd/kfd_device.c | 122 +++++- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 283 ++++++++----- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 32 +- .../drm/amd/amdkfd/kfd_device_queue_manager_v9.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 9 +- drivers/gpu/drm/amd/amdkfd/kfd_events.c | 118 +++++- drivers/gpu/drm/amd/amdkfd/kfd_events.h | 1 + drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c | 22 +- drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 6 +- drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 18 +- drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.h | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_module.c | 16 +- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 41 +- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h | 4 + drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 29 +- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 31 +- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c | 29 +- drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c | 26 ++ drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 40 +- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 + .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 43 +- drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 40 ++ include/uapi/linux/kfd_ioctl.h | 33 +- 45 files changed, 1460 insertions(+), 447 deletions(-)

1 0

[PATCH] drm/nouveau/debugfs: fix pm_runtime.cocci warnings (fwd)
by Julia Lawall 28 Jul '18

28 Jul '18

From: kbuild test robot <fengguang.wu(a)intel.com> pm_runtime_get_sync returns < 0 as error. Unecessary IS_ERR_VALUE at line 164 Generated by: scripts/coccinelle/api/pm_runtime.cocci Fixes: eaeb9010bb4b ("drm/nouveau/debugfs: Wake up GPU before doing any reclocking") CC: Karol Herbst <karolherbst(a)gmail.com> Signed-off-by: kbuild test robot <fengguang.wu(a)intel.com> Signed-off-by: Julia Lawall <julia.lawall(a)lip6.fr> --- Please take the patch only if it's a positive warning. Thanks! nouveau_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c +++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c @@ -161,7 +161,7 @@ nouveau_debugfs_pstate_set(struct file * } ret = pm_runtime_get_sync(drm->dev); - if (IS_ERR_VALUE(ret) && ret != -EACCES) + if (ret < 0 && ret != -EACCES) return ret; ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_USER, &args, sizeof(args)); pm_runtime_put_autosuspend(drm->dev);

1 0

[PATCH] drm: qxl: Fix NULL pointer dereference at qxl_alloc_client_monitors_config
by Anton Vasilyev 27 Jul '18

27 Jul '18

If qxl_alloc_client_monitors_config() fails to allocate client_monitors_config then NULL pointer dereference occurs in function qxl_display_copy_rom_client_monitors_config() after qxl_alloc_client_monitors_config() call. The patch adds return error from qxl_alloc_client_monitors_config() and additional status for qxl_display_copy_rom_client_monitors_config return value. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Anton Vasilyev <vasilyev(a)ispras.ru> --- Note: Is it correct that qxl_display_read_client_monitors_config() does not return error in case of fail? --- drivers/gpu/drm/qxl/qxl_display.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 768207fbbae3..a59b2eca5f5b 100644 --- a/drivers/gpu/drm/qxl/qxl_display.c +++ b/drivers/gpu/drm/qxl/qxl_display.c @@ -37,7 +37,8 @@ static bool qxl_head_enabled(struct qxl_head *head) return head->width && head->height; } -static void qxl_alloc_client_monitors_config(struct qxl_device *qdev, unsigned count) +static int qxl_alloc_client_monitors_config(struct qxl_device *qdev, + unsigned int count) { if (qdev->client_monitors_config && count > qdev->client_monitors_config->count) { @@ -49,15 +50,17 @@ static void qxl_alloc_client_monitors_config(struct qxl_device *qdev, unsigned c sizeof(struct qxl_monitors_config) + sizeof(struct qxl_head) * count, GFP_KERNEL); if (!qdev->client_monitors_config) - return; + return -ENOMEM; } qdev->client_monitors_config->count = count; + return 0; } enum { MONITORS_CONFIG_MODIFIED, MONITORS_CONFIG_UNCHANGED, MONITORS_CONFIG_BAD_CRC, + MONITORS_CONFIG_ERROR, }; static int qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev) @@ -87,7 +90,10 @@ static int qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev) && (num_monitors != qdev->client_monitors_config->count)) { status = MONITORS_CONFIG_MODIFIED; } - qxl_alloc_client_monitors_config(qdev, num_monitors); + if (qxl_alloc_client_monitors_config(qdev, num_monitors)) { + status = MONITORS_CONFIG_ERROR; + return status; + } /* we copy max from the client but it isn't used */ qdev->client_monitors_config->max_allowed = qdev->monitors_config->max_allowed; @@ -161,6 +167,10 @@ void qxl_display_read_client_monitors_config(struct qxl_device *qdev) break; udelay(5); } + if (status == MONITORS_CONFIG_ERROR) { + DRM_DEBUG_KMS("ignoring client monitors config: error"); + return; + } if (status == MONITORS_CONFIG_BAD_CRC) { DRM_DEBUG_KMS("ignoring client monitors config: bad crc"); return; -- 2.18.0

1 0

[PATCH] backlight: pwm_bl: switch to using "atomic" PWM API
by Enric Balletbo i Serra 27 Jul '18

27 Jul '18

The "atomic" API allows us to configure PWM period and duty_cycle and enable it in one call. The patch also moves the pwm_init_state just before any use of the pwm_state struct, this fixes a potential bug where pwm_get_state can be called before pwm_init_state. Signed-off-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> --- drivers/video/backlight/pwm_bl.c | 48 ++++++++++++++++++++------------ 1 file changed, 30 insertions(+), 18 deletions(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index bdfcc0a71db1..2c734d55d607 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -46,7 +46,8 @@ struct pwm_bl_data { void (*exit)(struct device *); }; -static void pwm_backlight_power_on(struct pwm_bl_data *pb, int brightness) +static void pwm_backlight_power_on(struct pwm_bl_data *pb, + struct pwm_state *state) { int err; @@ -57,7 +58,8 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb, int brightness) if (err < 0) dev_err(pb->dev, "failed to enable power supply\n"); - pwm_enable(pb->pwm); + state->enabled = true; + pwm_apply_state(pb->pwm, state); if (pb->post_pwm_on_delay) msleep(pb->post_pwm_on_delay); @@ -70,6 +72,8 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb, int brightness) static void pwm_backlight_power_off(struct pwm_bl_data *pb) { + struct pwm_state state; + if (!pb->enabled) return; @@ -79,8 +83,11 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb) if (pb->pwm_off_delay) msleep(pb->pwm_off_delay); - pwm_config(pb->pwm, 0, pb->period); - pwm_disable(pb->pwm); + pwm_get_state(pb->pwm, &state); + state.enabled = false; + state.period = pb->period; + state.duty_cycle = 0; + pwm_apply_state(pb->pwm, &state); regulator_disable(pb->power_supply); pb->enabled = false; @@ -106,6 +113,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl) { struct pwm_bl_data *pb = bl_get_data(bl); int brightness = bl->props.brightness; + struct pwm_state state; int duty_cycle; if (bl->props.power != FB_BLANK_UNBLANK || @@ -118,8 +126,13 @@ static int pwm_backlight_update_status(struct backlight_device *bl) if (brightness > 0) { duty_cycle = compute_duty_cycle(pb, brightness); - pwm_config(pb->pwm, duty_cycle, pb->period); - pwm_backlight_power_on(pb, brightness); + pwm_get_state(pb->pwm, &state); + state.duty_cycle = duty_cycle; + state.period = pb->period; + if (!state.enabled) + pwm_backlight_power_on(pb, &state); + else + pwm_apply_state(pb->pwm, &state); } else pwm_backlight_power_off(pb); @@ -447,7 +460,6 @@ static int pwm_backlight_probe(struct platform_device *pdev) struct device_node *node = pdev->dev.of_node; struct pwm_bl_data *pb; struct pwm_state state; - struct pwm_args pargs; unsigned int i; int ret; @@ -539,10 +551,17 @@ static int pwm_backlight_probe(struct platform_device *pdev) dev_dbg(&pdev->dev, "got pwm for backlight\n"); - if (!data->levels) { - /* Get the PWM period (in nanoseconds) */ - pwm_get_state(pb->pwm, &state); + /* Sync up PWM state and ensure it is off. */ + pwm_init_state(pb->pwm, &state); + state.enabled = false; + ret = pwm_apply_state(pb->pwm, &state); + if (ret) { + dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n", + ret); + goto err_alloc; + } + if (!data->levels) { ret = pwm_backlight_brightness_default(&pdev->dev, data, state.period); if (ret < 0) { @@ -559,20 +578,13 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->levels = data->levels; } - /* - * FIXME: pwm_apply_args() should be removed when switching to - * the atomic PWM API. - */ - pwm_apply_args(pb->pwm); - /* * The DT case will set the pwm_period_ns field to 0 and store the * period, parsed from the DT, in the PWM device. For the non-DT case, * set the period from platform data if it has not already been set * via the PWM lookup table. */ - pwm_get_args(pb->pwm, &pargs); - pb->period = pargs.period; + pb->period = state.period; if (!pb->period && (data->pwm_period_ns > 0)) pb->period = data->pwm_period_ns; -- 2.18.0

2 2

[Bug 107001] hard system freeze with mesa 18.1.1 and 18.1.2 on AMD RX 580
by bugzilla-daemon＠freedesktop.org 27 Jul '18

27 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=107001 claude(a)mathr.co.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from claude(a)mathr.co.uk --- Seems fixed in mesa-18.1.4, no freezes since upgrading. New kernel too, with amdgpu.dc=0 set for an unrelated issue. $ uptime 14:07:18 up 1 day, 12:48, 1 user, load average: 16.86, 16.36, 15.81 $ uname -a Linux eiskaffee 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 GNU/Linux $ clinfo | grep Device\ Name | head -n 1 Device Name Radeon RX 580 Series (POLARIS10, DRM 3.25.0, 4.17.0-1-amd64, LLVM 6.0.1) $ apt-cache policy mesa-common-dev mesa-common-dev: Installed: 18.1.4-1 Candidate: 18.1.4-1 Version table: *** 18.1.4-1 990 990 http://ftp.uk.debian.org/debian buster/main amd64 Packages 500 http://ftp.uk.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH v2 00/10] Add helper for plane reset
by Alexandru Gheorghe 27 Jul '18

27 Jul '18

Changes since v1: - Make __drm_atomic_helper_plane_reset consistent with the other helpers and require that both plane and state not be NULL, suggested by Boris Brezillon and Philipp Zabel. Drivers already check for that. - Add a proper commit message for driver changes. Drivers that subclass drm_plane need to copy the logic for linking the drm_plane with its state and to initialize core properties to their default values. E.g (alpha and rotation) Having a helper to reset the plane_state makes sense because of multiple reasons: 1. Eliminate code duplication. 2. Add a single place for initializing core properties to their default values, no need for driver to do it if what the helper sets makes sense for them. 3. No need to debug the driver when you enable a core property and observe it doesn't have a proper default value. Tested with mali-dp the other drivers are just built-tested. Alexandru Gheorghe (10): drm/atomic: Add __drm_atomic_helper_plane_reset drm/amd/display: Use __drm_atomic_helper_plane_reset instead of copying the logic drm: mali-dp: Use __drm_atomic_helper_plane_reset instead of copying the logic drm: atmel-hlcdc: Use __drm_atomic_helper_plane_reset instead of copying the logic drm/exynos: Use __drm_atomic_helper_plane_reset instead of copying the logic drm/imx: Use __drm_atomic_helper_plane_reset instead of copying the logic drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying the logic drm/sun4i: Use __drm_atomic_helper_plane_reset instead of copying the logic drm/vc4: Use __drm_atomic_helper_plane_reset instead of copying the logic drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the logic .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++--- drivers/gpu/drm/arm/malidp_planes.c | 7 ++--- .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 5 +-- drivers/gpu/drm/drm_atomic_helper.c | 31 +++++++++++++------ drivers/gpu/drm/exynos/exynos_drm_plane.c | 3 +- drivers/gpu/drm/imx/ipuv3-plane.c | 8 ++--- drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +-- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 +-- drivers/gpu/drm/sun4i/sun4i_layer.c | 4 +-- drivers/gpu/drm/vc4/vc4_plane.c | 4 +-- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-- include/drm/drm_atomic_helper.h | 2 ++ 12 files changed, 38 insertions(+), 45 deletions(-) -- 2.18.0

3 13

[Bug 107403] Quadratic behavior due to leaking fence contexts in reservation objects
by bugzilla-daemon＠freedesktop.org 27 Jul '18

27 Jul '18

https://bugs.freedesktop.org/show_bug.cgi?id=107403 Bug ID: 107403 Summary: Quadratic behavior due to leaking fence contexts in reservation objects Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: bas(a)basnieuwenhuizen.nl As part of the Vulkan CTS, radv creates about 30k AMDGPU contexts (about 1-20 live at the same time though). Each of those creates a bunch of fence contexts, one for each ring, to use for fences created from submitted jobs. However, as part of running jobs, fences with those contexts get attached to the vm->root.base.bo->tbo.resv of the corresponding vm. Which means that at some point we have tens of thousands of fences attached to it as they never get removed. They only ever get deduplicated with a later fence from the same fence context, so fences from destroyed contexts never get removed. Then in amdgpu_gem_va_ioctl -> amdgpu_vm_clear_freed -> amdgpu_vm_bo_update_mapping we do an amdgpu_sync_resv, which tries to add that to an amdgpu_sync object. Which only has a 16-entry hashtable, so adding the fences to the hashtable results in quadratic behavior. Combine this with doing sparse buffer tests at the end, which do lots of VA operations this results in tests taking 20+ minuts. So I could reduce the number of amdgpu contexts a bit in radv, but the bigger issue in my opnion is that we are pretty much leaking and never reclaiming the fences. Any idea how to best remove some signalled fences? -- You are receiving this mail because: You are the assignee for the bug.

1 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2018