Kit Development

../_images/ovas_api_banner_thin.png

Developing a Omniverse Kit Application to be deployed to an Omniverse Application Streaming API instance for on-demand streaming, is largely the same as for other streaming environments.

New to Kit Application development?

If you’re new to Kit Application development, the Kit App Template Tutorial is a great starting point. It provides step-by-step instructions and various templates to help you quickly create your own applications. You’ll be guided through key processes, like enabling streaming and containerization, with the USD Viewer template as a recommended first project.

Once you have walked through creating a container of a streamable Kit Application, come back here to dive into the specifics of creating Omniverse Kit Applications to be deployed to an Omniverse Application Streaming API instance.

Before going, read through the Overview to provide a bit of context while you are learning.

For more detailed guidance, explore the Omniverse Kit Application Development Guide, which offers comprehensive documentation to support your development journey.

Overview

We’ll start with a high-level overview of the entire process, before going into specifics.

In short, the process can be divided into two major areas:

Creating your Kit Application

This starts with creating your application, whether from a template or a blank screen, and includes everything until you have a tested containerized streamable Kit Application.

Basic steps

Creating your Kit Application

The basic steps are:

  1. Create your Kit Application

  2. Enable streaming using the NVIDIA Omniverse™ Kit Application Streaming extensions.

  3. Locally test your streamable Kit Application

  4. Package and Containerize your Kit Application

  5. Test your Kit Application container

Once you have confirmed that your Kit Application is containerized and streaming properly, you are ready for deployment.

Deploying to your instance.

This involves everything required to make your containerized Kit Application available for streaming on your deployment environment, an Omniverse Application Streaming API instance in this case.

Basic steps

Deploying your Kit Application

Deploying to an Omniverse Application Streaming API instance involves the following steps:

  1. Register your Kit Application container with an image registry accessible by your cluster, such as NVIDIA NGC™.

  2. Register your application with your Omniverse Application Streaming API instance.


Creating your Kit Application

This guide only covers specific information required to successfully deploy a Kit Application to an Omniverse Application Streaming API instance. If you are new to Kit Application development, please review the New to Omniverse Kit Application development dropdown, above, or utilize the Kit App Template Tutorial and Omniverse Kit Application Development Guide.

Required knowledge:

  • Kit Application development

  • Kit Application Streaming

  • Containerizing Kit Applications

Kit Streaming requirements

There are no special requirements for creating your Kit Application to be deployed to an Omniverse Application Streaming API instance, other than ensuring it meets the basic requirements for Kit Application Streaming, in general:

  • omni.kit.livestream.webrtc to enable WebRTC streaming

  • omni.kit.livestream.messaging for messaging between the Kit Application and the client, if required.

  • The application configured properly for its intended use:

    • Minimal UI suitable for streaming, especially if being embedded into a web-client’s interface.

    • Resolution no greater than 1920x1080.

    • Render rate set to 30fps.

  • Streaming specific configuration options in a [my-app].streaming.kit file.

Container requirements

There are no specific requirements, other than ensuring the kit application successfully runs and streams when containerized.

Shader Cache support

To minimize start-up latency, Omniverse Application Streaming API instances have a shared shader cache service that all of the GPU Worker Nodes can access. Shared shader caching is critical to minimizing Kit start-up latency as shader compilation can take 5-10 minutes.

Why Shared Shader Caching is important.

Shader caching is a performance optimization technique used in GPU rendering to store the results of shader compilation for reuse in future sessions. Shaders are programs that run on the GPU to handle graphical tasks like lighting, shading, and other visual effects. These shaders must be compiled from source code into executable instructions before they can be run on the GPU, and this process can be time-consuming. Shader caching addresses this issue by storing the compiled shaders, significantly reducing the need for recompilation and improving performance.

More info

Enabling shared shader caching in Kit

To enable shared shader caching, the NVIDIA gpu driver must be configured properly. Starting with Kit 105.1, a new mechanism was added to Kit that does so automatically by detecting the presence of a properly configured envar AUTO_ENABLE_DRIVER_SHADER_CACHE_WRAPPER.

Example of the AUTO_ENABLE_DRIVER_SHADER_CACHE_WRAPPER envar being set to point to a memcached instance.
export AUTO_ENABLE_DRIVER_SHADER_CACHE_WRAPPER="hsscdns://memcached-service-r3.shadercache.svc.cluster.local"
Kit 105.1

This requires that the omni.hsscclient extension be enabled.

Kit 106+

This was added to Kit’s GPU Foundation, so should just automatically work.

This replaces an older method that requires specific environment variables that control GPU driver behavior to be set in the Omniverse Kit Applications start-up script.

Switch any existing applications to use the newer method, described above.

Setting the AUTO_ENABLE_DRIVER_SHADER_CACHE_WRAPPER envar

This can occur automatically when the application’s container is started within the pod, as part of the container sidecar’s environment variable configuration. You can refer to Install Memcached Service

What do I need to do?

For Kit 105.1 you just need to ensure that the omni.hssc kit extension is being loaded. For Kit 106+, in most situations, nothing. As long as the AUTO_ENABLE_DRIVER_SHADER_CACHE_WRAPPER is set automatically by the instance, shared shader caching should just work.

Alternatively, you can hard-code the AUTO_ENABLE_DRIVER_SHADER_CACHE_WRAPPER envar in the start-up script of your Kit Application. This is not preferred as any changes will require recreating your Kit Application container.


Deploying your Kit Application

Once you have a containerized Kit Application that you have tested to ensure it streams properly, you are ready to begin the deployment process. This typically requires elevated privileges, which you may not have. A common workflow involves developers collaborating with cluster administrators for the deployment of applications. Make sure that you are clear on the deployment process for your instance and whether you have the requisite permissions.

Requisite Knowledge and permissions

  • Familiarity with image repositories and authorization to push images

  • Cluster access and the ability to modify and push Kubernetes CRDs, or:

  • Access to optionally exposed Application management endpoints.

Deploying a Kit Application Container

You have successfully created a container of your Kit Application and now want to deploy it to your instance. Before doing so, lets clarify one key point about your container; your container represents a “version” of your application. It isn’t your application, just one version of your application. Every container you create of your application is a “version” of it.

This is exactly the model that Omniverse Application Streaming API uses with Application and ApplicationVersion, the two representations you need to create and manage when deploying a Omniverse Kit Application to your instance.

Before diving deeper, lets look at the two overarching steps required to deploy your container image.

1. Register your container image

The first step is pushing your container image to an image repository, which the services and Worker Nodes have access to. Ensure you choose a clear name for your image. Also, follow best-practices when choosing your label, use semver and potentially stages when doing so. This can help when registering your container image with your instance, in the next step.

You will need the URI to the container image in the next step.

2. Adding the Image to your instance

This is the step where you inform your instance that there is a new ApplicationVersion that can be streamed using the container image you registered. There must also be a valid ApplicationProfile compatible with your Application and ApplicationVersion.

There are two methods for registering a Omniverse Kit Application with your instance. The default is to use standard methods for managing resources on a Kubernetes cluster. This requires administrative access to your cluster and familiarity with Kubernetes CRDs and Helm charts.

Deploying Omniverse Kit Applications describes how Applications and ApplicationVersions are managed.

Optionally, you can create and delete Application and ApplicationVersion by enabling management endpoints of the Application service. This has security impications, so may not available.

Managing Applications and Versions via Endpoints discusses the security concerns and how to enable the endpoints.