This change causes ES shaders to precision qualifiers for build-in functions as defined in ESSL spec. It especially mattersfor functions that are defined as highp or taking a highp.
Fixes vulkanCTS dEQP-VK.glsl.builtin.function.integer.bitfieldreverse.*, where bitfieldReverse() retval was wrongly marked as RelaxedPrecision.
Note: floatBitsToInt/floatBitsToUInt precision is also broken, but in different way - so it is not addressed here.
Reimplement the whole workflow to make that: precise'ness of struct
members won't spread to other non-precise members of the same struct
instance.
Approach:
1. Build the map from symbols to their defining nodes. And for each
object node (StructIndex, DirectIndex, Symbol nodes, etc), generates an
accesschain path. Different AST nodes that indicating a same object
should have the same accesschain path.
2. Along the building phase in step 1, collect the initial set of
'precise' (AST qualifier: 'noContraction') objects' accesschain paths.
3. Start with the initial set of 'precise' accesschain paths, use it as
a worklist, do as the following steps until the worklist is empty:
1) Pop an accesschain path from worklist.
2) Get the symbol part from the accesschain path.
3) Find the defining nodes of that symbol.
4) For each defining node, check whether it is defining a 'precise'
object, or its assignee has nested 'precise' object. Get the
incremental path from assignee to its nested 'precise' object (if
any).
5) Traverse the right side of the defining node, obtain the
accesschain paths of the corresponding involved 'precise' objects.
Update the worklist with those new objects' accesschain paths.
Label involved operations with 'noContraction'.
In each step, whenever we find the parent object of an nested object is
'precise' (has 'noContraction' qualifier), we let the nested object
inherit the 'precise'ness from its parent object.
Note this requires test-based piecing together of the preamble string,
so it changed to being a std::string to make it easier to do.
This closes issue #254.
This is a replacement commit for pull request #238.
This is a design change, followed by implementation change that
A) fixes the changes caused by the design change, and
B) fixes some cases that were originally incorrect.
The design change is to not give built-in functions default precision qualification.
This is to allow the rule that the precision of some built-in functions adopt their
precision qualification from the calling arguments. This is A above.
A consequence of this design change is that all built-ins that are supposed to have
an explicit precision qualifier must now be declared that way. So, a lot more
built-in declarations now have precision qualifiers, just to keep things the same.
This is B above.
- Add new keyword int64_t/uint64_t/i64vec/u64vec.
- Support 64-bit integer literals (dec/hex/oct).
- Support built-in operators for 64-bit integer type.
- Add implicit and explicit type conversion for 64-bit integer type.
- Add new built-in functions defined in this extension.
The input scanner can be trapped in an infinite loop if the given input
file does not have EOF (and is not ended with a 'whitespace').
The problem is caused by unget(), which keeps rolling back the scanner
pointer without hitting an EOF at the end of the file. This makes getch()
function keep returning the last character of the file and never ends,
and the effect of advance() is always counteracted by unget().
Fix issue: #237
1. The code generated for matrix constructor should 1) build column
vectors first, 2) build matrix with the vectors.
2. When there is only one scalar type constituent in vector's
constructor, we should populate the constituent to fill all the slots in
the vector. As for matrix, the single constituent should be populated to
the diagonal positions (top-left to bottom-right diagonal).
remove createSpvConstantFromConstSubTree()
Bool -> uint/int with OpSpecConstantOp OpSelect instruction.
uint <-> int conversion with OpSpecConstantOp OpIAdd instruction.
Note, implicit conversion: `const uint = an_int_spec_constant` is not
supported. Explicit type casting is required: `const uint =
uint(an_int_spec_constant)`
This is according to the expected KHR_vulkan_glsl without floating point.
So, floating-point spec-const operations no longer work, and that's
reflected in the tests.
Move SpecConstantOpModeGuard from makeSpvConstantFromConstSubTree() to
visitbinary() and visitunary(). Checking if the visiting node is a spec
constants, if so, turn on the SpecConstantOpMode, otherwise, stay in the
normal mode.
The existing test harness is a homemade shell script. All the tests
and the expected results are written in plain text files. The harness
just reads in a test, invoke the glslangValidator binary on it, and
compare the result with the golden file. All tests are kinda
integration tests.
This patch add Google Test as an external project, which provides a
new harness for reading shader source files, compile to SPIR-V, and
then compare with the expected output.
Approach:
Add a flag in `Builder` to indicate 'spec constant mode' and 'normal
mode'. When the builder is in 'normal mode', nothing changed. When the
builder is in 'spec constant mode', binary, unary and other instruction
creation rountines will be redirected to `createSpecConstantOp()` to
create instrution at module level with `OpSpecConstantOp <original
opcode> <operands>`.
'spec constant mode' should be enabled if and only if we are creating
spec constants. So a flager setter/recover guard is added when handling
binary/unary nodes in `createSpvConstantsFromConstSubTree()`.
Note when handling spec constants which are represented as ConstantUnion
Node, we should not use `OpSpecConstantOp` to initialize the composite
constant, so builder is set to 'normal mode'.
Tests:
Tests are added in Test/spv.specConstantOperations.vert, including:
1) Arithmetic, shift opeations for both scalar and composite type spec constants.
2) Size conversion from/to float and double for both scalar and vector.
3) Bitwise and/or/xor for both scalar and vector.
4) Unary negate/not for both scalar and vector.
5) Vector swizzles.
6) Comparisons for scalars.
7) == and != for composite type spec constants
Issues:
1) To implement == and != for composite type spec constants, the Spec needs
to allow OpAll, OpAny, OpFOrdEqual, OpFUnordEqual, OpOrdNotEqual,
OpFUnordNotEqual. Currently none of them are allowed in the Spec.
Much about const or temp is mechanical, about actual declaration,
while much is semantic, about something higher level. This commit
checks every use everywhere, and for the high-level ones, substitutes
an encapsulated version instead.
