| Message ID | 20190617181236.7981-24-tvrtko.ursulin@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Implicit dev_priv removal and GT compartmentalization | expand |
Quoting Tvrtko Ursulin (2019-06-17 19:12:26) > From: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > > Having introduced struct intel_gt (named the anonymous structure in i915) > we can start using it to compartmentalize our code better. It makes more > sense logically to have the code internally like this and it will also > help with future split between gt and display in i915. > > v2: > * Keep ggtt flush before fb obj flush. (Chris) > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > --- > drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++--- > .../drm/i915/gem/selftests/i915_gem_mman.c | 3 +- > drivers/gpu/drm/i915/gt/intel_gt.c | 41 +++++++++++++++++++ > drivers/gpu/drm/i915/gt/intel_gt.h | 2 + > drivers/gpu/drm/i915/i915_drv.h | 2 - > drivers/gpu/drm/i915/i915_gem.c | 40 ------------------ > drivers/gpu/drm/i915/i915_vma.c | 3 +- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- > 8 files changed, 54 insertions(+), 51 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c > index a4047a585c8b..f58d45ae10d0 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c > @@ -22,6 +22,7 @@ > * > */ > > +#include "gt/intel_gt.h" > #include "i915_drv.h" > #include "i915_gem_clflush.h" > #include "i915_gem_context.h" > @@ -367,7 +368,6 @@ void > i915_gem_object_flush_write_domain(struct drm_i915_gem_object *obj, > unsigned int flush_domains) > { > - struct drm_i915_private *dev_priv = to_i915(obj->base.dev); > struct i915_vma *vma; > > assert_object_held(obj); > @@ -377,17 +377,17 @@ i915_gem_object_flush_write_domain(struct drm_i915_gem_object *obj, > > switch (obj->write_domain) { > case I915_GEM_DOMAIN_GTT: > - i915_gem_flush_ggtt_writes(dev_priv); > - > - intel_fb_obj_flush(obj, > - fb_write_origin(obj, I915_GEM_DOMAIN_GTT)); > - > for_each_ggtt_vma(vma, obj) { > if (vma->iomap) > continue; > > + intel_gt_flush_ggtt_writes(vma->vm->gt); > i915_vma_unset_ggtt_write(vma); > + break; So we no longer flush writes from user GGTT mmaps, nor clear all the dirty bits? And now despite the move to be gt centric we end up assuming that it is still really device centric (breaking after one gt flush). -Chris
On 17/06/2019 21:01, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2019-06-17 19:12:26) >> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com> >> >> Having introduced struct intel_gt (named the anonymous structure in i915) >> we can start using it to compartmentalize our code better. It makes more >> sense logically to have the code internally like this and it will also >> help with future split between gt and display in i915. >> >> v2: >> * Keep ggtt flush before fb obj flush. (Chris) >> >> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> >> --- >> drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++--- >> .../drm/i915/gem/selftests/i915_gem_mman.c | 3 +- >> drivers/gpu/drm/i915/gt/intel_gt.c | 41 +++++++++++++++++++ >> drivers/gpu/drm/i915/gt/intel_gt.h | 2 + >> drivers/gpu/drm/i915/i915_drv.h | 2 - >> drivers/gpu/drm/i915/i915_gem.c | 40 ------------------ >> drivers/gpu/drm/i915/i915_vma.c | 3 +- >> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- >> 8 files changed, 54 insertions(+), 51 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c >> index a4047a585c8b..f58d45ae10d0 100644 >> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c >> @@ -22,6 +22,7 @@ >> * >> */ >> >> +#include "gt/intel_gt.h" >> #include "i915_drv.h" >> #include "i915_gem_clflush.h" >> #include "i915_gem_context.h" >> @@ -367,7 +368,6 @@ void >> i915_gem_object_flush_write_domain(struct drm_i915_gem_object *obj, >> unsigned int flush_domains) >> { >> - struct drm_i915_private *dev_priv = to_i915(obj->base.dev); >> struct i915_vma *vma; >> >> assert_object_held(obj); >> @@ -377,17 +377,17 @@ i915_gem_object_flush_write_domain(struct drm_i915_gem_object *obj, >> >> switch (obj->write_domain) { >> case I915_GEM_DOMAIN_GTT: >> - i915_gem_flush_ggtt_writes(dev_priv); >> - >> - intel_fb_obj_flush(obj, >> - fb_write_origin(obj, I915_GEM_DOMAIN_GTT)); >> - >> for_each_ggtt_vma(vma, obj) { >> if (vma->iomap) >> continue; >> >> + intel_gt_flush_ggtt_writes(vma->vm->gt); >> i915_vma_unset_ggtt_write(vma); >> + break; > > So we no longer flush writes from user GGTT mmaps, nor clear all the > dirty bits? And now despite the move to be gt centric we end up assuming > that it is still really device centric (breaking after one gt flush). I did not realize the significance of vma->iomap and the break was not supposed to be there, sneaked up after some back and forth refactoring. So it sounds like it needs to be two loops to preserve existing behaviour. Regards, Tvrtko
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index a4047a585c8b..f58d45ae10d0 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -22,6 +22,7 @@ * */ +#include "gt/intel_gt.h" #include "i915_drv.h" #include "i915_gem_clflush.h" #include "i915_gem_context.h" @@ -367,7 +368,6 @@ void i915_gem_object_flush_write_domain(struct drm_i915_gem_object *obj, unsigned int flush_domains) { - struct drm_i915_private *dev_priv = to_i915(obj->base.dev); struct i915_vma *vma; assert_object_held(obj); @@ -377,17 +377,17 @@ i915_gem_object_flush_write_domain(struct drm_i915_gem_object *obj, switch (obj->write_domain) { case I915_GEM_DOMAIN_GTT: - i915_gem_flush_ggtt_writes(dev_priv); - - intel_fb_obj_flush(obj, - fb_write_origin(obj, I915_GEM_DOMAIN_GTT)); - for_each_ggtt_vma(vma, obj) { if (vma->iomap) continue; + intel_gt_flush_ggtt_writes(vma->vm->gt); i915_vma_unset_ggtt_write(vma); + break; } + + intel_fb_obj_flush(obj, + fb_write_origin(obj, I915_GEM_DOMAIN_GTT)); break; case I915_GEM_DOMAIN_WC: diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c index 5c81f4b4813a..2812f7fa27fe 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c @@ -6,6 +6,7 @@ #include <linux/prime_numbers.h> +#include "gt/intel_gt.h" #include "gt/intel_gt_pm.h" #include "huge_gem_object.h" #include "i915_selftest.h" @@ -143,7 +144,7 @@ static int check_partial_mapping(struct drm_i915_gem_object *obj, if (offset >= obj->base.size) continue; - i915_gem_flush_ggtt_writes(to_i915(obj->base.dev)); + intel_gt_flush_ggtt_writes(&to_i915(obj->base.dev)->gt); p = i915_gem_object_get_page(obj, offset >> PAGE_SHIFT); cpu = kmap(p) + offset_in_page(offset); diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c index 6f6f61cc142d..2500bef06af4 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt.c +++ b/drivers/gpu/drm/i915/gt/intel_gt.c @@ -150,3 +150,44 @@ void intel_gt_check_and_clear_faults(struct intel_gt *gt) intel_gt_clear_error_registers(gt, ALL_ENGINES); } + +void intel_gt_flush_ggtt_writes(struct intel_gt *gt) +{ + struct drm_i915_private *i915 = gt->i915; + intel_wakeref_t wakeref; + + /* + * No actual flushing is required for the GTT write domain for reads + * from the GTT domain. Writes to it "immediately" go to main memory + * as far as we know, so there's no chipset flush. It also doesn't + * land in the GPU render cache. + * + * However, we do have to enforce the order so that all writes through + * the GTT land before any writes to the device, such as updates to + * the GATT itself. + * + * We also have to wait a bit for the writes to land from the GTT. + * An uncached read (i.e. mmio) seems to be ideal for the round-trip + * timing. This issue has only been observed when switching quickly + * between GTT writes and CPU reads from inside the kernel on recent hw, + * and it appears to only affect discrete GTT blocks (i.e. on LLC + * system agents we cannot reproduce this behaviour, until Cannonlake + * that was!). + */ + + wmb(); + + if (INTEL_INFO(i915)->has_coherent_ggtt) + return; + + i915_gem_chipset_flush(i915); + + with_intel_runtime_pm(&i915->runtime_pm, wakeref) { + struct intel_uncore *uncore = gt->uncore; + + spin_lock_irq(&uncore->lock); + intel_uncore_posting_read_fw(uncore, + RING_HEAD(RENDER_RING_BASE)); + spin_unlock_irq(&uncore->lock); + } +} diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h b/drivers/gpu/drm/i915/gt/intel_gt.h index 1847c189bd78..d894c1178116 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt.h +++ b/drivers/gpu/drm/i915/gt/intel_gt.h @@ -18,4 +18,6 @@ void intel_gt_check_and_clear_faults(struct intel_gt *gt); void intel_gt_clear_error_registers(struct intel_gt *gt, intel_engine_mask_t engine_mask); +void intel_gt_flush_ggtt_writes(struct intel_gt *gt); + #endif /* __INTEL_GT_H__ */ diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 2c4c8ee4133b..d9c02bf42052 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2600,8 +2600,6 @@ int __must_check i915_gem_evict_for_node(struct i915_address_space *vm, unsigned int flags); int i915_gem_evict_vm(struct i915_address_space *vm); -void i915_gem_flush_ggtt_writes(struct drm_i915_private *dev_priv); - /* belongs in i915_gem_gtt.h */ static inline void i915_gem_chipset_flush(struct drm_i915_private *dev_priv) { diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index ac76ac781afe..79c718f053cd 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -232,46 +232,6 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data, &args->size, &args->handle); } -void i915_gem_flush_ggtt_writes(struct drm_i915_private *dev_priv) -{ - intel_wakeref_t wakeref; - - /* - * No actual flushing is required for the GTT write domain for reads - * from the GTT domain. Writes to it "immediately" go to main memory - * as far as we know, so there's no chipset flush. It also doesn't - * land in the GPU render cache. - * - * However, we do have to enforce the order so that all writes through - * the GTT land before any writes to the device, such as updates to - * the GATT itself. - * - * We also have to wait a bit for the writes to land from the GTT. - * An uncached read (i.e. mmio) seems to be ideal for the round-trip - * timing. This issue has only been observed when switching quickly - * between GTT writes and CPU reads from inside the kernel on recent hw, - * and it appears to only affect discrete GTT blocks (i.e. on LLC - * system agents we cannot reproduce this behaviour, until Cannonlake - * that was!). - */ - - wmb(); - - if (INTEL_INFO(dev_priv)->has_coherent_ggtt) - return; - - i915_gem_chipset_flush(dev_priv); - - with_intel_runtime_pm(&dev_priv->runtime_pm, wakeref) { - struct intel_uncore *uncore = &dev_priv->uncore; - - spin_lock_irq(&uncore->lock); - intel_uncore_posting_read_fw(uncore, - RING_HEAD(RENDER_RING_BASE)); - spin_unlock_irq(&uncore->lock); - } -} - static int shmem_pread(struct page *page, int offset, int len, char __user *user_data, bool needs_clflush) diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index b295c53085ee..571c6ddd7eaf 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -23,6 +23,7 @@ */ #include "gt/intel_engine.h" +#include "gt/intel_gt.h" #include "i915_vma.h" @@ -408,7 +409,7 @@ void i915_vma_flush_writes(struct i915_vma *vma) if (!i915_vma_has_ggtt_write(vma)) return; - i915_gem_flush_ggtt_writes(vma->vm->i915); + intel_gt_flush_ggtt_writes(vma->vm->gt); i915_vma_unset_ggtt_write(vma); } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index 1a60b9fe8221..d9531cb5f235 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c @@ -1195,7 +1195,7 @@ static int igt_ggtt_page(void *arg) iowrite32(n, vaddr + n); io_mapping_unmap_atomic(vaddr); } - i915_gem_flush_ggtt_writes(i915); + intel_gt_flush_ggtt_writes(ggtt->vm.gt); i915_random_reorder(order, count, &prng); for (n = 0; n < count; n++) {