[Mesa-dev] [RFC PATCH 03/26] glsl: introduce new base types for bindless samplers/images

[Dave Airlie]

On 19 April 2017 at 05:30, Samuel Pitoiset <samuel.pitoiset at gmail.com> wrote:
>
>
> On 04/18/2017 08:14 PM, Nicolai Hähnle wrote:
>>
>> On 11.04.2017 18:48, Samuel Pitoiset wrote:
>>>
>>> Bindless sampler/image types are really different from the existing
>>> sampler/image types. They are considered 64-bit unsigned integers,
>>> they can be declared as temporary, shader inputs/outputs and are
>>> non-opaque types.
>>>
>>> For these reasons, it looks more convenient to introduce new
>>> internal base types to the GLSL compiler, called
>>> GLSL_TYPE_BINDLESS_SAMPLER and respectively GLSL_TYPE_BINDLESS_IMAGE.
>>
>>
>> Sorry for taking so long to get to this series, but could you explain the
>> rationale here a bit more?
>
>
> No worries, all feedbacks are always welcome, even late. :)
>
> So, the bindless sampler/image types introduced in ARB_bindless_texture are
> really different from the "standard" ones.
>
> They are considered as 64-bit unsigned integers (not 32-bit) and they are
> non-opaque types. The latter means they can be declared as temporary
> variables, as shader inputs/outputs, inside an interface block, etc.
>
> That said, the current sampler/image types are opaque (cf,
> glsl_type::is_opaque()) and it seemed quite impossible to change the
> glsl_type helpers to fit my needs.
>
> I tried many different solutions before figuring this one which seems better
> for some reasons:
>
> - easy to make bindless sampler/image types 64-bit unsigned int
> - easy to make bindless sampler/image types non-opaque
> - should avoid breakage because the base type is different
> - reduce the amount of changes in most places in the compiler
>
> At the Gallium level, the changes are really small. Basically, if the type
> is a bindless sampler, the ir_dereference variable is visited and it can be
> considered as PROGRAM_UNIFORM or PROGRAM_TEMPORARY (for shader
> inputs/outputs).
>
> Hopefully, you are convinced now. :)

When I did my initial implementation I went with merged types, I don't think
it was a good idea either. Apart from making old non-bindless samples take up
twice as much space, there's a lot or corner cases.

Unless we hit some problem in the future where they need to be the same
type I'd say this is preferable.

Dave.