The GitHub Actions job "CI" on tvm-ffi.git/module-load-from-bytes has failed. Run started by GitHub user lucifer1004 (triggered by lucifer1004).
Head commit for run: 70ef19be8cb01e3f2620fc8ae56ccd9b118b09f2 / Zihua Wu <[email protected]> [FEAT] Module::LoadFromBytes: dispatching entry point for in-memory module loaders The internal helper `LoadModuleFromBytes(kind, bytes)` (`src/ffi/extra/library_module.cc`) has been around for a while as a C++ free function used during binary deserialization. It was not exposed as a public Module API, so callers who already hold module payload in memory (e.g. a PTX or CUBIN blob fetched from a registry) had to materialize it to disk first and go through `ModuleLoadFromFile`. This commit promotes the helper to a public `Module::LoadFromBytes(kind, bytes)` and registers it as the `ffi.ModuleLoadFromBytes` global so Python and Rust bindings can call it without re-implementing kind → loader dispatch. ## API contract `Module::LoadFromBytes(kind, bytes)` dispatches to the registered global `ffi.Module.load_from_bytes.<kind>` (signature `(Bytes) -> Module`). If no loader for the given kind is registered, `RuntimeError` is raised naming the missing key — so the user knows exactly what to register. This is the *dispatching entry point*, not a specific format loader. Loaders are registered by consumers, mirroring how loaders for module formats already work today (the cubin_launcher example header-only library is the canonical CUDA loader template). This split keeps `libtvm_ffi.so` independent of libcuda / ROCm / etc.: a CPU-only build of tvm-ffi has the API but no built-in CUDA loader, whereas a consumer-side `.so` (built against `cubin_launcher.h`) can register `ffi.Module.load_from_bytes.cubin` for everyone in the same process. ## Changes * `include/tvm/ffi/extra/module.h`: declares `Module::LoadFromBytes(const String& kind, const Bytes& bytes)` with a doc note pointing at `cubin_launcher` as the canonical loader template. * `src/ffi/extra/library_module.cc`: defines it as a thin wrapper around the existing `LoadModuleFromBytes`. * `src/ffi/extra/module.cc`: registers `ffi.ModuleLoadFromBytes` in the static-init block alongside `ffi.ModuleLoadFromFile`. * `rust/tvm-ffi/src/extra/module.rs`: adds `tvm_ffi::Module::load_from_bytes(kind, bytes)`. * `python/tvm_ffi/module.py`: adds `load_module_from_bytes(kind, data)` mirroring the existing `load_module(path)`. Exposed from `tvm_ffi/__init__.py`. * `python/tvm_ffi/_ffi_api.py`: regenerated stub. * `tests/python/test_module_load_from_bytes.py`: three end-to-end tests covering (1) round-trip via a Python-registered loader, (2) error path when no loader is registered, (3) loader exceptions propagating to the caller. ## Motivation Use case: a project that fetches CUDA PTX / CUBIN payloads from a registry already has the bytes in memory. The current `Module::LoadFromFile` path forces a tempfile detour. With this API: ```python import tvm_ffi @tvm_ffi.register_global_func("ffi.Module.load_from_bytes.echo") def _echo_loader(payload: bytes) -> tvm_ffi.Module: # Real loader would parse `payload` and return a runnable module. ... mod = tvm_ffi.load_module_from_bytes("echo", b"<payload>") ``` The dispatch through `ffi.Module.load_from_bytes.<kind>` is unchanged; existing loaders register exactly as before. Report URL: https://github.com/apache/tvm-ffi/actions/runs/25899730272 With regards, GitHub Actions via GitBox --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
