NvStreams Changes#

NvSciError_StreamBadBlock#

Target Changes

Backward Compatible

Platform

OS

The following APIs, which return NvSciError_BadParameter for invalid block in 6.0, will return NvSciError_StreamBadBlock instead:

NvSciStreamBlockConnect

NvSciStreamProducerCreate

NvSciStreamProducerCreate2

NvSciStreamConsumerCreate

NvSciStreamConsumerCreate2

NvSciStreamBlockEventQuery

NvSciStreamBlockDelete

NvSciStreamBlockEventServiceSetup

NvSciStreamBlockInternalEventServiceSetup

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

In 5.2, NvSciStream used NvSciError_BadParameter for all invalid input, like null pointer, invalid block handle, invalid packet handle, etc. The user could not tell the exact issue from the error code. In 6.0, specific error code: NvSciError_StreamBadBlock, for invalid block handle was introduced, but not all APIs migrated to this new error code. 7.0 moves all the APIs to this new error code (NvSciError_StreamBadBlock) consistently.

Steps to Migrate

Sample old application implementation:

NvSciError err;

err = NvSciStreamProducerCreate( pool, &producer);

if (err != NvSciError_Success) {

if (err == NvSciError_BadParameter) {

printf("NvSciError_BadParameter received from \
NvSciStreamProducerCreate, pool block could be invalid\n");

}

exit();

}

NvSciSync Timestamp Behavior Changes#

Target Changes

Backward Compatible

Platform

OS

NvSciSync timestamp behavior changes for CUDA NvSciSync on Linux.

CUDA-provided timestamps will be in microseconds instead of nanoseconds.

NvSciSync on DRIVE Linux will obtain time via a CCPLEX register tracking with ARM TSC (previously from CLOCK_MONOTONIC). This change exists from 6.0.9.3` prior releases.

No

NSR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

It was confusing to have a timestamp from a different unit or source. This update makes timestamps across engines and the CCPLEX consistent.

Steps to Migrate

Application code that assumes nanoseconds for NvSciSync timestamps from CUDA requires a change to the scaling factor. Application code that assumes CLOCK_MONOTONIC and adjusts it to be consistent with ARM TSC requires removal; use the raw value instead.

NvSciBuf API Changes#

Target Changes

Backward Compatible

Platform

OS

The following NvSciBuf APIs may now return NvSciError_Busy during allocation or import:

  • NvSciBufAttrListReconcileAndObjAlloc

  • NvSciBufObjAlloc

  • NvSciBufIpcImportAttrListAndObj

  • NvSciBufObjIpcImport

Yes

NSR

Linux and Android

Migration Path

  • Orin to Thor

  • Dimensity C-X1 to Dimensity C-X1

Migration Release Path

6.x to 7.x

7.2.3.0 to 7.2.4.0 (NVIDIA DriveOS for Dimensity)

7.2.5.0+ (NVIDIA DRIVE Orin/Thor)

Migration Rationale

NvMap now defers work after the kernel module probe. Calling these APIs may race with that work and require the caller to retry later. The error code is now propagated to the application for the application to decide how to handle the new error.

Steps to Migrate

Handle NvSciError_Busy in callers of the affected APIs. When this error is returned, depending on your application’s requirements, you may choose to retry the operation later when the kernel module is ready or return an error.

NvSciBuf and NvSciSync NUMA Attribute Support#

Target Changes

Backward Compatible

Platform

OS

NvSciBuf and NvSciSync provide optional NUMA locality attributes for resource allocation:

  • NvSciBufGeneralAttrKey_NumaNodeId

  • NvSciSyncAttrKey_Numa

NvSciBufGeneralAttrKey_NumaNodeId takes an int64_t NUMA node value. If the attribute is not specified or is set to -1, NvSciBuf allocates from a NUMA node with enough memory. The valid input range is -1 to 1. On non-NUMA systems, this attribute is a no-op.

NvSciSyncAttrKey_Numa takes a uint64_t NUMA node value. On Linux, NvSciSync uses it to request NUMA locality for a synchronization object. It is unused on non-Linux OSes.

Yes

NSR

Linux

Migration Path

  • Thor to Dual Thor with NVLink

Migration Release Path

7.2.5.0+

Migration Rationale

Thor supports NUMA configurations where buffer and synchronization object placement can affect application performance. These optional attributes allow applications to request NvSciBuf and NvSciSync resources from a specific NUMA node when NUMA locality matters.

Steps to Migrate

Applications that do not require NUMA locality do not need to change. Leave these attributes unset to preserve the previous behavior.

Applications that require NUMA locality should set NvSciBufGeneralAttrKey_NumaNodeId in the NvSciBuf unreconciled attribute list and NvSciSyncAttrKey_Numa in the NvSciSync unreconciled attribute list. For NvSciSync, ensure the signaler and waiter attribute lists request compatible NUMA node values. Reconciliation fails if a waiter attribute list specifies a NUMA node but the corresponding signaler attribute list does not specify the same node.

NvSciSync API Changes#

Target Changes

Backward Compatible

Platform

OS

The following NvSciSync APIs may now return NvSciError_Busy during allocation or import:

  • NvSciSyncAttrListReconcileAndObjAlloc

  • NvSciSyncObjAlloc

  • NvSciSyncIpcImportAttrListAndObj

  • NvSciSyncObjIpcImport

Yes

NSR

Linux and Android

Migration Path

  • Orin to Thor

  • Dimensity C-X1 to Dimensity C-X1

Migration Release Path

7.2.3.0 to 7.2.4.0 (NVIDIA DriveOS for Dimensity)

7.2.5.0+ (NVIDIA DRIVE Orin/Thor)

Migration Rationale

NvMap now defers work after the kernel module probe. Calling these APIs may race with that work and require the caller to retry later. The error code is now propagated to the application for the application to decide how to handle the new error.

Steps to Migrate

Handle NvSciError_Busy in callers of the affected APIs. When this error is returned, depending on your application’s requirements, you may choose to retry the operation later when the kernel module is ready or return an error.

NvSciIpc Transitive Dependency on libnvos_s3_safety (QNX)#

Target Changes

Backward Compatible

Platform

OS

On QNX, libnvsciipc.so now has a transitive dependency on libnvos_s3_safety.so. The NvSciIpc library references the NvOsDebugPrintStrStr symbol, which is provided by libnvos_s3_safety.so.

Any application that links libnvsciipc (for example, NvSciStream and rawstream applications) must now also link libnvos_s3_safety explicitly. Otherwise, linking -lnvsciipc without -lnvos_s3_safety fails with an undefined reference error for the NvOsDebugPrintStrStr symbol.

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.x to 7.x

Migration Rationale

NvSciIpc on QNX added a dependency on NvOS for its logging (NvLog) path. As a result, libnvsciipc.so now pulls in the NvOsDebugPrintStrStr symbol provided by libnvos_s3_safety.so. Because this is a transitive dependency of a shared library, the linker requires the dependent library to be specified explicitly on the application’s link line.

Steps to Migrate

Add -lnvos_s3_safety to LDLIBS (after -lnvsciipc) for any QNX target that links libnvsciipc:

LDLIBS += -lnvsciipc
LDLIBS += -lnvos_s3_safety

The DRIVE OS NvSci and NvSciStream sample applications are updated accordingly: nvscistream_event_sample, nvscistream_safety_sample_app, nvscistream_drive_event_sample, rawstream, and rawstream_iep.

NvSciBuf, NvSciStream, and NvSciSync Library Minor Version Bumps#

Target Changes

Backward Compatible

Platform

OS

  • NvSciBufMinorVersion bumped from 11U to 13U in nvscibuf.h (cumulative across 6.5.4.2 → 7.2.5.0; 11U → 12U in a prior release for the color-format and bits-per-component additions, 12U → 13U in 7.2.5.0 for the NvSciError_Busy return code on the affected APIs).

  • NvSciStreamMinorVersion bumped from 2U to 3U in nvscistream_types.h.

  • NvSciSyncMinorVersion bumped from 8U to 10U in nvscisync.h (covers the NvSciError_Busy return code on the affected APIs plus additive NvSciSync surface for which no separate migration is required).

Yes

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.5.4.2 to 7.2.5.0

Migration Rationale

Standard minor-version bumps that advertise the backwards-compatible additions shipping in this release. Applications that probe the library version at runtime see the new values.

Steps to Migrate

Update any hard-coded minor-version comparisons in version-probe logic to accept the new values.

NvSciBuf and NvSciStream Tightened Input-Validity Contracts#

Target Changes

Backward Compatible

Platform

OS

  • The blanket-statements section of nvscibuf.h adds new contract clauses requiring callers to (a) pass attribute values in valid ranges when setting attributes in an NvSciBufAttrList and (b) ensure that any non-NULL NvSciBuf opaque structures (NvSciBufModule, NvSciBufAttrList, NvSciBufObj, AttrList/Object transport descriptors) passed to NvSciBuf APIs were obtained from prior successful NvSciBuf API calls and have not been freed.

  • The blanket-statements section of nvscistream_api.h adds detailed input-validity contracts for NvSciStreamPacket (pool packet inserts/deletes vs. block packet accepts), NvSciStreamBlock, sync-fence array validity and ordering against NvSciStreamBlockSyncObject indices, and NvSciIpcEndpoint / NvSciEventService validity tied to their constructor APIs. It also documents that applications can use PresentSync and ReturnSync blocks for CPU-side fence waiting.

Yes

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.5.4.2 to 7.2.5.0

Migration Rationale

Establishes single-source documented preconditions used by every NvSciBuf and NvSciStream API rather than re-stating them per function, and tightens the documented input-validity contract that callers must satisfy before invoking the APIs.

Steps to Migrate

  1. Audit any code that constructs NvSciBuf or NvSciStream opaque handles other than via the documented constructors, or that retains a handle past its destroy call. Such usage was previously tolerated by accident.

  2. Audit attribute-key assignments to ensure values are within the valid ranges documented for each NvSciBufAttrList key.

NvSciBuf Color Format and Bits-Per-Component Additions#

Target Changes

Backward Compatible

Platform

OS

  • Many new entries added to NvSciBufAttrValColorFmt before the existing NvSciColor_UpperBound terminator. New families include packed YUV 10-bit formats (NvSciColor_Y10_U10__Y10_V10, NvSciColor_Y10_V10__Y10_U10, NvSciColor_U10_Y10__V10_Y10, NvSciColor_V10_Y10__U10_Y10), packed RGB (NvSciColor_R8_G8_B8, NvSciColor_B8_G8_R8), tightly-packed 10-bit YUV components (NvSciColor_Y10t, NvSciColor_U10t, NvSciColor_V10t, NvSciColor_U10V10t, NvSciColor_V10U10t), right-justified Bayer RAW 10-bit packed formats with the X2Rc10Rb10Ra10 prefix, and right-justified Bayer RAW 12-bit packed formats. The terminator NvSciColor_UpperBound shifts to a new numeric value.

  • NvSciSurfBPC_10t entry is added to NvSciBufSurfBPC (10 bits per component, tightly packed) before the NvSciSurfBPC_MaxValid terminator. The existing NvSciSurfBPC_10 / _12 / _14 entries gain a documentation clarification noting they are padded into a 16-bit word.

  • Documentation of NvSciColor_U10V10 / V10U10 / U12V12 / V12U12 now states the per-component padding (6 bits for 10-bit, 4 bits for 12-bit), and documentation of NvSciBufImageAttrKey_PlaneBitsPerPixel and NvSciBufImageAttrKey_PlanePitch now describes the special-case computation rules for the new right-justified Bayer RAW 10-bit and 12-bit packed formats.

Yes

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.5.4.2 to 7.2.5.0

Migration Rationale

Adds support for additional camera/display pixel formats including packed and tightly-packed YUV/RGB/Bayer RAW variants used by ISP pipelines, and aligns the documented contracts with the bit-layout reality of the new packed formats.

Steps to Migrate

  1. Applications iterating NvSciBufAttrValColorFmt or NvSciBufSurfBPC values must accept the new entries (and the shifted terminator values) in any switch / table-driven logic.

    NvSciBufAttrValColorFmt fmt = NvSciColor_Bayer12RGGB;

    NvSciBufSurfBPC bpc = NvSciSurfBPC_10t;

  2. Applications computing pitch or bits-per-pixel manually for right-justified Bayer RAW 10-bit / 12-bit formats must follow the updated special-case rules documented on NvSciBufImageAttrKey_PlaneBitsPerPixel and NvSciBufImageAttrKey_PlanePitch.

NvSciBufObjGetCpuPtr Read-Only Buffer Behavior Change#

Target Changes

Backward Compatible

Platform

OS

The documented contract for NvSciBufObjGetCpuPtr has changed. Previously, the function returned the CPU virtual address of the “read/write buffer” and returned NvSciError_BadParameter when the NvSciBufObj did not have NvSciBufAccessPerm_ReadWrite. The function now returns the CPU virtual address of the buffer regardless of permission and writes to the buffer when the NvSciBufObj only has the NvSciBufAccessPerm_ReadOnly result in an undefined behavior. The BadParameter clause now only triggers on NULL input or absent NvSciBufGeneralAttrKey_NeedCpuAccess. It no longer triggers on read-only buffers.

No. The source rebuilds, but runtime behavior changed.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.5.4.2 to 7.2.5.0

Migration Rationale

Allows CPU read access on read-only NvSciBufObj instances while making writes to such buffers undefined behavior rather than a hard error.

Steps to Migrate

Replace any code that relied on NvSciError_BadParameter from NvSciBufObjGetCpuPtr to detect read-only buffers with an explicit permission query, and ensure the caller never writes to the returned pointer when the underlying object is read-only.

// Previously: BadParameter if not ReadWrite.
if (NvSciBufObjGetCpuPtr(obj, &ptr) == NvSciError_BadParameter) { /* RO buffer */ }

// Now: succeeds for RO buffers; writes are UB.
NvSciBufAttrValAccessPerm perm = ...; // query separately
NvSciBufObjGetCpuPtr(obj, &ptr);
if (perm == NvSciBufAccessPerm_Readonly) { /* read only */ }

NvSciStream Documented Error-Code Enrichments#

Target Changes

Backward Compatible

Platform

OS

  • Several APIs now document additional explicit return codes that were previously implicit or grouped under generic NvSciError_BadParameter: NvSciError_BadParameter when bufAttrList is NULL on the Set/SetWithCrc element APIs; NvSciError_BadAddress for NULL crc pointers in the WithCrc family; NvSciError_IndexOutOfRange for out-of-range elemIndex / consumerIndex; NvSciError_Busy for NvSciStreamBlockElementNotVisible while another thread is interacting with imported element info; and a more specific NvSciError_BadParameter clause on NvSciStreamPoolPacketStatusQuery when queryBlockType does not indicate a producer/consumer endpoint. NvSciStreamPoolPacketCreate also removes the previously documented NvSciError_InsufficientMemory return.

  • Several APIs gained “Any error or panic behavior that X can generate” clauses propagating the error/panic surface of downstream calls: NvSciIpcEndpointGetTopoId (Ipc/C2C constructors); NvSciEventService::CreateLocalEvent and NvSciIpcBindEventService (event-service setup); NvSciIpcGetEventSafe, NvSciIpcGetAsyncErrors, NvSciIpcWriteSafe, NvSciIpcReadSafe, NvSciLocalEvent::Signal (internal event-service message processing and block disconnect); NvSciBufObjDup (NvSciStreamBlockPacketBufferGet); NvSciSyncObjGetAttrList, NvSciSyncAttrListValidateReconciled, and NvSciSyncObjDup (signal-obj set/get APIs).

No. The source rebuilds, but runtime behavior changed.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.5.4.2 to 7.2.5.0

Migration Rationale

Documents previously implicit failure modes, tightens parameter validation contracts, and surfaces previously undocumented downstream error and panic propagation so callers can plan for them.

Steps to Migrate

  1. Audit switch statements or error-handling tables over NvSciStream return codes to recognize the additional documented codes (NvSciError_BadAddress, NvSciError_IndexOutOfRange, NvSciError_Busy, and the propagated NvSciIpc / NvSciEvent / NvSciBuf / NvSciSync errors and panics).

  2. Remove any handler for the removed NvSciError_InsufficientMemory return on NvSciStreamPoolPacketCreate.

NvSciStream Ipc/C2C Constructor Error Surface Expanded#

Target Changes

Backward Compatible

Platform

OS

The Ipc/C2C source/destination block constructors NvSciStreamIpcSrcCreate, NvSciStreamIpcSrcCreate2, NvSciStreamIpcDstCreate, and NvSciStreamIpcDstCreate2 now document additional return outcomes. NvSciError_NotInitialized is now explicitly returned for an uninitialized ipcEndpoint argument, and the documentation additionally passes through any error or panic behavior that NvSciIpcEndpointGetTopoId can generate from the underlying NvSciIpc query.

No. Source rebuilds, but runtime behavior changed.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.5.4.2 to 7.2.5.0

Migration Rationale

Surfaces the underlying NvSciIpc query error path that was previously undocumented so customers can plan for it.

Steps to Migrate

Add a handler for NvSciError_NotInitialized and any NvSciIpcEndpointGetTopoId-propagated errors in callers of these constructors.

NvSciError err = NvSciStreamIpcSrcCreate2(ipc, queue, &block);

NvSciError err = NvSciStreamIpcSrcCreate2(ipc, queue, &block);
if (err == NvSciError_NotInitialized) { /* uninitialised ipc */ }

NvSciStreamPacketSendSync No Longer Supported on C2C Blocks#

Target Changes

Backward Compatible

Platform

OS

The documented contract for NvSciStreamPacketSendSync changed. Previously, the API was “supported only for IpcSrc/C2CSrc and IpcDst/C2CDst”. Now support is only on inter-process IpcSrc and IpcDst blocks and explicitly NOT supported on C2C blocks. Calling on a C2C block now returns NvSciError_NotSupported per the updated NotSupported documentation.

No. The source rebuilds, but runtime behavior changed.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.5.4.2 to 7.2.5.0

Migration Rationale

Reflects the actual supported scope of the API; C2C send-sync was not part of the validated contract.

Steps to Migrate

Remove or guard any call sites that pass a C2C block to NvSciStreamPacketSendSync; route the call to the inter-process IpcSrc or IpcDst block instead.

// Previously assumed C2C support:
NvSciStreamPacketSendSync(c2cBlock);

// Now: only on inter-proc IpcSrc / IpcDst.
NvSciStreamPacketSendSync(ipcSrcOrIpcDstBlock);