Re: [Intel-gfx] [PATCH] drm/i915: Skip CPU synchronisation on dmabuf attachments

The patch is here: https://lists.freedesktop.org/archives/intel-gfx/2017-November/148988.html On Mon, Feb 10, 2020 at 11:34:07AM -0800, Dongwon Kim wrote: > Acked-by: Dongwon Kim > > It makes lots of sense to make CPU cache operation done only when > needed. Similar change was al

Re: [Intel-gfx] [PATCH] drm/i915: Skip CPU synchronisation on dmabuf attachments

(mistakenly put a wrong message id in "In-reply-To") Acked-by: Dongwon Kim It makes lots of sense to make CPU cache operation done only when needed. Similar change was already landed in drm-prime and other vendor specific drivers. We are actually seeing huge performance boost in

Re: [Intel-gfx] [PATCH] drm/i915: Skip CPU synchronisation on dmabuf attachments

Acked-by: Dongwon Kim It makes lots of sense to make CPU cache operation done only when needed. Similar change was already landed in drm-prime and other vendor specific drivers. We are actually seeing huge performance boost in a specific customer case where dmabuf was used between camera driver

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: enable support for headerless msgs (rev4)

Chris, This patch apparently passed the regression test. Can you please help this move forward to the merging process? On Tue, May 07, 2019 at 11:41:10PM -0700, Peres, Martin wrote: > On 06/05/2019 23:30, Kim, Dongwon wrote: > > This doesn't seem to be a valid failure. I just reran the test

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: enable support for headerless msgs (rev4)

This doesn't seem to be a valid failure. I just reran the test using trybot and there were no failures. https://lists.freedesktop.org/archives/intel-gfx-trybot/2019-May/071989.html On Thu, Apr 25, 2019 at 07:54:51AM +, intel-gfx-requ...@lists.freedesktop.org wrote: > Date: Thu, 25 Apr 2019

[Intel-gfx] [PATCH v3] drm/i915/gen11: enable support for headerless msgs

complies with the new recommendation for the default bit value for the next gen. v2: rewrote commit message to include more information v3: setting the bit in icl_ctx_workarounds_init() Signed-off-by: Dongwon Kim --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915

[Intel-gfx] [PATCH] drm/i915/gen11: enable support for headerless msgs

complies with the new recommendation for the default bit value for the next gen. v2: rewrote commit message to include more information Signed-off-by: Dongwon Kim --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_lrc.c | 18 ++ 2 files changed, 19 insertions

[Intel-gfx] [PATCH] drm/i915/gen11: enable support for headerless msgs

set bit5 (Headerless Message for Pre-emptable Contexts) in SAMPLER_MODE register while initializing render ring to enable support for headerless messages for preemptable GPGPU contexts on Gen11. Signed-off-by: Dongwon Kim --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915

Re: [Intel-gfx] [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

On Wed, Dec 20, 2017 at 10:59:57AM +0100, Daniel Vetter wrote: > On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote: > > I forgot to include this brief information about this patch series. > > > > This patch series contains the implementation of a new device dri

Re: [Intel-gfx] [PATCH 03/24] drm/i915: Store i915_gem_object_is_coherent() as a bit next to cache-dirty

Chris, I tested this together with your v3 (Mark cache dirty...) patch and verified tests are all passing. Tested-by : Dongwon Kim <dongwon@intel.com> On Thu, May 18, 2017 at 10:46:17AM +0100, Chris Wilson wrote: > For ease of use (i.e. avoiding a few checks and function call

Re: [Intel-gfx] [PATCH] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

Chris, This patch works now as we unconditionally set cache_dirty in set_cache_level function. Tested-by: Dongwon Kim <dongwon@intel.com> On Wed, May 17, 2017 at 04:05:24PM +0100, Chris Wilson wrote: > Currently, we only mark the CPU cache as dirty if we skip a clflush. >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

_coherent = i915_gem_object_is_coherent(obj); obj->cache_level = cache level; , I see all tests are passing.. -DW On Sat, Apr 29, 2017 at 09:43:52AM +0100, Chris Wilson wrote: > On Fri, Apr 28, 2017 at 03:55:56PM -0700, Dongwon Kim wrote: > > Hi Chris, > > > > I tried this but I still see

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

work on llc systems that migrate dirty > buffers back and forth - but we do try to limit that by only setting > cache_dirty at the end of the gpu sequence. > > Reported-by: Dongwon Kim <dongwon@intel.com> > Fixes: a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

Chris, I am sorry that I didn't tell you about GPU that I am working on. It is GEN9LP. Our target is APL-I. So no LLC is available. On Wed, Apr 19, 2017 at 07:26:29PM +0100, Chris Wilson wrote: > On Wed, Apr 19, 2017 at 11:13:17AM -0700, Dongwon Kim wrote: > > Chris, > > > &

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

+0100, Chris Wilson wrote: > On Wed, Apr 19, 2017 at 11:13:17AM -0700, Dongwon Kim wrote: > > Chris, > > > > Just to make sure, you want to just remove write_domain check from > > if statement before clflush in execbuffer_move_to_gpu. Am I right? > > I will tr

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

lson wrote: > On Wed, Apr 19, 2017 at 09:52:28AM -0700, Dongwon Kim wrote: > > I tried your patch but it didn't fix the original > > problem. I think it is somehow related to the flushing condition > > here: > > > > @@ -1129,10 +1129,8 @@ i915_gem_execbuffer_move_to

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

t; The goal remains to do as few clflushes as required and to do them as > late as possible, in the hope of deferring the work to a kthread and not > block the caller (e.g. execbuf, flips). > > Reported-by: Dongwon Kim <dongwon@intel.com> > Fixes: a6a7cc4b7db6 ("drm/i915: Alway

[Intel-gfx] [PATCH] drm/i915/bxt: PORT_PLL_REF_SEL bit should be set for all BXT variations.

This patch is to correct one thing in this commit: commit 25a56705332add0363e47b3a0eca001d6fbd5bec Author: Dongwon Kim <dongwon@intel.com> Date: Wed Mar 16 18:06:13 2016 -0700 drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit For BXT, description of pola

[Intel-gfx] [PATCH v2] drm/i915/Gen9+: optional IPC enablement

With IPC(Isochronous Priority Control) enabled, display sends requests based on the priority of each request. To enable it, a i915 param, i915.enable_ipc should be set to 1. v2: corrected matched type of enable_ipc in module_param_named_unsafe macro Signed-off-by: Dongwon Kim <dong

[Intel-gfx] [PATCH] drm/i915/Gen9+: optional IPC enablement

With IPC(Isochronous Priority Control) enabled, display sends requests based on the priority of each request. To enable it, a i915 param, i915.enable_ipc should be set to 1. Signed-off-by: Dongwon Kim <dongwon@intel.com> --- drivers/gpu/drm/i915/i915_params.c | 5 + drivers/gpu/dr

[Intel-gfx] [PATCH] drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit

his change. Signed-off-by: Dongwon Kim <dongwon@intel.com> --- drivers/gpu/drm/i915/intel_dpll_mgr.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c b/drivers/gpu/drm/i915/intel_dpll_mgr.c index 4b636c4..c84589e 100644 -

[Intel-gfx] [PATCH] drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit

For BXT, Polarity of PORT_PLL_REF_SEL is reversed in its description in Bspec. This bit should be set for "Non-SSC". Signed-off-by: Dongwon Kim <dongwon@intel.com> --- drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a

[Intel-gfx] [PATCH] drm/i915: Do not hardcode s_max, ss_max and eu_mask for BXT

We can calculate BXT values correctly from GFX fuse values without hardcoding special limits. Cc: Imre Deak <imre.d...@intel.com> Cc: Matthew D Roper <matthew.d.ro...@intel.com> signed-off-by: Dongwon Kim <dongwon@intel.com> --- drivers/gpu/drm/i915/i915_dma.c | 11 -

[Intel-gfx] [PATCH] drm/i915: fixing eu_mask value for BXT due to wrong bit mapping (v2)

From: dw kim Correct bit mapping of EUs in 'eu_disable' fuse register for each subslice is (each word represents one subslice), bit # 7 6 5 4 3 2 1 0 EU # 11 10 9 8 3 2 1 0 In BXT, each subslice has 6 EUs at most, which are EU0~EU2 and EU8~EU10

[Intel-gfx] [PATCH] fixing eu_mask value for BXT due to wrong bit mapping

From: dw kim Correct bit mapping of EUs in 'eu_disable' fuse register for each subslice is (each word represents one subslice), bit # 7 6 5 4 3 2 1 0 EU # 11 10 9 8 3 2 1 0 In BXT, each subslice has 6 EUs at most, which are EU0~EU2 and EU8~EU10