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
[Backport to 15] Use SPV_EXT_long_vector extension for non-standard vector size (#3777)
For a vector type, add `SPV_EXT_long_vector` extension and prioritize it
over `SPV_INTEL_vector_compute` whenever the vector type doesn't have a
standard component size (2, 3, 4, 8, or 16).
[Backport to 15] Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector (#3829)
#3777 added `SPV_EXT_long_vector` and gave it priority over
`SPV_INTEL_vector_compute`: when both extensions are enabled and a
vector has a non-standard component count, the translator now emits
`CapabilityLongVectorEXT` instead of `CapabilityVectorAnyINTEL`.
This regresses `VectorCompute` modules. The offloading flow (producing
both `VectorCompute` and non-`VectorCompute` modules) applies a single,
fixed extension list uniformly to every device image, so a
`VectorCompute` module is translated with both
`SPV_INTEL_vector_compute` and `SPV_EXT_long_vector` enabled. Before
#3777 such a module emitted `VectorAnyINTEL` for its non-standard
vectors; after #3777 it emits `LongVectorEXT`. `VectorCompute` consumers
require `VectorAnyINTEL`, so this is a functional regression.
Hence, the enabled extension list does not identify a module as
`VectorCompute` - the `VectorCompute` metadata (`VCFunction`
/`VCGlobalVariable`) does. `IsVectorComputeModule` records the presence
of that metadata before type translation. `VectorCompute` modules keep
using `VectorAnyINTEL`, restoring the pre-#3777 behavior; all other
modules still prefer the multi-vendor `LongVectorEXT` when its extension
is enabled.
0 commit comments