TensorRtSharp4.0 Sample Series Learning Path
English | 简体中文
Use the samples catalog for focused runnable cases and the applications catalog for complete model and desktop workflows. Every user-facing README has an English and Simplified Chinese version.
All sample and application projects are executables with IsPackable=false. They consume the published 4-series JYPPX.TensorRT.CSharp.API package; Classification and YoloVision are examples, not extension NuGet packages. The host user installs CUDA, cuDNN, TensorRT, and NVRTC and selects a project-owned Bridge package matching the target platform and vendor-runtime versions.
Package Setup
Use the 4.0.0-* floating rule for the maintained preview line. A bare --prerelease may select the API-incompatible historical 4.0.6170 package:
dotnet add package JYPPX.TensorRT.CSharp.API --version "4.0.0-*"
dotnet add package JYPPX.TensorRT.CSharp.API.Runtime.win-x64.trt10.11.cuda12.9.cudnn9.22.Bridge --version "4.0.0-*"
The Bridge ID is an environment example. Choose the package matching the target OS, architecture, TensorRT, CUDA, and cuDNN line. Bridge packages do not install NVIDIA vendor runtimes.
Vision samples use the project owner's OpenCV-CSharp-API:
dotnet add package JYPPX.OpenCV.CSharp.API --prerelease
dotnet add package JYPPX.OpenCV.runtime.win-x64 --prerelease
Learning Modules
| Order | Module and case | Learning goal | Main article |
|---|---|---|---|
| 01 | Cuda/01.RuntimeCompilation |
Compile CUDA C, load a module, launch a typed kernel, and read results | CUDA RTC |
| 02 | Inference/01.Bindings |
Tensor ownership, host/device memory, enqueue, and output readback | Inference bindings |
| 03 | Inference/02.DynamicShapes |
Optimization profiles and runtime dynamic shapes | Dynamic shapes |
| 04 | Performance/01.MultiStream |
CUDA streams, events, dependencies, and timing boundaries | Multi-stream |
| 05 | ComputerVision/01.Classification |
OpenCV decoding, ImageNet preprocessing, Top-K, JSON, and an annotated result | ResNet18 classification |
Complete applications continue with:
| Application | Scope | Main article |
|---|---|---|
YoloVision |
Detection, classification, instance segmentation, OBB, pose, semantic segmentation, reports, and visualizations | All-task overview |
OnnxToEngine |
ONNX parsing, builder configuration, dynamic profiles, Engine serialization, and MNIST validation | ONNX to Engine |
TensorRtExec |
CLI and WinForms model build/deployment workflow | TensorRtExec GUI |
All three applications consume the published TensorRT managed package. OnnxToEngine and TensorRtExec share a
non-packable application Tools project that links the repository implementation and compiles it against that public
package; neither application references the core CUDA or TensorRT source projects.
Model Staging
Converted ONNX files are staged in the workspace-level models directory beside the source repository. They are excluded from Git, NuGet, and Release assets until a separate model zoo is available.
Every model article must record the upstream project and license, pinned revision, acquisition command, framework-to-ONNX conversion command, tool versions, opset, input/output contract, preprocessing and postprocessing, and SHA256 values. Commands use workspace variables, repository-relative paths, or placeholders such as <model> and <image> instead of a contributor's drive letter and user name.
Complete Article Standard
A publishable case article follows the full workflow rather than listing APIs:
- Introduce the project, target reader, and responsibility of every dependency.
- Acquire the model, license, labels, and test image; verify hashes.
- Export ONNX and document versions, options, tensor names, shapes, layouts, and hashes.
- Install public packages and prepare a matching user-owned runtime environment.
- Explain the important code and run the exact command.
- Preserve real stdout, compare against an independent reference, and run a controlled negative.
- Render classification, detection, segmentation, OBB, pose, or semantic results onto the source image.
- Include the real terminal window and, for desktop applications, the actual software window.
Preflight, build-only output, a generated report, or a screenshot cannot be promoted to real-model runtime evidence. When the local host lacks a compatible runtime, document the environment blocker and the installation requirement instead of presenting a simulated success.