[Mesa-dev] [PATCH 10/95] i965/vec4: handle 32 and 64 bit channels in liveness analysis

[Francisco Jerez]

"Juan A. Suarez Romero" <jasuarez at igalia.com> writes:

> On Mon, 2016-08-08 at 16:12 +0200, Juan A. Suarez Romero wrote:
>> Hmm... what about the case of exec_size == 4 and writing just a
>> float? 
>> 
>> I understand in this case we only should mark one word, so the loop
>> should  not be 2*inst->regs_written.
>> 
>> Note that in the original patch that was the case for using offs ==
>> 0.
>> So I guess we should compute if we should use 1 or 2 times
>> regs_written.
>
>
> Thinking more carefully, I think it is fine using 2*regs_written/read
> in this case.
>

The fundamental problem is that regs_written is expressed in units of
whole GRFs, but SIMD4 single-precision instructions typically write less
than one GRF, which will cause you to overestimate the number of dwords
written or read by the instruction (that's exactly what I was referring
to earlier with losing accuracy with sub-GRF writes).

I wouldn't worry too much about this right now, because it will only
cause you to calculate slightly pessimistic live intervals for the
variables used in such instructions, and shouldn't ever lead to program
miscompilation.  Overriding the dwords-per-vec4-component factor
depending on the SIMD width of the instruction seems like a hack that
could potentially hurt more than it would help (What if a
single-precision SIMD4 instruction actually reads or writes the whole
GRF register because it has multiple output phases?  How do you know?).

The right solution would be to represent regs_written in units that give
you sufficient accuracy, but I think there is enough going on in this
series that I wouldn't bother to fix that in addition.  We hadn't been
using SIMD4 instructions in the vec4 back-end until now, which means
that this inaccuracy shouldn't affect existing code or lead to
performance regressions, and the FS back-end has exactly the same
problem so you could potentially fix both at the same time. ;)

> So forget about my comment!
>
>
> 	J.A.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160808/85e4a1fd/attachment.sig>