<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 31, 2017 at 11:09 AM, Pohjolainen, Topi <<a href="mailto:topi.pohjolainen@gmail.com" target="_blank">topi.pohjolainen@gmail.com</a>> wrote: <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 Wed, May 31, 2017 at 09:57:08AM -0700, Jason Ekstrand wrote: > On Wed, May 31, 2017 at 9:10 AM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> > wrote: > > > On Wed, May 31, 2017 at 2:15 AM, Pohjolainen, Topi < > > <a href="mailto:topi.pohjolainen@gmail.com">topi.pohjolainen@gmail.com</a>> wrote: > > > >> On Fri, May 26, 2017 at 04:30:19PM -0700, Jason Ekstrand wrote: > >> > This commit adds a new unified interface for doing resolves. The basic > >> > format is that, prior to any surface access such as texturing or > >> > rendering, you call intel_miptree_prepare_access. If the surface was > >> > written, you call intel_miptree_finish_write. These two functions take > >> > parameters which tell them whether or not auxiliary compression and fast > >> > clears are supported on the surface. Later commits will add wrappers > >> > around these two functions for texturing, rendering, etc. > >> > --- > >> > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 156 > >> +++++++++++++++++++++++++- > >> > src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 80 +++++++++++++ > >> > 2 files changed, 232 insertions(+), 4 deletions(-) > >> > > >> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c > >> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c > >> > index 6cd32ce..0659e75 100644 > >> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c > >> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c > >> > @@ -2028,8 +2028,7 @@ bool > >> > intel_miptree_all_slices_resolve_hiz(struct brw_context *brw, > >> > struct intel_mipmap_tree *mt) > >> > { > >> > - return intel_miptree_depth_hiz_resolve(brw, mt, > >> > - 0, UINT32_MAX, 0, UINT32_MAX, > >> > + return intel_miptree_depth_hiz_resolve(brw, mt, 0, UINT32_MAX, 0, > >> UINT32_MAX, > >> > BLORP_HIZ_OP_HIZ_RESOLVE); > >> > } > >> > > >> > @@ -2037,8 +2036,7 @@ bool > >> > intel_miptree_all_slices_resolve_depth(struct brw_context *brw, > >> > struct intel_mipmap_tree *mt) > >> > { > >> > - return intel_miptree_depth_hiz_resolve(brw, mt, > >> > - 0, UINT32_MAX, 0, UINT32_MAX, > >> > + return intel_miptree_depth_hiz_resolve(brw, mt, 0, UINT32_MAX, 0, > >> UINT32_MAX, > >> > BLORP_HIZ_OP_DEPTH_RESOLVE); > >> > } > >> > > >> > @@ -2221,6 +2219,156 @@ intel_miptree_all_slices_resolve_color(struct > >> brw_context *brw, > >> > intel_miptree_resolve_color(brw, mt, 0, UINT32_MAX, 0, UINT32_MAX, > >> flags); > >> > } > >> > > >> > +void > >> > +intel_miptree_prepare_access(struct brw_context *brw, > >> > + struct intel_mipmap_tree *mt, > >> > + uint32_t start_level, uint32_t num_levels, > >> > + uint32_t start_layer, uint32_t num_layers, > >> > + bool aux_supported, bool > >> fast_clear_supported) > >> > >> Well, I might as well throw in my preference on using enumarated flags > >> instead > >> of booleans. In call sites, for exmaple, > >> > >> intel_miptree_prepare_access(brw, mt, start_level, num_levels, > >> start_layer, num_layers, > >> INTEL_SUPPORT_AUX | > >> INTEL_SUPPORT_FAST_CLEAR); > >> > >> is more informative than > >> > >> intel_miptree_prepare_access(brw, mt, start_level, num_levels, > >> start_layer, num_layers, > >> true, true); > >> > > > > Yeah, it is. I'll give it a go and see what it looks like. > > > > > >> Former also allows adding more flags without changing the signature. > >> > > > > 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. > > > > I gave this a go. Take a look at the top patch on > > <a href="https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/</a> > i965-resolve-rework-v3 > > I'm not sure I actually like the result. Here's some thoughts: > > 1) It is somewhat more explicit what you support from the call. > > 2) If you don't support aux at all, then it becomes 0 which is less clear > than false, false. > > 3) Very few things call prepare_access directly. > > 4) Things are fairly firmly structured on the two bits right now. If > someone adds a third flag without thinking carefully about it and plumbing > it through to everything, they will break things. Having them be separate > parameters forces you to think about it at every stage. > > 5) I was renaming parameters in the special-case prepare_access functions > so, for instance, the HiZ version had hiz_supported and > fast_clear_supported. We can't do this anymore. > > 6) It's actually a bit more awkward to construct a set of flags than to > construct a pair of booleans. Not bad, but mildly annoying. </div></div>Agreed. Lets drop that idea. The more I read, the more I saw cases where you didn't just pass true or false but nicely named helper variables. All those cases would just get unnecessarily complicated with the flags. <div class="HOEnZb"><div class="h5"></div></div></blockquote><div> </div><div>Done. :) </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"> > > 7) It's unclear what to do with finish_write since it only takes one > boolean. > > All in all, I'm not incredibly pleased with the change. While I agree in > general that flags are better than a pile of bools, I think the bools make > more sense here given how many layers of plumbing there are. I'm willing > to change it if you really want but it doesn't seem all that compelling. </div></div></blockquote></div> </div></div>