On 25 October 2011 17:08, Kenneth Graunke <<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>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(-) </div>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. </blockquote><div> 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. </div></div>