[Mesa-dev] [PATCH] i965/fs: Change the type of booleans to UD and emit correct immediates

Jason Ekstrand jason at jlekstrand.net
Tue Oct 28 17:35:15 PDT 2014


On Tue, Oct 28, 2014 at 5:23 PM, Jason Ekstrand <jason at jlekstrand.net>
wrote:

>
>
>
> On Tue, Oct 28, 2014 at 12:29 PM, Matt Turner <mattst88 at gmail.com> wrote:
>
>> On Tue, Oct 28, 2014 at 12:10 PM, Jason Ekstrand <jason at jlekstrand.net>
>> wrote:
>> >
>> > On Oct 28, 2014 11:57 AM, "Matt Turner" <mattst88 at gmail.com> wrote:
>> >>
>> >> On Thu, Oct 16, 2014 at 3:40 PM, Jason Ekstrand <jason at jlekstrand.net>
>> >> wrote:
>> >> > Before, we used the a signed d-word for booleans and the immedates we
>> >> > emitted varried between signed and unsigned.  This commit changes the
>> >> > type
>> >> > to unsigned (I think that makes more sense) and makes immediates more
>> >> > consistent.  This allows copy propagation to work better cleans up
>> some
>> >> > instructions.
>> >> >
>> >> > total instructions in shared programs: 5473519 -> 5465864 (-0.14%)
>> >> > instructions in affected programs:     432849 -> 425194 (-1.77%)
>> >> > GAINED:                                27
>> >> > LOST:                                  0
>> >>
>> >> I assumed at first that this was on Haswell, but it couldn't be
>> >> because Haswell doesn't use 0/1 for boolean. What platform was this?
>> >
>> > It doesn't matter what form of booleans the arch uses.  I believe it
>> was on
>> > HSW.
>>
>> It's unclear to me how you're coming to that conclusion. None of the
>> hunks in brw_fs_visitor.cpp affect platforms where
>> Const.UniformBooleanTrue != 1.
>>
>
> Not true.  The real problem we were hitting was when we emitted a value
> from an ir_constant.  In this case, we emitted it as a copy from unsigned
> to signed regardless of your platform.  That was what was causing us extra
> instructions.  Most of the other changes are purely cosmetic because I
> decided to unify on UD rather than D.
>
>
>> I suppose the meaningful change in this patch for those platforms is
>> the one in brw_shader.cpp.
>>
>> > However, as I have mentioned in private, I've had trouble running
>> > shaderdb and believing the results.  They could be bogus but I don't
>> think
>> > so.
>>
>> Also unclear to me how you could not when I just tested it myself.
>>
>
> Re-running shader-db myself...
>

Ok, Now I'm seeing what you're seeing (go figure).  I wonder if something
broke...

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141028/f4ab5a31/attachment.html>


More information about the mesa-dev mailing list