Skip to content

Commit 3f35fc5

Browse files
Andy-Jostclaude
Andy-Jost
and
claude
committed
cuda.core: say what decides whether a host operand update is accepted
A diagnostic run across Linux, Windows MCDM, and Windows TCC rows showed that the executable-update outcome follows the allocation kind, not the platform: the driver compares the memory class of pool-backed and virtual-memory operands and rejects a replacement by host memory or by a cuMemAlloc buffer, while plain cuMemAlloc operands accept it. The TCC runners report no memory-pool support, so the default memory resource is not pool-backed there, which is why the update was accepted on them. The release note and the test docstring now say so. Co-Authored-By: Claude Fable 5.1 <[email protected]>
1 parent 1f96478 commit 3f35fc5

2 files changed

Lines changed: 15 additions & 9 deletions

File tree

‎cuda_core/docs/source/release/1.3.0-notes.rst‎

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -265,9 +265,12 @@ Fixes and enhancements
265265
multidimensional copies. Such an operand stays unified when it is replaced,
266266
because the driver does not accept a change of an operand's memory type in
267267
an instantiated graph. Replacing a device operand with another device
268-
buffer can therefore also be applied with :meth:`~graph.Graph.update`.
269-
Replacing it with host memory always takes effect in a new instantiation;
270-
whether an executable update accepts it depends on the driver, and Linux
271-
drivers reject it. The node's ``repr`` now shows ``U`` for unified
272-
operands.
268+
buffer of the same kind can therefore also be applied with
269+
:meth:`~graph.Graph.update`. Replacing it with host memory, or with memory
270+
from a different allocator, always takes effect in a new instantiation;
271+
whether an executable update accepts it depends on how the operands were
272+
allocated and on the driver. The driver compares the memory class of
273+
pool-backed and virtual-memory operands and rejects the change for them,
274+
while operands from plain ``cuMemAlloc`` allocations accept it. The node's
275+
``repr`` now shows ``U`` for unified operands.
273276
(`#2649 <https://github.com/NVIDIA/cuda-python/issues/2649>`__)

‎cuda_core/tests/graph/test_graph_node_update.py‎

Lines changed: 7 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -887,10 +887,13 @@ def test_memcpy_update_captured_node_host_operand(init_cuda):
887887
888888
The definition node accepts the host buffer and a fresh instantiation
889889
copies from it. Whether an executable update accepts the replacement
890-
depends on the driver: Linux drivers reject it (a memcpy operand may not
891-
move to another device or to the host), while Windows TCC drivers accept
892-
it. The test allows either outcome and checks the copy when the update
893-
is accepted. cuda.core enforces nothing here.
890+
depends on how the operands were allocated: the driver compares the
891+
memory class of pool-backed and virtual-memory operands and rejects the
892+
change for them, while plain ``cuMemAlloc`` operands accept it. A device
893+
without memory-pool support (Windows TCC in CI) gets a default memory
894+
resource that is not pool-backed, so the same test is accepted there.
895+
The test allows either outcome and checks the copy when the update is
896+
accepted. cuda.core enforces nothing here.
894897
"""
895898
if driver_version() < (12, 2, 0):
896899
pytest.skip("individual graph node updates require CUDA 12.2+")

0 commit comments

Comments
 (0)