NVIDIA Iray SDK API nvidia_logo_transpbg.gif Up
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Groups Pages
Bridge client

The Bridge client is integrated in the application that wishes to use the resources of the remote cluster. More...


class  mi::bridge::IClient_job_progress
 Provides detailed information about the progress of a Bridge job. More...
class  mi::bridge::IElement_set
 Used to specify a set of elements by name. More...
class  mi::bridge::IClient_job
 Represents the client-side part of a job that can be executed by the Bridge server. More...
class  mi::bridge::Client_job< i_id1, i_id2, i_id3, i_id4, i_id5, i_id6, i_id7, i_id8, i_id9, i_id10, i_id11, I >
 This mixin class provides a default implementation for some of the methods needed by mi::bridge::IClient_job. More...
class  mi::bridge::Update_job
 Base class for Bridge jobs that only update elements without executing anything. More...
class  mi::bridge::IClient_session_state_callback
 Abstract interface for callbacks for session state changes. More...
class  mi::bridge::IClient_measure_bandwidth_callback
 Abstract interface for bandwidth measurement events. More...
class  mi::bridge::IClient_session
 Represents the client side of a Bridge session. More...
class  mi::bridge::IBridge_client
 API component that serves as entry point for the client-side Bridge API. More...
class  mi::bridge::IClient_video_context
 Client-side video context that receives and decodes video frames from the corresponding server-side video context. More...
class  mi::bridge::IVideo_frame
 Represents the data for a single video frame. More...
class  mi::bridge::IVideo_sink
 Abstract interface to receive video frames produced by the corresponding server-side video context. More...
class  mi::bridge::IIray_bridge_snapshot_callback
 Abstract interface for snapshot events. More...
class  mi::bridge::IIray_bridge_snapshot_context
 Context for creating Iray Bridge snapshots. More...
class  mi::bridge::IIray_bridge_session
 Represents a session (connection) to an Iray Bridge Server. More...
class  mi::bridge::IIray_bridge_client
 API component that serves as entry point for the client-side Iray Bridge API. More...


enum  mi::bridge::Client_job_state {
  mi::bridge::CLIENT_JOB_PREPARING = 1,
  mi::bridge::CLIENT_JOB_UPLOADING = 3,
  mi::bridge::CLIENT_JOB_PENDING = 4,
  mi::bridge::CLIENT_JOB_DONE = 5
 Job states of Bridge jobs. More...
enum  mi::bridge::Client_session_state {
 The different states a client session can be in. More...

Detailed Description

The Bridge client is integrated in the application that wishes to use the resources of the remote cluster.

The client connects to a single Bridge server. The client does not form a cluster with the Bridge server. The server can be part of a normal cluster of any size, which automatically makes the resources of the entire remote cluster available to the client. The client can be part of a cluster of any size, but the resources of the client-side cluster are used only for local jobs, not when executing jobs using a remote cluster via the Bridge.

The API consists of two layers: a low-level API, called Bridge API, and a high-level API, called Iray Bridge API. The low-level Bridge API is generic and independent of domain-specific tasks like rendering. It exposes the full flexibility of the Bridge. The high-level Iray Bridge API is specific to rendering. It encapsulates the details of the Bridge API and exposes them in a simpler way sufficient for rendering. Using the high-level API is strongly recommended unless there are specific needs which require the use of the low-level API. See the API component mi::bridge::IBridge_client for the Bridge API, and mi::bridge::IIray_bridge_client for the Iray Bridge API.

See Also
Iray Bridge, Bridge server

Enumeration Type Documentation

Job states of Bridge jobs.

Execution of Bridge jobs often involves uploads to the server which can take a considerable time. Each Bridge job goes through a sequence of states defined by this enum, starting in the state CLIENT_JOB_DETECTING_CHANGES and then progressing to the next state when some conditions are met until the job execution is done and the job ends up in the state CLIENT_JOB_DONE. States will always progress to the next state in the defined order, but some states might be skipped if there is no work that needs to be done in that state. Note that a lot of work is done in parallel so while the job is still determining which elements that needs to be updated, it will also query the cache status and start uploading data for cache misses, etc.

See Also

Detecting which database elements needs to be updated before executing the job.


Calculates hashes for the elements that will be updated and to some extent serialize data that will be sent inline.


Determining how much data needs to be uploaded before executing this job.

The elements that need to be updated is now known, but there are still pending cache status requests. The job might not enter this state if no cache status requests were needed, or if all requests were already answered while in state CLIENT_JOB_PREPARING.


Uploading data.

There are no pending cache status requests left and it is known how much data needs to be uploaded before executing the job. The job does not enter this state if there were no cache misses or if all data was already uploaded in previous states.


Waiting for execution of the job to finish.

All data needed by the job is now uploaded and the job is either executing on the server or waiting for all previous jobs to finish before it can start executing. To get progress feedback in this state it is possible for the server-side job to send partial results back to the client.


The result has been received and deserialized by the client-side job and the job is done.

The different states a client session can be in.

See Also

The session is trying to establish a connection to the remote Bridge application for the first time.


The session has successfully established a connection to the Bridge server and is ready for use.


The session was disconnected unexpectedly.

The session cannot be used in this state, but will automatically attempt to reconnect and resume the session. Session resume is only possible if the corresponding server-side session is still available when reconnecting, if not the session will be closed.

Note that session resume is currently not supported so disconnected sessions will always be closed.


The session has been closed in an orderly fashion, or the session has been pending but the session could not be resumed.

Once a session has been closed it can not be used anymore. To attempt a reconnection a new session must be opened.