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

[Ian Romanick]

On 12/05/2016 10:31 AM, Matt Turner wrote:
> On Wed, Nov 30, 2016 at 1:11 PM, Matt Turner <mattst88 at gmail.com> wrote:
>> On 11/28, Ian Romanick wrote:
>>>
>>> From: Ian Romanick <ian.d.romanick at intel.com>
>>>
>>> I believe that I have addressed all of the review feedback from the
>>> previous iteration.  Many of the patches have been reviewed, and they
>>> should be ready to go.
>>>
>>> Patches marked with "vN" in the subject have changed in a non-trivial
>>> way since last being sent to he list.
>>>
>>> Several patches that have not changed need review:
>>>
>>>    Patches 23 through 33 add lowering passes for 64-bit operations.
>>
>> I sent a few comments, and I cannot claim to have verified the division
>> routine, but the rest are
>>
>> Reviewed-by: Matt Turner <mattst88 at gmail.com>
> 
> Having thought more about this, I think doing this in GLSL IR is not
> the way we should be going.
> 
> Presumably we're going to want to support int64 in SPIR-V, and that
> necessitates lowering these operations in NIR.
> 
> I don't think it's a good idea to do this outside of NIR.

With this series and a follow-on series that will enable IVB, any GPU
that has real integers will be able to support int64.  The same will go
for fp64.  This applies not only to i965 but also basically every
Gallium driver that is still maintained.  Getting int64 and fp64 "for
free" on a number of Mesa-supported GPUs seems like a good thing.
Requiring all of Gallium enable NIR is... much more expensive than free.

At some point, probably soon, we will want all of this for SPIR-V, and
that does mean we'll need NIR support.  There will still presumably be
users of the GLSL lowering even then.  My expectation is that the NIR
lowering would be implemented in a similar manner to the GLSL lowering,
but it will be a bunch more typing.

> Thoughts?