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

Ilia Mirkin imirkin at alum.mit.edu
Thu Dec 17 09:45:44 PST 2015


On Thu, Dec 17, 2015 at 12:31 PM, Connor Abbott <cwabbott0 at gmail.com> wrote:
> 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.

Not sure if you guys are thinking about it, but a lot of these things
that apply to doubles also apply to ARB_gpu_shader_int64. While you
obviously don't need to support it now, you may want to keep it in
mind as you make design decisions.

Cheers,

  -ilia


More information about the mesa-dev mailing list