On Wed, 21 Apr 2021 at 20:13, Matthew Auld
<matthew.william.auld@xxxxxxxxx> wrote:
>
> On Wed, 21 Apr 2021 at 16:41, Tvrtko Ursulin
> <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote:
> >
> >
> > On 21/04/2021 12:42, Matthew Auld wrote:
> > > On 19/04/2021 16:01, Tvrtko Ursulin wrote:
> > >>
> > >> On 19/04/2021 15:37, Matthew Auld wrote:
> > >>> On 19/04/2021 15:07, Tvrtko Ursulin wrote:
> > >>>>
> > >>>> On 19/04/2021 12:30, Matthew Auld wrote:
> > >>>>> On 15/04/2021 12:05, Tvrtko Ursulin wrote:
> > >>>>>>
> > >>>>>> On 15/04/2021 10:23, Matthew Auld wrote:
> > >>>>>>> On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
> > >>>>>>> <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote:
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On 14/04/2021 17:20, Matthew Auld wrote:
> > >>>>>>>>> On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
> > >>>>>>>>> <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On 12/04/2021 10:05, Matthew Auld wrote:
> > >>>>>>>>>>> From: Venkata Sandeep Dhanalakota
> > >>>>>>>>>>> <venkata.s.dhanalakota@xxxxxxxxx>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Determine the possible coherent map type based on object
> > >>>>>>>>>>> location,
> > >>>>>>>>>>> and if target has llc or if user requires an always coherent
> > >>>>>>>>>>> mapping.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Cc: Matthew Auld <matthew.auld@xxxxxxxxx>
> > >>>>>>>>>>> Cc: CQ Tang <cq.tang@xxxxxxxxx>
> > >>>>>>>>>>> Suggested-by: Michal Wajdeczko <michal.wajdeczko@xxxxxxxxx>
> > >>>>>>>>>>> Signed-off-by: Venkata Sandeep Dhanalakota
> > >>>>>>>>>>> <venkata.s.dhanalakota@xxxxxxxxx>
> > >>>>>>>>>>> ---
> > >>>>>>>>>>> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 ++-
> > >>>>>>>>>>> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
> > >>>>>>>>>>> drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
> > >>>>>>>>>>> drivers/gpu/drm/i915/gt/intel_ring.c | 9 ++++++---
> > >>>>>>>>>>> drivers/gpu/drm/i915/gt/selftest_context.c | 3 ++-
> > >>>>>>>>>>> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++--
> > >>>>>>>>>>> drivers/gpu/drm/i915/gt/selftest_lrc.c | 4 +++-
> > >>>>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +++-
> > >>>>>>>>>>> drivers/gpu/drm/i915/gt/uc/intel_huc.c | 4 +++-
> > >>>>>>>>>>> drivers/gpu/drm/i915/i915_drv.h | 11
> > >>>>>>>>>>> +++++++++--
> > >>>>>>>>>>> drivers/gpu/drm/i915/selftests/igt_spinner.c | 4 ++--
> > >>>>>>>>>>> 11 files changed, 36 insertions(+), 16 deletions(-)
> > >>>>>>>>>>>
> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > >>>>>>>>>>> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > >>>>>>>>>>> index efe935f80c1a..b79568d370f5 100644
> > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > >>>>>>>>>>> @@ -664,7 +664,8 @@ static int init_status_page(struct
> > >>>>>>>>>>> intel_engine_cs *engine)
> > >>>>>>>>>>> if (ret)
> > >>>>>>>>>>> goto err;
> > >>>>>>>>>>>
> > >>>>>>>>>>> - vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
> > >>>>>>>>>>> + vaddr = i915_gem_object_pin_map(obj,
> > >>>>>>>>>>> + i915_coherent_map_type(engine->i915, obj, true));
> > >>>>>>>>>>> if (IS_ERR(vaddr)) {
> > >>>>>>>>>>> ret = PTR_ERR(vaddr);
> > >>>>>>>>>>> goto err_unpin;
> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > >>>>>>>>>>> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > >>>>>>>>>>> index 7c9af86fdb1e..47f4397095e5 100644
> > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > >>>>>>>>>>> @@ -23,7 +23,7 @@ static void dbg_poison_ce(struct
> > >>>>>>>>>>> intel_context *ce)
> > >>>>>>>>>>>
> > >>>>>>>>>>> if (ce->state) {
> > >>>>>>>>>>> struct drm_i915_gem_object *obj =
> > >>>>>>>>>>> ce->state->obj;
> > >>>>>>>>>>> - int type =
> > >>>>>>>>>>> i915_coherent_map_type(ce->engine->i915);
> > >>>>>>>>>>> + int type =
> > >>>>>>>>>>> i915_coherent_map_type(ce->engine->i915, obj, true);
> > >>>>>>>>>>> void *map;
> > >>>>>>>>>>>
> > >>>>>>>>>>> if (!i915_gem_object_trylock(obj))
> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > >>>>>>>>>>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > >>>>>>>>>>> index e86897cde984..aafe2a4df496 100644
> > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > >>>>>>>>>>> @@ -903,7 +903,9 @@ lrc_pre_pin(struct intel_context *ce,
> > >>>>>>>>>>> GEM_BUG_ON(!i915_vma_is_pinned(ce->state));
> > >>>>>>>>>>>
> > >>>>>>>>>>> *vaddr = i915_gem_object_pin_map(ce->state->obj,
> > >>>>>>>>>>> - i915_coherent_map_type(ce->engine->i915) |
> > >>>>>>>>>>> + i915_coherent_map_type(ce->engine->i915,
> > >>>>>>>>>>> + ce->state->obj,
> > >>>>>>>>>>> + false) |
> > >>>>>>>>>>> I915_MAP_OVERRIDE);
> > >>>>>>>>>>>
> > >>>>>>>>>>> return PTR_ERR_OR_ZERO(*vaddr);
> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
> > >>>>>>>>>>> b/drivers/gpu/drm/i915/gt/intel_ring.c
> > >>>>>>>>>>> index aee0a77c77e0..3cf6c7e68108 100644
> > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/intel_ring.c
> > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/intel_ring.c
> > >>>>>>>>>>> @@ -53,9 +53,12 @@ int intel_ring_pin(struct intel_ring
> > >>>>>>>>>>> *ring, struct i915_gem_ww_ctx *ww)
> > >>>>>>>>>>>
> > >>>>>>>>>>> if (i915_vma_is_map_and_fenceable(vma))
> > >>>>>>>>>>> addr = (void __force *)i915_vma_pin_iomap(vma);
> > >>>>>>>>>>> - else
> > >>>>>>>>>>> - addr = i915_gem_object_pin_map(vma->obj,
> > >>>>>>>>>>> - i915_coherent_map_type(vma->vm->i915));
> > >>>>>>>>>>> + else {
> > >>>>>>>>>>> + int type =
> > >>>>>>>>>>> i915_coherent_map_type(vma->vm->i915, vma->obj, false);
> > >>>>>>>>>>> +
> > >>>>>>>>>>> + addr = i915_gem_object_pin_map(vma->obj, type);
> > >>>>>>>>>>> + }
> > >>>>>>>>>>> +
> > >>>>>>>>>>> if (IS_ERR(addr)) {
> > >>>>>>>>>>> ret = PTR_ERR(addr);
> > >>>>>>>>>>> goto err_ring;
> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
> > >>>>>>>>>>> b/drivers/gpu/drm/i915/gt/selftest_context.c
> > >>>>>>>>>>> index b9bdd1d23243..26685b927169 100644
> > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/selftest_context.c
> > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/selftest_context.c
> > >>>>>>>>>>> @@ -88,7 +88,8 @@ static int __live_context_size(struct
> > >>>>>>>>>>> intel_engine_cs *engine)
> > >>>>>>>>>>> goto err;
> > >>>>>>>>>>>
> > >>>>>>>>>>> vaddr = i915_gem_object_pin_map_unlocked(ce->state->obj,
> > >>>>>>>>>>> - i915_coherent_map_type(engine->i915));
> > >>>>>>>>>>> + i915_coherent_map_type(engine->i915,
> > >>>>>>>>>>> + ce->state->obj, false));
> > >>>>>>>>>>> if (IS_ERR(vaddr)) {
> > >>>>>>>>>>> err = PTR_ERR(vaddr);
> > >>>>>>>>>>> intel_context_unpin(ce);
> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> > >>>>>>>>>>> b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> > >>>>>>>>>>> index 746985971c3a..5b63d4df8c93 100644
> > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> > >>>>>>>>>>> @@ -69,7 +69,7 @@ static int hang_init(struct hang *h, struct
> > >>>>>>>>>>> intel_gt *gt)
> > >>>>>>>>>>> h->seqno = memset(vaddr, 0xff, PAGE_SIZE);
> > >>>>>>>>>>>
> > >>>>>>>>>>> vaddr = i915_gem_object_pin_map_unlocked(h->obj,
> > >>>>>>>>>>> - i915_coherent_map_type(gt->i915));
> > >>>>>>>>>>> + i915_coherent_map_type(gt->i915, h->obj, false));
> > >>>>>>>>>>> if (IS_ERR(vaddr)) {
> > >>>>>>>>>>> err = PTR_ERR(vaddr);
> > >>>>>>>>>>> goto err_unpin_hws;
> > >>>>>>>>>>> @@ -130,7 +130,7 @@ hang_create_request(struct hang *h,
> > >>>>>>>>>>> struct intel_engine_cs *engine)
> > >>>>>>>>>>> return ERR_CAST(obj);
> > >>>>>>>>>>> }
> > >>>>>>>>>>>
> > >>>>>>>>>>> - vaddr = i915_gem_object_pin_map_unlocked(obj,
> > >>>>>>>>>>> i915_coherent_map_type(gt->i915));
> > >>>>>>>>>>> + vaddr = i915_gem_object_pin_map_unlocked(obj,
> > >>>>>>>>>>> i915_coherent_map_type(gt->i915, obj, false));
> > >>>>>>>>>>> if (IS_ERR(vaddr)) {
> > >>>>>>>>>>> i915_gem_object_put(obj);
> > >>>>>>>>>>> i915_vm_put(vm);
> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > >>>>>>>>>>> b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > >>>>>>>>>>> index 85e7df6a5123..d8f6623524e8 100644
> > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > >>>>>>>>>>> @@ -1221,7 +1221,9 @@ static int compare_isolation(struct
> > >>>>>>>>>>> intel_engine_cs *engine,
> > >>>>>>>>>>> }
> > >>>>>>>>>>>
> > >>>>>>>>>>> lrc = i915_gem_object_pin_map_unlocked(ce->state->obj,
> > >>>>>>>>>>> - i915_coherent_map_type(engine->i915));
> > >>>>>>>>>>> + i915_coherent_map_type(engine->i915,
> > >>>>>>>>>>> + ce->state->obj,
> > >>>>>>>>>>> + false));
> > >>>>>>>>>>> if (IS_ERR(lrc)) {
> > >>>>>>>>>>> err = PTR_ERR(lrc);
> > >>>>>>>>>>> goto err_B1;
> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > >>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > >>>>>>>>>>> index 78305b2ec89d..adae04c47aab 100644
> > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > >>>>>>>>>>> @@ -682,7 +682,9 @@ int intel_guc_allocate_and_map_vma(struct
> > >>>>>>>>>>> intel_guc *guc, u32 size,
> > >>>>>>>>>>> if (IS_ERR(vma))
> > >>>>>>>>>>> return PTR_ERR(vma);
> > >>>>>>>>>>>
> > >>>>>>>>>>> - vaddr = i915_gem_object_pin_map_unlocked(vma->obj,
> > >>>>>>>>>>> I915_MAP_WB);
> > >>>>>>>>>>> + vaddr = i915_gem_object_pin_map_unlocked(vma->obj,
> > >>>>>>>>>>> + i915_coherent_map_type(guc_to_gt(guc)->i915,
> > >>>>>>>>>>> + vma->obj, true));
> > >>>>>>>>>>> if (IS_ERR(vaddr)) {
> > >>>>>>>>>>> i915_vma_unpin_and_release(&vma, 0);
> > >>>>>>>>>>> return PTR_ERR(vaddr);
> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> > >>>>>>>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> > >>>>>>>>>>> index 2126dd81ac38..56d2144dc6a0 100644
> > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> > >>>>>>>>>>> @@ -82,7 +82,9 @@ static int intel_huc_rsa_data_create(struct
> > >>>>>>>>>>> intel_huc *huc)
> > >>>>>>>>>>> if (IS_ERR(vma))
> > >>>>>>>>>>> return PTR_ERR(vma);
> > >>>>>>>>>>>
> > >>>>>>>>>>> - vaddr = i915_gem_object_pin_map_unlocked(vma->obj,
> > >>>>>>>>>>> I915_MAP_WB);
> > >>>>>>>>>>> + vaddr = i915_gem_object_pin_map_unlocked(vma->obj,
> > >>>>>>>>>>> + i915_coherent_map_type(gt->i915,
> > >>>>>>>>>>> + vma->obj, true));
> > >>>>>>>>>>> if (IS_ERR(vaddr)) {
> > >>>>>>>>>>> i915_vma_unpin_and_release(&vma, 0);
> > >>>>>>>>>>> return PTR_ERR(vaddr);
> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > >>>>>>>>>>> b/drivers/gpu/drm/i915/i915_drv.h
> > >>>>>>>>>>> index 69e43bf91a15..2abbc06712a4 100644
> > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/i915_drv.h
> > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
> > >>>>>>>>>>> @@ -78,6 +78,7 @@
> > >>>>>>>>>>> #include "gem/i915_gem_context_types.h"
> > >>>>>>>>>>> #include "gem/i915_gem_shrinker.h"
> > >>>>>>>>>>> #include "gem/i915_gem_stolen.h"
> > >>>>>>>>>>> +#include "gem/i915_gem_lmem.h"
> > >>>>>>>>>>>
> > >>>>>>>>>>> #include "gt/intel_engine.h"
> > >>>>>>>>>>> #include "gt/intel_gt_types.h"
> > >>>>>>>>>>> @@ -1921,9 +1922,15 @@ static inline int
> > >>>>>>>>>>> intel_hws_csb_write_index(struct drm_i915_private *i915)
> > >>>>>>>>>>> }
> > >>>>>>>>>>>
> > >>>>>>>>>>> static inline enum i915_map_type
> > >>>>>>>>>>> -i915_coherent_map_type(struct drm_i915_private *i915)
> > >>>>>>>>>>> +i915_coherent_map_type(struct drm_i915_private *i915,
> > >>>>>>>>>>> + struct drm_i915_gem_object *obj, bool
> > >>>>>>>>>>> always_coherent)
> > >>>>>>>>>>> {
> > >>>>>>>>>>> - return HAS_LLC(i915) ? I915_MAP_WB : I915_MAP_WC;
> > >>>>>>>>>>> + if (i915_gem_object_is_lmem(obj))
> > >>>>>>>>>>> + return I915_MAP_WC;
> > >>>>>>>>>>> + if (HAS_LLC(i915) || always_coherent)
> > >>>>>>>>>>> + return I915_MAP_WB;
> > >>>>>>>>>>> + else
> > >>>>>>>>>>> + return I915_MAP_WC;
> > >>>>>>>>>>
> > >>>>>>>>>> Seems this patch is doing two things.
> > >>>>>>>>>>
> > >>>>>>>>>> First it is adding lmem support to this helper by always
> > >>>>>>>>>> returning WC
> > >>>>>>>>>> for lmem objects.
> > >>>>>>>>>>
> > >>>>>>>>>> Secondly it is introducing an idea of "always coherent" in a
> > >>>>>>>>>> helper
> > >>>>>>>>>> called i915_coherent_map_type. Could someone explain what is
> > >>>>>>>>>> coherent vs
> > >>>>>>>>>> always coherent?
> > >>>>>>>>>>
> > >>>>>>>>>> And also, why is always coherent happy with WB? Sounds counter
> > >>>>>>>>>> intuitive
> > >>>>>>>>>> to me.
> > >>>>>>>>>
> > >>>>>>>>> All this does is try to keep the existing behaviour intact, whilst
> > >>>>>>>>> also ensuring that all lmem objects are mapped using only WC, no
> > >>>>>>>>> matter what. The always_coherent=true thing is for the existing
> > >>>>>>>>> places
> > >>>>>>>>> where we sometimes map the object using WB, without first
> > >>>>>>>>> considering
> > >>>>>>>>> whether the device has the fast shared LLC vs snooping. Yes, it's
> > >>>>>>>>> slightly ugly :)
> > >>>>>>>>
> > >>>>>>>> Not fully following - if we had to write kerneldoc for
> > >>>>>>>> always_coherent
> > >>>>>>>> input argument - what it would say?
> > >>>>>>>
> > >>>>>>> @always_coherent - If true we should always try to map the object
> > >>>>>>> using WB. If false we should only map as WB if the device
> > >>>>>>> supports the
> > >>>>>>> fast shared LLC, in the case of snooped devices we will map use WC.
> > >>>>>>> Note that If the resource is lmem then we will always map as WC,
> > >>>>>>> regardless of the value of always_coherent, since that's all we
> > >>>>>>> currently support.
> > >>>>>>>
> > >>>>>>> Maybe the naming is poor?
> > >>>>>>
> > >>>>>> Maybe just confusing to me, not sure yet.
> > >>>>>>
> > >>>>>> So always_coherent is not about how the callers wants to use it,
> > >>>>>> but about platform knowledge? Or a performance concern for LLC vs
> > >>>>>> snooping cases? Does WB works (coherently) on snooping platforms?
> > >>>>>
> > >>>>> The always_coherent=true is for the existing callers that want WB,
> > >>>>> regardless of LLC vs snooping.
> > >>>>>
> > >>>>> The other callers use the existing i915_coherent_map_type() which
> > >>>>> only gives out WB for LLC platforms.
> > >>>>>
> > >>>>> AFAIK, LLC vs snooping should offer the same in terms of coherency,
> > >>>>> but in terms of performance the shared LLC is much faster, and so
> > >>>>> for snooping platforms we choose to not enable WB everywhere.
> > >>>>>
> > >>>>> On top of that we now have lmem, but for that we only allow WC.
> > >>>>> This patch just rolls all of that into one helper, while keeping
> > >>>>> the existing behaviour unchanged.
> > >>>>
> > >>>> Thanks. But I am still struggling with the API. :(
> > >>>>
> > >>>> Is the introduction of always_coherent flag in the context of DG1
> > >>>> required even? AFAICT for lmem objects the flag is ignored so no?
> > >>>
> > >>> If we drop the flag/helper thing, then we need something like:
> > >>>
> > >>> type = WB;
> > >>> if (i915_gem_object_is_lmem(obj))
> > >>> type = WC;
> > >>>
> > >>> vaddr = i915_gem_object_pin_map(obj, type);
> > >>>
> > >>> In all the places where we currently do:
> > >>>
> > >>> vaddr = i915_gem_object_pin_map(obj, WB);
> > >>>
> > >>> Where obj can be lmem, so ctx, ring, guc etc. Is that better or
> > >>> worse? The existing i915_coherent_map_type() callers should work
> > >>> as-is, since DG1 is snooped. And this patch just extends that to
> > >>> cover all cases.
> > >>>
> > >>> Perhaps we need a new helper instead? Maybe you have a better idea?
> > >>
> > >> Not yet. Would it make sense to put something in kerneldoc about when
> > >> callers might choose always_coherent true vs false? In terms of
> > >> expected usage (frequency, simplicity?) and any rules with regards
> > >> when callers need to worry about flushing/ordering when there are
> > >> mixed read and writes?
> > >
> > > Hmmm, looking at this again, maybe for now we should just go with:
> > >
> > > type = WB;
> > > if (i915_gem_object_is_lmem(obj))
> > > type = WC;
> > >
> > > vaddr = i915_gem_object_pin_map(obj, type)
> > >
> > > Which is way less confusing, plus there are only a handful of places
> > > where we need this, so doesn't seem too bad?
> > >
> > > Alternatively, we could wrap that in something like:
> > >
> > > /* Returns WB for system memory, or WC for local memory */
> > > void *i915_gem_object_pin_map_default(obj);
> > >
> > > Thoughts?
> >
> > I went and looked at the use sites to try and figure it out.
> >
> > First thing, the bool always_coherent story is only relevant when we
> > decide to place some object in system memory. Otherwise mapping is
> > always WC so I guess our code needs to handle it anyway. Well, if the
> > assumption is that we can change the location of the objects and it all
> > just keeps working? Or that is not the goal?
>
> I guess your concern is that mapping as WC has different semantics,
> and that might somehow break the caller?
>
> >
> > Let see about the users (ignoring selftests):
> >
> > 1) lrc_reg_state and ring; always_coherent=false
> >
> > Update frequency medium and mostly write from the CPU side.
> >
> > They say always_coherent=false - which means they have to handle being
> > given a WC mapping anyway.
> >
> > What is the benefit of ever selecting WB here?
> >
> > 2) Engine status page; always_coherent=true
> >
> > Frequently read and written from the CPU and GPU so cost of snooping is
> > therefore fine? Apart from having to be ready to deal with WC anyway.
> >
> > 3) dbg_poison_ce; always_coherent=true
> >
> > Writes to lrc_reg_state once - meh. Could just as well always ask for WC.
> >
> > 4) intel_guc_allocate_and_map_vma; always_coherent=true
> >
> > This one has three users:
> >
> > a) guc_stage_desc_pool_create stage_desc_pool_vaddr
> >
> > This one seems write once at init.
> >
> > b) intel_guc_ct_init
> >
> > Use for CT communication so similar to CSB on engine status page in
> > principle. But code also has to deal with WC when object is in lmem.
> >
> > c) intel_guc_ads_create
> >
> > CPU appears to only write on init and GPU reset.
> >
> > 5) intel_huc_rsa_data_create; always_coheret=true
> >
> > Called from intel_huc_init so it appears write once from CPU. Not sure
> > why it would need a coherent mapping if that is correct.
> >
> > I think this exercise left me equally confused. Because flushing and
> > read-write ordering rules are different between WB and WC. And code
> > which accesses all these mappings either has to know which one is in
> > use, or does not care. For the latter case we have to be sure about for
> > every path.
>
> Users of pin_map() are generally meant to call flush_map() where
> appropriate, which should do the right thing for us. For WC it only
> needs to flush the wcb. For WB it's more complicated since that
> depends on if the object is considered coherent or not, if it is then
> we don't need to do anything, otherwise we need to clflush.
>
> Also note that we If we just map the buffer as WB, that by itself
> doesn't magically enable snooping for the pages AFAIK. We still have
> to tell the GPU that these pages are meant to be coherent, which we
> always do for LLC platforms I think, since the shared LLC is
> considered fast, whereas on snooping platforms, we don't enable this
> by default, and have this as CACHE_NONE instead(see shmem_object_init
> for example), and incur the cost of additional clflushing. Doing an
> explicit i915_gem_object_set_coherency(I915_CACHE_LLC) I think will
> mark the object as coherent for us. I think there are also some
> matching GTT bits for caching.
>
> Also for DG1 you apparently can't disable snooping, as per what Daniel
> was saying in another thread.
>
> >
> > The write on init / reset ones are easy enough and it doesn't really
> > matter for them to use the coherent helper.
> >
> > Lrc_reg_state as well I think can be WC with explicit flushing - it has
> > to on lmem, no?
>
> I doubt it has to be, since the GPU still just accesses it through the GTT.
>
> >
> > This leaves the status page (CSB, etc) and GuC CT. Those are frequent
> > R/W but also code has to be able to handle WC so what is the benefit of
> > WB? It ends up faster than if it was WC, considering explicit
> > flushes/barriers are still in there?
>
> No idea for GuC, but for the hwsp it's still in system memory, and is
> WB, even for discrete. Chris measured this to be more performant with
> our execlists submission path than say just sticking it in lmem, and
> mapping it as WC.
Ping? How should we proceed with this patch?
>
> >
> > Regards,
> >
> > Tvrtko
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
