This function is used to import SPIR-V extended instruction set. It
mistakenly treated the name of SPIR-V extended instruction set as the
name of SPIR-V extension. For example, when we have such code
getExtBuiltins("NonSemantic.DebugBreak")
'NonSemantic.DebugBreak' is added to SPIR-V extension. Rather, the
SPIR-V extension name should be 'SPV_KHR_non_semantics_info'. Therefore,
we must avoid this since the name of SPIR-V extended instruction set is
not necessarily equal to that of relevant SPIR-V extension. Adding a
SPIR-V extension must be done by calling addExtension() explicitly
outside this function.
This change also fixes disassembly issues of debugBreak().
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>"
The file and source text was not being set correctly in the test output.
This change makes the test fixture consistent with the command line
behavior, "-gVS", which was my original intent when I added these tests.
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.
- Correctly populate the field `currentFileId` with the presence of include directive
- Support lazy OpLine/OpDebugLine generation only when a real instruction is added instead of a debug location is set
- Improve the debug location tracking to per-block instead of just per-builder
- A few bug fixes related to debug source info
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.
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.
The preprocessor now reports errors for #'s appearing in the wrong
place, which were being triggered by this test. This test is rewritten
slightly to only report the errors we want.
This change primarily fixes some -Wconversion warnings from gcc, but
also silences a warning triggered in glslang_tab.cpp, which is generated
code from bison.
There are still several GCC conversion warnings in Types.h due to the
use of bit fields that will be resolved in a future change.
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
1. Pull OpDebugFunction, OpDebugScope and OpDebugVariable for params out
of makeFunctionEntry.
2. Put above in a separate function called setupDebugFunctionEntry,
which also accept line number and set it correctly in builder.
3. Call setupDebugFunctionEntry in makeFunction. Also special case
handle entry function since it's created ealier elsewhere.
Currently no debug info is emitted for buffer reference types, which
resulted in the SPIR-V backend code asserting when trying to emit the
debug info for struct member that had such a type. Instead, the code now
skips such struct members. Full debug info for buffer references may
require forward references in the debug info instructions, which is
currently prohibited by the spec.
SPIR-V 1.6 added the LocalSizeId execution mode that allows using
spec constants for setting the work-group size, however it does not
deprecate the LocalSize mode. This change causes the LocalSizeId mode to
only be used when at least one of the workgroup size is actually
specified with a spec constant.
Fixes#3200
Move the parameter verifictation to a centralized place where all the builtins
are verified for correctness.
Add verification for the new builtins with version and extension check
These builtins are supported on GLSL since version 130 and GLES since
version 300.
Adds the --no-link option which outputs the compiled shader binaries
without linking them. This is a first step towards allowing users to
create SPIR-v binary, non-executable libraries.
When using the --no-link option, all functions are decorated with the
Export linkage attribute.
Previously, the type names in the nonsemantic shader debug info would be
"int", "uint", or "float" for all numeric types. This change makes the
correct names such as "int8_t" or "float16_t" get emitted.
