<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 31, 2017 at 2:15 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, May 26, 2017 at 04:30:19PM -0700, Jason Ekstrand wrote:<br>
</span><div><div class="h5">> This commit adds a new unified interface for doing resolves.  The basic<br>
> format is that, prior to any surface access such as texturing or<br>
> rendering, you call intel_miptree_prepare_access.  If the surface was<br>
> written, you call intel_miptree_finish_write.  These two functions take<br>
> parameters which tell them whether or not auxiliary compression and fast<br>
> clears are supported on the surface.  Later commits will add wrappers<br>
> around these two functions for texturing, rendering, etc.<br>
> ---<br>
>  src/mesa/drivers/dri/i965/<wbr>intel_mipmap_tree.c | 156 +++++++++++++++++++++++++-<br>
>  src/mesa/drivers/dri/i965/<wbr>intel_mipmap_tree.h |  80 +++++++++++++<br>
>  2 files changed, 232 insertions(+), 4 deletions(-)<br>
><br>
> diff --git a/src/mesa/drivers/dri/i965/<wbr>intel_mipmap_tree.c b/src/mesa/drivers/dri/i965/<wbr>intel_mipmap_tree.c<br>
> index 6cd32ce..0659e75 100644<br>
> --- a/src/mesa/drivers/dri/i965/<wbr>intel_mipmap_tree.c<br>
> +++ b/src/mesa/drivers/dri/i965/<wbr>intel_mipmap_tree.c<br>
> @@ -2028,8 +2028,7 @@ bool<br>
>  intel_miptree_all_slices_<wbr>resolve_hiz(struct brw_context *brw,<br>
>                                    struct intel_mipmap_tree *mt)<br>
>  {<br>
> -   return intel_miptree_depth_hiz_<wbr>resolve(brw, mt,<br>
> -                                          0, UINT32_MAX, 0, UINT32_MAX,<br>
> +   return intel_miptree_depth_hiz_<wbr>resolve(brw, mt, 0, UINT32_MAX, 0, UINT32_MAX,<br>
>                                            BLORP_HIZ_OP_HIZ_RESOLVE);<br>
>  }<br>
><br>
> @@ -2037,8 +2036,7 @@ bool<br>
>  intel_miptree_all_slices_<wbr>resolve_depth(struct brw_context *brw,<br>
>                                      struct intel_mipmap_tree *mt)<br>
>  {<br>
> -   return intel_miptree_depth_hiz_<wbr>resolve(brw, mt,<br>
> -                                          0, UINT32_MAX, 0, UINT32_MAX,<br>
> +   return intel_miptree_depth_hiz_<wbr>resolve(brw, mt, 0, UINT32_MAX, 0, UINT32_MAX,<br>
>                                            BLORP_HIZ_OP_DEPTH_RESOLVE);<br>
>  }<br>
><br>
> @@ -2221,6 +2219,156 @@ intel_miptree_all_slices_<wbr>resolve_color(struct brw_context *brw,<br>
>     intel_miptree_resolve_color(<wbr>brw, mt, 0, UINT32_MAX, 0, UINT32_MAX, flags);<br>
>  }<br>
><br>
> +void<br>
> +intel_miptree_prepare_access(<wbr>struct brw_context *brw,<br>
> +                             struct intel_mipmap_tree *mt,<br>
> +                             uint32_t start_level, uint32_t num_levels,<br>
> +                             uint32_t start_layer, uint32_t num_layers,<br>
> +                             bool aux_supported, bool fast_clear_supported)<br>
<br>
</div></div>Well, I might as well throw in my preference on using enumarated flags instead<br>
of booleans. In call sites, for exmaple,<br>
<br>
intel_miptree_prepare_access(<wbr>brw, mt, start_level, num_levels,<br>
                             start_layer, num_layers,<br>
                             INTEL_SUPPORT_AUX | INTEL_SUPPORT_FAST_CLEAR);<br>
<br>
is more informative than<br>
<br>
intel_miptree_prepare_access(<wbr>brw, mt, start_level, num_levels,<br>
                             start_layer, num_layers,<br>
                             true, true);<br></blockquote><div><br></div><div>Yeah, it is.  I'll give it a go and see what it looks like.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Former also allows adding more flags without changing the signature.<br>
</blockquote></div><br></div><div class="gmail_extra">I'm not sure if that's actually a feature... People tend to expand flags fields without thinking about what they're doing. :-)  But I agree that labels are nice.<br></div></div>