SDK Source Map and Current Rules
🚧 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.
-
Overview
-
Build, Run, and Validate
-
Core Concepts
-
Operators and Graphs
-
Tensor Data and Memory
-
Interprocess Communication
-
-
Application and Operator Development
- Building an HSDK Application
- Writing a Minimal Operator
- Typed Parameters and Configuration
- Reading, Writing, and Forwarding Data
- Writing Tensor Operators
- Complete Operator Patterns
- Authoring Runtime Behavior
- Runtime Parameter Updates
- Lifecycle Callbacks and Restart Control
- Performance and Debugging
- SDK Source Map
-
Operator Reference
-
Core Operators
-
Holoscan Camera
-
Holoscan RidgeRun
- Overview
- Build and Installation
- ArgusCameraOp
- V4L2SourceOp
- V4L2UserPtrSourceOp
- BgraToPlanarTensorOp
- RawBayerToBgraOp
- RawBayerToYoloTensorOp
- YuyvToBgraOp
- TensorRtInferenceOp
- DrmDisplayOp
- DrmBgraDisplayOp
- X11DisplayOp
- CudaCompositorOp
- DepthColorizerOp
- FakesinkOp
- FrameSkipperOp
- InterprocessSrcOp
- TestPatternOp
-
-
Migration from Holoscan 4.x
-
Examples
-
Core
-
Holoscan Camera
-
Holoscan RidgeRun
-
-
Benchmark and Use Cases
-
Holoscan vs GStreamer
- Overview
-
Capture and Display
-
Capture and Inference
- Compare the workloads
- Implemented Applications
- Framework Selection
- Interprocess
-
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.
temporal_plan_lowering.cppresolves input selection and missing-data behavior. Pair it withTemporal contractsand Temporal Contracts and Input Selection.valid_capture_member_completion()checks completion placement in CUDA graph regions. See Timing, Graphs, and Runtime Behavior for the allowed independent, inputless source case.lifecycle_plan_lowering.cppchecks effective lifecycle profiles. See Lifecycle Callbacks and Restart Control for the permissions and bounded capacities a restart requires.Performance modelexplains the relationships between rates, queues, and retained storage. The worked guide is Rates, Queue Sizing, and Derived Tensor Capacity.
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. |