[Mesa-dev] [PATCH 00/50] GL_ARB_gpu_shader_int64... this time for sure!

[Connor Abbott]

On Mon, Dec 5, 2016 at 3:22 PM, Matt Turner <mattst88 at gmail.com> wrote:
> On 12/05, Matt Turner wrote:
>>
>> On 11/28, Ian Romanick wrote:
>>>
>>> From: Ian Romanick <ian.d.romanick at intel.com>
>>>    Patches 42 through 50 enable the extension on BDW+.
>>
>>
>> 42-48 are
>>
>> Reviewed-by: Matt Turner <mattst88 at gmail.com>
>>
>> I don't understand the 64-bit CMP issue, so I'm booting a SKL to see how
>> fp64 works.
>
>
> Ah, I think  I see. Because 16x doubles take up 4 registers, we have to
> emit two CMP instructions, one with 1Q and one with 2Q:
>
> cmp.ge.f0(8)    null<1>DF       g2.2<0,1,0>DF   (abs)g11<4,4,1>DF { align1
> 1Q };
> cmp.ge.f0(8)    null<1>DF       g2.2<0,1,0>DF   (abs)g7<4,4,1>DF { align1 2Q
> };
>
> (from fs-op-add-double-double.shader_test)
>
> Makes sense to me. 49 is
>
> Reviewed-by: Matt Turner <mattst88 at gmail.com>

Actually, it's something a little different. The splitting you're
talking about is handled just fine by curro's SIMD lowering pass. The
issue here is that if you don't specify a null destination register
(in which case this a moot point), CMP will always output the same
destination bitsize as the source bitsize. That is, if you compare two
registers with 8 doubles each (two SIMD8 registers each), the result
will take up two SIMD8 registers instead of one as you'd expect. I
couldn't track this down in the PRM, but I definitely remember having
to implement it and getting wrong results without it. The end result
is that you have to use a strided move to get the low 32 bits of each
64-bit destination channel, which is what subscript() does. This
happens irrespective of whether you're compiling for SIMD8 or SIMD16.
Of course, in this case some backend optimizations have managed to
remove the destination register, so that's why you don't see it here,
but if you do something trickier, like store the result to a buffer,
the strided mov will be there.

Anyways, that's what I remember of it... it's been a while.

>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>