On Fri, Oct 21, 2016 at 5:13 PM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:
> Here brw_setup_vue_interpolation() is rewritten not to use the
> InterpQualifier
> array in gl_fragment_program which will allow us to remove it.
>
> This change also makes the code which is only used by gen4/5 more self
> contained
> as it now has its own gen5_fragment_program struct rather than storing the
> map
> in brw_context. This means the interpolation map will only get processed
> once
> and will get stored in the in memory cache rather than being processed
> everytime
> the fs changes.
>
> Also by calling this from the fs compile code rather than from the upload
> code
> and using the interpolation assigned there we can get rid of the
> BRW_NEW_INTERPOLATION_MAP flag.
>
> It might not seem ideal to add a gen5_fragment_program struct however by
> the end
> of this series we will have gotten rid of all the
> brw_{shader_stage}_program
> structs and replaced them with a generic brw_program struct so there will
> only
> be two program structs which is better than what we have now.
>
> V2: Don't remove BRW_NEW_INTERPOLATION_MAP from dirty_bit_map until the
> following
> patch to fix build error.
>
> V3 - Suggestions by Jason:
> - name struct gen4_fragment_program rather than gen5_fragment_program
> - don't use enum with memset()
> - create interp mode set helper and simplify logic to call it
> - add assert when calling function to show prog will never be NULL for
> gen4/5 i.e. no Vulkan
>
V3 is
Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net>
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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
