All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
To: <intel-gfx@lists.freedesktop.org>, <dri-devel@lists.freedesktop.org>
Cc: Thomas Hellstr_m <thomas.hellstrom@linux.intel.com>,
	Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Jani Nikula <jani.nikula@intel.com>,
	lucas.demarchi@intel.com, Chris Wilson <chris.p.wilson@intel.com>,
	siva.mullati@intel.com, David Airlie <airlied@linux.ie>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Nirmoy Das <nirmoy.das@intel.com>
Subject: [PATCH v3 0/7] drm/i915: Use the memcpy_from_wc function from drm
Date: Tue, 26 Apr 2022 22:21:41 +0530	[thread overview]
Message-ID: <20220426165148.1784-1-balasubramani.vivekanandan@intel.com> (raw)

drm_memcpy_from_wc() performs fast copy from WC memory type using
non-temporal instructions. Now there are two similar implementations of
this function. One exists in drm_cache.c as drm_memcpy_from_wc() and
another implementation in i915/i915_memcpy.c as i915_memcpy_from_wc().
drm_memcpy_from_wc() was the recent addition through the series
https://patchwork.freedesktop.org/patch/436276/?series=90681&rev=6

The goal of this patch series is to change all users of
i915_memcpy_from_wc() to drm_memcpy_from_wc() and a have common
implementation in drm and eventually remove the copy from i915.

Another benefit of using memcpy functions from drm is that
drm_memcpy_from_wc() is available for non-x86 architectures.
i915_memcpy_from_wc() is implemented only for x86 and prevents building
i915 for ARM64.
drm_memcpy_from_wc() does fast copy using non-temporal instructions for
x86 and for other architectures makes use of memcpy() family of
functions as fallback.

Another major difference is unlike i915_memcpy_from_wc(),
drm_memcpy_from_wc() will not fail if the passed address argument is not
alignment to be used with non-temporal load instructions or if the
platform lacks support for those instructions (non-temporal load
instructions are provided through SSE4.1 instruction set extension).
Instead drm_memcpy_from_wc() continues with fallback functions to
complete the copy.
This relieves the caller from checking the return value of
i915_memcpy_from_wc() and explicitly using a fallback.

Follow up series will be created to remove the memcpy_from_wc functions
from i915 once the dependency is completely removed.

v2: Fixed missing check to find if the address is from system memory or
    io memory and use the right initialization function to construct the
    iosys_map structure (Review feedback from Lucas)

v3: "drm/i915/guc: use the memcpy_from_wc call from the drm" replaced by
    patch "drm/i915/guc: use iosys_map abstraction to access GuC log".
    New patch does a wider change compared to the old patch. It
    completely changes the access to GuC log using iosys_map
    abstraction, in addition to using drm_memcpy_from_wc.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: David Airlie <airlied@linux.ie> 
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Chris Wilson <chris.p.wilson@intel.com>
Cc: Thomas Hellstr_m <thomas.hellstrom@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>

Balasubramani Vivekanandan (7):
  drm: Relax alignment constraint for destination address
  drm: Add drm_memcpy_from_wc() variant which accepts destination
    address
  drm/i915: use the memcpy_from_wc call from the drm
  drm/i915/guc: use iosys_map abstraction to access GuC log
  drm/i915/selftests: use the memcpy_from_wc call from the drm
  drm/i915/gt: Avoid direct dereferencing of io memory
  drm/i915: Avoid dereferencing io mapped memory

 drivers/gpu/drm/drm_cache.c                   | 99 +++++++++++++++++--
 drivers/gpu/drm/i915/gem/i915_gem_object.c    |  8 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c      | 21 ++--
 drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h |  2 +-
 .../gpu/drm/i915/gt/uc/intel_guc_capture.c    | 52 +++++++---
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c    | 77 +++++++++++----
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.h    |  3 +-
 drivers/gpu/drm/i915/i915_gpu_error.c         | 45 +++++----
 .../drm/i915/selftests/intel_memory_region.c  | 41 +++++---
 include/drm/drm_cache.h                       |  3 +
 10 files changed, 261 insertions(+), 90 deletions(-)

-- 
2.25.1


WARNING: multiple messages have this Message-ID (diff)
From: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
To: <intel-gfx@lists.freedesktop.org>, <dri-devel@lists.freedesktop.org>
Cc: Thomas Hellstr_m <thomas.hellstrom@linux.intel.com>,
	Jani Nikula <jani.nikula@intel.com>,
	lucas.demarchi@intel.com, Chris Wilson <chris.p.wilson@intel.com>,
	siva.mullati@intel.com, David Airlie <airlied@linux.ie>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Nirmoy Das <nirmoy.das@intel.com>
Subject: [Intel-gfx] [PATCH v3 0/7] drm/i915: Use the memcpy_from_wc function from drm
Date: Tue, 26 Apr 2022 22:21:41 +0530	[thread overview]
Message-ID: <20220426165148.1784-1-balasubramani.vivekanandan@intel.com> (raw)

drm_memcpy_from_wc() performs fast copy from WC memory type using
non-temporal instructions. Now there are two similar implementations of
this function. One exists in drm_cache.c as drm_memcpy_from_wc() and
another implementation in i915/i915_memcpy.c as i915_memcpy_from_wc().
drm_memcpy_from_wc() was the recent addition through the series
https://patchwork.freedesktop.org/patch/436276/?series=90681&rev=6

The goal of this patch series is to change all users of
i915_memcpy_from_wc() to drm_memcpy_from_wc() and a have common
implementation in drm and eventually remove the copy from i915.

Another benefit of using memcpy functions from drm is that
drm_memcpy_from_wc() is available for non-x86 architectures.
i915_memcpy_from_wc() is implemented only for x86 and prevents building
i915 for ARM64.
drm_memcpy_from_wc() does fast copy using non-temporal instructions for
x86 and for other architectures makes use of memcpy() family of
functions as fallback.

Another major difference is unlike i915_memcpy_from_wc(),
drm_memcpy_from_wc() will not fail if the passed address argument is not
alignment to be used with non-temporal load instructions or if the
platform lacks support for those instructions (non-temporal load
instructions are provided through SSE4.1 instruction set extension).
Instead drm_memcpy_from_wc() continues with fallback functions to
complete the copy.
This relieves the caller from checking the return value of
i915_memcpy_from_wc() and explicitly using a fallback.

Follow up series will be created to remove the memcpy_from_wc functions
from i915 once the dependency is completely removed.

v2: Fixed missing check to find if the address is from system memory or
    io memory and use the right initialization function to construct the
    iosys_map structure (Review feedback from Lucas)

v3: "drm/i915/guc: use the memcpy_from_wc call from the drm" replaced by
    patch "drm/i915/guc: use iosys_map abstraction to access GuC log".
    New patch does a wider change compared to the old patch. It
    completely changes the access to GuC log using iosys_map
    abstraction, in addition to using drm_memcpy_from_wc.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: David Airlie <airlied@linux.ie> 
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Chris Wilson <chris.p.wilson@intel.com>
Cc: Thomas Hellstr_m <thomas.hellstrom@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>

Balasubramani Vivekanandan (7):
  drm: Relax alignment constraint for destination address
  drm: Add drm_memcpy_from_wc() variant which accepts destination
    address
  drm/i915: use the memcpy_from_wc call from the drm
  drm/i915/guc: use iosys_map abstraction to access GuC log
  drm/i915/selftests: use the memcpy_from_wc call from the drm
  drm/i915/gt: Avoid direct dereferencing of io memory
  drm/i915: Avoid dereferencing io mapped memory

 drivers/gpu/drm/drm_cache.c                   | 99 +++++++++++++++++--
 drivers/gpu/drm/i915/gem/i915_gem_object.c    |  8 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c      | 21 ++--
 drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h |  2 +-
 .../gpu/drm/i915/gt/uc/intel_guc_capture.c    | 52 +++++++---
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c    | 77 +++++++++++----
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.h    |  3 +-
 drivers/gpu/drm/i915/i915_gpu_error.c         | 45 +++++----
 .../drm/i915/selftests/intel_memory_region.c  | 41 +++++---
 include/drm/drm_cache.h                       |  3 +
 10 files changed, 261 insertions(+), 90 deletions(-)

-- 
2.25.1


             reply	other threads:[~2022-04-26 16:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-26 16:51 Balasubramani Vivekanandan [this message]
2022-04-26 16:51 ` [Intel-gfx] [PATCH v3 0/7] drm/i915: Use the memcpy_from_wc function from drm Balasubramani Vivekanandan
2022-04-26 16:51 ` [PATCH v3 1/7] drm: Relax alignment constraint for destination address Balasubramani Vivekanandan
2022-04-26 16:51   ` [Intel-gfx] " Balasubramani Vivekanandan
2022-04-26 16:51 ` [PATCH v3 2/7] drm: Add drm_memcpy_from_wc() variant which accepts " Balasubramani Vivekanandan
2022-04-26 16:51   ` [Intel-gfx] " Balasubramani Vivekanandan
2022-07-13 15:47   ` Lucas De Marchi
2022-07-13 15:47     ` Lucas De Marchi
2022-07-14 11:20     ` Christian König
2022-07-14 11:20       ` Christian König
2022-04-26 16:51 ` [PATCH v3 3/7] drm/i915: use the memcpy_from_wc call from the drm Balasubramani Vivekanandan
2022-04-26 16:51   ` [Intel-gfx] " Balasubramani Vivekanandan
2022-04-26 16:51 ` [PATCH v3 4/7] drm/i915/guc: use iosys_map abstraction to access GuC log Balasubramani Vivekanandan
2022-04-26 16:51   ` [Intel-gfx] " Balasubramani Vivekanandan
2022-04-26 16:51 ` [PATCH v3 5/7] drm/i915/selftests: use the memcpy_from_wc call from the drm Balasubramani Vivekanandan
2022-04-26 16:51   ` [Intel-gfx] " Balasubramani Vivekanandan
2022-04-26 16:51 ` [PATCH v3 6/7] drm/i915/gt: Avoid direct dereferencing of io memory Balasubramani Vivekanandan
2022-04-26 16:51   ` [Intel-gfx] " Balasubramani Vivekanandan
2022-04-26 16:51 ` [PATCH v3 7/7] drm/i915: Avoid dereferencing io mapped memory Balasubramani Vivekanandan
2022-04-26 16:51   ` [Intel-gfx] " Balasubramani Vivekanandan
2022-04-26 17:57 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use the memcpy_from_wc function from drm (rev4) Patchwork
2022-04-26 20:16 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=20220426165148.1784-1-balasubramani.vivekanandan@intel.com \
    --to=balasubramani.vivekanandan@intel.com \
    --cc=airlied@linux.ie \
    --cc=chris.p.wilson@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=nirmoy.das@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=siva.mullati@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tvrtko.ursulin@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.