# ms_ops

**Repository Path**: zhao_ting_v/ms_ops

## Basic Information

- **Project Name**: ms_ops
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 7
- **Created**: 2026-02-05
- **Last Updated**: 2026-06-16

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# custom_ops

[View Chinese](./README_CN.md)

<!-- TOC -->

- [About custom_ops](#about-custom_ops)
  - [Key Features](#key-features)
- [Quick Start](#quick-start)
- [Repository Layout](#repository-layout)
- [Documentation](#documentation)
- [Contributing](#contributing)
- [License](#license)

<!-- /TOC -->

## About custom_ops

`custom_ops` is a custom-operator repository for MindSpore/Pytorch Ascend. It uses YAML operator specifications  as the source of truth and generates MindSpore adapter code, enabling fast ACLNN operator integration through configuration-driven code generation.

For the currently supported operators, see [operation_manu](./docs/operation_manu.md).

### Key Features

- **YAML-driven integration**: operator specifications are maintained centrally under `custom_ops/config/` for batch onboarding and consistent review.
- **Automatic generation pipeline**: generates MindSpore-side operator integration code, test scaffolding, and operator documentation.
- **Dual loading modes**: supports both source-tree dev mode and release mode for development, debugging, and packaged validation.
- **Ascend-focused adaptation**: targets MindSpore Ascend + CANN, with emphasis on ACLNN and custom extension scenarios.
- **Extensible archive paths**: reserves `custom_ops/cann_ops/` for future in-house ACLNN / AscendC source archiving.

## Quick Start

Build and install:

```bash
CUSTOM_OPS_BUILD_JOBS=24 python compile.py --release --jobs 24
python -m pip install --force-reinstall output/custom_ops-*.whl
```

AscendC artifacts are built and packaged by default during release builds. After installation, importing `custom_ops` automatically adds the packaged AscendC OPP path to `ASCEND_CUSTOM_OPP_PATH`. To build only the AscendC artifacts, or to skip them during release packaging:

```bash
python compile.py --ascendc
python compile.py --release --no-ascendc
python compile.py --ascendc
```

`python compile.py --ascendc` now reuses `build/ascendc/cmake` incrementally by default, keeps `ASCEND_OP_NAME=ALL`,
auto-selects parallel jobs from `CUSTOM_OPS_BUILD_JOBS` / `MAX_JOBS` or `min(cpu_count, 32)`, and keeps the inner
`opc.py` stages on the same Python interpreter as `compile.py`.
Use `--clean` when a full AscendC rebuild is required.

To disable loading packaged AscendC artifacts at runtime:

```bash
CUSTOM_OPS_LOAD_ASCENDC=0 python your_script.py
```

A minimal usage example:

```python
import custom_ops
import mindspore as ms

ms.set_device("Ascend")

x = ms.Tensor([1.0, -2.0, 3.0], dtype=ms.float32)
print(ms.ops.custom.npu_fast_gelu(x).asnumpy())
```

For environment requirements, build commands, wheel generation, loader modes, and installation verification, see [docs/compilation_modes.md](./docs/compilation_modes.md).
For guidance on setting up the CANN and MindSpore runtime environment, refer to the official MindSpore repository: [https://gitcode.com/mindspore/mindspore](https://gitcode.com/mindspore/mindspore).

## Repository Layout

```text
ms_ops/
├── custom_ops/
│   ├── __init__.py                  # Source-tree import shim
│   ├── python/
│   │   ├── __init__.py              # Package entry
│   │   ├── bootstrap.py             # Registers ms.ops.custom
│   │   ├── dev_loader.py            # Source-tree JIT loader
│   │   ├── ops.py                   # Python compatibility entry
│   │   ├── custom/                  # Lazy ms.ops.custom namespace bridge
│   │   ├── registry/                # Runtime registry helpers
│   │   └── _C/                      # In-place release build output
│   ├── config/                      # YAML operator specifications
│   ├── ms_adapter/
│   │   ├── common/                  # Shared C++ entry and inference helpers
│   │   ├── pynative/                # Current active PyNative adapter path
│   │   └── kbk/                     # Reserved graph-mode adapter path
│   ├── cann_ops/                    # Reserved in-house ACLNN / AscendC archive
│   └── pt_adapter/                  # Reserved PyTorch-side adapter archive
├── codegen/
│   ├── ms_adapter/                  # Code generation scripts
│   └── templates/                   # Jinja2 templates
├── tests/
│   ├── shared/                      # Shared fixtures, utils, and opinfo base
│   ├── ms_adapter/                  # MindSpore adapter tests and opinfo cases
│   ├── pt_adapter/                  # Reserved PyTorch adapter tests
│   ├── legacy/                      # Historical generated function/aclnn tests
│   └── package/                     # Package/import/build-mode checks
├── docs/                            # Guides and generated operator docs
├── reference/                       # External reference code snapshots
├── compile.py
├── setup.py
└── pyproject.toml
```

## Documentation

- [docs/compilation_modes.md](./docs/compilation_modes.md): build and load mode reference
- [docs/directory_structure.md](./docs/directory_structure.md): directory structure overview
- [docs/ms_ops_development_guide.md](./docs/ms_ops_development_guide.md): development guide, test commands, and operator onboarding flow
- [docs/operation_manu.md](./docs/operation_manu.md): operator documentation index
- [docs/operators/supported_operators.md](./docs/operators/supported_operators.md): supported operator list

## Contributing

Contributions are welcome in the following areas:

- Add or complete YAML operator specifications
- Improve MindSpore-side adaptation implementations
- Add tests and regression coverage
- Improve operator docs and development docs

Before submitting changes, run at least the tests that match your modification scope and make sure dev / release behavior has not regressed.

## License

The repository root does not currently provide a standalone `LICENSE` file. If you need explicit license constraints, confirm them against future repository updates or the relevant upstream project policy.