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