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
{{ message }}
Repository navigation
Commit fde20d9
Browse filesBrowse the repository at this point in the historyBrowse files
## PR stack
#23088 adds Python buffer inputs, relanded in #23535. #23089 removes the
portable bindings' C++ ATen dependency. This PR adds DLPack interchange
on top of the updated #23089 head (`55f443a9f8`).
## Summary
Accept dense CPU and CUDA DLPack producers alongside Python buffers and
`torch.Tensor` inputs. Preserve pointers, dtype, shape, strides, storage
offsets, and device indices while checking compatibility with ExecuTorch
dimension order and serialized input devices.
`ExecuTorchResult` exposes `__dlpack__` and `__dlpack_device__`. Outputs
remain Python Torch tensors when Torch is available;
`EXECUTORCH_PYBINDINGS_TENSOR_OUTPUT=executorch` selects ExecuTorch
results without importing Torch. When the setting is unset and Torch is
unavailable, the bindings automatically select ExecuTorch results. An
explicit `torch` setting still requires Torch to import successfully.
CUDA outputs remain device allocations. Borrowed results retain their
actual runtime or producer storage, and cloned CUDA results use
device-to-device copies without a C++ ATen dependency. CUDA DLPack
inputs and ExecuTorch CUDA results require CUDA-enabled bindings. Torch
CUDA inputs and outputs synchronize through Python Torch, preserving
their behavior in CPU builds of the bindings.
The CUDA boundary currently synchronizes device work to establish
producer, delegate, and consumer readiness. DLPack producers receive the
supported legacy default stream. Retain installed Module inputs for
subsequent executions, bound ownership during repeated result feedback,
and serialize calls on each shared method and module.
The Windows wheel uses its shipped CUDA helper without requiring an
external CUDA runtime DLL at import. CUDA result cloning can use that
helper's allocator without requiring CUDA delegate registration. CUDA CI
selects a compatible C++ runtime so CUDA 12.6 can load its AOTI model
libraries.
## Validation
The CUDA build workflow runs three required-GPU integration tests in
both output modes on CUDA 12.6, 13.0, and 13.4 runners. They exercise a
real CUDA delegate, delayed producer streams, separate consumer streams,
driver-verified device pointers, offsets, channels last, cloning, direct
result roundtrip, and borrowed lifetimes. The identity test covers both
Torch and DLPack inputs. Missing CUDA hardware or backend fails the CI
invocation.
Locally, nine focused CPU checks passed, including import policies,
shared-object concurrency, DLPack inputs, layout validation, mixed
protocols, runtime error codes, and ownership. Shared-object concurrency
also passed in ExecuTorch output mode. Execution with the output
variable unset passed in a Torch-free interpreter. Portable compilation
and linking with LTO, CUDA helper compilation against CUDA 12.6 headers
using GCC 13, workflow YAML, shell syntax, formatting, and diff checks
passed. The local extension links no Torch libraries. GPU execution and
Windows wheel verification await CI because this machine has no CUDA
device or Windows runtime.
Authored with OpenAI Codex.
The CUDA build workflow runs `test_pybindings_cuda_dlpack.py` in both output
87
+
modes on a GPU. It checks device allocations, DLPack stream ordering, channels
88
+
last views, cloning, and borrowed output lifetimes using a CUDA delegate.
89
+
Set `EXECUTORCH_PYBIND_TEST_REQUIRE_CUDA=1` when running this test to treat missing
90
+
GPU hardware or a missing CUDA backend as a failure.
91
+
51
92
# Link Backends
52
93
53
94
Not all backends are built into the pip wheel by default. You can link these missing/experimental backends by turning on the corresponding cmake flag. For example, to include the Vulkan backend:
0 commit comments