[Mesa-dev] [PATCH 1/3] glsl: correctly handle conversions between int and uint

Kenneth Graunke kenneth at whitecape.org
Mon Apr 18 13:13:25 PDT 2011


On 04/17/2011 11:39 PM, Bryan Cain wrote:
>  From the GLSL 1.30 specification, section 4.1.10 ("Implicit Conversions"):
>      "There are no implicit conversions between signed and unsigned integers."
>
> However, convert_component() was assuming that conversions between int and uint were implicit.

Hmm.  I'm not sure about this patch.

First of all, the comment above convert_component explicitly states that 
it implements the rules in section 5.4.1, "Conversion and Scalar 
Constructors", not section 4.1.10's "Implicit Conversions."  For 
historical reasons, there are two sets of rules (yes, it's confusing!).

The "constructor rules" do seem to allow int/uint conversions.  For 
example, I believe these are allowed:
   uvec4(1, 2, 3, 4)
   ivec4(1u, 2u, 3, 4)

However, the implicit conversion rules do not:
   2u + 3
is definitely not allowed.

We definitely need to do both kinds of semantic checking.

A separate question is whether we need explicit i2u and u2i operations 
in the IR.  I think i2u and u2i would be no-ops in almost every case 
since it's the same bits...just whether you interpret them as having a 
sign bit or not.  I think the idea was to just change the type:

(expression uint + (constant int (0)) (constant int (1)))

This is also why we don't have f2u, b2u, and u2b - they're the same for 
int and uint.  The one operation we do have, u2f, is because it does 
matter whether the source operand is interpreted as unsigned or not.

Still, this is awfully non-symmetric, so it may be worth having them...

I'll defer to Ian here.  If we do add patch 1/3, 3/3 looks good.

Thanks,
--Kenneth


More information about the mesa-dev mailing list