You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Type Conversions: asdouble, asfloat, asfloat16, asint, asint16, asuint, asuint16
In addition to this, any vector used for these intrinsics should produce DXIL that uses native vectors as parameters.
Some of these are trivially convertable into corresponding DXIL intrinsics that will form vector variants with similar if not identical arguments. Some others expand into a few operations that may involve multiple DXIL intrinsics or intrinsics paired with native operators. In either case, the generated DXIL should use vector variants of the operations to implement the intent.
Implementation will mostly differ little from that done for operators in #7123. The exception might be intrinsics that scalarize themselves as part of their lowering, which will need to change to preserve the vectors until the scalarization pass runs or doesn't depending on compile-time flags. This is a separate issue in spite of that since many intrinsic lowering involves native operators and testing will be involved and can be separated. This does depend on #7123.
The text was updated successfully, but these errors were encountered:
pow2clk
changed the title
generating native vectors operations for elementwise intrinsics
Generate native vectors operations for elementwise intrinsics
Feb 4, 2025
pow2clk
changed the title
Generate native vectors operations for elementwise intrinsics
[SM6.9] Generate native vectors operations for elementwise intrinsics
Feb 4, 2025
In SM6.9, long vectors should be usable on the following HLSL intrinsics:
In addition to this, any vector used for these intrinsics should produce DXIL that uses native vectors as parameters.
Some of these are trivially convertable into corresponding DXIL intrinsics that will form vector variants with similar if not identical arguments. Some others expand into a few operations that may involve multiple DXIL intrinsics or intrinsics paired with native operators. In either case, the generated DXIL should use vector variants of the operations to implement the intent.
Implementation will mostly differ little from that done for operators in #7123. The exception might be intrinsics that scalarize themselves as part of their lowering, which will need to change to preserve the vectors until the scalarization pass runs or doesn't depending on compile-time flags. This is a separate issue in spite of that since many intrinsic lowering involves native operators and testing will be involved and can be separated. This does depend on #7123.
The text was updated successfully, but these errors were encountered: