On Tue 06 Jun 2017, Jason Ekstrand wrote: > On Tue, Jun 6, 2017 at 6:00 PM, Chad Versace <c...@kiwitree.net> wrote: > > > On Tue 06 Jun 2017, Jason Ekstrand wrote: > > > On Tue, Jun 6, 2017 at 1:32 PM, Jason Ekstrand <ja...@jlekstrand.net> > > wrote: > > > > > > > On Tue, Jun 6, 2017 at 1:22 PM, Chad Versace <chadvers...@chromium.org > > > > > > > wrote: > > > > > > > >> On Fri 26 May 2017, Jason Ekstrand wrote: > > > > > > How about a section after the auxiliary compression ops section which > > goes > > > > into detail on each of the compression types and discusses which > > states are > > > > valid etc. > > > > > > > > > > How does this look: > > > > > > https://cgit.freedesktop.org/~jekstrand/mesa/commit/?h=wip/ > > i965-resolve-rework-v3&id=8478b102c99e3ec43ec687b3f4e52acb9acbd5ba > > > > > > I'll squash it in if you like it. > > > > Please squash that in, with fixes :) > > > > I don't believe the pass-through state is impossible with MCS, because > > there is no single surface for write to "pass through" to. The aux > > surface can never be ignored with MCS. Another bit of evidence for this > > is that there exists no MCS ambiguate op, and therefore no arrow can > > exist in the diagram that carries the "resolved" box to the > > pass-through" box. > > > > Too many negatives going on... I think you meant "I belive the > pass-through state is impossible" :-)
Right... sloppy me. > I do not agree. While no resolve has been written, one could easily do > so. It would be implemented most likely as a blit from the surface to > itself with MCS enabled on the source and disabled for the destination > followed by blasting the appropriate value into the MCS. Modulo issues > with the order in which pixels are dispatched (which I don't think is an > actual issue so long as SIMD > num_samples), the result should be a surface > in the pass-through state which can safely be rendered to with MCS > disabled. Now, why anyone would ever want to do that is beyond me. The > state which doesn't exist is the regular resolved state because, as with > CCS and MCS, the aux surface stores so little data, that there isn't really > any room for compression when the main surface contains valid data. Thanks for taking the time to explain that corner case to stubborn me. Such a state is so far outside of realistic usage that I failed to see it earlier. This patch, with extras squashed in, is Reviewed-by: Chad Versace <chadvers...@chromium.org> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev