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

Dave Airlie airlied at gmail.com
Sat Jul 2 06:23:26 UTC 2016

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,

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.


More information about the mesa-dev mailing list