[Mesa-dev] [PATCH V3] i965: rewrite brw_setup_vue_interpolation()

[Jason Ekstrand]

On Fri, Oct 21, 2016 at 5:13 PM, Timothy Arceri <
timothy.arceri at 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 <jason at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161024/d0c3b9de/attachment.html>