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

Samuel Pitoiset samuel.pitoiset at gmail.com
Thu Apr 20 17:51:22 UTC 2017



On 04/20/2017 07:47 PM, Nicolai Hähnle wrote:
> 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.

Sure, this can be improved later.

> 
> Cheers,
> Nicolai


More information about the mesa-dev mailing list