* location aliasing
when location aliasing, the aliases sharing the location must have the same underlying numerical type
(floating-point or integer) and the same auxiliary storage and interpolation qualification.
The following case, glslang need report error.
layout(vertices = 1) out;
layout (location = 1, component = 0) in double gohan[];
layout (location = 1, component = 2) in float goten[];
in vec4 vs_tcs[];
out vec4 tcs_tes[];
void main()
{
}
* Need consider the following case: location aliasing with different interpolation qualifier.
Even for a double precision float, the largest valid exponent is 308, so
clamp exponents to 500 when parsing to avoid overflow of the parsed
exponent value if the exponent is too big.
coopmat<> type definition allows type parameters. To make it accept
types defined by spirv_type directive, we add spirvType info to the type
parameters. This change is to support this case. And a test is added to
show the missing usage.
The actual support has been available with GL_EXT_control_flow_attributes.
This change set is to handle
"#extension GL_EXT_control_flow_attributes2 : <val>"
Add support for GL_ARB_shading_language_include. Usage is identical to
the way GL_GOOGLE_include_directive currently works glslang (since
GL_ARB_shading_language_include is inherently a runtime feature and
glslang is an offline compiler).
Users can simulate their runtime environment by using a custom
glslang::TShader::Includer or using filenames that match their GL
runtime names.
Closes#249.
Since assert(0) compiles to nothing on release builds, it's not
sufficient to silence a fallthrough warning. Instead, some switch
statements are changed into if/else and others have the assert(0)
replaced with "return 0".
This is intended so that downstream projects consuming glslang with FetchContent or similar means can use `-Wimplicit-fallthrough` without getting warning spam.
I've used my best judgement to determine whether the implicit fallthrough was desired, or was simply unreachable code.
`std::unreachable` is unavailable until C++23, but I saw places where `default: assert(0);` was used, so copied that.
There were a few places where some code might actually have been reachable and intended to return a value that represented an error, so someone should double check that kind of thing.
Like with the last few PRs from me, it fixes a warning that's commonly enabled in downstream projects that might want to consume glslang via FetchContent or equivalent.
It doesn't actually enable the warning, but that might be desirable.
I think I found a bug in the Spv.FromFile.cpp tests that would have been prevented had this warning been enabled all along.
I had to guess the value for the missing field, so went for the most common one in the list.
The only test case that used a different value before had an RWTexture1D, so if baseImageBinding is meaning the same kind of image as image load store in OpenGL, it would make sense that that would be the only one to need a non-zero value for the binding.
I'm a little concerned that the test wasn't previously failing with the incorrectly-assigned fields as it implies they don't make any difference, so the test might be too permissive.
Co-authored-by: Neil Hickey <neil.hickey@arm.com>
Co-authored-by: Stuart Brady <stuart.brady@arm.com>
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
Oes spec says:
For the both the input array gl_SampleMaskIn[] and the output array gl_SampleMask[], bit B of mask M
(gl_SampleMaskIn[M] or gl_SampleMask[M]) corresponds to sample 32*M+B. These arrays have
ceil(gl_MaxSamples/32) elements, where gl_MaxSamples is the maximum number of color samples
supported by the implementation.
But glslang report error "array must have size before use length".
layout(location = 0) out mediump vec4 fragColor;
void main (void)
{
for (int i = 0; i < gl_SampleMask.length(); ++i)
gl_SampleMask[i] = int(0xAAAAAAAA);
fragColor = vec4(0.0, 1.0, 0.0, 1.0);
}
* Add two test items, one is for gl_MaxSapmles = 32 and the other one is for gl_MaxSapmles = 64.
Removes some of the pointers/"end markes" used in the BuiltInFuntion
versioning, replacing them with std::arrays and spans.
NOTE: The span class used is a copy of the span class that has been in
use in the Vulkan-ValidationLayers as a temporary solution until C++20
is available.
NOTE: The std::arrays could be constexprs, but this requires some extra
work pre-C++20, and is therefore not included in this change, but could
be done in a follow up PR.
According to the GLSL spec
Each number sign (#) can be preceded in its line only by spaces or horizontal tabs.
It may also be followed by spaces and horizontal tabs, preceding the directive.
This requires a small change to to use strncpy() instead of strcpy(),
as well as change of include paths to not use "..". The other warnings
are just not being hit anymore.
glslang representing literal constants with double precision, so 1.0e40 and 1.0e-50 are normal values.
Shader1：
precision highp float;
out vec4 my_FragColor;
void main()
{
// Out-of-range floats should overflow to infinity
// GLSL ES 3.00.6 section 4.1.4 Floats:
// "If the value of the floating point number is too large (small) to be stored as a single precision value, it is converted to positive (negative) infinity"
float correct = isinf(1.0e40) ? 1.0 : 0.0;
my_FragColor = vec4(0.0, correct, 0.0, 1.0);
}
The expected ouput result of this test is vec4(0.0, 1.0, 0.0, 1.0),
but it's vec4(0.0,0.0,0.0,1.0).Because the return value of isInf is
false.
precision highp float;
out vec4 my_FragColor;
void main()
{
// GLSL ES 3.00.6 section 4.1.4 Floats:
// "A value with a magnitude too small to be represented as a mantissa and exponent is converted to zero."
// 1.0e-50 is small enough that it can't even be stored as subnormal.
float correct = (1.0e-50 == 0.0) ? 1.0 : 0.0;
my_FragColor = vec4(0.0, correct, 0.0, 1.0);
}
The expected ouput result of this test is vec4(0.0, 1.0, 0.0, 1.0),
but it's vec4(0.0,0.0,0.0,1.0).
For f32 and f16 type, when the literal constant out of range of the f32
and f16 number, the value should overflow or underflow to inf or zero.
glcts test item
KHR-GLES3.number_parsing.float_out_of_range_as_infinity
The debug options passed down from the public ShConstruct* functions to
internal code is unused. This change removes the internal debugOptions
fields and attempts to make it more obvious these fields are not used.
This change does not change the public-facing interface.
This change also adds the -Wshorten-64-to-32 warning to the StandAlone
build in order to avoid unwanted 64-to-32 bit conversions in the future.
Closes#3348.
