- 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
- Add missing constructor ops to support float16/int16/uint16 types
- Allow half float literals
- Correct two errors of double literal parse in HLSL: extension check and
postfix
- 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
The grammar for no semicolon and no object name for cbuffer/tbuffer
was correct, but the production still skipped the anonymous declarations
if an identifier followed.
Issue #791 was partially fixed by PR #1161 (the mat mul implicit
truncations were its main point), but it still wouldn't compile due to
the use of ConstantBuffer as an identifier. Apparently those fall into
the same class as "float float", where float is both a type and an
identifier.
This allows struct definitions with such keyword-identifiers,
and adds ConstantBuffer to the set. 'cbuffer int' is legal in HLSL,
and 'struct int' appears to only be rejected due to the redefinition
of the 'int' type.
Fixes#791
Add support for Subpass Input proposal of issue #1069.
Subpass input types are given as:
layout(input_attachment_index = 1) SubpassInput<float4> subpass_f;
layout(input_attachment_index = 2) SubpassInput<int4> subpass_i;
layout(input_attachment_index = 3) SubpassInput<uint4> subpass_u;
layout(input_attachment_index = 1) SubpassInputMS<float4> subpass_ms_f;
layout(input_attachment_index = 2) SubpassInputMS<int4> subpass_ms_i;
layout(input_attachment_index = 3) SubpassInputMS<uint4> subpass_ms_u;
The input attachment may also be specified using attribute syntax:
[[vk::input_attachment_index(7)]] SubpassInput subpass_2;
The template type may be a shorter-than-vec4 vector, but currently user
structs are not supported. (An unimplemented error will be issued).
The load operations are methods on objects of the above type:
float4 result = subpass_f.SubpassLoad();
int4 result = subpass_i.SubpassLoad();
uint4 result = subpass_u.SubpassLoad();
float4 result = subpass_ms_f.SubpassLoad(samp);
int4 result = subpass_ms_i.SubpassLoad(samp);
uint4 result = subpass_ms_u.SubpassLoad(samp);
Additionally, the AST printer could not print EOpSubpass* nodes. Now it can.
Fixes#1069
- support C++11 style brackets [[...]]
- support namespaces [[vk::...]]
- support these on parameter declarations in functions
- support location, binding/set, input attachments
Some languages allow a restricted set of user structure types returned from texture sampling
operations. Restrictions include the total vector size of all components may not exceed 4,
and the basic types of all members must be identical.
This adds underpinnings for that ability. Because storing a whole TType or even a simple
TTypeList in the TSampler would be expensive, the structure definition is held in a
table outside the TType. The TSampler contains a small bitfield index, currently 4 bits
to support up to 15 separate texture template structure types, but that can be adjusted
up or down. Vector returns are handled as before.
There are abstraction methods accepting and returning a TType (such as may have been parsed
from a grammar). The new methods will accept a texture template type and set the
sampler to the structure if possible, checking a range of error conditions such as whether
the total structure vector components exceed 4, or whether their basic types differe, or
whether the struct contains non-vector-or-scalar members. Another query returns the
appropriate TType for the sampler.
High level summary of design:
In the TSampler, this holds an index into the texture structure return type table:
unsigned int structReturnIndex : structReturnIndexBits;
These are the methods to set or get the return type from the TSampler. They work for vector or structure returns, and potentially could be expanded to handle other things (small arrays?) if ever needed.
bool setTextureReturnType(TSampler& sampler, const TType& retType, const TSourceLoc& loc);
void getTextureReturnType(const TSampler& sampler, const TType& retType, const TSourceLoc& loc) const;
The ``convertReturn`` lambda in ``HlslParseContext::decomposeSampleMethods`` is greatly expanded to know how to copy a vec4 sample return to whatever the structure type should be. This is a little awkward since it involves introducing a comma expression to return the proper aggregate value after a set of memberwise copies.
Semantic test left over from other source languages is removed, since this is permitted by HLSL.
Also, to support the functionality, a targeted test is performed for this case and it is
turned into a EvqGlobal qualifier to create an AST initialization segment when needed.
Constness is now propagated up aggregate chains during initializer construction. This
handles hierarchical cases such as the distinction between:
static const float2 a[2] = { { 1, 2 }, { 3, 4} };
vs
static const float2 a[2] = { { 1, 2 }, { cbuffer_member, 4} };
The first of which can use a first class constant initalization, and the second cannot.
Lays the groundwork for fixing issue #954.
Partial flattenings were previously tracked through a stack of active subsets
in the parse context, but full functionality needs AST nodes to represent
this across time, removing the need for parsecontext tracking.
This adds infrastructure suitable for any front end to create SPIR-V loop
control flags. The only current front end doing so is HLSL.
[unroll] turns into spv::LoopControlUnrollMask
[loop] turns into spv::LoopControlDontUnrollMask
no specification means spv::LoopControlMaskNone
This is WIP, heavy on the IP part. There's not yet enough to use in real workloads.
Currently present:
* Creation of separate counter buffers for structured buffer types needing them.
* IncrementCounter / DecrementCounter methods
* Postprocess to remove unused counter buffers from linkage
* Associated counter buffers are given @count suffix (invalid as a user identifier)
Not yet present:
* reflection queries to obtain bindings for counter buffers
* Append/Consume buffers
* Ability to use SB references passed as fn parameters
Improves foundation for adding scalar casts.
Makes handle/make names more sane, better commented, uses more
precise subclass typing, and removes mutual recursion between
converting initializer lists and making constructors.
