We need to check the element types of PS input variables to
properly apply interpolation decorations. Previously the method
used to query element type does not support array types, which
caused an assertion eventually.
Fixing a bunch of SM 6.2 Tests
- BinaryHalfOp tests reading input2 instead of input1
- Fixed converting signed zero from float to float16
- Fixed compiler options for float16 min,max test
- Fixed expected results for following float16 operations
- cos(0), sin(314), sin(-314)
- frc(-7.39)
- rsqrt(65504)
- int16 subtraction
- int16 unsigned multiplication
- sqrt, rsqrt, round_pi, round_ni, fmad treat denorm as it is
cbuffers/tbuffers are handled differently than other resource types
becuase their members do not need to be qualified when using.
That is, their members are distinct entities. However, in SPIR-V,
we need to generate one single entity to hold them all for all
members in a cbuffer/tbuffer.
Previously we didn't record the marjorness annotated on each member,
which results in returning the wrong types for members.
For a struct T with only one member of type S, (T)<an-instance-of-S>
is allowed and will be interpreted as constructing an instance of
T using the instance of S as its member.
This commit add support for generating OpSpecConstant* instructions
with SpecId decorations. Spec constants are only allowed to be of
scalar boolean/integer/float types. Using spec constant as the array
size does not work at the moment.
Code had a (reasonable) assumption that sources have names, but the
entry point wasn't verifying that. For compat with prior compilers and
the annotation, we choose to support it. Unlikely other implementations,
the name is a simple hard-coded one, instead of varying, to allow for
easier deduping when the output is checked (name is in debug section).
Types and constants are interdependent. Previously we use different
members for storing them, which requires hacks to output types
and constants in the correct order to satisfy their dependencies.
However, with specialization constants, things will be more
complicated. Using the same member to store all of them solves
the problem naturally.
Specialization constants are more like variables. Unlike normal
constants, we cannot unify spec constants, even if two of them
have exactly the same arguments. Neither can we replace a spec
constant with its default value (initializer) or folding exprs
containing spec constants.
We can use the SpecId decoration to distinguish spec constants
with the same arguments, but the problem is that not all spec
constants have SpecId decorations. Only those explicitly marked
in the source code have, derived ones do not.
Also, we cannot decorate normal constants. So we can remove the
decoration member in the Constant class.
Two new Vulkan specific intrinsic resource types, SubpassInput and
SubpassInputMS, are introduced to provide a way to use subpass inputs
in Vulkan. Their signatures:
template<typename T>
class SubpassInput {
T SubpassLoad();
};
template<typename T>
class SubpassInputMS {
T SubpassLoad(int sample);
};
T can be a scalar or vector type.
If compiled without ENABLE_SPIRV_CODEGEN, the compiler will report
unknown type name for SubpassInput(MS). If compiled with SPIR-V
CodeGen and trying to use SubpassInput(MS) in DXIL CodeGen, the
compiler will report an error saying the type is Vulkan-specific.
A new Vulkan-specific attribute, vk::input_attachment_index is
introduced to provide a way to set the input attachment index for
SubpassInput(MS) objects.
This only supports .GetSamplePosition() for standard sample
positions, i.e., sample count is 1, 2, 4, 8, or 16. For other
cases, the method will just return float2(0, 0).
This requires us to regenerate the InstBuilder class and also
manually pin the SPIR-V version as 1.0 instead of relying on
spv::Version.
Also refreshed SPIRV-Tools