On Mon, Dec 30, 2019 at 10:53:21AM +0000, Chris Wilson wrote:
> Quoting Imre Deak (2019-12-27 23:51:46)
> > Currently the start address of a UV plane in a semiplanar YUV FB is tile
> > size (4kB) aligned. I noticed, that enforcing only this alignment leads
> > oddly to random memory corruptions on TGL while scanning out Y-tiled
> > FBs. This issue can be easily reproduced with a UV plane that is not
> > aligned to the plane's tile row size.
> >
> > Some experiments showed the correct alignment to be tile row size
> > indeed. This also makes sense, since the de-tiling fence created for the
>
> One would expect the implicit fence to follow the fence detiling HW
> logic, which does not require tile-row alignment, just 4096 alignment
> (since gen4). That suggests this logic is peculiar to the display engine.
Not sure what's an implicit fence, I only considered the fence we add
(which is added at offset 0 for the whole object via the set_tiling
IOCTL). But I suppose you mean the display would use its own fence even
if we don't add one (since an explicit fence for display is not needed
for a while now). Not sure what's the exact reason for the spec's
tile-row alignment restriction for UV surface addresses, maybe it's
required both by an implicit or explicit fence. Note that I haven't seen
the memory corruption if I didn't add the explicit fence for the object,
but I haven't checked if there are other problems even then, once I
noticed the spec alignment requirement.
To me what's logical as a rule is to not wrap around the right edge of
the fence (implicit or explicit) by programming a display surface base
address and an x offset. That would also mean that the stride of FB
surfaces (for planar YUV surfaces all surface stride's being the same)
match the stride of an implicit or explicit fence. Not sure if we
enforce all these.
> > object - with its own stride and so "left" and "right" edge - applies to
> > all the planes in the FB, so each tile row of all planes should be tile
> > row aligned.
> >
> > In fact BSpec requires this alignment since SKL. On SKL we may enforce
> > this due to the AUX plane x,y coords check, but on ICL and TGL we don't.
> > For now enforce this only on TGL; I can follow up with any necessary
> > change for ICL after more tests.
>
> Considering the severity of the error, I strongly suggest we fix all
> suspected machines and Cc:stable.
Ok, will add Cc now to this one, but would follow up with other machines
after more empirical proofs.
> > BSpec requires a stricter alignment for linear UV planes too (kind of a
> > tile row alignment), but it's unclear whether that's really needed
> > (couldn't be explained with the de-tiling fence as above) and enforcing
> > that could break existing user space; so avoid that too for now until
> > more tests.
> >
> > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > Signed-off-by: Imre Deak <imre.deak@xxxxxxxxx>
> > ---
> > +static unsigned int intel_tile_row_size(const struct drm_framebuffer *fb,
> > + int color_plane)
> > +{
> > + unsigned int tile_width, tile_height;
> > +
> > + intel_tile_dims(fb, color_plane, &tile_width, &tile_height);
> > +
> > + return fb->pitches[color_plane] * tile_height;
>
> Ok, that is tile_row_size.
> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
