Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


             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