On 04/07/2014 11:00 AM, Matt Turner wrote: > On Sun, Apr 6, 2014 at 11:49 PM, Kenneth Graunke <kenn...@whitecape.org> > wrote: >> Integer shifts are basically always well supported and efficient; that >> isn't always true of integer division, and sometimes even integer >> multiplication isn't without issues. >> >> On some Intel hardware, INTDIV can't be used in SIMD16 mode. It also >> doesn't support immediate operands (on any generation), while ASR can. >> >> On Haswell, this cuts the number of instructions in dolphin/efb2ram by >> 7.94%. It also removes a single MOV in dolphin/realxfb (due to ASR >> supporting immediates), and gains SIMD16 support (due to no INTDIV). > > Just a note that the upstream shaders have already been changed to not > do integer division. That's the reason I didn't bother fixing up my > patch a couple of weeks ago.
Sure. I was actually looking at a different program (some webgl demo)
when I started implementing this, though. Seems generally useful.
[snip]
>> + ir_constant_data shift_data;
>> + for (int i = 0; i < const_op->type->vector_elements; i++) {
>> + if (const_op->type->base_type == GLSL_TYPE_INT &&
>> + const_op->value.i[i] <= 0) {
>> + /* Negative values aren't powers of two. */
>
> I was going to comment on the is_power_of_two() function returning
> true for 0 and how this was going to break things, but I see this
> check for <= 0 should handle it.
Right.
> I don't know what is_power_of_two() should return for zero. The
> comment "Negative values" would be more correct if we returned false
> from is_power_of_two() though.
Not sure either. I just moved the function from i965, and also found
that Gallium's u_math.h has a util_is_power_of_two() function which is
implemented identically - that's actually where the comment comes from.
--Ken
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
