Decoration Stream depends on it.
GeometryStreams depends on Geometry capability.
Spot check dependence of OpEmitStreamVertex on GeometryStreams.
(Opcode dependencies on capabilities are automatically generated from
opcode.inc)
Updated readme.
Note: The header advertises itself as Rev 1, but contains
many (all?) the updates intended for Rev 2. We might need
to update one more time before SPIR-V 1.0 Rev2 is published.
Regenerated syntax tables for 1.0.
Changed names:
InputTriangles -> Triangles
InputQuads -> Quads
InputIsolines -> Isolines
WorkgroupLocal -> Workgroup
WorkgroupGlobal -> CrossWorkgroup
PrivateGlobal -> Private
(Dim) InputTarget -> SubpassData
WorkgroupLocalMemoryMask -> WorkgroupMemoryMask
WorkgroupGlobalMemoryMask -> CrossWorkgroupMemoryMask
AsyncGroupCopy -> GroupAsyncCopy
WaitGroupEvents -> GroupWaitEvents
Remove:
IndependentForwardProgress capability
Smooth decoration
FragColor BuiltIn
WorkgroupLinearId in favour of LocalInvocationId
ImageSRGBWrite capability
Special OpenCL image instructions
Add:
image channel data type UnormInt101010_2
AcquireReleaseMask
InputTargetIndex updates:
InputTargetIndex -> InputAttachmentIndex
InputAttachmentIndex depends on InputAttachment capability,
and it takes a literal number argument.
Capability StorageImageExtendedFormats updates:
Enum value changed from 26 to 49. (Changes position in tables).
Replaces AdvancedImageFormat capability.
OpenCL source language -> OpenCL_C, OpenCL_CPP
- Concrete operand types are never optional.
Split them to make this so, e.g. add SPV_OPERAND_TYPE_IMAGE
since there was SPV_OPERAND_TYPE_OPTIONAL_IMAGE.
Similarly for SPV_OPERAND_TYPE_MEMORY_ACCESS.
This entails duplicating two operand table entries.
- The above, plus some rearranging of enums, allows us to define
first and last optional operand types, and first and last
variable operand types.
This lets us simplify the code for spvOperandIsOptional, and
spvOperandIsVariable.
- Replace SPV_OPERAND_TYPE_MULTIWORD_LITERAL_NUMBER with the
more accurately named SPV_OPERAND_TYPE_TYPED_LITERAL_NUMBER.
Its special characteristic is that the type of the literal
number is determined by some previous operand in the instruction.
This is used for literals in OpSwitch, OpConstant, and OpSpecConstant.
This lets us refactor operand parsing cases in the assembler.
- Remove the special required-thing-in-optional-tuple in favour of
the corresponding concrete operand type:
SPV_OPERAND_TYPE_ID_IN_OPTIONAL_TUPLE
--> SPV_OPERAND_TYPE_ID
SPV_OPERAND_TYPE_INTEGER_LITERAL_IN_OPTIONAL_TUPLE
--> SPV_OPERAND_TYPE_INTEGER_LITERAL
- Constrain spvOpeandTypeStr to only have to work for non-variable
operand types. Add a test for this.
Note that we are more strict than Google style for one aspect:
pointer/reference indicators are adjacent to their types, not
their variables.
find . -name "*.h" -exec clang-format -i {} \;
find . -name "*.cpp" -exec clang-format -i {} \;
Except for OpConstant and OpSpecConstant, all other literal number
operands are indeed unsigned integers. So,
* Rename all *LITERAL_NUMBER* operand types to *LITERAL_INTEGER*.
* Expect unsigned integers for *LITERAL_INTEGER* operands.
* Keep MULITPLE_WORD_LITERAL untouched since it is only used by
OpConstant and OpSpecConstant.
And we want to provide the capability to specify floating-point
numbers after !<integer> in the alternate parsing mode. So,
OPTIONAL_LITERAL_NUMBER is reserved for OPTIONAL_CIV.
Fixes dependencies among capabilities. (The table should store
the mask of capabilites, not the capability enum.)
Remove the old spot check test for capabilities of enums.
All uses of OptionalLiteral by the SPIR-V spec are used
for literal numbers.
Also rename:
- SPV_OPERAND_TYPE_OPTIONAL_LITERAL to
SPV_OPERAND_TYPE_OPTIONAL_LITERAL_NUMBER.
- SPV_OPERAND_TYPE_VARIABLE_LITERAL to
SPV_OPERAND_TYPE_VARIABLE_LITERAL_NUMBER.
- SPV_OPERAND_TYPE_VARIABLE_LITERAL_ID to
SPV_OPERAND_TYPE_VARIABLE_LITERAL_NUMBER_ID.
- SPV_OPERAND_TYPE_VARIABLE_ID_LITERAL to
SPV_OPERAND_TYPE_VARIABLE_ID_LITERAL_NUMBER.
- SPV_OPERAND_TYPE_LITERAL_IN_OPTIONAL_TUPLE to
SPV_OPERAND_TYPE_LITERAL_NUMBER_IN_OPTIONAL_TUPLE.
If a memory mask operand is present, it is a mask. The mask appears
only once, so just use SPV_OPERAND_TYPE_OPTIONAL_MEMORY_MASK.
The "variable literals" aspect comes into play as follows: if the
Aligned bit is set in the mask, then the parser will be made to
expect the alignment value as a literal number operand that follows
the mask. That is done through mask operand expansion.
Properly support a memory access mask with a combination
of bits, including the Aligned bit. When the Aligned bit is
set, the parser should expect an alignment value literal operand.
Add a new operand type SPV_OPERAND_TYPE_MULTIWORD_LITERAL_NUMBER
to represent those operands that can expand into multiple words.
Now only OpConstant and OpSpecConstant have such kind of operand.
