[Mesa-dev] [PATCH 14/30] intel/isl: Add an enum for describing auxiliary compression state
Jason Ekstrand
jason at jlekstrand.net
Wed May 31 15:35:22 UTC 2017
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
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?
> >
> > >
> > >
> > > > 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
> > > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170531/6c9cdbfd/attachment-0001.html>
More information about the mesa-dev
mailing list