[Mesa-dev] [PATCH 14/30] intel/isl: Add an enum for describing auxiliary compression state
Pohjolainen, Topi
topi.pohjolainen at gmail.com
Wed May 31 17:58:27 UTC 2017
On Wed, May 31, 2017 at 08:35:22AM -0700, Jason Ekstrand wrote:
> On Wed, May 31, 2017 at 5:40 AM, Pohjolainen, Topi <
> topi.pohjolainen at gmail.com> wrote:
>
> > On Tue, May 30, 2017 at 08:29:55PM +0300, Pohjolainen, Topi wrote:
> > > On Tue, May 30, 2017 at 07:32:24AM -0700, Jason Ekstrand wrote:
> > > > On Tue, May 30, 2017 at 1:43 AM, Pohjolainen, Topi <
> > > > topi.pohjolainen at gmail.com> wrote:
> > > >
> > > > > On Fri, May 26, 2017 at 04:30:18PM -0700, Jason Ekstrand wrote:
> > > > > > This enum describes all of the states that a auxiliary compressed
> > > > > > surface can have. All of the states as well as normative language
> > for
> > > > > > referring to each of the compression operations is provided in the
> > > > > > truly colossal comment for the new isl_aux_state enum. There is
> > also
> > > > > > a diagram showing how surfaces move between the different states.
> > > > > > ---
> > > > > > src/intel/isl/isl.h | 142 ++++++++++++++++++++++++++++++
> > > > > ++++++++++++++++++++++
> > > > > > 1 file changed, 142 insertions(+)
> > > > > >
> > > > > > diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> > > > > > index b9d8fa8..df6d3e3 100644
> > > > > > --- a/src/intel/isl/isl.h
> > > > > > +++ b/src/intel/isl/isl.h
> > > > > > @@ -560,6 +560,148 @@ enum isl_aux_usage {
> > > > > > ISL_AUX_USAGE_CCS_E,
> > > > > > };
> > > > > >
> > > > > > +/**
> > > > > > + * Enum for keeping track of the state an auxiliary compressed
> > surface.
> > > > > > + *
> > > > > > + * For any given auxiliary surface compression format (HiZ, CCS,
> > or
> > > > > MCS), any
> > > > > > + * given slice (lod + array layer) can be in one of the six states
> > > > > described
> > > > > > + * by this enum. Draw and resolve operations may cause the slice
> > to
> > > > > change
> > > > > > + * from one state to another. The six valid states are:
> > > > > > + *
> > > > > > + * 1) Clear: In this state, each block in the auxiliary
> > surface
> > > > > contains a
> > > > > > + * magic value that indicates that the block is in the clear
> > > > > state. If
> > > > > > + * a block is in the clear state, it's values in the primary
> > > > > surface are
> > > > > > + * ignored and the color of the samples in the block is
> > taken
> > > > > either the
> > > > > > + * RENDER_SURFACE_STATE packet for color or
> > 3DSTATE_CLEAR_PARAMS
> > > > > for
> > > > > > + * depth. Since neither the primary surface nor the
> > auxiliary
> > > > > surface
> > > > > > + * contains the clear value, the surface can be cleared to a
> > > > > different
> > > > > > + * color by simply changing the clear color without
> > modifying
> > > > > either
> > > > > > + * surface.
> > > > > > + *
> > > > > > + * 2) Compressed w/ Clear: In this state, neither the
> > auxiliary
> > > > > surface
> > > > > > + * nor the primary surface has a complete representation of
> > the
> > > > > data.
> > > > > > + * Instead, both surfaces must be used together or else
> > rendering
> > > > > > + * corruption may occur. Depending on the auxiliary
> > compression
> > > > > format
> > > > > > + * and the data, any given block in the primary surface may
> > > > > contain all,
> > > > > > + * some, or none of the data required to reconstruct the
> > actual
> > > > > sample
> > > > > > + * values. Blocks may also be in the clear state (see
> > Clear) and
> > > > > have
> > > > > > + * their value taken from outside the surface.
> > > > > > + *
> > > > > > + * 3) Compressed w/o Clear: This state is identical to the
> > state
> > > > > above
> > > > > > + * except that no blocks are in the clear state. In this
> > state,
> > > > > all of
> > > > > > + * the data required to reconstruct the final sample values
> > is
> > > > > contained
> > > > > > + * in the auxiliary and primary surface and the clear value
> > is not
> > > > > > + * considered.
> > > > > > + *
> > > > > > + * 4) Resolved: In this state, the primary surface contains
> > 100% of
> > > > > the
> > > > > > + * data. The auxiliary surface is also valid so the
> > surface can
> > > > > be
> > > > > > + * validly used with or without aux enabled. The auxiliary
> > > > > surface may,
> > > > > > + * however, contain non-trivial data and any update to the
> > primary
> > > > > > + * surface with aux disabled will cause the two to get out
> > of
> > > > > sync.
> > > > > > + *
> > > > > > + * 5) Pass-through: In this state, the primary surface
> > contains
> > > > > 100% of the
> > > > > > + * data and every block in the auxiliary surface contains a
> > magic
> > > > > value
> > > > > > + * which indicates that the auxiliary surface should be
> > ignored
> > > > > and the
> > > > > > + * only the primary surface should be considered. Updating
> > the
> > > > > primary
> > > > > > + * surface without aux works fine and can be done
> > repeatedly in
> > > > > this
> > > > > > + * mode. Writing to a surface in pass-through mode with aux
> > > > > enabled may
> > > > > > + * cause the auxiliary buffer to contain non-trivial data
> > and no
> > > > > longer
> > > > > > + * be in the pass-through state.
> > > > > > + *
> > > > > > + * 5) Aux Invalid: In this state, the primary surface
> > contains 100%
> > > > > of the
> > > > > > + * data and the auxiliary surface is completely bogus. Any
> > > > > attempt to
> > > > > > + * use the auxiliary surface is liable to result in
> > rendering
> > > > > > + * corruption. The only thing that one can do to re-enable
> > aux
> > > > > once
> > > > > > + * this state is reached is to use an ambiguate pass to
> > > > > transition into
> > > > > > + * the pass-through state.
> > > > > > + *
> > > > > > + * Drawing with or without aux enabled may implicitly cause the
> > surface
> > > > > to
> > > > > > + * transition between these states. There are also four types of
> > > > > "resolve"
> > > > > > + * operations which cause an explicit transition:
> > > > > > + *
> > > > > > + * 1) Fast Clear: This operation writes the magic "clear"
> > value to
> > > > > the
> > > > > > + * auxiliary surface. This operation will safely
> > transition any
> > > > > slice
> > > > > > + * of a surface from any state to the clear state so long
> > as the
> > > > > entire
> > > > > > + * slice is fast cleared at once.
> > > > > > + *
> > > > > > + * 2) Full Resolve: This operation combines the auxiliary
> > surface
> > > > > data
> > > > > > + * with the primary surface data and writes the result to
> > the
> > > > > primary.
> > > > > > + * For CCS resolves, this operation is destructive in the
> > sense
> > > > > that it
> > > > > > + * also sets the auxiliary surface to the pass-through
> > mode. For
> > > > > HiZ,
> > > > >
> > > > > In the diagram below this ends up in "Resolved" state which in the
> > diagram
> > > > > is not the same as "Passthrough". It stroke me odd that "Draw w/o
> > Aux"
> > > > > transitions it to "Aux Invalid". This is true for HIZ but not for
> > CCS. In
> > > > > case
> > > > > of CCS one should actually be in "Passthrough" where "Draw w/o Aux"
> > > > > maintains
> > > > > the state.
> > > > >
> > > >
> > > > Right. The CCS full resolve is not only a resolve but also an
> > ambiguate.
> > > > Does that make it make sense? I'm happy to document it better.
> > >
> > > It makes sense, I was just thinking the diagram where "Full Resolve"
> > should
> > > move CCS directly to "Passthrough". But it looks difficult to draw, CCS
> > and
> > > HIZ having their own special "Full Resolve" transitions.
> >
> > And now reading patch 27 and get_ccs_d_resolve_op(). There you (correctly)
> > mark RESOLVED and AUX_INVALID as unreachable for CCS. I hope there would be
> > some way of reflecting that in the diagram.
> >
>
> I don't think the diagram is actually wrong. In my view, what's going on
I didn't think it was wrong either, just a little misleading.
> is that the CCS full resolve operation goes further and follows two arrows
> instead of just the one. I've updated the comment above as follows:
>
> * 2) Full Resolve: This operation combines the auxiliary surface data
> * with the primary surface data and writes the result to the primary.
> * For HiZ, the docs call this a depth resolve. For CCS, the hardware
> * full resolve operation does both a full resolve and an ambiguate so
> * it actually takes you all the way to the pass-through state.
>
> Is that any better?
Sounds good, thanks!
Reviewed-by: Topi Pohjolainen <topi.pohjolainen at intel.com>
>
>
> > >
> > > >
> > > >
> > > > > Other than that this is really nice piece of documentation!!
> > > > >
> > > >
> > > > Thanks. It helped me quite a bit while trying to reason about all
> > this.
> > > >
> > > >
> > > > > > + * it is not destructive.
> > > > > > + *
> > > > > > + * 3) Partial Resolve: This operation considers blocks which
> > are in
> > > > > the
> > > > > > + * "clear" state and writes the clear value directly into
> > the
> > > > > primary or
> > > > > > + * auxiliary surface. Once this operation completes, the
> > surface
> > > > > is
> > > > > > + * still compressed but no longer references the clear
> > color.
> > > > > This
> > > > > > + * operation is only available for CCS.
> > > > > > + *
> > > > > > + * 4) Ambiguate: This operation throws away the current
> > auxiliary
> > > > > data and
> > > > > > + * replaces it with the magic pass-through value. If an
> > ambiguate
> > > > > > + * operation is performed when the primary surface does not
> > > > > contain 100%
> > > > > > + * of the data, data will be lost. This operation is only
> > > > > implemented
> > > > > > + * in hardware for depth where it is called a HiZ resolve.
> > > > > > + *
> > > > > > + * Not all operations are valid or useful in all states. The
> > diagram
> > > > > below
> > > > > > + * contains a complete description of the states and all valid and
> > > > > useful
> > > > > > + * transitions except clear.
> > > > > > + *
> > > > > > + * Draw w/ Aux
> > > > > > + * +----------+
> > > > > > + * | |
> > > > > > + * | +-------------+ Draw w/ Aux +-------------+
> > > > > > + * +------>| Compressed |<---------------------| Clear |
> > > > > > + * | w/ Clear | | |
> > > > > > + * +-------------+ +-------------+
> > > > > > + * | | |
> > > > > > + * Partial | | |
> > > > > > + * Resolve | | Full Resolve |
> > > > > > + * | +----------------------------+ | Full
> > > > > > + * | | | Resolve
> > > > > > + * Draw w/ aux | | |
> > > > > > + * +----------+ | | |
> > > > > > + * | | \|/ \|/ \|/
> > > > > > + * | +-------------+ Full Resolve +-------------+
> > > > > > + * +------>| Compressed |--------------------->| Resolved |
> > > > > > + * | w/o Clear |<---------------------| |
> > > > > > + * +-------------+ Draw w/ Aux +-------------+
> > > > > > + * /|\ | |
> > > > > > + * | Draw | | Draw
> > > > > > + * | w/ Aux | | w/o Aux
> > > > > > + * | Ambiguate | |
> > > > > > + * | +----------------------------+ |
> > > > > > + * Draw w/o Aux | | | Draw
> > w/o
> > > > > Aux
> > > > > > + * +----------+ | | |
> > > > > +----------+
> > > > > > + * | | | \|/ \|/ |
> > > > > |
> > > > > > + * | +-------------+ Ambiguate +-------------+
> > > > > |
> > > > > > + * +------>| Pass- |<---------------------| Aux
> > > > > |<------+
> > > > > > + * | through | | Invalid |
> > > > > > + * +-------------+ +-------------+
> > > > > > + *
> > > > > > + *
> > > > > > + * As referenced in the description of the different operations
> > above,
> > > > > not all
> > > > > > + * auxiliary surface formats actually support all of the above
> > modes.
> > > > > With
> > > > > > + * HiZ, for instance, does not have a partial resolve operation
> > so the
> > > > > two
> > > > > > + * "compressed" modes are the same. With CCS, the resolve
> > operation is
> > > > > > + * destructive and takes you directly to passthrough so the
> > "resolved"
> > > > > state
> > > > > > + * doesn't really exist. However, if you consider the CCS resolve
> > > > > operation
> > > > > > + * as doing a resolve and then an ambiguate, the diagram is still
> > > > > accurate.
> > > > > > + */
> > > > > > +enum isl_aux_state {
> > > > > > + /** Describes the Clear state */
> > > > > > + ISL_AUX_STATE_CLEAR = 0,
> > > > > > + /** Describes the Compressed w/ Clear state */
> > > > > > + ISL_AUX_STATE_COMPRESSED_CLEAR,
> > > > > > + /** Describes the Compressed w/o Clear state */
> > > > > > + ISL_AUX_STATE_COMPRESSED_NO_CLEAR,
> > > > > > + /** Describes the Resolved state */
> > > > > > + ISL_AUX_STATE_RESOLVED,
> > > > > > + /** Describes the Pass-through state */
> > > > > > + ISL_AUX_STATE_PASS_THROUGH,
> > > > > > + /** Describes the Aux Invalid state */
> > > > > > + ISL_AUX_STATE_AUX_INVALID,
> > > > > > +};
> > > > > > +
> > > > > > /* TODO(chadv): Explain */
> > > > > > enum isl_array_pitch_span {
> > > > > > ISL_ARRAY_PITCH_SPAN_FULL,
> > > > > > --
> > > > > > 2.5.0.400.gff86faf
> > > > > >
> > > > > > _______________________________________________
> > > > > > mesa-dev mailing list
> > > > > > mesa-dev at lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > > > >
> >
More information about the mesa-dev
mailing list