From 27ee1337a0090cf28a0600758884fad405866afe Mon Sep 17 00:00:00 2001 From: Ellie Hermaszewska Date: Thu, 5 Dec 2024 19:28:26 +0800 Subject: [PATCH] Extended vector proposal (#5734) Closes https://github.com/shader-slang/slang/issues/5504 Co-authored-by: Yong He --- docs/proposals/13-extended-length-vectors.md | 193 +++++++++++++++++++ 1 file changed, 193 insertions(+) create mode 100644 docs/proposals/13-extended-length-vectors.md diff --git a/docs/proposals/13-extended-length-vectors.md b/docs/proposals/13-extended-length-vectors.md new file mode 100644 index 0000000000..3b0a2d190a --- /dev/null +++ b/docs/proposals/13-extended-length-vectors.md @@ -0,0 +1,193 @@ +# SP #13: Extended Length Vectors + +This proposal introduces support for vectors with 0 or more than 4 components in +Slang, extending the current vector type system while maintaining compatibility +with existing features. + +## Status + +Status: Design Review + +Implementation: N/A + +Author: Ellie Hermaszewska + +Reviewer: TBD + +## Background + +Currently, Slang supports vectors between 1 and 4 components (float1, float2, +float3, float4, (etc for other element types)), following HLSL conventions. +This limitation stems from historical GPU hardware constraints and HLSL's +graphics-focused heritage. However, modern compute applications may require +working with longer vectors for tasks like machine learning, scientific +computing, and select graphics tasks. + +Related Work + +- C++: std::array provides fixed-size array containers but lacks + vector-specific operations. SIMD types like std::simd (C++23) support + hardware-specific vector lengths. + +- CUDA: While CUDA doesn't provide native long vectors, libraries like Thrust + implement vector abstractions. Built-in vector types are limited to 1-4 + components (float1, float2, float3, float4). + +- OpenCL: Provides vector types up to 16 components (float2, float4, float8, + float16, etc.) with full arithmetic and logical operations. + +- Modern CPU SIMD: Hardware support for longer vectors continues to grow: + - Intel AVX-512: 512-bit vectors (16 float32s) + - ARM SVE/SVE2: Scalable vector lengths up to 2048 bits + - RISC-V Vector Extensions: Variable-length vector support + +These approaches demonstrate different strategies for handling longer vectors, +from fixed-size containers to hardware-specific implementations. + +## Motivation + +The primary motivation for extended length vectors is to support mathematical +operations and algorithms that naturally operate on higher-dimensional vectors. +While Slang already supports arrays for data storage, certain computations +specifically require vector semantics and operations that arrays don't provide. + +A key principle of this proposal is consistency: there is no fundamental +mathematical reason to limit vectors to 4 components. While the current limit +stems from graphics hardware history, modern compute applications shouldn't be +constrained by this arbitrary boundary. Supporting any natural length N +provides a clean, orthogonal design that follows mathematical principles rather +than historical limitations. + +Some example use cases: + +- Geometric Algebra and Clifford Algebras: + + - 6D vectors for Plücker coordinates (representing lines in 3D space) + - 6D vectors for screw theory in robotics (combining rotation and translation) + - 8D vectors for dual quaternions in their vector representation + - Higher-dimensional geometric products and outer products + +- Machine Learning: + + - Neural network feature vectors where vector operations (dot products, + normalization) are fundamental + - Distance metrics in high-dimensional embedding spaces + - Principal Component Analysis with multiple components + +- Scientific Computing: + - Spherical harmonics: Vector operations on coefficient spaces beyond 4D + - Quantum computing: State vectors in higher-dimensional Hilbert spaces + +This extension maintains Slang's mathematical vector semantics while enabling +computations that naturally operate in higher dimensions. The focus is not on +data storage (which arrays already handle) but on preserving vector-specific +operations and mathematical properties in higher dimensions and improving +consistency in the language. + +## Proposed Approach + +We propose extending Slang's vector type system to support vectors of arbitrary +length, supporting as many of the operations available to 4-vectors as +possible. Hardware limitations will prohibit a complete implementation, for +example certain atomic operations may not be possible on longer vectors. + +Key aspects: + +- Support vectors of any length that is a natural number, subject to the same + limits as fixed-length arrays +- Maintain existing syntax for vectors up to length 4 +- Maintain numeric swizzling operators. +- Support standard vector operations (add, multiply, etc.) + +## Detailed Explanation + +### Type System Integration + +There are no type system changes required, as the vector type constructor is +already parameterized over arbitrary vector length. + +### Operations + +#### Component Access: + +```slang +vector v; +float f0 = v.x; // First component +float f1 = v[1]; // Array-style access +float2 f3 = v_6_7; // last two member +vector = float2(1,2).xxxxxxxx; // extended swizzling example +``` + +#### Arithmetic Operations: + +Any operations currently supported and generic over restricted vector length +will be made unrestricted. + +Part of the scope of this work is to generate a precise list. + +For example all componentwise operations will be supported, as well as +reductions. + +Cross product will remain restricted to 3-vectors, and will not be overloaded +to 0-vectors or 7-vectors; this is due to worse type inference and error +messages should overloads be added. + +#### Atomic Operations: + +Not supported + +### Storage Operations: + +Most platforms restrict the type of data able to be stored in textures, this +proposal does not intend to work-around these restrictions. + +### Implementation Details + +Memory Layout: + +- Vectors are stored in contiguous memory +- Alignment follows platform requirements +- Padding may be required for certain lengths, for example padding to the + nearest multiple of 4 + +Performance Considerations: + +- No performance degredation for 1,2,3,4-vectors +- SIMD implementation work possible, not initially required + +## Alternatives Considered + +Fixed Maximum Length: + +- Could limit to common sizes (8, 16, 32) +- Simpler implementation but less flexible +- Rejected due to limiting future use cases + +Do nothing: + +- See motivation section + +## Additional notes + +### Zero-Length Vectors + +This proposal includes support for zero-length vectors. While seemingly +unusual, zero-length vectors are mathematically well-defined and provide +important completeness properties: + +- They are the natural result of certain slicing operations +- They serve as the identity element for vector concatenation + +### Extended Matrices + +While this proposal focuses on vectors, it naturally suggests a future +extension to matrices beyond the current 4x4 limit. Extended matrices would +follow similar principles. + +However, extended matrices introduce additional considerations: + +- Memory layout and padding strategies for large matrices +- Optimization of common operations (multiplication, transpose) + +These matrix-specific concerns are best addressed in a separate proposal that +can build upon the extended vector foundation established here.