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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to