Closed jkwak-work closed 1 month ago
I understand the change is to make the definitions more conformant to glsl, but does it have any downside to allow more texture types?
I tested the question.
It seems this change is not be required if we prefer functionality over conformance to GLSL as described.
example of functionally working:
#version 450 core
#extension GL_EXT_texture_shadow_lod : enable
RWStructuredBuffer<float> outputBuffer;
uniform Sampler1D<vector<float,3>> uniform_sampler1D;
[numthreads(4, 1, 1)]
void computeMain(uint3 dispatchThreadID : SV_DispatchThreadID)
{
outputBuffer[0] = textureLod(uniform_sampler1D, 0, 0).z;
}
Thanks for the comments and also for the testing. Honestly I didn't think more than thinking about the GLSL conformance. And it appears that my understanding was incorrect based on my testing that is similar to what Ariel did. I am abandoning this change.
GLSL supports only four types for textures: vec4, ivec4, uvec4, and float. The generic parameterization for the vector element count is not needed for the GLSL texture functions.
In other words,
N
is removed from__generic
and it is replaced with4
.