executorch: make CUDA backend and partitioner targets PUBLIC - #21411
Conversation
…t dtype/device (PR pytorch#4404) Summary: Forward-port of upstream pytorch/TensorRT PR pytorch#4404, re-anchored on top of the pristine release/2.13 cut. PR pytorch#4404 is now merged upstream (merge commit 8ab76546); the vendored code here is byte-identical to the merged files (the two new test files, _exporter.py, test_api.py additions, and docs match exactly, and _compile.py carries the merged PR's additions verbatim). This is the FULL PR: upstream converged on the partitioners= approach and dropped the earlier cuda_fallback kwarg, so a coalesced TensorRT + CUDA .pte is built via save(..., partitioners=[CudaPartitioner(...)]) appended after the TensorRTPartitioner. Fix 1 (py/torch_tensorrt/_compile.py): write the external weight .ptd. torch_tensorrt.save(..., output_format="executorch") wrote only the .pte and dropped ExecutorchProgramManager._tensor_data, so any program whose delegate externalizes weight constants to a separate data file had no backing blob at load. The CUDA (AOTInductor) backend externalizes its weights (save_data_externally / package_constants_in_so=False) as <hash>_weights_blob .ptd files; without the .ptd the delegated kernel dereferenced a null weights pointer (illegal memory access) even though the .pte itself loaded fine. Factored into _write_external_tensor_data(program, file_path), called after write_to_file: it writes the .ptd data file(s) into the .pte's directory when _tensor_data is present (a no-op otherwise), and logs where it wrote. _tensor_data is read directly (no getattr default) so a future rename fails loudly instead of silently reintroducing the crash. The loader must be pointed at the .ptd (e.g. via the runtime Module's data-files argument); co-locating them with the .pte is the convention this write follows. Fix 2 (py/torch_tensorrt/dynamo/_exporter.py, lift): keep lifted constant device and dtype. The meta val for a lifted parameter/buffer was built with torch.empty_strided(shape, strides), dropping the source tensor's dtype and device. A non-float32 or non-CPU lifted constant then got wrong meta, which matters once the program is placed on an accelerator. The current PR fakifies the source constant through the graph's own fake_mode (fake_mode.from_tensor(lift_val, static_shapes=True)), preserving dtype, device, and stride without allocating a real tensor on the source device. Tests + docs (mirrored from pytorch#4404): - tests/py/dynamo/executorch/test_api.py, test_edge_cases.py: CPU-only unit tests (no GPU/CUDA backend needed) for lift() dtype/device preservation and the .ptd write (present -> writes, empty -> no-op, missing attr -> fails loud). - tests/py/dynamo/executorch/test_cuda_partitioner_composition.py: GPU-gated composition suite -- a CudaPartitioner catch-all routes a TRT-unsupported op to the CUDA backend, a weighted CUDA partition persists its external .ptd, and a TRT-only program writes none. Buckified here (new python_pytest_remote_gpu target) so the suite that upstream GitHub CI runs is also covered in fbsource; this needs the executorch CUDA-backend python targets (cuda_backend, cuda_partitioner) visible to third-party/torch_tensorrt, so their visibility is widened in executorch/backends/cuda/BUCK. - docsrc/user_guide/runtime_performance/saving_models.rst: the CudaPartitioner coalescing recipe. Vendored as a temporary forward-port on top of the pristine release/2.13 cut, tracked in fb/patches/upstream/4404-executorch-write-ptd-and-exporter-device.patch and IMPORT.md; drop it when the next 2.13 import already contains pytorch#4404. The patch and its description are public-clean. Reviewed By: SS-JIA Differential Revision: D113389646
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/21411
Note: Links to docs will display an error until the docs builds have been completed. ❌ 2 New Failures, 1 Unrelated FailureAs of commit ff51ee2 with merge base 55d693b ( NEW FAILURES - The following jobs have failed:
FLAKY - The following job failed but was likely due to flakiness present on trunk:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
|
@shoumikhin has exported this pull request. If you are a Meta employee, you can view the originating Diff in D113389646. |
SS-JIA
left a comment
There was a problem hiding this comment.
Review automatically exported from Phabricator review in Meta.
This PR needs a
|
There was a problem hiding this comment.
Pull request overview
This PR adjusts ExecuTorch’s Buck build visibility for CUDA backend Python targets, making them consumable by external Buck packages (e.g., third-party integrations).
Changes:
- Widen
cuda_backendBuck target visibility toPUBLIC. - Widen
cuda_partitionerBuck target visibility toPUBLIC.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Summary
Make the ExecuTorch CUDA backend's Python export targets publicly visible.
backends/cuda/BUCKnow setscuda_backendandcuda_partitionertovisibility = ["PUBLIC"](previously["//executorch/..."]). These are the Python export-side targets: theCudaBackenddelegate and theCudaPartitionerused at.pteexport time.Motivation
A consumer outside
//executorch/...(the Torch-TensorRT ExecuTorch composition test, which builds a coalesced TensorRT + CUDA.pteviaCudaPartitioner) needs to depend on these targets.PUBLICis how ExecuTorch already exposes this kind of target: the CoreMLbackend/partitioner, the MPS and MediaTek backends, and the CUDA runtime targets (cuda_platform,runtime_shims,cuda_allocator, and the C++cuda_backend) are allPUBLIC. Using it here avoids ad-hoc per-consumer visibility grants that would need editing every time a new consumer appears.Test plan
Visibility-only change; no code behavior is affected.
buck2 cqueryon the consuming composition test resolves its dependencies oncuda_backendandcuda_partitionerwith no visibility violation.