Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/xe: Add XE_BO_FLAG_NEEDS_WC_CPU and unify mapping for page tables.
Date: Mon, 23 Sep 2024 20:52:16 -0700	[thread overview]
Message-ID: <85ldzhg13j.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20240920190107.156914-1-maarten.lankhorst@linux.intel.com>

On Fri, 20 Sep 2024 12:01:06 -0700, Maarten Lankhorst wrote:
>

Hey Maarten,

I will try to review as well as I can, but I am not very familiar with this
stuff, so ideally someone else should also review this. I also later
realized that this patch is not useful to the use case I had in mind.

Any case, going on.

> There are various places where we map buffers WC_CPU and uncached on the
> GPU. Unify all of those users to a single flag.

To me, this patch doesn't seem to "Unify all of those users to a single
flag" at all. The patch only adds XE_BO_FLAG_NEEDS_WC_CPU to
XE_BO_FLAG_PAGETABLE, not to XE_BO_FLAG_SCANOUT and
DRM_XE_GEM_CPU_CACHING_WC. So finally the only unifying thing seems to be
"ttm_write_combined".

The other issue maybe is that caching is specified through both
bo->cpu_caching as well as bo->flags. Also, 'bo->cpu_caching == 0' seems to
mean the same thing as '!(bo->flags & XE_BO_FLAG_USER)'. But maybe ok.

So maybe the commit message should just say we are exposing a new
XE_BO_FLAG_NEEDS_WC_CPU flag for internally created BO's to use which will
give "WC from CPU, UC from GPU" mapping. And using this new flag for
XE_BO_FLAG_PAGETABLE.

>
> In particular our usage of page table flags has been incoherent,
> and we should use uncached where applicable.

"uncached" meaning XE_BO_FLAG_NEEDS_WC_CPU?

> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>

With the commit message change, the patch itself seems ok to me, except for
one question below.

> @@ -568,6 +577,7 @@ xe_pt_stage_bind_entry(struct xe_ptw *parent, pgoff_t offset,
>			xe_child->is_compact = true;
>		}
>
> +		pat_index = xe_pt_pat_index_from_bo(xe_child->bo);

This wasn't needed earlier? Didn't know what to make out of this new line
which appeared out of the blue.

Thanks.
--
Ashutosh

  parent reply	other threads:[~2024-09-24  3:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-20 19:01 [PATCH 1/2] drm/xe: Add XE_BO_FLAG_NEEDS_WC_CPU and unify mapping for page tables Maarten Lankhorst
2024-09-20 19:01 ` [PATCH 2/2] drm/xe: Use XE_BO_FLAG_NEEDS_WC_CPU for DSB Maarten Lankhorst
2024-09-24  3:52   ` Dixit, Ashutosh
2024-09-20 19:07 ` ✓ CI.Patch_applied: success for series starting with [1/2] drm/xe: Add XE_BO_FLAG_NEEDS_WC_CPU and unify mapping for page tables Patchwork
2024-09-20 19:07 ` ✗ CI.checkpatch: warning " Patchwork
2024-09-20 19:08 ` ✓ CI.KUnit: success " Patchwork
2024-09-20 19:20 ` ✓ CI.Build: " Patchwork
2024-09-20 19:22 ` ✓ CI.Hooks: " Patchwork
2024-09-20 19:24 ` ✓ CI.checksparse: " Patchwork
2024-09-20 19:42 ` ✓ CI.BAT: " Patchwork
2024-09-21  0:52 ` ✗ CI.FULL: failure " Patchwork
2024-09-24  3:52 ` Dixit, Ashutosh [this message]
2024-09-25 23:05 ` ✓ CI.Patch_applied: success for series starting with [1/2] drm/xe: Add XE_BO_FLAG_NEEDS_WC_CPU and unify mapping for page tables. (rev2) Patchwork
2024-09-25 23:05 ` ✗ CI.checkpatch: warning " Patchwork
2024-09-25 23:06 ` ✓ CI.KUnit: success " Patchwork
2024-09-25 23:18 ` ✓ CI.Build: " Patchwork
2024-09-25 23:20 ` ✓ CI.Hooks: " Patchwork
2024-09-25 23:21 ` ✓ CI.checksparse: " Patchwork
2024-09-26  0:00 ` ✓ CI.BAT: " Patchwork
2024-09-26  4:46 ` ✗ CI.FULL: failure " Patchwork
2024-09-26  8:23 ` 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=85ldzhg13j.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=maarten.lankhorst@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox