# Rendering network using crowdsourced GPU

The graphics rendering service consists in a network of decentralized machines called *nodes* which are of 3 kinds: *manager*, *worker* and *verifier*. The *managers* are dedicated machines of Inferix while *verifiers* and *workers* are machines joined by GPU owners. The number of *workers* is normally much larger than the number of *managers* and *verifiers*.

#### Figure 1 <a href="#fig_rendering_flow" id="fig_rendering_flow"></a>

<figure><img src="https://3032367557-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FcE7ARktdPinaZgrdSJOX%2Fuploads%2F6XvNsNFpGDpILDSiL0ds%2Frendering-network-flow%20(2).svg?alt=media&#x26;token=4c040ed5-0f76-429d-adfa-76771a6a5390" alt=""><figcaption><p>Rendering flow</p></figcaption></figure>

A typical rendering session contains several steps as shown in [Figure 1](#fig_rendering_flow) and explained below:

1. A user creates a rendering job request using the Inferix's plugin for client, this job uploads user's scene data to some *manager*.
2. The rendering task controller of the *manager* receives the rendering job request, then

   1. splits it into multiple rendering tasks, each task consists of the scene data and several parameters: range of frames to be rendered, output format, etc.
   2. generates corresponding verification keys and sends these keys to the verifying task controller.

   The rendering tasks will be assigned to *workers* and the verification keys will be sent to the verifying task controller.
3. Receiving a rendering task, a *worker* renders the included scene using the parameters given by the task. When it finishes, it saves the rendered frames to a decentralized storage, then notifies the *manager* by a message containing a unique URL to the result.
4. The verifying task controller of the notified *manager* receives the notification then creates a verification task; this task will be assigned to a *verifier*.
5. Receiving a verification task, a *verifier*
   1. checks the authenticity of the corresponding rendered frames, then
   2. notifies the *manager* about the verification result.
6. If the rendered frames pass the verification, then the manager notifies the user by a message containing the URL to the rendered frames. Otherwise, these frames are rejected.
7. The user downloads the frames from the storage and manually confirms whether they meet the expectation, if they do not then the user sends a bad result claim to the manager.

The *managers* synchronize a database of rendering and verification tasks. That makes the rendering service being both logically and physically decentralized: a graphics scene can be simultaneously rendered by different *workers* and later checked by different *verifiers*, the machines of *workers* and *verifiers* can be also located at different geographical locations.