[Mesa-dev] [PATCH 2/2] i965: Fix flat integral varyings.
Paul Berry
stereotype441 at gmail.com
Tue Oct 25 17:18:08 PDT 2011
On 25 October 2011 17:08, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On 10/25/2011 04:47 PM, Paul Berry wrote:
> > Previously, the vertex and fragment shader back-ends assumed that all
> > varyings were floats. In GLSL 1.30 this is no longer true--they can
> > also be of integral types provided that they have an interpolation
> > qualifier of "flat".
> >
> > This required two changes in each back-end: assigning the correct type
> > to the register that holds the varying value during shader execution,
> > and assigning the correct type to the register that ties the varying
> > value to the rest of the graphics pipeline (the message register in
> > the case of VS, and the payload register in the case of FS).
> >
> > Fixes piglit tests fs-int-interpolation and fs-uint-interpolation.
> > ---
> > src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++--
> > src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 4 +++-
> > 2 files changed, 5 insertions(+), 3 deletions(-)
>
> Now that I see the code, I'd honestly just update brw_type_for_base_type
> to do:
>
> if (type->is_array())
> type = type->element_type();
>
> and then change the GLSL_TYPE_ARRAY case to be an assert.
>
> brw_type_for_base_type was returning a bogus value before, and I'm
> pretty sure nothing depends on the prior behavior. This patch
> demonstrates a use where you really want it to return something
> sensible. I don't think the old bogus value (UD) is ever preferable to
> this new behavior.
>
> Then we don't need another odd "get related type" function, either.
>
That's what I was going to do at first too, but before I tried it I ran an
experiment to convince myself that nothing depended on the prior behavior: I
changed brw_type_for_base_type() to assert whenever it is called on an array
type, and then did a piglit run. Result: lots of assertion failures. Does
that experimental result change your opinion? It makes me worried that your
proposal will break some part of the shader back-ends that I don't
understand.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111025/566953a1/attachment.htm>
More information about the mesa-dev
mailing list