dri-devel April 2018

dri-devel@lists.freedesktop.org

267 participants
1852 discussions

[PATCH 0/5] Adreno A6xx system cache support
by Sharat Masetty 05 Apr '18

05 Apr '18

Some hardware variants contain a system level cache or the last level cache(llc). This cache is typically a large block which is shared by multiple clients on the SOC. GPU uses the system cache to cache both the GPU data buffers(like textures) as well the SMMU pagetables. This helps with improved render performance as well as lower power consumption by reducing the bus traffic to the system memory. The system cache architecture allows the cache to be split into slices which then be used by multiple SOC clients. This patch series is an effort to enable and use two of those slices perallocated for the GPU, one for the GPU data buffers and another for the GPU SMMU hardware pagetables. This patchseries depends on the core llcc driver which was submitted to the mailing list: https://patchwork.kernel.org/patch/10184935/ and SMMU support for upstream hint which will be posted to the lists soon by Vivek. Sharat Masetty (5): drm/msm: rearrange the gpu_rmw() function arm64:dts:sdm845: Add support for GPU LLCC drm/msm/adreno: Add registers in the GPU CX domain drm/msm: Pass mmu features to generic layers drm/msm/A6xx: Add support for using system cache(llc) arch/arm64/boot/dts/qcom/sdm845.dtsi | 8 +- drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a6xx.xml.h | 4 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 162 +++++++++++++++++++++++++++++++- drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 9 ++ drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 2 +- drivers/gpu/drm/msm/msm_drv.c | 8 ++ drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_gpu.c | 6 +- drivers/gpu/drm/msm/msm_gpu.h | 6 +- drivers/gpu/drm/msm/msm_iommu.c | 13 +++ drivers/gpu/drm/msm/msm_mmu.h | 16 ++++ 15 files changed, 231 insertions(+), 14 deletions(-) -- 1.9.1

3 15

ww-mutex performance tests?
by Thomas Hellstrom 05 Apr '18

05 Apr '18

Maarten, Daniel, Do we have any ww-mutex performance tests somewhere that can be used to test the impact of implementation details on various locking scenarios? Thanks, /Thomas

4 4

[Bug 105680] [CI] igt@kms_frontbuffer_tracking@* - fail - FBC disabled: mode too large for compression
by bugzilla-daemon＠freedesktop.org 05 Apr '18

05 Apr '18

https://bugs.freedesktop.org/show_bug.cgi?id=105680 --- Comment #7 from Marta Löfstedt <marta.lofstedt(a)intel.com> --- (In reply to Jose Roberto de Souza from comment #6) > Done: https://patchwork.freedesktop.org/series/41156/ Thanks for the patch, we'll need a drmtip run to see if it works, since the affected machine doesn't run those test on regular basis in BAT. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 93216] Artifacts with DCC when render target also texture
by bugzilla-daemon＠freedesktop.org 05 Apr '18

05 Apr '18

https://bugs.freedesktop.org/show_bug.cgi?id=93216 Bug ID: 93216 Summary: Artifacts with DCC when render target also texture 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: axel.davy(a)ens.fr QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 120280 --> https://bugs.freedesktop.org/attachment.cgi?id=120280&action=edit Before a buggy draw call I noticed a few games had some strange artifacts on my tonga that I had not on verde. Those artifacts are usually along lines. These artifacts disappear with R600_DEBUG=nodcc. I managed to determine the bug appears when the render target is also used as input texture. Attached is the render target content before and after such draw call. The draw call draws two triangles. We can see the artifacts are along the border region of the top right triangle with the bottom left triangle. My guess is that it is some flush issue. That the bottom left triangle is drawn first, the cache content of the texture cache updated, and the artifacts are at locations where the dcc data was updated. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[DPU PATCH v2 0/2] Remove DPU RSC support
by Rajesh Yadav 05 Apr '18

05 Apr '18

MSM display controller hardware (DPU) has an inbuilt RSC block which can control power resources and bus bandwidth voting based on frame timing parameters w/o DPU driver intervention. In absence of RSC HW, DPU driver controls these resources. Downstream driver relies on RSC driver for controlling these resources (via RSC HW block) for better power benefits. Since, DPU driver can control these resources, removing RSC driver support. Corresponding devicetree binding are also removed. Details for DPU driver upstreaming: https://lists.freedesktop.org/archives/freedreno/2018-February/001678.html Changes in v2: - Remove last reference to dpu_power_rsc_update - Add DPU PATCH tag for better filtering - Rebase on tip of for-next-staging Rajesh Yadav (2): dt-bindings: msm/disp: Remove DPU RSC device bindings drm/msm: Remove RSC support from DPU driver .../devicetree/bindings/display/msm/dpu-rsc.txt | 96 -- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 130 +- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 6 - drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 14 - drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 9 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 242 +--- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 7 - drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h | 3 - drivers/gpu/drm/msm/dpu_dbg.c | 27 - drivers/gpu/drm/msm/dpu_dbg.h | 10 - drivers/gpu/drm/msm/dpu_power_handle.c | 73 +- drivers/gpu/drm/msm/dpu_power_handle.h | 4 - drivers/gpu/drm/msm/dpu_rsc.c | 1367 -------------------- drivers/gpu/drm/msm/dpu_rsc_hw.c | 818 ------------ drivers/gpu/drm/msm/dpu_rsc_priv.h | 191 --- include/linux/dpu_rsc.h | 302 ----- 18 files changed, 42 insertions(+), 3278 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu-rsc.txt delete mode 100644 drivers/gpu/drm/msm/dpu_rsc.c delete mode 100644 drivers/gpu/drm/msm/dpu_rsc_hw.c delete mode 100644 drivers/gpu/drm/msm/dpu_rsc_priv.h delete mode 100644 include/linux/dpu_rsc.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

4 6

[Bug 105026] glxgears asserts with pp_jimenezmlaa=1
by bugzilla-daemon＠freedesktop.org 05 Apr '18

05 Apr '18

https://bugs.freedesktop.org/show_bug.cgi?id=105026 Bug ID: 105026 Summary: glxgears asserts with pp_jimenezmlaa=1 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: EoD(a)xmw.de QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 137249 --> https://bugs.freedesktop.org/attachment.cgi?id=137249&action=edit glxgears/mesa backtrace with -Og Any program asserts when pp_jimenezmlaa is enabled. For example glxgears. > gdb glxgears > (gdb) set environment pp_jimenezmlaa 1 > (gdb) run Might be a duplicate of bug 99549 -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 104034] Mesa/Radeonsi does not compile on musl due to endianess check
by bugzilla-daemon＠freedesktop.org 05 Apr '18

05 Apr '18

https://bugs.freedesktop.org/show_bug.cgi?id=104034 Bug ID: 104034 Summary: Mesa/Radeonsi does not compile on musl due to endianess check Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: lucas.francesco93(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org https://lists.freedesktop.org/archives/mesa-dev/2016-November/134355.html used to need to apply this patch and everything went fine(mainline still wasnt compiling patchless anyway) but recently the source files changed and the patch does not work anymore the patch fails to apply and if i build it without the patch i get In file included from /var/tmp/portage/media-libs/mesa-9999/work/mesa-9999/src/amd/addrlib/gfx9/gfx9addrlib.cpp:36:0: /var/tmp/portage/media-libs/mesa-9999/work/mesa-9999/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h:44:2: error: #error "BIGENDIAN_CPU or LITTLEENDIAN_CPU must be defined" #error "BIGENDIAN_CPU or LITTLEENDIAN_CPU must be defined" ^~~~~ which is the behavior i was having already w/o the patch since 2016 would you guys mindig fixing endianess dectection on musl libc? -- You are receiving this mail because: You are the assignee for the bug.

1 2

[PATCH] [RESEND] drm/i915/dp: Send DPCD ON for MST before phy_up
by Lyude Paul 04 Apr '18

04 Apr '18

As it turns out, the aux block being off was not the real problem here, as transition from D3 to D0 is mandated by the DP spec to take a maximum of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs. The real problem here is a bit more subtle. When doing a modeset where the problem of the sink timing out to our sideband requests when transitioning from D3 to D0 occurs, the timeout is from the aux block not coming on. However, nothing else times out other than the initial phy_up message because the DPCD on call in intel_ddi_enable_dp() ends up waking up the AUX block on the hub, not the phy_up sideband message. This means that the real fix we need is to use the DPMS on before sending a phy_up to ensure that the hub is ready to accept sideband messages. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- drivers/gpu/drm/i915/intel_ddi.c | 6 +++++- drivers/gpu/drm/i915/intel_dp_mst.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index a6672a9abd85..9bd675f73f7b 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -2324,7 +2324,11 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder, intel_prepare_dp_ddi_buffers(encoder, crtc_state); intel_ddi_init_dp_buf_reg(encoder); - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + /* for MST, we do DPMS_ON outside of here so that DPMS_ON can happen + * before drm_dp_send_power_updown_phy() + */ + if (!intel_dp->is_mst) + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_start_link_train(intel_dp); if (port != PORT_A || INTEL_GEN(dev_priv) >= 9) intel_dp_stop_link_train(intel_dp); diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index c3de0918ee13..eff9a4eae1f0 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -223,6 +223,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links); + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true); if (intel_dp->active_mst_links == 0) intel_dig_port->base.pre_enable(&intel_dig_port->base, -- 2.14.3

1 0

[Bug 105200] [r600g] Regression: ImageMagick OpenCL kernel no longer compiles
by bugzilla-daemon＠freedesktop.org 04 Apr '18

04 Apr '18

https://bugs.freedesktop.org/show_bug.cgi?id=105200 Bug ID: 105200 Summary: [r600g] Regression: ImageMagick OpenCL kernel no longer compiles Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: nixscripter(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 137519 --> https://bugs.freedesktop.org/attachment.cgi?id=137519&action=edit The ImageMagick OpenCL Kernel LLVM svn version: 325439 Mesa version: git fa8a764b62 The last version that worked was several weeks ago -- prior to the LLVM 6 branch. The log is so short, I can paste it in here: build options: -cl-single-precision-constant -cl-mad-enable -DMAGICKCORE_HDRI_SUPPORT=1 -DCLQuantum=float -DCLSignedQuantum=float -DCLPixelType=float4 -DQuantumRange=65535.000000 -DQuantumScale=0.000015 -DCharQuantumScale=1.000000 -DMagickEpsilon=0.000000 -DMagickPI=3.141593 -DMaxMap=65535 -DMAGICKCORE_QUANTUM_DEPTH=16 <unknown>:0:0: in function AddNoise void (<4 x float> addrspace(1)*, <4 x float> addrspace(1)*, i32, i32, i32, i32, float, i32, i32, i32): unsupported initializer for address space The unknown is because I have a stripped binary. I have not done all the manual rebuilds for the symbols yet. The actual kernel being compiled is attached. Hopefully it should be obvious enough what the problem is. -- You are receiving this mail because: You are the assignee for the bug.

1 13

[PATCH 1/1] drm/i915: Do not use kfree() to free kmem_cache_alloc() return value
by Xidong Wang 04 Apr '18

04 Apr '18

In eb_lookup_vmas(), the return value of kmem_cache_alloc() is freed with kfree(). I think the expected paired function is kmem_cahce_free(). Signed-off-by: Xidong Wang <wangxidong_97(a)163.com> --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 8c170db..0414228 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -728,7 +728,7 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) err = radix_tree_insert(handles_vma, handle, vma); if (unlikely(err)) { - kfree(lut); + kmem_cache_free(eb->i915->luts, lut); goto err_obj; } -- 2.7.4

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2018