From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: Matt Roper <matthew.d.roper@intel.com>
Subject: [Intel-gfx] [RFC 0/8] Another take on PAT/object cache mode refactoring
Date: Thu, 27 Jul 2023 15:54:56 +0100 [thread overview]
Message-ID: <20230727145504.1919316-1-tvrtko.ursulin@linux.intel.com> (raw)
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Good news is that I realized series can be split after all. Bad news is that it
is still a lot to go through.
drm/i915: Skip clflush after GPU writes on Meteorlake
This is based on what Fei found out from hardware architects. If we agree the
the function this helper should achieve follow up is checking if other snoopable
platforms are the same.
drm/i915: Split PTE encode between Gen12 and Meteorlake
Not that much related but I feel we don't need to run impossible code on
platforms before Meteorlake. Shouldn't be controversial.
drm/i915: Cache PAT index used by the driver
This one shouldn't be controversial either. Just eliminates a pile of calls to
i915_gem_get_pat_index().
drm/i915: Refactor PAT/object cache handling
This is most code and the "table reversal" logic which makes i915 understands
caching modes behind PAT indices.
Review for taste and general "does it make sense" is needed here. Oh and extra
care about boolean logic conversion as I was pulling out obj->user_pat_set from
inside i915_gem_object_has_cache_level to the call sites.
All magic "if user PAT is set assume the worst" are still left in with this
patch.
drm/i915: Improve the vm_fault_gtt user PAT index restriction
drm/i915: Lift the user PAT restriction from gpu_write_needs_clflush
drm/i915: Lift the user PAT restriction from use_cpu_reloc
drm/i915: Refine the caching check in i915_gem_object_can_bypass_llc
This bunch is what removes the "user PAT set special casing".
Each of them probably have different reasons why the original cache level check
was in them so as many extra pair of eyes as possible are needed to verify both
that I have correctly understood what the underlying reasons why each were
there, and that I haven't fumbled the logic on the rudimentary level. Or perhaps
that it is possible to simplify this further. By maybe using more of
I915_BO_CACHE_COHERENT_FOR_... flags, or something.
Overall, a lot of scrutiny is needed for most of the series since it is
complicated and I am juggling multiple things.
Cc: Fei Yang <fei.yang@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Tvrtko Ursulin (8):
drm/i915: Skip clflush after GPU writes on Meteorlake
drm/i915: Split PTE encode between Gen12 and Meteorlake
drm/i915: Cache PAT index used by the driver
drm/i915: Refactor PAT/object cache handling
drm/i915: Improve the vm_fault_gtt user PAT index restriction
drm/i915: Lift the user PAT restriction from gpu_write_needs_clflush
drm/i915: Lift the user PAT restriction from use_cpu_reloc
drm/i915: Refine the caching check in i915_gem_object_can_bypass_llc
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 67 ++++++---
drivers/gpu/drm/i915/gem/i915_gem_domain.h | 5 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 +-
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 12 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 135 ++++++++++--------
drivers/gpu/drm/i915/gem/i915_gem_object.h | 11 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 116 +--------------
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 8 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 9 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 46 +++---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
.../drm/i915/gem/selftests/huge_gem_object.c | 2 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 5 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 4 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 40 ++++--
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 33 ++---
drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 4 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +-
drivers/gpu/drm/i915/gt/intel_migrate.c | 11 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 4 +-
drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_migrate.c | 9 +-
drivers/gpu/drm/i915/gt/selftest_reset.c | 14 +-
drivers/gpu/drm/i915/gt/selftest_tlb.c | 5 +-
.../gpu/drm/i915/gt/selftest_workarounds.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +-
drivers/gpu/drm/i915/i915_cache.c | 93 ++++++++++++
drivers/gpu/drm/i915/i915_cache.h | 81 +++++++++++
drivers/gpu/drm/i915/i915_debugfs.c | 53 +------
drivers/gpu/drm/i915/i915_driver.c | 5 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 21 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 8 +-
drivers/gpu/drm/i915/i915_pci.c | 84 ++++++-----
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.h | 6 +-
drivers/gpu/drm/i915/selftests/i915_gem.c | 5 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 8 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 11 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +-
.../drm/i915/selftests/intel_memory_region.c | 4 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 14 +-
48 files changed, 513 insertions(+), 469 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_cache.c
create mode 100644 drivers/gpu/drm/i915/i915_cache.h
--
2.39.2
next reply other threads:[~2023-07-27 14:55 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-27 14:54 Tvrtko Ursulin [this message]
2023-07-27 14:54 ` [Intel-gfx] [RFC 1/8] drm/i915: Skip clflush after GPU writes on Meteorlake Tvrtko Ursulin
2023-07-27 22:19 ` Matt Roper
2023-07-28 5:50 ` Yang, Fei
2023-07-27 14:54 ` [Intel-gfx] [RFC 2/8] drm/i915: Split PTE encode between Gen12 and Meteorlake Tvrtko Ursulin
2023-07-27 22:25 ` Matt Roper
2023-07-28 8:18 ` Tvrtko Ursulin
2023-07-28 14:41 ` Matt Roper
2023-07-27 14:54 ` [Intel-gfx] [RFC 3/8] drm/i915: Cache PAT index used by the driver Tvrtko Ursulin
2023-07-27 22:44 ` Matt Roper
2023-07-28 12:03 ` Tvrtko Ursulin
2023-07-27 14:55 ` [Intel-gfx] [RFC 4/8] drm/i915: Refactor PAT/object cache handling Tvrtko Ursulin
2023-07-27 23:57 ` Matt Roper
2023-07-28 0:17 ` Matt Roper
2023-07-28 12:35 ` Tvrtko Ursulin
2023-07-28 12:23 ` Tvrtko Ursulin
2023-07-28 12:39 ` Tvrtko Ursulin
2023-07-28 14:53 ` Matt Roper
2023-07-28 7:14 ` Yang, Fei
2023-07-28 12:55 ` Tvrtko Ursulin
2023-07-27 14:55 ` [Intel-gfx] [RFC 5/8] drm/i915: Improve the vm_fault_gtt user PAT index restriction Tvrtko Ursulin
2023-07-28 0:04 ` Matt Roper
2023-07-28 12:28 ` Tvrtko Ursulin
2023-07-27 14:55 ` [Intel-gfx] [RFC 6/8] drm/i915: Lift the user PAT restriction from gpu_write_needs_clflush Tvrtko Ursulin
2023-07-28 0:05 ` Matt Roper
2023-07-27 14:55 ` [Intel-gfx] [RFC 7/8] drm/i915: Lift the user PAT restriction from use_cpu_reloc Tvrtko Ursulin
2023-07-28 0:09 ` Matt Roper
2023-07-28 12:45 ` Tvrtko Ursulin
2023-07-27 14:55 ` [Intel-gfx] [RFC 8/8] drm/i915: Refine the caching check in i915_gem_object_can_bypass_llc Tvrtko Ursulin
2023-07-27 19:43 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Another take on PAT/object cache mode refactoring Patchwork
2023-07-27 19:43 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-07-27 20:01 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-07-28 1:03 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230727145504.1919316-1-tvrtko.ursulin@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=matthew.d.roper@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox