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

Nicolai Hähnle nhaehnle at gmail.com
Thu Apr 20 17:47:04 UTC 2017


On 20.04.2017 16:54, Samuel Pitoiset wrote:
[snip]
>>>> Yes, contains_opaque() not is_opaque(). Well, how do you plan to handle
>>>> the fact that bindless sampler types are 64-bit? It seemed quite
>>>> logical
>>>> to make glsl_type::is_64bit() returns true for them.
>>>
>>> So, for the purposes of src/compiler/glsl/, I think it simply
>>> shouldn't matter whether is_64bit returns true or not. However, I
>>> agree that for st/glsl_to_tgsi, it'd probably be very helpful to make
>>> is_64bit return true for them.
>>
>> One new restriction is glsl_type::component_slots(). With the new base
>> types it's easy to return something similar to uint64_t (ie. 2
>> components if it's BINDLESS_SAMPLER). However, without a separate type
>> it returns 0 for samplers and 1 for images.
>>
>> glsl_type is a quite good interface for base types, but for bindless
>> sampler we just can't store the information there. Currently, the only
>> way to know if a sampler is bindless is to have access to a
>> ir_variable object.
>>
>> I don't see how to solve this properly without adding hacks. The way
>> glsl_type is designed is one of the argument for the current solution.
>>
>> Any thoughts?
>
> It's allowed by the spec to count samplers/images as two components. So
> component_slots() can return N*2 like uint64_t. However,
> glsl_type::components() currently returns 0 for sampler types because
> matrix_columns and vector_elements are 0 (while 1 for image types).
>
> I think this needs to be clarified and components() should return 1 for
> sampler and image types.

I agree that this makes more sense.

Just to bring some more of the offline discussion back to the mailing 
list, we also realized that in current master, every sampler uniform 
actually occupies 16 bytes (one vec4 slot) in the constant buffer, so 
having the component_slots() increased from 1 to 2 is not a regression 
in terms of performance or anything like that.

It'd make sense to improve the code that maps default block uniforms to 
driver memory in a way such that old-style samplers / bound_samplers do 
not take up any space at all (and while we're at it, we might want to 
pack uniforms that are smaller than a vec4), but I think that that's a 
separate concern from ARB_bindless_texture.

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.


More information about the mesa-dev mailing list