cuda.core: account for DLTensor.byte_offset in from_dlpack

[fedonman]

Description

closes #2592

DLPack places a tensor's first element at data + byte_offset. view_as_dlpack, which backs StridedMemoryView.from_dlpack and from_any_interface, set ptr from data alone, so a producer that reports the allocation base in data and expresses a slice as byte_offset produced a view pointing byte_offset bytes before the tensor, with nothing raised. The capsule-consuming importer in the same module, _smv_from_dlpack_capsule, already folds byte_offset in, so the two import paths disagreed about the same capsule. This makes view_as_dlpack match it, and that one line is the whole production change.

Correcting ptr also fixes the round-trip. The __dlpack__ re-export writes ptr back out as data with byte_offset = 0, so before this change a non-zero offset was dropped permanently on the way back out.

The new test exercises both the versioned and the unversioned capsule branches. It views the first 8 elements of a 9-element array, then re-describes the same tensor as src[1:9] by writing byte_offset alone, so a regression fails an assertion rather than reading out of bounds. shape and strides share a single producer-owned allocation, so the test does not touch them.

A release note is added under Fixes and enhancements in cuda_core/docs/source/release/1.2.0-notes.rst; the affected behavior has been present since 0.1.0.

Verification

The new test, both capsule flavours:

tests/test_utils_dlpack.py::test_from_dlpack_honours_byte_offset[unversioned] PASSED [ 50%]
tests/test_utils_dlpack.py::test_from_dlpack_honours_byte_offset[versioned] PASSED [100%]
======================= 2 passed, 30 deselected in 0.11s =======================

The same test with the one-line change reverted:

=========================== short test summary info ============================
FAILED tests/test_utils_dlpack.py::test_from_dlpack_honours_byte_offset[unversioned]
FAILED tests/test_utils_dlpack.py::test_from_dlpack_honours_byte_offset[versioned]
======================= 2 failed, 30 deselected in 0.14s =======================

The full cuda_core suite:

3569 passed, 412 skipped, 1 xfailed in 159.90s (0:02:39)

Checklist

• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[aryanputta]

@fedonman I was assigned #2592 today, but this PR already has the fix, so I would rather see it merged than open another one. I closed my own #2595 as a duplicate of this back on Aug 10.

The only thing blocking it is that the branch is 30 commits behind main and GitHub now reports it as conflicting. The conflict is in cuda_core/docs/source/release/1.2.0-notes.rst, where #2517, #2439, and #2389 all added entries to the same list since you opened this. Keeping every upstream entry and appending yours last resolves it.

Are you able to merge main into it? If you would rather not carry it, say so and I will open a PR that cherry-picks your commit so the authorship stays with you.

For what it is worth, I audited whether the one line is sufficient. byte_offset appears at exactly three sites in _memoryview.pyx: L741 in _smv_setup_dl_tensor_common sets data = ptr with byte_offset = 0, which is a valid encoding and needs no change; L866 in _smv_from_dlpack_capsule already adds it; L1105 in view_as_dlpack is the only defect. So this is complete, and the round-trip loss described in the issue is a consequence of the import side rather than a second bug on export.

[aryanputta]

I reviewed this properly rather than just eyeballing the diff. No blocking findings. Recording what I checked so it is not re-done.

The fix line is the idiom already shipping in this file. After patching, the right-hand side of L1105 is byte-identical to L866 in _smv_from_dlpack_capsule, which has always been correct:

view.ptr = <intptr_t>(dl_tensor.data) + <intptr_t>(dl_tensor.byte_offset)

So this is not a new expression, it makes the two import paths agree.

One line is sufficient. byte_offset occurs at exactly three sites in _memoryview.pyx. L741 in _smv_setup_dl_tensor_common sets data = ptr and byte_offset = 0 on export, which is a valid encoding and needs no change. L866 already adds it. L1105 is the only defect. This also means the re-export cannot double-count: it writes byte_offset = 0 rather than propagating the consumed tensor's value.

Cython accepts it. I cannot build cuda.core here, so I compiled _memoryview.pyx with and without the patch and diffed the diagnostics. Identical, so the cast introduces nothing new. byte_offset is uint64_t and intptr_t is 64-bit on every supported target, so the cast is lossless in practice.

The spec claim holds against an independent implementation. I built the issue's producer and consumed it with numpy 2.3.5, which has its own DLPack reader:

data               : 105553171907136
byte_offset        : 32
data + byte_offset : 105553171907168
numpy read         : [ 8  9 10 11 12 13 14 15]
expected (src[8:]) : [ 8  9 10 11 12 13 14 15]

So data + byte_offset is not just this issue's assertion.

The test drives the path it claims to. view_as_dlpack negotiates with try: obj.__dlpack__(..., max_version=(1,0)) except TypeError: obj.__dlpack__(...), so the raise TypeError("force unversioned") branch does reach the unversioned reader, and __dlpack__ maps max_version=None to versioned = False, so the capsule name matches. The capsule is only returned on the retry, so it is never consumed twice. It also fails without the fix, on assert view.ptr == src.ctypes.data + src.itemsize, so it is a real regression test.

Three things you may or may not want to act on, none blocking:

1. The release note names from_any_interface, but the test only exercises from_dlpack. Same code path, so it is covered in substance, though a one-line from_any_interface assertion would match what the note promises.
2. Coverage is CPU-only. The defect applies identically to device pointers and this repo has GPU CI, so a kDLCUDA variant is cheap if you think it is worth it.
3. Per AGENTS.md, @pytest.mark.agent_authored(model="claude-opus-5") means not yet materially human-reviewed. If you would like, treat this comment as that review and swap it for @pytest.mark.human_reviewed.

The merge into main is still the only thing actually blocking.