<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 6, 2017 at 10:11 PM, Chad Versace <span dir="ltr"><<a href="mailto:chad@kiwitree.net" target="_blank">chad@kiwitree.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue 06 Jun 2017, Jason Ekstrand wrote:<br>
> On Tue, Jun 6, 2017 at 6:00 PM, Chad Versace <<a href="mailto:chad@kiwitree.net">chad@kiwitree.net</a>> wrote:<br>
><br>
> > On Tue 06 Jun 2017, Jason Ekstrand wrote:<br>
> > > On Tue, Jun 6, 2017 at 1:32 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>><br>
> > wrote:<br>
> > ><br>
> > > > On Tue, Jun 6, 2017 at 1:22 PM, Chad Versace <<a href="mailto:chadversary@chromium.org">chadversary@chromium.org</a><br>
> > ><br>
> > > > wrote:<br>
> > > ><br>
> > > >> On Fri 26 May 2017, Jason Ekstrand wrote:<br>
> ><br>
> > > > How about a section after the auxiliary compression ops section which<br>
> > goes<br>
> > > > into detail on each of the compression types and discusses which<br>
> > states are<br>
> > > > valid etc.<br>
> > > ><br>
> > ><br>
> > > How does this look:<br>
> > ><br>
> > > <a href="https://cgit.freedesktop.org/~jekstrand/mesa/commit/?h=wip/" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/~<wbr>jekstrand/mesa/commit/?h=wip/</a><br>
> > i965-resolve-rework-v3&id=<wbr>8478b102c99e3ec43ec687b3f4e52a<wbr>cb9acbd5ba<br>
> > ><br>
> > > I'll squash it in if you like it.<br>
> ><br>
> > Please squash that in, with fixes :)<br>
> ><br>
> > I don't believe the pass-through state is impossible with MCS, because<br>
> > there is no single surface for write to "pass through" to. The aux<br>
> > surface can never be ignored with MCS. Another bit of evidence for this<br>
> > is that there exists no MCS ambiguate op, and therefore no arrow can<br>
> > exist in the diagram that carries the "resolved" box to the<br>
> > pass-through" box.<br>
> ><br>
><br>
> Too many negatives going on...  I think you meant "I belive the<br>
> pass-through state is impossible" :-)<br>
<br>
</div></div>Right... sloppy me.<br>
<span class=""><br>
> I do not agree.  While no resolve has been written, one could easily do<br>
> so.  It would be implemented most likely as a blit from the surface to<br>
> itself with MCS enabled on the source and disabled for the destination<br>
> followed by blasting the appropriate value into the MCS.  Modulo issues<br>
> with the order in which pixels are dispatched (which I don't think is an<br>
> actual issue so long as SIMD > num_samples), the result should be a surface<br>
> in the pass-through state which can safely be rendered to with MCS<br>
> disabled.  Now, why anyone would ever want to do that is beyond me.  The<br>
> state which doesn't exist is the regular resolved state because, as with<br>
> CCS and MCS, the aux surface stores so little data, that there isn't really<br>
> any room for compression when the main surface contains valid data.<br>
<br>
</span>Thanks for taking the time to explain that corner case to stubborn me.<br>
Such a state is so far outside of realistic usage that I failed to see<br>
it earlier.<br></blockquote><div><br></div><div>I'll freely admit that it's highly exotic and will never be seen in the wild.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This patch, with extras squashed in, is<br></blockquote><div><br></div><div>Done.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Reviewed-by: Chad Versace <<a href="mailto:chadversary@chromium.org">chadversary@chromium.org</a>><br></blockquote><div><br></div><div>Thanks!  And thank you for being careful and making me document even more things. <br></div></div><br></div></div>