[Mesa-dev] [PATCH 04/27] glsl: add basic arb_gpu_shader_int64 types

[Dave Airlie]

On 30 June 2016 at 08:26, Ian Romanick <idr at freedesktop.org> wrote:
> On 06/20/2016 02:02 PM, Dave Airlie wrote:
>> On 21 June 2016 at 04:29, Ian Romanick <idr at freedesktop.org> wrote:
>>> I sent feedback for this patch the first time. :)
>>>
>>> https://lists.freedesktop.org/archives/mesa-dev/2016-June/119945.html
>>
>> This reply for some reason isn't in my inbox at all. Not sure what ate it.
>>
>> To address the comments in it:
>>
>> Keeping the types together: NAK, we currently store 2-bits in
>> sampled_type which while wrong I don't feel like changing as part
>> of this series. Those two bits are enough to store int/uint/float. So
>> I'm open to reviewing follow on patches to making sampled_type
>> larger if people want it. The only place anyone does <= comparisons
>> is in the is_numeric bit. Really anyone doing that should be caught
>> in review as it's clearly not a great idea.
>
> That makes sense, but also yuk. :(  When we get support for 8-bit and
> 16-bit types, this "little" check function is going to get ugly.
>
>> I fixed the GLSL version checks, thanks.
>> I fixed the spacing for Matt, thanks.
>>
>> is_integer_32_64 is needed in IR validation where there are lots
>> of places we only allows 32-bit integer operations. I felt it was easier
>> to explicitly mark 64-bit validity as it's easy to compare to spec.
>
> I haven't dug deeply enough into the rest of the series, but I'll buy
> that.  We may still want to rename things (somehow) so that it doesn't
> get too messy with 8-bit and 16-bit.  I never want to type
> is_integer_8_16_32_64 ever again. :)

Sounds like the 8/16 addition could add an is_integer_type and 4 bitfields,
INTEGER_32 | INTEGER_8 etc.

It's really to define what IR ops are valid for some of the integer types.

but probably best done as part of the 8/16 bit addition.

Dave.