<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 21, 2016 at 5:13 PM, Timothy Arceri <span dir="ltr"><<a href="mailto:timothy.arceri@collabora.com" target="_blank">timothy.arceri@collabora.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="">Here brw_setup_vue_interpolation() is rewritten not to use the InterpQualifier<br>
array in gl_fragment_program which will allow us to remove it.<br>
<br>
This change also makes the code which is only used by gen4/5 more self contained<br>
as it now has its own gen5_fragment_program struct rather than storing the map<br>
in brw_context. This means the interpolation map will only get processed once<br>
and will get stored in the in memory cache rather than being processed everytime<br>
the fs changes.<br>
<br>
Also by calling this from the fs compile code rather than from the upload code<br>
and using the interpolation assigned there we can get rid of the<br>
BRW_NEW_INTERPOLATION_MAP flag.<br>
<br>
It might not seem ideal to add a gen5_fragment_program struct however by the end<br>
of this series we will have gotten rid of all the brw_{shader_stage}_program<br>
structs and replaced them with a generic brw_program struct so there will only<br>
be two program structs which is better than what we have now.<br>
<br>
</span><span class="">V2: Don't remove BRW_NEW_INTERPOLATION_MAP from dirty_bit_map until the following<br>
patch to fix build error.<br>
<br>
</span>V3 - Suggestions by Jason:<br>
- name struct gen4_fragment_program rather than gen5_fragment_program<br>
- don't use enum with memset()<br>
- create interp mode set helper and simplify logic to call it<br>
- add assert when calling function to show prog will never be NULL for<br>
 gen4/5 i.e. no Vulkan<br><span class=""></span></blockquote><br></div><div class="gmail_quote">V3 is<br><br></div><div class="gmail_quote">Reviewed-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>><br><br></div><div class="gmail_quote">However, I trust Ken's opinion far more when it comes to atoms and the interactions between the different compile stages.  I'd like him to review this one too.<br></div><br></div></div>