dri-devel November 2016

dri-devel@lists.freedesktop.org

244 participants
1470 discussions

[Bug 98573] Mesa build fail since radeonsi: use PS epilog for monolithic shaders
by bugzilla-daemon＠freedesktop.org 05 Nov '16

05 Nov '16

https://bugs.freedesktop.org/show_bug.cgi?id=98573 Bug ID: 98573 Summary: Mesa build fail since radeonsi: use PS epilog for monolithic shaders Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: adf.lists(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Making all in targets/pipe-loader make[4]: Entering directory '/mnt/sdb1/Gits/mesa/src/gallium/targets/pipe-loader' CXXLD pipe_radeonsi.la ../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(si_shader.o): In function `si_build_wrapper_function': /mnt/sdb1/Gits/mesa/src/gallium/drivers/radeonsi/si_shader.c:6861: undefined reference to `ac_is_sgpr_param' /mnt/sdb1/Gits/mesa/src/gallium/drivers/radeonsi/si_shader.c:6951: undefined reference to `ac_is_sgpr_param' collect2: error: ld returned 1 exit status commit 7115e56c21ace07cf04f5073ba73a533e2182099 Author: Nicolai Hähnle <nicolai.haehnle(a)amd.com> Date: Fri Oct 28 14:45:59 2016 +0200 radeonsi: use PS epilog for monolithic shaders -- You are receiving this mail because: You are the assignee for the bug.

1 5

[radeon-alex:drm-next-4.10-wip 56/56] drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1225:10-29: WARNING: casting value returned by memory allocation function to (struct dma_fence * *) is useless.
by kbuild test robot 05 Nov '16

05 Nov '16

tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.10-wip head: 2f5945e707b5dffbf12444ad8bea079626ad30ec commit: 2f5945e707b5dffbf12444ad8bea079626ad30ec [56/56] drm/amdgpu: add the interface of waiting multiple fences (v4) coccinelle warnings: (new ones prefixed by >>) >> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1225:10-29: WARNING: casting value returned by memory allocation function to (struct dma_fence * *) is useless. Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

1 1

[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.
by Mario Kleiner 05 Nov '16

05 Nov '16

amdgpu-kms uses shared fences for its prime exported dmabufs, instead of an exclusive fence. Therefore we need to wait for all fences of the dmabuf reservation object to prevent unsynchronized rendering and flipping. This patch was tested to behave properly with intel-kms + radeon/amdgpu/nouveau-kms for correct prime sync during pageflipping under DRI3/Present. Should fix https://bugs.freedesktop.org/show_bug.cgi?id=95472 at least for page-flipped presentation. Suggested-by: Michel Dänzer <michel.daenzer(a)amd.com> Signed-off-by: Mario Kleiner <mario.kleiner.de(a)gmail.com> Cc: Michel Dänzer <michel.daenzer(a)amd.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: David Airlie <airlied(a)linux.ie> --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 922709b..4b74b96 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12043,7 +12043,7 @@ static void intel_mmio_flip_work_func(struct work_struct *w) /* For framebuffer backed by dmabuf, wait for fence */ resv = i915_gem_object_get_dmabuf_resv(obj); if (resv) - WARN_ON(reservation_object_wait_timeout_rcu(resv, false, false, + WARN_ON(reservation_object_wait_timeout_rcu(resv, true, false, MAX_SCHEDULE_TIMEOUT) < 0); intel_pipe_update_start(crtc); @@ -14700,7 +14700,7 @@ intel_prepare_plane_fb(struct drm_plane *plane, if (resv) { long lret; - lret = reservation_object_wait_timeout_rcu(resv, false, true, + lret = reservation_object_wait_timeout_rcu(resv, true, true, MAX_SCHEDULE_TIMEOUT); if (lret == -ERESTARTSYS) return lret; -- 2.7.0

6 45

[PATCH] drm/vc4: Use runtime autosuspend to avoid thrashing V3D power state.
by Eric Anholt 04 Nov '16

04 Nov '16

The pm_runtime_put() we were using immediately released power on the device, which meant that we were generally turning the device off and on once per frame. In many profiles I've looked at, that added up to about 1% of CPU time, but this could get worse in the case of frequent rendering and readback (as may happen in X rendering). By keeping the device on until we've been idle for a couple of frames, we drop the overhead of runtime PM down to sub-.1%. Signed-off-by: Eric Anholt <eric(a)anholt.net> --- drivers/gpu/drm/vc4/vc4_drv.c | 9 ++++++--- drivers/gpu/drm/vc4/vc4_gem.c | 6 ++++-- drivers/gpu/drm/vc4/vc4_v3d.c | 2 ++ 3 files changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index b087404c2784..7abfe088f2d1 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -61,21 +61,24 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void *data, if (ret < 0) return ret; args->value = V3D_READ(V3D_IDENT0); - pm_runtime_put(&vc4->v3d->pdev->dev); + pm_runtime_mark_last_busy(&vc4->v3d->pdev->dev); + pm_runtime_put_autosuspend(&vc4->v3d->pdev->dev); break; case DRM_VC4_PARAM_V3D_IDENT1: ret = pm_runtime_get_sync(&vc4->v3d->pdev->dev); if (ret < 0) return ret; args->value = V3D_READ(V3D_IDENT1); - pm_runtime_put(&vc4->v3d->pdev->dev); + pm_runtime_mark_last_busy(&vc4->v3d->pdev->dev); + pm_runtime_put_autosuspend(&vc4->v3d->pdev->dev); break; case DRM_VC4_PARAM_V3D_IDENT2: ret = pm_runtime_get_sync(&vc4->v3d->pdev->dev); if (ret < 0) return ret; args->value = V3D_READ(V3D_IDENT2); - pm_runtime_put(&vc4->v3d->pdev->dev); + pm_runtime_mark_last_busy(&vc4->v3d->pdev->dev); + pm_runtime_put_autosuspend(&vc4->v3d->pdev->dev); break; case DRM_VC4_PARAM_SUPPORTS_BRANCHES: case DRM_VC4_PARAM_SUPPORTS_ETC1: diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c index 303f23c96220..db920771bfb5 100644 --- a/drivers/gpu/drm/vc4/vc4_gem.c +++ b/drivers/gpu/drm/vc4/vc4_gem.c @@ -709,8 +709,10 @@ vc4_complete_exec(struct drm_device *dev, struct vc4_exec_info *exec) } mutex_lock(&vc4->power_lock); - if (--vc4->power_refcount == 0) - pm_runtime_put(&vc4->v3d->pdev->dev); + if (--vc4->power_refcount == 0) { + pm_runtime_mark_last_busy(&vc4->v3d->pdev->dev); + pm_runtime_put_autosuspend(&vc4->v3d->pdev->dev); + } mutex_unlock(&vc4->power_lock); kfree(exec); diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c index e6d3c6028341..7cc346ad9b0b 100644 --- a/drivers/gpu/drm/vc4/vc4_v3d.c +++ b/drivers/gpu/drm/vc4/vc4_v3d.c @@ -222,6 +222,8 @@ static int vc4_v3d_bind(struct device *dev, struct device *master, void *data) return ret; } + pm_runtime_use_autosuspend(dev); + pm_runtime_set_autosuspend_delay(dev, 40); /* a little over 2 frames. */ pm_runtime_enable(dev); return 0; -- 2.10.2

1 0

[PATCH 1/2] drm/vc4: Fix termination of the initial scan for branch targets.
by Eric Anholt 04 Nov '16

04 Nov '16

The loop is scanning until the original max_ip (size of the BO), but we want to not examine any code after the PROG_END's delay slots. There was a block trying to do that, except that we had some early continue statements if the signal wasn't a PROG_END or a BRANCH. The failure mode would be that a valid shader is rejected because some undefined memory after the PROG_END slots is parsed as a branch and the rest of its setup is illegal. I haven't seen this in the wild, but valgrind was complaining when about this up in the userland simulator mode. Signed-off-by: Eric Anholt <eric(a)anholt.net> --- drivers/gpu/drm/vc4/vc4_validate_shaders.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_validate_shaders.c b/drivers/gpu/drm/vc4/vc4_validate_shaders.c index 2543cf5b8b51..917321ce832f 100644 --- a/drivers/gpu/drm/vc4/vc4_validate_shaders.c +++ b/drivers/gpu/drm/vc4/vc4_validate_shaders.c @@ -608,9 +608,7 @@ static bool vc4_validate_branches(struct vc4_shader_validation_state *validation_state) { uint32_t max_branch_target = 0; - bool found_shader_end = false; int ip; - int shader_end_ip = 0; int last_branch = -2; for (ip = 0; ip < validation_state->max_ip; ip++) { @@ -621,8 +619,13 @@ vc4_validate_branches(struct vc4_shader_validation_state *validation_state) uint32_t branch_target_ip; if (sig == QPU_SIG_PROG_END) { - shader_end_ip = ip; - found_shader_end = true; + /* There are two delay slots after program end is + * signaled that are still executed, then we're + * finished. validation_state->max_ip is the + * instruction after the last valid instruction in the + * program. + */ + validation_state->max_ip = ip + 3; continue; } @@ -676,15 +679,9 @@ vc4_validate_branches(struct vc4_shader_validation_state *validation_state) } set_bit(after_delay_ip, validation_state->branch_targets); max_branch_target = max(max_branch_target, after_delay_ip); - - /* There are two delay slots after program end is signaled - * that are still executed, then we're finished. - */ - if (found_shader_end && ip == shader_end_ip + 2) - break; } - if (max_branch_target > shader_end_ip) { + if (max_branch_target > validation_state->max_ip - 3) { DRM_ERROR("Branch landed after QPU_SIG_PROG_END"); return false; } -- 2.10.1

1 1

[PATCH 1/3] dma-buf: return index of the first signaled fence
by Alex Deucher 04 Nov '16

04 Nov '16

From: "monk.liu" <monk.liu(a)amd.com> Return the index of the first signaled fence. This information is useful in some APIs like Vulkan. Signed-off-by: monk.liu <monk.liu(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> --- drivers/dma-buf/fence.c | 19 ++++++++++++++----- include/linux/fence.h | 2 +- 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c index 64478f9..32fdce1 100644 --- a/drivers/dma-buf/fence.c +++ b/drivers/dma-buf/fence.c @@ -397,14 +397,17 @@ out: EXPORT_SYMBOL(fence_default_wait); static bool -fence_test_signaled_any(struct fence **fences, uint32_t count) +fence_test_signaled_any(struct fence **fences, uint32_t count, uint32_t *idx) { int i; for (i = 0; i < count; ++i) { struct fence *fence = fences[i]; - if (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags)) + if (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { + if (idx) + *idx = i; return true; + } } return false; } @@ -416,6 +419,7 @@ fence_test_signaled_any(struct fence **fences, uint32_t count) * @count: [in] number of fences to wait on * @intr: [in] if true, do an interruptible wait * @timeout: [in] timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT + * @idx: [out] the first signaled fence index, meaninful only on Returns positive * * Returns -EINVAL on custom fence wait implementation, -ERESTARTSYS if * interrupted, 0 if the wait timed out, or the remaining timeout in jiffies @@ -427,7 +431,7 @@ fence_test_signaled_any(struct fence **fences, uint32_t count) */ signed long fence_wait_any_timeout(struct fence **fences, uint32_t count, - bool intr, signed long timeout) + bool intr, signed long timeout, uint32_t *idx) { struct default_wait_cb *cb; signed long ret = timeout; @@ -438,8 +442,11 @@ fence_wait_any_timeout(struct fence **fences, uint32_t count, if (timeout == 0) { for (i = 0; i < count; ++i) - if (fence_is_signaled(fences[i])) + if (fence_is_signaled(fences[i])) { + if (idx) + *idx = i; return 1; + } return 0; } @@ -462,6 +469,8 @@ fence_wait_any_timeout(struct fence **fences, uint32_t count, if (fence_add_callback(fence, &cb[i].base, fence_default_wait_cb)) { /* This fence is already signaled */ + if (idx) + *idx = i; goto fence_rm_cb; } } @@ -472,7 +481,7 @@ fence_wait_any_timeout(struct fence **fences, uint32_t count, else set_current_state(TASK_UNINTERRUPTIBLE); - if (fence_test_signaled_any(fences, count)) + if (fence_test_signaled_any(fences, count, idx)) break; ret = schedule_timeout(ret); diff --git a/include/linux/fence.h b/include/linux/fence.h index 44d945e..6a7e68a 100644 --- a/include/linux/fence.h +++ b/include/linux/fence.h @@ -327,7 +327,7 @@ static inline struct fence *fence_later(struct fence *f1, struct fence *f2) signed long fence_wait_timeout(struct fence *, bool intr, signed long timeout); signed long fence_wait_any_timeout(struct fence **fences, uint32_t count, - bool intr, signed long timeout); + bool intr, signed long timeout, uint32_t *idx); /** * fence_wait - sleep until the fence gets signaled -- 2.5.5

3 6

linux-next: manual merge of the mali-dp tree with the drm-misc tree
by Stephen Rothwell 04 Nov '16

04 Nov '16

Hi Liviu, Today's linux-next merge of the mali-dp tree got a conflict in: drivers/gpu/drm/arm/malidp_planes.c between commit: ea0e1ce20f73 ("drm/arm: Use per-plane rotation property") from the drm-misc tree and commit: 9ebb89762c30 ("drm: mali-dp: Refactor plane initialisation") from the mali-dp tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/gpu/drm/arm/malidp_planes.c index abaca03b9d36,9020c0d8399c..000000000000 --- a/drivers/gpu/drm/arm/malidp_planes.c +++ b/drivers/gpu/drm/arm/malidp_planes.c @@@ -254,23 -284,33 +284,30 @@@ int malidp_de_planes_init(struct drm_de if (ret < 0) goto cleanup; + drm_plane_helper_add(&plane->base, + &malidp_de_plane_helper_funcs); + plane->hwdev = malidp->dev; + plane->layer = &map->layers[i]; + + /* Skip the features which the SMART layer doesn't have */ + if (id == DE_SMART) + continue; + - if (!drm->mode_config.rotation_property) { + /* SMART layer can't be rotated */ + if (id != DE_SMART) { unsigned long flags = DRM_ROTATE_0 | DRM_ROTATE_90 | DRM_ROTATE_180 | DRM_ROTATE_270 | DRM_REFLECT_X | DRM_REFLECT_Y; - drm->mode_config.rotation_property = - drm_mode_create_rotation_property(drm, flags); + drm_plane_create_rotation_property(&plane->base, + DRM_ROTATE_0, + flags); } - drm_plane_helper_add(&plane->base, - &malidp_de_plane_helper_funcs); - plane->hwdev = malidp->dev; - plane->layer = &map->layers[i]; - if (drm->mode_config.rotation_property) - drm_object_attach_property(&plane->base.base, - drm->mode_config.rotation_property, - DRM_ROTATE_0); - + malidp_hw_write(malidp->dev, MALIDP_ALPHA_LUT, + plane->layer->base + MALIDP_LAYER_COMPOSE); } kfree(formats);

2 5

Ping: [PATCH] radeon: avoid boot hang in Xen Dom0
by Jan Beulich 04 Nov '16

04 Nov '16

>>> On 13.09.16 at 17:54, wrote: > While a hard hang in atom_asic_init() likely points at a deeper problem > in the driver, restore the capability to boot a Xen Dom0 by simply > avoiding the call there: Other than for Xen DomU, Dom0 owning a device > does not really mean is has got passed through to it. > > In case it is of interest for further investigation, lspci for the > offending device says: > > ATI Technologies Inc RS480 [Radeon Xpress 200G Series] [1002:5954] > > Fixes: 05082b8bbd "drm/radeon: fix asic initialization for virtualized environments" I may have overlooked a different fix dealing with the problem; if so, I'd appreciate that fix being pointed out. Thanks, Jan > Signed-off-by: Jan Beulich <jbeulich(a)suse.com> > --- > drivers/gpu/drm/radeon/radeon_device.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > --- 4.8-rc6/drivers/gpu/drm/radeon/radeon_device.c > +++ 4.8-rc6-radeon-Xen-boot/drivers/gpu/drm/radeon/radeon_device.c > @@ -34,6 +34,7 @@ > #include <linux/vgaarb.h> > #include <linux/vga_switcheroo.h> > #include <linux/efi.h> > +#include <xen/xen.h> > #include "radeon_reg.h" > #include "radeon.h" > #include "atom.h" > @@ -642,7 +643,7 @@ void radeon_gtt_location(struct radeon_d > static bool radeon_device_is_virtual(void) > { > #ifdef CONFIG_X86 > - return boot_cpu_has(X86_FEATURE_HYPERVISOR); > + return boot_cpu_has(X86_FEATURE_HYPERVISOR) && !xen_initial_domain(); > #else > return false; > #endif > > >

2 2

[Bug 97643] Shader crashes radeon driver and brings the whole system down
by bugzilla-daemon＠freedesktop.org 04 Nov '16

04 Nov '16

https://bugs.freedesktop.org/show_bug.cgi?id=97643 Cris <cristiano04(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|REOPENED |RESOLVED --- Comment #11 from Cris <cristiano04(a)gmail.com> --- No longer an issue. Recompiled llvm-git and mesa-git and everything works fine with no frame drops, including lower resolution videos (which were grinding everything to a halt). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[drm/qxl 0/6] Various cleanups/fixes
by Christophe Fergeau 04 Nov '16

04 Nov '16

Hey, This patch series starts by doing some various small cleanups (patch 1 to 4), and then there are 2 fixes for issues which were noticed in fedora 25, the more annoying one being the one fixed by patch 5 where the VM screen would constantly flicker when wayland is used. Patch 6 is very hacky, I'm not familiar at all with that code, so I don't know what is the correct way of doing it. Christophe

4 18

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2016