[Mesa-dev] [RFC PATCH 0/5] Skip automatic execsize for instructions with a width of 4

[Connor Abbott]

On Thu, Dec 17, 2015 at 11:44 AM, Matt Turner <mattst88 at gmail.com> wrote:
> On Wed, Dec 9, 2015 at 4:15 AM, Iago Toral Quiroga <itoral at igalia.com> wrote:
>> Right now we rely on the code at the bottom of brw_set_dest to set the correct execution size for anything that does not operate on a full SIMD register (dst.width < BRW_EXECUTE_8). However, this won't work with fp64, where operands are twice as big and we see instructions with a horizontal width of 4 that still require an execution size of 8. We cannot fix this by simply checking the type of the operands involved and skip the automatic execsize adjustment when they are doubles because we can also operate on doubles as integers (for pack and unpack operations for example).
>
> Can you give an example of when checking the type wouldn't be
> sufficient? Presumably packDouble2x32/unpackDouble2x32? What code do
> they generate? Could we look at the destination's stride as well?

Yes, packDouble2x32 is what would cause the same issue, since it turns
into two 32-bit MOV's with a destination stride of 2 (and offset of 0
and 1, ofc). We could check for the stride, but if we really don't
want to change this code, the better way to go would be to avoid the
width adjustment that causes this whole thing to happen for
destination registers, since everything other than this piece of code
ignores the destination width and vstride. But that being said, this
code is a hack since it breaks the assumption that fs_inst::exec_size
always equals the final ExecSize of the instruction, and Iago and I
agreed to fix it (or at least for now, do the portion of the fix
needed for fp64) rather than work around it.