From 4a63e33d60e02d421f693217d36ecd689208155d Mon Sep 17 00:00:00 2001 From: Ellie Hermaszewska Date: Wed, 11 Dec 2024 02:13:08 +0800 Subject: Correct proposal number (#5809) Co-authored-by: Yong He --- docs/proposals/014-extended-length-vectors.md | 193 ++++++++++++++++++++++++++ docs/proposals/13-extended-length-vectors.md | 193 -------------------------- 2 files changed, 193 insertions(+), 193 deletions(-) create mode 100644 docs/proposals/014-extended-length-vectors.md delete mode 100644 docs/proposals/13-extended-length-vectors.md (limited to 'docs') diff --git a/docs/proposals/014-extended-length-vectors.md b/docs/proposals/014-extended-length-vectors.md new file mode 100644 index 000000000..4dcc7f88f --- /dev/null +++ b/docs/proposals/014-extended-length-vectors.md @@ -0,0 +1,193 @@ +# SP #014: 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. diff --git a/docs/proposals/13-extended-length-vectors.md b/docs/proposals/13-extended-length-vectors.md deleted file mode 100644 index 3b0a2d190..000000000 --- a/docs/proposals/13-extended-length-vectors.md +++ /dev/null @@ -1,193 +0,0 @@ -# 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. -- cgit v1.2.3