On 01/08/2015 10:59 PM, Matt Turner wrote:
> + if ((then_rhs->is_one() || then_rhs->is_negative_one()) &&
> + (else_rhs->is_one() || else_rhs->is_negative_one())) {
> + assert(then_rhs->is_one() == else_rhs->is_negative_one());
> + assert(else_rhs->is_one() == then_rhs->is_negative_one());
I'm adapting this code to do some other tricks... why did you use this
logic instead of
if ((then_rhs->is_one() && else_rhs->is_negative_one()) ||
(else_rhs->is_one() && then_rhs->is_negative_one())) {
It seems like that's what you actually want.
The reason I ask is in my adaptation I'm hitting some cases where the
assertion fails. This is from code like:
if (gl_FrontFacing)
gl_FragColor = vec4(0.0, 1.0, 0.0, 1.0);
else
gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
After channel expressions, I end up with the equivalent of
gl_FragColor.w = mix(1.0, 1.0, gl_FrontFacing);
I already have the obvious pass that fixes those, so it's not a huge deal.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
