Kit Development#

../_images/ovas_api_banner_thin.png

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

New to Kit App development?

If you’re new to Kit App 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 App, come back here to dive into the specifics of creating Omniverse Kit Apps to be deployed to an Omniverse Kit App Streaming 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 App 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 App

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 App.

Basic steps

Creating your Kit App

The basic steps are:

  1. Create your Kit App

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

  3. Locally test your streamable Kit App

  4. Package and Containerize your Kit App

  5. Test your Kit App container

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

Deploying to your instance.

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

Basic steps

Deploying your Kit App

Deploying to an Omniverse Kit App Streaming instance involves the following steps:

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

  2. Register your application with your Omniverse Kit App Streaming instance.


Creating your Kit App#

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

Required knowledge:

  • Kit App development

  • Kit App Streaming

  • Containerizing Kit Apps

Kit Streaming requirements#

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

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

  • omni.kit.livestream.messaging for messaging between the Kit App 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 Kit App Streaming 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 Apps 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 App. This is not preferred as any changes will require recreating your Kit App container.


Deploying your Kit App#

Once you have a containerized Kit App 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 Kit App Streaming uses with Application and ApplicationVersion, the two representations you need to create and manage when deploying a Omniverse Kit App 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 App 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 Apps 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.