Jump to content

SDK Source Map and Current Rules

From RidgeRun Developer Wiki

🚧 Documentation is under development

The Holoscan SDK guide is currently under active development. Some sections may be incomplete or change without notice.

Questions? Contact RidgeRun or email to support@ridgerun.com.

Contents Pin





SDK Source Map and Current Rules

This reference maps operator declarations, compiler decisions, and runtime behavior to their SDK and camera implementations. Use the links to follow a port, parameter, timing rule, or storage requirement from its public interface into the code that handles it.

For a failure investigated with Performance and Debugging, check the declaration first, then the compiler or runtime path involved. A declaration can be valid on its own while its combination with other graph requirements is rejected.

Operator authoring and run control

What you are working on Where to look
Declaring an operator and its callbacks Operator defines the typed operator base. Operator anatomy explains how setup, contracts, lifecycle callbacks, and compute fit together. See Application, Graph, and Operator Anatomy.
Accessing activation state ExecutionContext provides the activation stream, current parameter snapshot, and runtime controls. See Timing, Graphs, and Runtime Behavior.
Declaring and configuring typed parameters HOLOSCAN_PARAM_SCHEMA builds the schema; try_decode decodes configuration through that schema. Typed parameters and Parameter schemas provide the authoring background. See Typed Parameters and Configuration.
Admitting parameter updates and restarts runtime_mutable() and lifecycle_mutable(stage) mark different update routes. Their compiler settings live in ParameterCompileOptions and LifecycleTransactionOptions. See Runtime Parameter Updates and Lifecycle Callbacks and Restart Control.
Inspecting a plan and observing a run ExecutionPlan exposes the compiled plan; RunSession exposes run control and results. See plan inspection and Running and Stopping.

Ports, tensors, and external peers

These declarations describe what can cross an edge and how storage is acquired and published. Follow them together when checking a tensor path: a matching payload type alone does not establish memory compatibility, stream ordering, or an exportable external boundary.

Question Source and guide
Which payloads can a port publish? PublishedPayload defines the supported categories. Raw POD payloads additionally need ChannelTypeIdentity and ChannelPodLayout. See Ports, Samples, and Payload Types.
What does a tensor port require? TensorInputSpec and TensorOutputSpec describe the tensor contract. See Tensor Contracts and Memory Types.
How does a producer write and publish storage? TensorOutputLoan owns the output loan; TensorOutputWriteGuard::commit() completes its write transaction before emission. See Writing Tensor Operators.
Which edge policy is being compiled? ConnectionOptions carries queue, topic, and conversion choices. See Building Graphs and Queue Policies and Copy Paths and Memory Conversion.
How do external clients and tensor topics fit? External topics, Standalone channel clients, and HoloMQ documentation explain the separate communication layers. See Descriptor-Tensor External Topics and Channels and HoloMQ.

From contracts to runtime behavior

The compiler resolves temporal selection, CUDA graph regions, lifecycle permissions, and resource capacity before execution. The following implementation files are useful when a graph reports an unsupported combination. Read the diagnostic and the surrounding checks together rather than treating one successful sample as permission for every topology.

Examples to read alongside the API

Small examples make the declarations easier to follow because you can see their complete graph and the result the program checks. The SDK sources below cover planning, run control, memory, and communication as well as inference and image processing.



Camera module sources

Camera operators live in a separate module. Its repository branch is hosted under the Holohub repository, but the links here select the camera module itself; its operator and application paths start at the branch root.

Part of the module Source and guide
Build and platform selection CMakeLists.txt and sipl_compat.hpp provide the build and SIPL compatibility entry points. See Build and Installation.
V4L2 capture V4l2CaptureOp::compute() shows capture, copying, and publication. See V4L2CaptureOp.
SIPL capture and service SIPLCaptureOp::compute() and SIPL service sources show the byte layout and frame lifetime. See SIPLCaptureOp.
Configuration and applications camera applications contains the frame saver, stereo monitor, and V4L2 workflows. See SIPL Frame Saver Example and SIPL Stereo Monitor Example.


Cookies help us deliver our services. By using our services, you agree to our use of cookies.