From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH] drm/xe: Ensure display fb is aligned in GGTT to a multiple of 64k, through padding
Date: Tue, 20 Aug 2024 15:41:36 +0200 [thread overview]
Message-ID: <485b9fa4714b2bdc6745d5e25d5160c98f0de0d5.camel@linux.intel.com> (raw)
In-Reply-To: <20240820050608.sueqpjtpayoygicj@zkempczy-mobl2>
Hi, Zbigniew, Maarten
On Tue, 2024-08-20 at 07:06 +0200, Zbigniew Kempczyński wrote:
> On Mon, Aug 19, 2024 at 05:31:27PM +0200, Maarten Lankhorst wrote:
> > This workaround is needed on battlemage to ensure that there is no
> > corruption when CCS is used.
> >
> > For testing, always enable the workaround. Should be easier to see
> > if something blows up. :)
> >
> > Signed-off-by: Maarten Lankhorst
> > <maarten.lankhorst@linux.intel.com>
> > ---
> > drivers/gpu/drm/xe/display/xe_fb_pin.c | 82
> > ++++++++++++++++++++++++--
> > 1 file changed, 77 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c
> > b/drivers/gpu/drm/xe/display/xe_fb_pin.c
> > index d7db44e79eaf5..29a13a889414d 100644
> > --- a/drivers/gpu/drm/xe/display/xe_fb_pin.c
> > +++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c
> > @@ -15,8 +15,68 @@
> > #include "xe_gt.h"
> > #include "xe_pm.h"
> >
> > +static inline bool needs_bmg_64k_workaround(struct xe_device *xe,
> > const struct intel_framebuffer *fb)
> > +{
> > + if (xe->info.platform != XE_BATTLEMAGE)
> > + goto skip;
> > +
> > + /* XXX? What is affected? */
> > + if (fb->base.modifier != I915_FORMAT_MOD_4_TILED)
> > + goto skip;
> > +
> > + if (!(intel_fb_obj(&fb->base)->ttm.base.size % SZ_64K))
> > + goto skip;
> > +
> > + return true;
> > +skip:
> > + return true;
>
> I guess you mean false here according to commit description.
>
> I'm not too familiar with fb code, but if I'm not wrong you're adding
> dedicated padding on ggtt to keep fb in 64K chunks, but this is
> virtual
> range. Display folks said we should use physically contiguous 64K
> pages
> due to decompression CCS is resolved at physical addressing, not
> virtual.
>
> If I don't understand your code correctly, just forget about above
> note.
Yeah, if it requires *phyiscally* contigous 64K pages, then that's
indeed a different thing. But otoh, requiring 64K pages and at the same
time allowing 4K pages for other allocations might cause fragmentation
to the point where the 64K allocations fail.
So if this patch indeed doesn't fix the issue then that requires some
rethinking.
/Thomas
>
> --
> Zbigniew
>
> > +}
> > +
> > +static inline void pad_bmg_dpt(struct xe_device *xe, const struct
> > intel_framebuffer *fb,
> > + struct iosys_map *map, u32 ofs)
> > +{
> > + struct xe_ggtt *ggtt = xe_device_get_root_tile(xe)-
> > >mem.ggtt;
> > + struct xe_bo *bo = intel_fb_obj(&fb->base);
> > + u32 pad = 16 - (ofs % 16), x;
> > + u64 pte;
> > +
> > + if (!needs_bmg_64k_workaround(xe, fb))
> > + return;
> > +
> > + if (!(ofs % 16))
> > + return;
> > +
> > + pte = ggtt->pt_ops->pte_encode_bo(bo, 0, xe-
> > >pat.idx[XE_CACHE_NONE]);
> > +
> > + /* Start over with the first few pages, dpt is always
> > aligned to a multiple
> > + * of 512 pages, which means that there is enough
> > padding here
> > + */
> > + for (x = 0; x < pad; x++)
> > + iosys_map_wr(map, (ofs + x) * 8, u64, pte);
> > +}
> > +
> > +static inline void pad_bmg_ggtt(struct xe_device *xe, const struct
> > intel_framebuffer *fb, u32 ofs)
> > +{
> > + struct xe_ggtt *ggtt = xe_device_get_root_tile(xe)-
> > >mem.ggtt;
> > + struct xe_bo *bo = intel_fb_obj(&fb->base);
> > + u32 pad = SZ_64K - (ofs % SZ_64K), x;
> > + u64 pte;
> > +
> > + if (!needs_bmg_64k_workaround(xe, fb))
> > + return;
> > +
> > + if (!(ofs % SZ_64K))
> > + return;
> > +
> > + pte = ggtt->pt_ops->pte_encode_bo(bo, 0, xe-
> > >pat.idx[XE_CACHE_NONE]);
> > +
> > + for (x = 0; x < pad; x += XE_PAGE_SIZE)
> > + ggtt->pt_ops->ggtt_set_pte(ggtt, ofs + x, pte);
> > +}
> > +
> > static void
> > -write_dpt_rotated(struct xe_bo *bo, struct iosys_map *map, u32
> > *dpt_ofs, u32 bo_ofs,
> > +write_dpt_rotated(const struct intel_framebuffer *fb, struct xe_bo
> > *bo,
> > + struct iosys_map *map, u32 *dpt_ofs, u32 bo_ofs,
> > u32 width, u32 height, u32 src_stride, u32
> > dst_stride)
> > {
> > struct xe_device *xe = xe_bo_device(bo);
> > @@ -39,6 +99,9 @@ write_dpt_rotated(struct xe_bo *bo, struct
> > iosys_map *map, u32 *dpt_ofs, u32 bo_
> > src_idx -= src_stride;
> > }
> >
> > + /* Just pad everything out of paranoia? */
> > + pad_bmg_dpt(xe, fb, map, *dpt_ofs / 8);
> > +
> > /* The DE ignores the PTEs for the padding tiles
> > */
> > *dpt_ofs += (dst_stride - height) * 8;
> > }
> > @@ -128,6 +191,9 @@ static int __xe_pin_fb_vma_dpt(const struct
> > intel_framebuffer *fb,
> >
> > iosys_map_wr(&dpt->vmap, x * 8, u64, pte);
> > }
> > +
> > + /* BMG is crappy, just pad everything? */
> > + pad_bmg_dpt(xe, fb, &dpt->vmap, x);
> > } else if (view->type == I915_GTT_VIEW_REMAPPED) {
> > const struct intel_remapped_info *remap_info =
> > &view->remapped;
> > u32 i, dpt_ofs = 0;
> > @@ -145,7 +211,7 @@ static int __xe_pin_fb_vma_dpt(const struct
> > intel_framebuffer *fb,
> > u32 i, dpt_ofs = 0;
> >
> > for (i = 0; i < ARRAY_SIZE(rot_info->plane); i++)
> > - write_dpt_rotated(bo, &dpt->vmap,
> > &dpt_ofs,
> > + write_dpt_rotated(fb, bo, &dpt->vmap,
> > &dpt_ofs,
> > rot_info-
> > >plane[i].offset,
> > rot_info-
> > >plane[i].width,
> > rot_info-
> > >plane[i].height,
> > @@ -159,7 +225,8 @@ static int __xe_pin_fb_vma_dpt(const struct
> > intel_framebuffer *fb,
> > }
> >
> > static void
> > -write_ggtt_rotated(struct xe_bo *bo, struct xe_ggtt *ggtt, u32
> > *ggtt_ofs, u32 bo_ofs,
> > +write_ggtt_rotated(const struct intel_framebuffer *fb,
> > + struct xe_bo *bo, struct xe_ggtt *ggtt, u32
> > *ggtt_ofs, u32 bo_ofs,
> > u32 width, u32 height, u32 src_stride, u32
> > dst_stride)
> > {
> > struct xe_device *xe = xe_bo_device(bo);
> > @@ -177,6 +244,8 @@ write_ggtt_rotated(struct xe_bo *bo, struct
> > xe_ggtt *ggtt, u32 *ggtt_ofs, u32 bo
> > src_idx -= src_stride;
> > }
> >
> > + pad_bmg_ggtt(xe, fb, *ggtt_ofs);
> > +
> > /* The DE ignores the PTEs for the padding tiles
> > */
> > *ggtt_ofs += (dst_stride - height) * XE_PAGE_SIZE;
> > }
> > @@ -201,7 +270,8 @@ static int __xe_pin_fb_vma_ggtt(const struct
> > intel_framebuffer *fb,
> > goto out;
> >
> > align = XE_PAGE_SIZE;
> > - if (xe_bo_is_vram(bo) && ggtt->flags & XE_GGTT_FLAGS_64K)
> > + if ((xe_bo_is_vram(bo) && (ggtt->flags &
> > XE_GGTT_FLAGS_64K)) ||
> > + needs_bmg_64k_workaround(xe, fb))
> > align = max_t(u32, align, SZ_64K);
> >
> > if (bo->ggtt_node.size && view->type ==
> > I915_GTT_VIEW_NORMAL) {
> > @@ -220,6 +290,8 @@ static int __xe_pin_fb_vma_ggtt(const struct
> > intel_framebuffer *fb,
> >
> > ggtt->pt_ops->ggtt_set_pte(ggtt, vma-
> > >node.start + x, pte);
> > }
> > +
> > + pad_bmg_ggtt(xe, fb, vma->node.start + x);
> > } else {
> > u32 i, ggtt_ofs;
> > const struct intel_rotation_info *rot_info =
> > &view->rotated;
> > @@ -235,7 +307,7 @@ static int __xe_pin_fb_vma_ggtt(const struct
> > intel_framebuffer *fb,
> > ggtt_ofs = vma->node.start;
> >
> > for (i = 0; i < ARRAY_SIZE(rot_info->plane); i++)
> > - write_ggtt_rotated(bo, ggtt, &ggtt_ofs,
> > + write_ggtt_rotated(fb, bo, ggtt,
> > &ggtt_ofs,
> > rot_info-
> > >plane[i].offset,
> > rot_info-
> > >plane[i].width,
> > rot_info-
> > >plane[i].height,
> > --
> > 2.45.2
> >
prev parent reply other threads:[~2024-08-20 13:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-19 15:31 [PATCH] drm/xe: Ensure display fb is aligned in GGTT to a multiple of 64k, through padding Maarten Lankhorst
2024-08-19 15:39 ` ✓ CI.Patch_applied: success for " Patchwork
2024-08-19 15:39 ` ✗ CI.checkpatch: warning " Patchwork
2024-08-19 15:41 ` ✓ CI.KUnit: success " Patchwork
2024-08-19 15:52 ` ✓ CI.Build: " Patchwork
2024-08-19 15:55 ` ✓ CI.Hooks: " Patchwork
2024-08-19 15:56 ` ✓ CI.checksparse: " Patchwork
2024-08-19 16:20 ` ✓ CI.BAT: " Patchwork
2024-08-19 19:54 ` ✗ CI.FULL: failure " Patchwork
2024-08-20 5:06 ` [PATCH] " Zbigniew Kempczyński
2024-08-20 13:41 ` Thomas Hellström [this message]
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=485b9fa4714b2bdc6745d5e25d5160c98f0de0d5.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=zbigniew.kempczynski@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