From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 2/4] drm/xe: store bind time pat index to xe_bo
Date: Tue, 23 Jan 2024 10:05:37 +0200 [thread overview]
Message-ID: <Za9zURjbgjDUdlmJ@intel.com> (raw)
In-Reply-To: <6333556b-60ec-4233-be50-1dcb745bb89d@intel.com>
On Fri, Jan 19, 2024 at 03:45:22PM +0000, Matthew Auld wrote:
> On 18/01/2024 15:27, Juha-Pekka Heikkila wrote:
> > Store pat index from xe_vma to xe_bo
> >
> > Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
> > ---
> > drivers/gpu/drm/xe/xe_pt.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
> > index de1030a47588..4b76db698878 100644
> > --- a/drivers/gpu/drm/xe/xe_pt.c
> > +++ b/drivers/gpu/drm/xe/xe_pt.c
> > @@ -1252,6 +1252,10 @@ __xe_pt_bind_vma(struct xe_tile *tile, struct xe_vma *vma, struct xe_exec_queue
> > return ERR_PTR(-ENOMEM);
> > }
> >
> > + if (xe_vma_bo(vma)) {
> > + xe_vma_bo(vma)->pat_index = vma->pat_index;
>
> Multiple mappings will trash this I think. Is that OK for your usecase?
> It can be useful to map the same resource as compressed and uncompressed
> to facilitate in-place decompression/compression.
I thought the pat_index is set for the entire bo? The
cache_level->pat_index stuff doesn't really work otherwise
I don't think (assuming it works at all).
So dunno why this is doing anything using vmas. I think
what we probably need is to check/set the bo pat_index
at fb create time, and lock it into place (if there's
some mechanism by which a random userspace client could
change it after the fact, and thus screw up everything).
>
> Also would be good to be clear about what happens if the KMD doesn't do
> anything to prevent compression with non-tile4? Is it just a bit of
> display corruption or something much worse that we need to prevent? Is
> this just a best effort check to help userspace? Otherwise it is hard to
> evaluate how solid we need to be here in our checking to prevent this
> scenario. For example how is binding vs display races handled? What
> happens if the bind appears after the display check?
>
> > + }
> > +
> > fence = xe_migrate_update_pgtables(tile->migrate,
> > vm, xe_vma_bo(vma), q,
> > entries, num_entries,
--
Ville Syrjälä
Intel
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Subject: Re: [PATCH 2/4] drm/xe: store bind time pat index to xe_bo
Date: Tue, 23 Jan 2024 10:05:37 +0200 [thread overview]
Message-ID: <Za9zURjbgjDUdlmJ@intel.com> (raw)
In-Reply-To: <6333556b-60ec-4233-be50-1dcb745bb89d@intel.com>
On Fri, Jan 19, 2024 at 03:45:22PM +0000, Matthew Auld wrote:
> On 18/01/2024 15:27, Juha-Pekka Heikkila wrote:
> > Store pat index from xe_vma to xe_bo
> >
> > Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
> > ---
> > drivers/gpu/drm/xe/xe_pt.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
> > index de1030a47588..4b76db698878 100644
> > --- a/drivers/gpu/drm/xe/xe_pt.c
> > +++ b/drivers/gpu/drm/xe/xe_pt.c
> > @@ -1252,6 +1252,10 @@ __xe_pt_bind_vma(struct xe_tile *tile, struct xe_vma *vma, struct xe_exec_queue
> > return ERR_PTR(-ENOMEM);
> > }
> >
> > + if (xe_vma_bo(vma)) {
> > + xe_vma_bo(vma)->pat_index = vma->pat_index;
>
> Multiple mappings will trash this I think. Is that OK for your usecase?
> It can be useful to map the same resource as compressed and uncompressed
> to facilitate in-place decompression/compression.
I thought the pat_index is set for the entire bo? The
cache_level->pat_index stuff doesn't really work otherwise
I don't think (assuming it works at all).
So dunno why this is doing anything using vmas. I think
what we probably need is to check/set the bo pat_index
at fb create time, and lock it into place (if there's
some mechanism by which a random userspace client could
change it after the fact, and thus screw up everything).
>
> Also would be good to be clear about what happens if the KMD doesn't do
> anything to prevent compression with non-tile4? Is it just a bit of
> display corruption or something much worse that we need to prevent? Is
> this just a best effort check to help userspace? Otherwise it is hard to
> evaluate how solid we need to be here in our checking to prevent this
> scenario. For example how is binding vs display races handled? What
> happens if the bind appears after the display check?
>
> > + }
> > +
> > fence = xe_migrate_update_pgtables(tile->migrate,
> > vm, xe_vma_bo(vma), q,
> > entries, num_entries,
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2024-01-23 8:05 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-18 15:27 [PATCH 0/4] Enable ccs compressed framebuffers on Xe2 Juha-Pekka Heikkila
2024-01-18 15:27 ` Juha-Pekka Heikkila
2024-01-18 15:27 ` [PATCH 1/4] drm/xe: add bind time pat index to xe_bo structure Juha-Pekka Heikkila
2024-01-18 15:27 ` Juha-Pekka Heikkila
2024-01-18 15:27 ` [PATCH 2/4] drm/xe: store bind time pat index to xe_bo Juha-Pekka Heikkila
2024-01-18 15:27 ` Juha-Pekka Heikkila
2024-01-19 15:45 ` Matthew Auld
2024-01-22 18:26 ` Juha-Pekka Heikkila
2024-01-23 12:59 ` Matthew Auld
2024-01-23 8:05 ` Ville Syrjälä [this message]
2024-01-23 8:05 ` Ville Syrjälä
2024-01-23 9:17 ` Matthew Auld
2024-01-23 9:17 ` Matthew Auld
2024-01-18 15:27 ` [PATCH 3/4] drm/xe/xe2: Limit ccs framebuffers to tile4 only Juha-Pekka Heikkila
2024-01-18 15:27 ` Juha-Pekka Heikkila
2024-01-19 11:48 ` Jani Nikula
2024-01-19 12:08 ` Juha-Pekka Heikkila
2024-01-19 15:22 ` Matthew Auld
2024-01-22 18:27 ` Juha-Pekka Heikkila
2024-01-18 15:27 ` [PATCH 4/4] drm/i915/display: On Xe2 always enable decompression with tile4 Juha-Pekka Heikkila
2024-01-18 15:27 ` Juha-Pekka Heikkila
2024-01-19 12:15 ` Kahola, Mika
2024-01-18 15:48 ` ✓ CI.Patch_applied: success for Enable ccs compressed framebuffers on Xe2 Patchwork
2024-01-18 15:48 ` ✓ CI.checkpatch: " Patchwork
2024-01-18 15:49 ` ✓ CI.KUnit: " Patchwork
2024-01-18 15:56 ` ✓ CI.Build: " Patchwork
2024-01-18 15:57 ` ✓ CI.Hooks: " Patchwork
2024-01-18 15:58 ` ✗ CI.checksparse: warning " Patchwork
2024-01-18 16:22 ` ✗ CI.BAT: failure " Patchwork
2024-01-18 16:51 ` ✓ CI.Patch_applied: success for Enable ccs compressed framebuffers on Xe2 (rev2) Patchwork
2024-01-18 16:51 ` ✓ CI.checkpatch: " Patchwork
2024-01-18 16:52 ` ✓ CI.KUnit: " Patchwork
2024-01-18 16:59 ` ✓ CI.Build: " Patchwork
2024-01-18 17:00 ` ✓ CI.Hooks: " Patchwork
2024-01-18 17:01 ` ✗ CI.checksparse: warning " Patchwork
2024-01-18 17:25 ` ✓ CI.BAT: success " Patchwork
2024-01-18 22:45 ` ✗ Fi.CI.BAT: failure for Enable ccs compressed framebuffers on Xe2 Patchwork
2024-01-19 8:57 ` ✓ Fi.CI.BAT: success for Enable ccs compressed framebuffers on Xe2 (rev2) Patchwork
2024-01-19 13:34 ` ✗ 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=Za9zURjbgjDUdlmJ@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@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.