On 19.04.2017 11:09, Nicolai Hähnle wrote:
At least I haven't seen anything in the spec to contradict that.
Side note: As far as I can tell, you're even allowed to do:
layout (bound_sampler) uniform sampler2D tex;
...
uvec2 handle = uvec2(tex);
I think this is correct as well, at least it compiles with NV. However,
it makes just no sense to me. The spec says:
"The error INVALID_OPERATION is generated by UniformHandleui64{v}ARB if
the sampler or image uniform being updated has the "bound_sampler" or
"bound_image" layout qualifier.""
So, you can only assign a 32-bit uniform here, converting to a pair of
32-bit will make the .y component 0.
The way I understand it, converting to uvec2 should give a pointer to
the descriptor (at least for the GCN backend).
So bound_samplers are implemented as simply old-style samplers living in
the good old descriptor table. When they are converted to uvec2, we need
to emit code that returns a pointer into that descriptor table. That's a
fully 64-bit value.
By the way, this is also how Ilia's example would be implemented. When
inlined, it could become something like:
layout (bound_sampler) uniform sampler2D u_tex;
in sampler2D in_tex;
void main()
{
...
sampler2D tmp = foo ? u_tex : in_tex;
vec4 color = texture2D(tmp, ...);
}
This should compile. At the GLSL level, the type is always sampler2D. At
the TGSI and LLVM IR level, u_tex is converted to a 64-bit value at the
point of the ?: operation. To keep the craziness low in TGSI, there
should probably be some S2U64 instruction for explicitly converting
old-style samplers/images to 64-bit values, even though most cases of
explicit conversion between sampler types and uvec2 are actually no-ops
in TGSI.
Cheers,
Nicolai
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
