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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
