TensorView/DiffTensorView bypasses interop buffer on non-CUDA backends

[jhelferty-nv]

(Noticed by coderabbit in PR #781)

In NativeTorchTensorMarshall::write_torch_tensor_fields() and the DiffTensorView path in write_shader_cursor_pre_dispatch(), when offsets.is_tensorview is true, the code writes info.data_ptr (a CUDA device pointer from the PyTorch tensor) directly into the TensorViewData struct via shader_object->set_data(). This bypasses the interop buffer copy path that exists for non-CUDA backends (Vulkan/D3D12).

On Vulkan/D3D12, CUDA device addresses are not valid — the interop buffer mechanism exists specifically to copy data between PyTorch's CUDA memory and a shared buffer accessible to the non-CUDA device. The TensorView path skips this entirely, which would result in invalid device addresses being bound to the shader.

This was introduced in #775 ("Add DiffTensorView and TensorView support in slangpy"). The relevant code is in slangpytorchtensor.cpp:

• write_torch_tensor_fields(): the if (offsets.is_tensorview) early-return at ~line 491
• write_shader_cursor_pre_dispatch(): the else if (m_cached_binding_info.primal.is_tensorview) branch at ~line 417

Both paths call populate_tensorview_data() which embeds info.data_ptr directly, then write via set_data() without creating an interop buffer.

Possible fix: Either guard TensorView paths to error on non-CUDA backends, or extend the interop buffer mechanism to support TensorView bindings (copy to interop buffer, then write the interop buffer's device address into the TensorViewData struct).

[mkeshavaNV]

I doubt we ever plan to support these on non cuda backend. So I think this will be WNF. I will keep it on me to verify this and close.

[bmillsNV]

@mkeshavaNV can you verify next sprint?

[nv-slang-bot]

Triage: claim confirmed at HEAD — but open PR #934 carries only half the fix (the address, not copy-back)

• Status: Triaged. Claim CONFIRMED at HEAD 086ca32; the issue text's locations are stale and the mechanism is described slightly wrong (details below). Classified bug / low severity / P3 / torch-integration (nanobind) / Vulkan+D3D12. Not upstream-Slang. Disposition: maintainer-gated — no fix in flight from us. (Corrected 2026-08-04: an earlier revision of this comment said "the fix is already sitting in an open PR." That overstated Fix CUDA interop buffer race and add targeted CUDA↔graphics sync (#929) #934 — see Next-action. Apologies for the misleading headline.)
• Link: src/slangpy_ext/utils/slangpytorchtensor.cpp:428-433 (single site) → populate_tensorview_data():151. Note the path is src/slangpy_ext/utils/, not src/slangpy_torch/; the early-return is at 428, not ~491; and the second branch cited at "~line 417" in write_shader_cursor_pre_dispatch() no longer exists — that function (255-410) now contains zero is_tensorview references, so there is exactly one TensorView site, not two.
• Verdict: Reachable and unguarded — is_tensorview is set purely structurally (slangpytensor.cpp:133-143: true iff the Slang type has no _data field), with no DeviceType check anywhere on the path. The mechanism is not quite "bypasses the interop buffer": the buffer is allocated and the torch data is copied into it (:553-554 → create_interop_buffer_from_tensor → TorchBridge::copy_to_buffer at :522), it is passed into write_torch_tensor_fields (:571/582), and then line 428 returns without ever reading it. So a full device-to-device copy is paid and discarded, and the CUDA VA is embedded anyway. Severity stays low only because docs/src/autodiff/pytorch.rst:177 (added by Add DiffTensorView<T> and TensorView<T> support in slangpy #775 itself) already states "TensorView<T> is CUDA-only. It will not work with Vulkan or D3D12 backends" — this is a missing guard on a documented-unsupported config, not a broken supported feature.
• Next-action: ⚠️ @mkeshavaNV — a decision is needed, and please don't read Fix CUDA interop buffer race and add targeted CUDA↔graphics sync (#929) #934 as closing this. What Fix CUDA interop buffer race and add targeted CUDA↔graphics sync (#929) #934 does and doesn't do: it fixes the address at the single is_tensorview site (tvd.data = interop_buffer->device_address() + contiguous-stride recompute). It does not fix copy-back — its only other hunk near that block adds _primal_interop_keepalive/_grad_interop_keepalive refs for the Interop buffer cleanup race: cuImportExternalMemory fails after async memset on Vulkan/D3D12 interop buffers #929 lifetime race and leaves the copy-back gate untouched. Copy-back is gated on the Slang type-name prefix: needs_primal_copyback ← primal_writable ← name begins RW or W (:238-243). TensorViewType::build_tensorview_name (src/sgl/refl/type.cpp:843) emits exactly TensorView<{element}> — neither prefix, and no RW/W variant of TensorView exists — so the gate is unconditionally false for TensorView/DiffTensorView, while store() is precisely how these shaders write output (test_tensorview.slang:6,12,18). The prefix test does fire for other types (type.cpp:816 prefix += "RW" via build_tensor_name), so this is specific to TensorView, not a dead branch. ⇒ Fix CUDA interop buffer race and add targeted CUDA↔graphics sync (#929) #934 merged as-is yields a correct address and still silently drops output. Fix CUDA interop buffer race and add targeted CUDA↔graphics sync (#929) #934 is also open, non-draft, conflicted (mergeable_state: dirty, untouched since 2026-07-25). So please pick: (A) guard — ~3 lines, SGL_CHECK in write_shader_cursor_with_interop() before the :551 allocation (skips the wasted copy too); makes code agree with the docs; the only option testable in current CI. (B) extend — that's three pieces, not one: Fix CUDA interop buffer race and add targeted CUDA↔graphics sync (#929) #934's address change + a copy-back companion at :623 + a docs correction, since pytorch.rst:177/:207 become false under B; needs a CUDA-interop Vulkan/D3D12 runner CI doesn't have. (C) WNF, no code change — your Feb comment said "I doubt we ever plan to support these on non cuda backend… will be WNF"; if that still holds, C plus the small guard from A is likely the cheapest correct outcome, so the unsupported config fails loudly instead of silently.
• Blocker: No repro exists and none can be written without an A/B/C decision — and there is zero executing coverage on non-CUDA to regress against: test_tensorview.py:19-21 and test_difftensorview.py:18-20 both hardcode DEVICE_TYPES = [DeviceType.cuda] ... behind a module-level pytest.skip, so a Vulkan/D3D12 variant never even collects. All 63 TensorView/DiffTensorView tests are CUDA-only; CI installs torch+CUDA on self-hosted Win/Linux only (ci.yml:164-166) and has no CUDA-interop Vulkan/D3D12 runner. "No failing test" here means the path is unexercised, not that it works. Also note the automatic interop copy-back can't rescue B for free: device.cpp:1004-1013 iterates CommandBuffer::m_cuda_interop_buffers, populated only by ShaderObject::set_cuda_tensor_view_* (shader_object.cpp:199,209), whereas the torch marshall creates plain sgl::Buffers (:515-520) and does its own TorchBridge::copy_to_buffer.

_{🤖 Generated by an automated SlangPy coworker — may be inaccurate. A human maintainer should verify.}

[jkiviluoto-nv]

@nv-slang-bot Mukund (mkeshavaNV) won't be returning to this work for a while. Please scrub this issue and assess whether it is still relevant, needs reassignment, or should be closed.

[nv-slang-bot]

Scrub requested by @jkiviluoto-nv — re-verified at HEAD 507b4cf, answering your three questions

Re-derived from source today rather than from our 08-04 notes (main moved 086ca32 → 507b4cf; the two intervening commits, #1078 and #1084, touch none of the relevant files, and all four load-bearing facts below reproduce verbatim at 507b4cf).

• Status — 1) Still relevant? YES, but not for the reason the title says. The reported defect is real and unchanged: one is_tensorview site at slangpytorchtensor.cpp:428-433 early-returns and embeds the raw torch CUDA pointer (populate_tensorview_data():151, tvd.data = reinterpret_cast<uint64_t>(info.data_ptr)) while ignoring the interop buffer that was already allocated and filled for it. The more serious half is the part not in the original report: copy-back is gated on a Slang type-name prefix — needs_primal_copyback ← primal_writable ← name begins RW or W (:238-243) — and TensorViewType::build_tensorview_name (src/sgl/refl/type.cpp:843) emits exactly TensorView<{element}>. No RW/W variant of TensorView exists, so that gate is structurally always false, while store() is precisely how these shaders write output (test_tensorview.slang:6,12,18). Positive control: build_tensor_name (type.cpp:816) does emit prefix += "RW", so the test fires for other types — this is specific to TensorView, not a dead branch. Net user-visible behaviour on Vulkan/D3D12: output silently vanishes, no error. That's a silent-wrong-results footgun, which is why I'd not close this as a pure no-op.
• Link — what Fix CUDA interop buffer race and add targeted CUDA↔graphics sync (#929) #934 does and does not do (please don't read it as covering this): it fixes the address at the single is_tensorview site (tvd.data = interop_buffer->device_address() + contiguous-stride recompute). It does not touch copy-back — its only other hunk there adds _primal_interop_keepalive/_grad_interop_keepalive refs for the Interop buffer cleanup race: cuImportExternalMemory fails after async memset on Vulkan/D3D12 interop buffers #929 lifetime race. ⇒ Fix CUDA interop buffer race and add targeted CUDA↔graphics sync (#929) #934 merged as-is yields a correct address and still silently drops output. It is also mergeable: dirty (conflicted) and untouched since 2026-07-25 — ~6 weeks. Under the "extend" option, the copy-back fix and a docs correction (docs/src/autodiff/pytorch.rst:177 and :207 both assert TensorView is CUDA-only) still need an owner regardless of who lands the address change.
• Verdict — 3) Close? My recommendation: split it in two, and don't treat WNF as already-decided. @mkeshavaNV's Feb-26 "I doubt we ever plan to support these on non cuda backend… I think this will be WNF" is a well-informed data point, and the code and docs agree with it — pytorch.rst:170-173 calls TensorView "not recommended for new code… exists only for backward compatibility with existing slangtorch code." But it was never ratified, so I'm not executing it as a decision. The two parts are independent and I'd recommend both: (a) close the "make TensorView work on Vulkan/D3D12" ask as WNF — that's a feature commitment on a legacy compat path, contradicting your own documented position, needing three pieces (address + copy-back + docs) and a CUDA-interop Vulkan/D3D12 CI runner that doesn't exist; (b) keep, and land, a ~3-line guard — SGL_CHECK in write_shader_cursor_with_interop() before the :551 allocation, which also skips the wasted device-to-device copy that is currently paid and discarded. Closing WNF without (b) leaves silent data loss on a documented-unsupported config; (b) makes the code agree with the docs and is the only option testable in current CI (pytest.raises on any non-CUDA device). If you prefer, (b) is small enough to be a fresh narrowly-scoped issue and this one closed WNF.
• Next-action — 2) Reassignment: proposing @jhelferty-nv, for you to accept or reject — I'm explicitly not asserting he's available. He's the strongest candidate on the record: he filed TensorView/DiffTensorView bypasses interop buffer on non-CUDA backends #823, and he authored and is assigned Fix CUDA interop buffer race and add targeted CUDA↔graphics sync (#929) #934 and Interop buffer cleanup race: cuImportExternalMemory fails after async memset on Vulkan/D3D12 interop buffers #929, so the interop-buffer surface is already his. Caveat I want to be straight about: his last activity here is 2026-07-25, which is evidence about 07-25 and says nothing about his current capacity — the same inference that just proved wrong for Mukund. So this is a proposal, not a conclusion; you're better placed to judge. Also worth flagging beyond this issue: @mkeshavaNV is still assignee on 6 other open slangtorch_parity_polish items (Add bool dtype support to slangpy native Tensor #899, Support 2D/3D dispatch with configurable thread group size for torch tensor workflows #844, .dispatch() does not support torch.Tensor arguments #832, able to wrap a 'raw entry point' for the backwards pass, and detect that if the forwards function is marked [CUDAKernel], so should the backwards one be #822, Support raw dispatch in slangpy #768 and this one), several milestoned Q1/Q2 2026 — if he's away for a while, those need the same scrub, and TensorView/DiffTensorView bypasses interop buffer on non-CUDA backends #823's own milestone is still Q1 2026 (Winter), two quarters past.
• Blocker — what I could not settle, and what needs a human: whether TensorView support is worth extending is product scope, not something we should decide — I found no deprecation or removal plan on record for it, so "legacy but supported" is the status quo. Also note the honest evidence limit on severity: there is zero executing coverage on non-CUDA to regress against (test_tensorview.py:19-21, test_difftensorview.py:18-20 hardcode DEVICE_TYPES = [DeviceType.cuda] behind a module-level pytest.skip, so a Vulkan/D3D12 variant never even collects; all 63 TensorView/DiffTensorView tests are CUDA-only, and CI installs torch+CUDA on self-hosted Win/Linux only, ci.yml:164-166). So the silent-output-drop above is derived from reading the code, not from an observed repro — nobody has ever run this path. That cuts both ways: it's why the bug survived 5 months unnoticed, and it's why "no failing test" should not be read as "works."

_{🤖 Generated by an automated SlangPy coworker — may be inaccurate. A human maintainer should verify.}