Support Long Vectors in HLSL

[pow2clk]

Add support for vectors longer than 4 (long vectors) with some restrictions.

Is your feature request related to a problem? Please describe.
ML applications require vectors longer than the graphics-centric limit of 4 vector elements. Allowing longer vectors will better enable these applications to take advantage of hardware support and ease novel ML application development.

Describe the solution you'd like
Allow declaration and use of vectors longer than 4 elements (long vectors) as locals, groupshared, non-entry parameters, non-entry return types, and contents of raw buffers. These should be useable by HLSL operators and elementwise builtins.

These vectors will be declared using the existing template declarations. Existing defaults such as default vector length will be maintained to preserve behavior of existing shaders. Accessing such vectors will be exclusively through existing subscript operation as the member-style xyzw (or rgba) are specific to the interpretation of shorter vectors in a graphics context.

Describe alternatives you've considered
A bespoke, opaque vector type intended for ML applications was considered, but discarded in favor of extending the existing vector representations.

Additional context

While all elementwise DXIL intrinsics are supported, initial support might implement such support as scalarized breakdowns.

Support for this feature may be implemented in stages:

• [SM6.9] Support long vector declaration, casting, and assignment #7117
• [SM6.9] Templated Load and Store long vectors from and to byteaddressbuffers #7118
• [SM6.9] Load and store long vectors from and to StructuredBuffers #7119
• [SM6.9] Generate native vector variants of elementwise operators #7123
• [SM6.9] Generate native vectors operations for elementwise intrinsics #7120
• [SM6.9] Provide hidden flag to enable elementwise processing of long vectors #7121
• Execution Tests for Long Vectors #7069

Where matrices are represented as vectors, the max size is actually 16. There are many places in the DXC code where the lenght limit of 4 or 16 is pervasive. There are several esoteric changes that need to be made besides just allowing the validator to accept such vectors. Many of these will be included in the changes that require them, but others might require more individual changes along the way.

[devshgraphicsprogramming]

btw @Przemog1 found a nasty partial specialization bug where one tries to partially specialize where an integer (not a type) is involved in the template specialization declaration.

E.g. I want to partial spec for T where T=vector<U,N>

Which is why we had to partial spec only on the type, and go explicit for every single N from 1 to 4 with a macro
https://github.com/Devsh-Graphics-Programming/Nabla/blob/new_tgmath/include/nbl/builtin/hlsl/vector_utils/vector_traits.hlsl

Would be nice if we could get that fixed for when long vectors come around.

[damyanp]

btw @Przemog1 found a nasty partial specialization bug where one tries to partially specialize where an integer (not a type) is involved in the template specialization declaration.

Can you paste a link to the issue with a repro for this please?

[devshgraphicsprogramming]

btw @Przemog1 found a nasty partial specialization bug where one tries to partially specialize where an integer (not a type) is involved in the template specialization declaration.

Can you paste a link to the issue with a repro for this please?

#7007