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
Add cuSolverDx JIT fusion and solver projections (#1176)
* Add cuSolverDx JIT fusion and solver projections
Add support for cuSolverDx within JIT path. Solver functions are different than most operators since many of them return multiple values, and this was not compatible with the MatX syntax in the past. We introduce a new projection syntax where multiple values can be used inside of a single statement. This works because in non-JIT mode the `mtie` syntax is used and there's no ambiguity, but in JIT mode none of the overhead from the operator is present since it's converted to a string.
Copy file name to clipboardExpand all lines: AGENTS.md
+10Lines changed: 10 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,3 +9,13 @@ the @.devcontainer directory using the create_base_container.sh script. The pyth
9
9
## Compiling and Running
10
10
For use in external projects, MatX simply needs to be included by `#include <matx.h>`. To build unit tests the use the CMake option `MATX_BUILD_TESTS=ON`, benchmarks
11
11
`MATX_BUILD_BENCHMARKS=ON`, and examples `MATX_BUILD_EXAMPLES=ON`. Individual tests can be compiled separately via different targets output from CMake.
12
+
13
+
## Development Expectations
14
+
Every new public function, operator, transform, or backend path should include accompanying unit tests and documentation updates. Tests should cover the supported
15
+
types, ranks, batching behavior, and important error or fallback cases for the new behavior. Documentation should describe how to use the feature, required build
16
+
options or dependencies, and any limitations that would affect users or future maintainers. Any change to operators should also verify
17
+
@docs_input/executor_compatibility.rst and update it if executor support, limitations, or backend requirements changed.
18
+
19
+
When adding or changing accelerated backends such as CUDA, cuBLAS, cuSolver, cuFFT, or MathDx paths, preserve the existing non-accelerated behavior unless the task
20
+
explicitly calls for a breaking change. Prefer focused tests that compare the new backend against an existing trusted MatX path, and include negative tests for
21
+
unsupported shape, dtype, rank, or configuration combinations when applicable.
0 commit comments