Frequently Asked Questions#
General questions#
Which platforms support PVA?#
For supported Jetson Orin platforms, refer to the section “View Jetson Orin Technical Specifications” on the Jetson Orin page.
For supported DRIVE platforms, refer to the hardware specification section on the DRIVE AGX page.
Where can I learn more about the PVA processor architecture?#
Learn about the PVA processor architecture here.
What is the compatibility between PVA SDK versions and DRIVE OS / JetPack versions?#
Refer to the release notes to learn about which operating systems are supported by a specific version of the PVA SDK.
How does PVA SDK help VPI developers?#
NVIDIA’s Vision Programming Interface (VPI) provides Jetson developers with a suite of pre-built image processing and computer vision algorithms. Each algorithm can be targeted to the different hardware backends available on the Jetson platform, including CUDA and PVA.
While VPI provides a rich set of algorithms, it does not provide the flexibility to develop custom PVA workloads. To develop custom PVA algorithms which are not supported by VPI, the PVA SDK is required.
PVA is a fully programmable multi-core SIMD DSP. This means that in addition to image processing and computer vision workloads, PVA is also suitable for any algorithm that can be vectorized using SIMD instructions. This includes workloads such as processing data from sensors like Radar, LiDAR, etc.
Where can I find code examples for PVA?#
The PVA SDK includes a number of sample applications to demonstrate the basic programming model.
Each of the step-by-step tutorials is distributed as a complete application which can be compiled and run.
PVA Solutions is a repository containing optimized operators and primitives for the PVA.
Where can I learn about the latest features and updates in PVA SDK and Solutions?#
Refer to the release notes of the current and previous versions to learn more about new features, enhancements, and bug fixes:
Licensing#
Do I need ASIP Programmer to use the PVA SDK?#
No. The core SDK includes NVVPU for compiling VPU code, EMU for running it on the development host, and LLDB for debugging it. ASIP Programmer is required only for ASIP-specific workflows, including ChessDE, the native model, and safety builds. Speak to your NVIDIA representative if you need access; see Optional ASIP Programmer Addition.
Do I need ASIP Programmer to run precompiled PVA binaries?#
No. Running a precompiled PVA binary does not require ASIP Programmer, including binaries supplied by NVIDIA, a partner, or your own build process.
Do my customers need ASIP Programmer to run PVA binaries that I build?#
No. Refer to the applicable PVA SDK and ASIP Programmer license terms for redistribution rights.
Can I freely redistribute the PVA SDK?#
In general, no, but there are exceptions for distributing the PVA SDK to contractors who are working on your behalf. Refer to the PVA SDK license agreements for more information.
PVA SDK features#
What development and debugging features does the PVA SDK provide?#
PVA SDK is equipped with a suite of tools designed for debugging and profiling PVA applications. The core SDK provides LLDB debugging over a network connection. The optional ASIP Programmer addition provides ChessDE debugging over a network or JTAG connection.
Non-intrusive profiling is supported using NVIDIA Nsight Systems, information about using Nsight Systems with PVA is available here.
Intrusive profiling and debugging is supported via the cuPVA host utilities APIs
on host side, as well as the PerfmonCounters device side API. The runtime also supports printf from device code.
The provided step-by-step tutorials introduce methodologies and tools to evaluate application performance, assisting in identifying whether performance objectives are met and pinpointing potential efficiency bottlenecks.
Is it possible to integrate PVA and CUDA tasks into a single pipeline using PVA SDK?#
Yes, the cuPVA runtime directly supports submitting PVA workloads to CUDA streams, and configuring PVA workloads to read and write CUDA memory directly.
Should I use the C++ Host API or the C Host API?#
Both APIs target the same runtime and have feature parity. New applications should default to the Host C++ API. It is the primary API surface, uses RAII for resource lifetime, and integrates naturally with modern C++ codebases.
Choose the Host C API when the embedding
constraint forces it - for example, when integrating cuPVA into a pure-C codebase, when calling
from a language whose foreign function interface only consumes C symbols, or when the surrounding
toolchain cannot link C++ runtimes. The runtime functionality is equivalent in both cases; the C
API simply adds explicit Create/Destroy calls in place of constructors and destructors.
Note that the cuPVA host utility library (cupva::utils) is provided only as a C++ interface. Applications written entirely against the C host API cannot link the utility helpers directly; in that case either wrap the C++ helpers in a thin C shim or replicate the relevant behavior in your application code.
For applications that need to bridge between both APIs - for example, when a C++ application has to expose a handle to a C-only consumer - the type conversion helpers provide the supported way to translate compatible objects across the boundary. See the helpers documentation for the list of object types covered and the rules that apply.
How should I measure PVA loading? Should I use tegrastats or Nsight Systems?#
Use Nsight Systems. Among NVIDIA’s standard
SOC tools, Nsight Systems is the supported way to measure PVA loading: it reports per-VPU
utilization and DMA throughput as "SOC Metrics" (sampled at 100 kHz by default), and it
draws a per-task timeline that shows command latency, queueing, and overlap with other engines
(CPU, GPU, NvDLA, NVENC). See the Profiling Tools tutorial and the
Nsight Systems documentation for setup details.
tegrastats is a coarse SOC sampler aimed at CPU/GPU/EMC rails and thermals; it does not
expose a PVA utilization metric on the platforms supported by this SDK. It can be useful for
correlating PVA activity with overall SOC power and thermal headroom, but it should not be the
primary tool for answering “how much of PVA am I using?”.
How many commands can I submit per Stream::submit call?#
A single cupva::Stream submission accepts up to
cupva::config::MAX_NUM_COMMANDS_PER_SUBMIT commands. See the
Host C++ API reference for the
current value (the header is the source of truth). The limit applies to the batch
passed to one submit() call; applications can issue back-to-back submissions to
enqueue more work, and the runtime allows multiple submissions to be in flight on
the same Stream up to this same active-command bound.
Larger batches are rejected by submit(). If your application exceeds the limit,
split the batch into multiple submit() calls and, when ordering matters, end
each batch with a cupva::CmdBarrier (see also the
Scheduling APIs tutorial).
How many DataFlows / tiles / planes can a single CmdProgram use?#
cuPVA does not impose a fixed numeric cap on the number of
DataFlow objects a
cupva::CmdProgram may contain. In practice the limit is the number of physical DMA
channels available on the target VPS at runtime: DataFlows added with
cupva::CmdProgram::addDataFlowHead() each allocate a DMA channel for the lifetime of
the program, while DataFlows added with cupva::CmdProgram::addDataFlow() are chained
off an existing head and do not consume an additional channel. Programs that try to allocate
more heads than channels are rejected at cupva::CmdProgram::compileDataFlows() time.
cupva::GatherScatterDataFlow adds two hardware-defined per-trigger caps,
GSDF_MAX_NUM_TILES (tiles per trigger) and GSDF_MAX_NUM_PLANES (image planes
per dataflow); see the
Dataflow configuration reference
for the current values.
Other public limits that come up when sizing programs - including the maximum
combined parameter size per CmdProgram, fence array sizes, symbol-name length, and
the L2 SRAM budget - are exposed as constexpr values in the
cupva::config namespace in cupva_host_common.hpp. Treat the header as the
source of truth; the Host C++ API reference renders the current values under
that namespace.
For per-process limits such as the maximum number of cupva::Context
instances available system-wide, see the Context Management section of the
Architecture documentation.
Supported algorithms#
How can I request a new algorithm in PVA Solutions?#
Developers can submit their questions, issues/bugs, or enhancement requests related to PVA Solutions or the SDK on NVIDIA Forums. If you are a customer working with an NVIDIA rep, please reach out to them with your inquiries or requests.
Can I contribute my customer VPU-based algorithm implementations to PVA Solutions library?#
PVA solutions does not currently accept contributions from the community.
Does PVA support LiDAR and RADAR data processing?#
Yes. As a programmable VLIW SIMD DSP, PVA is well suited for algorithms operating on sensor data such as LiDAR and RADAR.
NVIDIA is considering adding samples to show LiDAR//RADAR processing in a future release. Please share feedback and interest on NVIDIA Forums or reach out to your NVIDIA representative for support.