Skip to content

docs(core): fix three cuda.core.system docs defects - #2584

Open
LeSingh1 wants to merge 1 commit into
NVIDIA:mainfrom
LeSingh1:system-docs-accuracy
Open

docs(core): fix three cuda.core.system docs defects#2584
LeSingh1 wants to merge 1 commit into
NVIDIA:mainfrom
LeSingh1:system-docs-accuracy

Conversation

@LeSingh1

@LeSingh1 LeSingh1 commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

Three documentation defects in cuda.core.system, all of which mislead or silently drop information in the rendered docs. Documentation only — no behaviour changes.

1. Four Sphinx version directives are misspelled, so their content never renders

cuda_core/cuda/core/system/_device.pyx:895   .. version-changed:: 1.1.0
cuda_core/cuda/core/system/_device.pyx:909   .. version-added:: 1.1.0
cuda_core/cuda/core/system/_device.pyx:919   .. version-added:: 1.1.0
cuda_core/cuda/core/system/_nvlink.pxi:31    .. version-deprecated:: 1.1.0

The directives are versionchanged, versionadded and deprecated — no hyphen. Sphinx emits Unknown directive type and drops the body, so two notices users need are missing from the published docs:

  • Device.get_nvlink"Any link number not supported by this specific device will raise a ValueError."
  • NvlinkInfo.max_links — the deprecation notice pointing at Device.get_nvlink_count.

This is a typo rather than a local convention: grep over cuda_core/, cuda_bindings/ and cuda_python/ finds .. versionadded:: spelled correctly 31 times (in texture/, graph/, …) against 4 hyphenated ones, and 0 correct uses of versionchanged/deprecated anywhere — i.e. every hyphenated instance is in these two files.

The generated _device.pyi stub carries the same four typos verbatim (stubgen-pyx copies the docstrings), so it is fixed alongside.

2. Device.get_cpu_affinity's docstring describes memory affinity, in the wrong units

The summary, the fallback sentence and the whole Returns section were copied from get_memory_affinity twenty lines above, so they promise "indices of NUMA nodes or CPU sockets" with the "ideal memory affinity". The body calls nvmlDeviceGetCpuAffinityWithinScope, sizes the bitmask in CPU words (ceil(cpu_count() / 64), :557) and runs it through _unpack_bitmask (_device_utils.pxi:8-24), so the returned list[int] holds logical CPU indices.

The docstring even contradicts itself: the summary says "ideal CPU affinity", the Returns section says "ideal memory affinity". A caller who believes the Returns section will index NUMA nodes with CPU numbers. Corrected, with an explicit pointer to get_memory_affinity for the node/socket form.

3. The register_events example calls .event_type on the wrong object

    >>> events = system.register_events([SystemEventType.UNBIND])
    >>> while event := events.wait(timeout_ms=10000):
    ...     print(f"Event {event.event_type} occurred.")

RegisteredSystemEvents.wait() returns SystemEvents (_system_events.pyx:143), which defines only __init__, __len__ and __getitem__ (:55-69); event_type lives on the singular SystemEvent (:34). The documented snippet therefore raises AttributeError. It was copied from the device-level example at _device.pyx:728-734, where DeviceEvents.wait() genuinely does return a single event.

Rewritten to index the batch via the documented __len__/__getitem__ (rather than relying on the legacy sequence-iteration protocol), and to import SystemEventType, which the snippet used without ever importing.

What I ran

Environment: macOS, no CUDA driver and no CUDA toolkit, so cuda.core cannot be built or imported here, and Sphinx is not installed.

  • Did not run: the docs build, or any test.
  • Verified by counting, on main: .. versionadded:: 31 uses vs .. version-added:: 4; .. versionchanged:: 0 vs .. version-changed:: 2; .. deprecated:: 0 vs .. version-deprecated:: 2. All 8 hyphenated uses are the ones changed here (4 in .pyx/.pxi, 4 in the generated .pyi); no hyphenated directive remains anywhere in the tree afterwards.
  • Verified by reading: SystemEvents really has no event_type (_system_events.pyx:55-69), and SystemEventType is exported from cuda.core.system.typing (typing.py:21,247) — which is the import path _system_events.pyx:13 itself uses.
  • Verified by reading: get_cpu_affinity calls nvml.device_get_cpu_affinity_within_scope, not the memory variant, and both helpers feed _unpack_bitmask, which yields set-bit indices.
  • Not changed, deliberately: get_memory_affinity sizes its NUMA-node bitmask with ceil(cpu_count() / 64) — a CPU count used for a node-set length. It over-allocates, which NVML tolerates, so I could not prove a wrong result and left it alone.

1. Four Sphinx version directives are misspelled and render as errors.

       cuda_core/cuda/core/system/_device.pyx:895   .. version-changed:: 1.1.0
       cuda_core/cuda/core/system/_device.pyx:909   .. version-added:: 1.1.0
       cuda_core/cuda/core/system/_device.pyx:919   .. version-added:: 1.1.0
       cuda_core/cuda/core/system/_nvlink.pxi:31    .. version-deprecated:: 1.1.0

   The directives are `versionchanged`, `versionadded` and `deprecated` --
   no hyphen. The repository already spells `.. versionadded::` correctly in
   31 other places (texture/, graph/), so these four are typos, not a local
   convention. Sphinx emits "Unknown directive type" and drops the content,
   which is how the behaviour change in `Device.get_nvlink` ("Any link number
   not supported by this specific device will raise a ValueError") and the
   deprecation of `NvlinkInfo.max_links` have been missing from the rendered
   docs. The generated `_device.pyi` carries the same four typos and is fixed
   with them.

2. `Device.get_cpu_affinity`'s docstring describes memory affinity.

   Summary, fallback sentence and Returns section were copied from
   `get_memory_affinity` twenty lines above, so they promise "indices of NUMA
   nodes or CPU sockets" and "ideal memory affinity". The body calls
   `nvmlDeviceGetCpuAffinityWithinScope`, sizes the bitmask in CPU words
   (`ceil(cpu_count() / 64)`) and runs it through `_unpack_bitmask`, so the
   list holds logical CPU indices. The docstring even contradicts itself: the
   summary says "CPU affinity", the Returns section says "memory affinity".
   A caller who believes it will index NUMA nodes with CPU numbers.

3. The `register_events` example calls `.event_type` on the wrong object.

   `RegisteredSystemEvents.wait()` returns `SystemEvents`, which defines only
   `__init__`, `__len__` and `__getitem__`; `event_type` lives on the
   singular `SystemEvent`. So the documented snippet raises AttributeError.
   The example was copied from the device-level one in _device.pyx:728-734,
   where `DeviceEvents.wait()` really does return a single event. Rewritten to
   index the batch, and to import `SystemEventType`, which the snippet used
   without ever importing.
@copy-pr-bot

copy-pr-bot Bot commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

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.

@github-actions github-actions Bot added the cuda.core Everything related to the cuda.core module label Aug 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cuda.core Everything related to the cuda.core module

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant