feat(hardware_backend): add HardwareBackend extension kind and PyO3 CUDA dispatch support - #1
Merged
Merged
Conversation
…y-gated resolve() gates every lookup through capability_check::check before attempting a native dlopen, the crate's first production call site for that function. HardwareBackendRouter::new keeps the same signature as PlaneCodecRouter/DeltaSchemeRouter (no policy parameter): neither existing router threads a HostPolicy through its constructor, and HostPolicy::default().available_hardware is an empty Vec, so the default denies every hardware_class-declaring contribution unconditionally. That is documented on resolve() itself rather than left as a TODO.
… not merely absent-safe
…ng back to the wrong generic template)
…ef_hardware_backend
HardwareBackendRouter::resolve() always checked capabilities against HostPolicy::default(), whose empty available_hardware denies every hardware_class-declaring contribution with no way for any caller to say "this host actually has X". new() keeps that exact default-deny behavior; new_with_policy() lets a caller supply a HostPolicy instead, so an operator-approved policy can admit a real contribution. Neither capability_check::check nor the hardware_class-presence precondition in resolve() changed. Adds a regression test proving new_with_policy actually admits what new()'s default denies, by checking that resolution fails at the "no native artifact" step rather than "capability check denied" once a matching hardware_class is granted.
…inding hardware_backend_cuda_stream_handle and hardware_backend_dispatch_decode_cuda were HardwareBackendRouter's only production callers, and both built the router with HardwareBackendRouter::new, so a real CUDA contribution would hit the same default-deny wall the router_native test fixture does. Both functions gain an optional trailing `policy` parameter (a ResolvedPolicy, the existing PyO3-exposed type from policy.rs). When supplied, its HostPolicy is passed to HardwareBackendRouter::new_with_policy; when omitted, behavior is unchanged (default-deny via HardwareBackendRouter::new). PyResolvedPolicy gains a pub(crate) host_policy() accessor for this, not exposed to Python.
…eference fixture First test in the repo's history exercising the entire hardware_backend dispatch path: router resolution, capability check, dlopen, native-symbol probing, and an FFI call, against a real compiled ref_hardware_backend .so, not a mock. ref_hardware_backend's manifest declares hardware_class = "cpu", which HardwareBackendRouter::new's default-deny policy would reject before any dlopen. Uses the just-added HardwareBackendRouter::new_with_policy with a policy that explicitly grants "cpu" to available_hardware, mirroring what an operator's policy file would need to configure on a real host. #[ignore]-gated: requires building extensions/ref_hardware_backend first (cd extensions/ref_hardware_backend/rust && cargo build --release).
…reBackend dispatch method
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds support for the
HardwareBackendextension kind toptwm-coreandptwm-py, enabling native hardware-accelerated extension dispatch (such as CUDA kernels).Changes
HardwareBackendextension kind, C ABI function signatures (HardwareBackendCudaDispatchDecodeFn,HardwareBackendCudaStreamHandleFn), and Rust wrapper types inptwm-core.HardwareBackendRouterwith capability-based policy checks (hardware_class = "cuda"), nativedlopenloading, andHardwareBackendRouter::new_with_policyfor operator-configured host hardware access.hardware_backend_dispatch_decode_cudaandhardware_backend_cuda_stream_handlePyO3 functions inptwm-pywith__dlpack__tensor memory inspection.ptwm ext inittemplate, added native build routing tocargo-oxideinptwm ext build, and added native reference fixture tests (ref_hardware_backend).