When capabilities are needed for specific SPIR-V instructions, it is
fragile to do so based on GLSL/AST usage; it should be based on actual
instructions they got translated to.
These introduce limited support for 8/16-bit types such that they can only be accessed in buffer memory and converted to/from 32-bit types.
Contributed from Khronos-internal work.
- Use much simpler method to update implicit array sizes.
The previous overly complicated method was error prone.
- Rationalize all use of unsized arrays.
- Combine decorations when generating SPIR-V, to simplify
adding extensions.
There a couple functional problems, which when reduced down also led to
some good simplifications and rationalization. So, this commit:
- corrects "mixed" functionality: int[A] f[B] -> f[B][A]
- correct multi-identifier decls: int[A] f[B], g[C] -> f and g are independently sized.
- increases symmetry between different places in the code that do this
- makes fewer ways to do the same thing; several methods are just gone now
- makes more clear when something is copied or shared
When a matrix is divided by a scalar it tries to take the reciprocal
of the scalar to convert the operation into a multiply. However it was
always doing this by making a 32-bit constant. If the scalar is a
double then this would end up making an FDiv instruction with
different types in the operands.
This patch adds a helper method called makeFpConstant which makes a
floating-point constant of the given type. The code to take the
reciprocal now uses it to make the same type as the result.
Fixes https://github.com/KhronosGroup/glslang/issues/1278
This factored computeTypeLocationSize() out of needing the TIntermediate contents,
and uses it to show how to know how many locations an object needs.
However, it still does not do cross stage, or mixed location/no-location
analysis.
HLSL allows image and texture types to be templatized on sub-vec4 types,
or even structures. This was mostly handled already during creation of
sampling operations. However, for operator[] which can generate image
loads, this wasn't happening.
It also isn't very easy to do at that point in time, because operator[]
does not know where the results it produces will end up. They may be
an lvalue or an rvalue, and there's a post-process to convert loads to
stores. They may end up in atomic ops.
To bypass that difficulty, GlslangToSpv now looks for this case and
adds the appropriate conversion. LIMITATION: this only works for
cases for which a simple conversion opcode suffices. That is to say,
it will not work if the type is templatized on a struct.
- make it sharable with GLSL
- correct the case insensitivity
- remove the map; queries are not needed, all entries need processing
- make it easier to build bottom up (will help GLSL parsing)
- support semantic checking and reporting
- allow front-end dependent semantics and attribute name mapping
