GLSL Version : >= 150
Purpose:
Allow users to use features by enabling this extension, even in low versions.
Extension Name:
ARB_gpu_shader_fp64
Builtin-variables:
Nah
Builtin-functions:
functions overloaded for this extension, please check registry in reference.
Keywords:
Double
Features:
add support for type "double"
Reference:
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt
Add support for implicit conversion
1. Remove builtin double vertex (this is introduced by vertex_attrib_64bit
2. Add extension check and implicit conversion as double has been introduced
3. Add test results.
Modify atomic_uint binding check.
Currently, when not declared with offset, default atomic_unint won't check whether its binding is valid or not more than its limit value.
GLSL Version : >= 140
Purpose:
Allow users to use features by enabling this extension, even in low versions.
Extension Name:
ARB_texture_multisample
Builtin-variables:
Nah
Builtin-functions:
Nah
Keywords:
sampler2DMS, isampler2DMS, usampler2DMS,
sampler2DMSArray, isampler2DMSArray, usampler2DMSArray
Reference:
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_texture_multisample.txt
Purpose:
glsl spec allows to define array with the length of the result of constant expression, the arithmetic operation of "mod(float (7.1), float (4.0))" should be generate the array length at the shader compile time,
but glslang didn't support mod operation for the constant expression in previous implementation;
An example is as following:
###########
#version 460
flat out highp int vtx_out_out0;
void main (void)
{
float array[int(mod(float (7.1), float (4.0)))];
vtx_out_out0 = array.length();
}
###########
The changes to glslang/glslang/MachineIndependent/ParseHelper.cpp exist
purely to prevent even more instances of "warning: enumeration value
‘EOp...’ not handled in switch"
v2: Remove 8-bit types. Overzealous copy-and-paste led to adding
support for a bunch of types that the extension doesn't actually enable.
v3: Update expected test results file. Just changing an expected
results file to make a test pass seems sketchy to me, but I'm not sure
what else to do.
v4: Add missing entry for EOpAbsDifference in
TOutputTraverser::visitBinary. Noticed by JohnK.
The problem is that constructing a float16_t, int8_t, uint8_t, int16_t,
or uint16_t with a non 32-bit argument generates an aggregate with the
wrong construction op. For int8_t and uint8_t, this resulted in a crash.
[PURPOSE]:
The current process design for Uniform / Block / Pipe IO symbols reflection (during program linking) is as following :
1.1 using a global mapper called 'TNameToIndex' to store all the relationship of name (of symbols) to their indexes (in their own MapIndexToReflection vectors).
1.2 TNameToIndex mapper will be used during program linking and helps to check and merge duplicate symbols within each stage ( Uniform, Block and Pipe IO)
1.3 Different types of symbols will have their own index mapping storage. All those symbols will share TNameToIndex as a general searching mapper.
1.4 Only IN in first stage and OUT in last stage will be dealed within traversing functions.
Now, here we meet those problems:
2.1 In and Out variables for pipelines are mapping to different MapIndexToReflection vector (ioItems), but they may still have same names within the general symbol search mapper : TNameToIndex.
2.2 Then, when there are same symbols of IN in VS and OUT in FS, TNameToIndex could not tell the difference because it only stores one local index for one symbol (1:1) as a pair of KeyValue.
[What fixed]:
Seperate I/O from other symbols like Uniform and Block (it is wrong to keep them all in TNameToIndex), and save in new searching mappers called pipeInNameToIndex and pipeOutNameToIndex.
Expose new top-level functions defined as getReflectionPipeIOIndex and getPipeIOIndex for users who need to query Pipe I/O information (As they may reach those things through getUniformIndex and getReflectionIndex now, which is a confused way.)
As there are 2 mappers for above symbols, users needs to input second argument when they wanna reach those pipe I/O parameters, that's also why we need to modify GET functions either.
[Test Case]:
The shader is as following:
######### VS ############
layout(location = 0) in vec4 g_position;
layout(location = 1) in vec4 g_color;
out StageData {
vec4 color;
} g_vs_out;
void main() {
gl_Position = g_position;
g_vs_out.color = g_color;
}
########### FS #############
in StageData {
vec4 color;
} g_fs_in;
layout(location = 0) out vec4 g_color;
void main() {
g_color = g_fs_in.color;
}
