|
| 1 | +This file describes `cuda_bindings`, the low-level CUDA host API bindings |
| 2 | +subpackage in the `cuda-python` monorepo. |
| 3 | + |
| 4 | +## Scope and principles |
| 5 | + |
| 6 | +- **Role**: provide low-level, close-to-CUDA interfaces under |
| 7 | + `cuda.bindings.*` with broad API coverage. |
| 8 | +- **Style**: prioritize correctness and API compatibility over convenience |
| 9 | + wrappers. High-level ergonomics belong in `cuda_core`, not here. |
| 10 | +- **Cross-platform**: preserve Linux and Windows behavior unless a change is |
| 11 | + intentionally platform-specific. |
| 12 | + |
| 13 | +## Package architecture |
| 14 | + |
| 15 | +- **Public module layer**: Cython modules under `cuda/bindings/` expose user |
| 16 | + APIs (`driver`, `runtime`, `nvrtc`, `nvjitlink`, `nvvm`, `cufile`, etc.). |
| 17 | +- **Internal binding layer**: `cuda/bindings/_bindings/` provides lower-level |
| 18 | + glue and loader helpers used by public modules. |
| 19 | +- **Platform internals**: `cuda/bindings/_internal/` contains |
| 20 | + platform-specific implementation files and support code. |
| 21 | +- **Build/codegen backend**: `build_hooks.py` drives header parsing, template |
| 22 | + expansion, extension configuration, and Cythonization. |
| 23 | + |
| 24 | +## Generated-source workflow |
| 25 | + |
| 26 | +- **Do not hand-edit generated binding files**: many files under |
| 27 | + `cuda/bindings/` (including `*.pyx`, `*.pxd`, `*.pyx.in`, and `*.pxd.in`) |
| 28 | + are generated artifacts. |
| 29 | +- **Generated files are synchronized from another repository**: changes to these |
| 30 | + files in this repo are expected to be overwritten by the next sync. |
| 31 | +- **If generated output must change**: make the change at the generation source |
| 32 | + and sync the updated artifacts back here, rather than patching generated files |
| 33 | + directly in this repo. |
| 34 | +- **Header-driven generation**: parser behavior and required CUDA headers are |
| 35 | + defined in `build_hooks.py`; update those rules when introducing new symbols. |
| 36 | +- **Platform split files**: keep `_linux.pyx` and `_windows.pyx` variants |
| 37 | + aligned when behavior should be equivalent. |
| 38 | + |
| 39 | +## Testing expectations |
| 40 | + |
| 41 | +- **Primary tests**: `pytest tests/` |
| 42 | +- **Cython tests**: |
| 43 | + - build: `tests/cython/build_tests.sh` (or platform equivalent) |
| 44 | + - run: `pytest tests/cython/` |
| 45 | +- **Examples**: example coverage is pytest-based under `examples/`. |
| 46 | +- **Benchmarks**: run with `pytest --benchmark-only benchmarks/` when needed. |
| 47 | +- **Orchestrated run**: from repo root, `scripts/run_tests.sh bindings`. |
| 48 | + |
| 49 | +## Build and environment notes |
| 50 | + |
| 51 | +- `CUDA_HOME` or `CUDA_PATH` must point to a valid CUDA Toolkit for source |
| 52 | + builds that parse headers. |
| 53 | +- `CUDA_PYTHON_PARALLEL_LEVEL` controls build parallelism. |
| 54 | +- `CUDA_PYTHON_PARSER_CACHING` controls parser-cache behavior during generation. |
| 55 | +- Runtime behavior is affected by |
| 56 | + `CUDA_PYTHON_CUDA_PER_THREAD_DEFAULT_STREAM` and |
| 57 | + `CUDA_PYTHON_DISABLE_MAJOR_VERSION_WARNING`. |
| 58 | + |
| 59 | +## Editing guidance |
| 60 | + |
| 61 | +- Keep CUDA return/error semantics explicit and avoid broad fallback behavior. |
| 62 | +- Reuse existing helper layers (`_bindings`, `_internal`, `_lib`) before adding |
| 63 | + new one-off utilities. |
| 64 | +- If you add or change exported APIs, update relevant docs under |
| 65 | + `docs/source/module/` and tests in `tests/`. |
| 66 | +- Prefer changes that are easy to regenerate/rebuild rather than patching |
| 67 | + generated output directly. |
0 commit comments