[Mesa-dev] [PATCH] i965/skl: Ignore the vertical alignment for the qpitch of 1D textures

Jason Ekstrand jason at jlekstrand.net
Fri Feb 27 21:49:57 PST 2015


On Feb 27, 2015 9:17 PM, "Ben Widawsky" <ben at bwidawsk.net> wrote:
>
> On Fri, Feb 27, 2015 at 07:24:16PM +0000, Neil Roberts wrote:
> > The vertical alignment is ignored in the surface state for 1D array
> > textures so we can tightly pack them.
> >
> > I've run this through Piglit and it doesn't cause any regressions.
> >
> > (This should probably be squashed into the patch entitled “i965/skl:
> > Fix the qpitch value”)
> > ---
> >  src/mesa/drivers/dri/i965/brw_tex_layout.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> > index 15a0eca..2969db0 100644
> > --- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
> > +++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> > @@ -323,11 +323,11 @@ brw_miptree_layout_texture_array(struct
brw_context *brw,
> >        brw_miptree_layout_2d(mt);
> >
> >     if (layout_1d) {
> > -      physical_qpitch = mt->align_h;
> > +      physical_qpitch = 1;
> >        /* When using the horizontal layout the qpitch specifies the
distance in
> >         * pixels between array slices.
> >         */
> > -      mt->qpitch = physical_qpitch * mt->total_width;
> > +      mt->qpitch = mt->total_width;
>
> I guess I'd appreciate a comment about how the total_width is guaranteed
to be a
> multiple of 64, and therefore is a multiple of all possible H_ALIGNS.
This is
> required to meet the qpitch restraint in the surface format, "This field
must be
> set to an integer multiple of the Surface Horizontal Alignment."
>
> Note, I don't know anything about compressed textures and what the block
widths
> can be, but just doing the math, if block size > 16 and not a multiple of
16,
> this constraint will not hold.

Going entirely off the top of my head here so I could be wrong.  I believe
that all the compressed formats we care about have either 4x4 or 4x8 blocks
(in pixels) that consume either 64, 128, or maybe 256 bytes of memory per
block.  In any case, it is always a power of two and I am sure about that.
More detail about formats can be found in main/formats.csv.

--Jason

> maybe:
> assert((mt->qpitch % mt->align_w) == 0);
>
> I dunno. Looks good assuming the compressed texture thing isn't an issue.
> Reviewed-by: Ben Widawsky <ben at bwidawsk.net>
>
>
> >     } else if (brw->gen >= 9) {
> >        GLenum base_format;
> >
> > --
> > 1.9.3
> >
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150227/42beeaa0/attachment.html>


More information about the mesa-dev mailing list