On 04/19/2017 03:23 PM, Ilia Mirkin wrote:
On Wed, Apr 19, 2017 at 5:47 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
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.
OK, so I think this is an important question. My understanding is that
this shouldn't compile. Furthermore, my understanding is that
layout (bound_sampler) uniform sampler2D a;
void main() {
sampler2D tmp = a;
}
IIRC, this compiles with NV. Anyways, I'm looking into an alternative
solution, I will also test more corner cases with NV and reply later
with a complete analysis. Thank you for all your feedbacks!
should also not compile. We should try to get a ruling on that from
the existing impls. If that is not the case, then this needs a
rethink, at least on my part :) It would force all the textures to
become bindless when that happens. This would obviously be supportable
on NVIDIA (it's all bindless), but there are two instructions for
loading stuff from textures, one which is "semi-bound", one which is
fully "indirect". I'm not sure why those two would exist if there
weren't some advantage to using the "semi-bound" one when possible.
[What I mean by semi-bound is that it reads the handle from a
dedicated constbuf, you pass in the offset into that constbuf. The
fully indirect one, you just pass in the handle to the op directly.]
Cheers,
-ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev