Stingray Renderer Walkthrough #6: RenderInterface

Today we will be looking at the RenderInterface. I’ve struggled a bit with deciding if it is worth covering this piece of the code or not, as most of the stuff described will likely feel kind of obvious. In the end I still decided to keep it to give a more complete picture of how everything fits together. Feel free to skim through it or sit tight and wait for the coming two posts that will dive into the data-driven aspects of the Stingray renderer.

The glue layer

The RenderInterface is responsible for tying together a bunch of rendering sub-systems. Some of which we have covered in earlier posts (like e.g the RenderDevice) and a bunch of other, more high-level, systems that forms the foundation of our data-driven rendering architecture.

The RenderInterface has a bunch of various responsibilities, including:

• Tracking of windows and swap chains.

  While windows are managed by the simulation thread, swap chains are managed by the render thread. The RenderInterface is responsible for creating the swap chains and keep track of the mapping between a window and a swap chain. It is also responsible for signaling resizing and other state information from the window to the renderer.

• Managing of RenderWorlds.

  As mentioned in the Overview post, the renderer has its own representation of game Worlds called RenderWorlds. The RenderInterface is responsible for creating, updating and destroying the RenderWorlds.

• Owner of the four main building blocks of our data-driven rendering architecture: LayerManager, ResourceGeneratorManager, RenderResourceSet, RenderSettings

  Will be covered in the next post (I’ve talked about them in various presentations before [1] [2]).

• Owner of the shader manager.

  Centralized repository for all available/loaded shaders. Controls scheduling for loading, unload and hot-reloading of shaders.

• Owner of the render resource streamer.

  While all resource loading is asynchronous in Stingray (See [3]), the resource streamer I’m referring to in this context is responsible for dynamically loading in/out mip-levels of textures based on their screen coverage. Since this streaming system piggybacks on the view frustum culling system, it is owned and updated by the RenderInterface.

The interface

In addition to being the glue layer, the RenderInterface is also the interface to communicate with the renderer from other threads (simulation, resource streaming, etc.). The renderer operates under its own “controller thread” (as covered in the Overview post), and exposes two different types of functions: blocking and non-blocking.

Blocking functions

Blocking functions will enforce a flush of all outstanding rendering work (i.e. synchronize the calling thread with the rendering thread), allowing the caller to operate directly on the state of the renderer. This is mainly a convenience path when doing bigger state changes / reconfiguring the entire renderer, and should typically not be used during game simulation as it might cause stuttering in the frame rate.

Typical operations that are blocking:

• Opening and closing of the RenderDevice.

  Sets up / shuts down the graphics API by calling the appropriate functions on the RenderDevice.

• Creation and destruction of the swap chains.

  Creating and destroying swap chains associated to a Window. Done by forwarding the calls to the RenderDevice.

• Loading of the render_config / configuring the data-driven rendering pipe.

  The render_config is a configuration file describing how the renderer should work for a specific project. It describes the entire flow of a rendered frame and without it the renderer won’t know what to do. It is the RenderInterface responsibility to make sure that all the different sub-systems (LayerManager, ResourceGeneratorManager, RenderResourceSet, RenderSettings) are set up correctly from the loaded render_config. More on this topic in the next post.

• Loading, unloading and reloading of shaders.

  The shader system doesn’t have a thread safe interface and is only meant to be accessed from the rendering thread. Therefor any loading, unloading and reloading of shaders needs to synchronize with the rendering thread.

• Registering and unregistering of Worlds

  Creates or destroys a corresponding RenderWorld and sets up mapping information to go from World* to RenderWorld*.

Non-blocking functions

Non-blocking functions communicates by posting messages to a ring-buffer that the rendering thread consumes. Since the renderer has its own representation of a “World” there is not much communication over this ring-buffer, in a normal frame we usually don’t have more than 10-20 messages posted.

Typical operations that are non-blocking:

• Rendering of a World.

  void render_world(World &world, const Camera &camera, const Viewport &viewport, 
      const ShadingEnvironment &shading_env, uint32_t swap_chain);
  

  Main interface for rendering of a world viewed from a certain Camera into a certain Viewport. The ShadingEnvironment is basically just a set of shader constants and resources defined in data (usually containing a description of the lighting environment, post effects and similar). swap_chain is a handle referencing which window that will present the final result.

  When the user calls this function a RenderWorldMsg will be created and posted to the ring buffer holding handles to the rendering representations for the world, camera, viewport and shading environment. When the message is consumed by rendering thread it will enter the first of the three stages described in the Overview post - Culling.

• Reflection of state from a World to the RenderWorld.

  Reflects the “state delta” (from the last frame) for all objects on the simulation thread over to the render thread. For more details see [4].

• Synchronization.

  uint32_t create_fence();
  void wait_for_fence(uint32_t fence);
  

  Synchronization methods for making sure the renderer is finished processing up to a certain point. Used to handle blocking calls and to make sure the simulation doesn’t run more than one frame ahead of the renderer.

• Presenting a swap chain.

  void present_frame(uint32_t swap_chain = 0);
  

  When the user is done with all rendering for a frame (i.e has no more render_world calls to do), the application will present the result by looping over all swap chains touched (i.e referenced in a previous call to render_world) and posting one or many PresentFrameMsg messages to the renderer.

• Providing statistics from the RenderDevice.

  As mentioned in the RenderContext post, we gather various statistics and (if possible) GPU timings in the RenderDevice. Exactly what is gathered depends on the implementation of the RenderDevice. The RenderInterface is responsible for providing a non blocking interface for retrieving the statistics. Note: the statistics returned will be 2 frames old as we update them after the rendering thread is done processing a frame (GPU timings are even older). This typically doesn’t matter though as usually they don’t fluctuate much from one frame to another.

• Executing user callbacks.

  typedef void (*Callback)(void *user_data);
  void run_callback(Callback callback, void *user, uint32_t user_data_size);
  

  Generic callback mechanics to easily inject code to be executed by the rendering thread.

• Creation, dispatching and releasing of RenderContexts and RenderResourceContexts.

  While most systems tends to create, dispatch and release RenderContexts and RenderResourceContexts from the rendering thread there can be use cases for doing it from another thread (e.g. the resource thread creates RenderResourceContexts). The RenderInterface provides the necessary functions for doing so in a thread-safe way without having to block the rendering thread.

Wrap up

The RenderInterface in itself doesn’t get more interesting than that. Something needs to be responsible for coupling of various rendering systems and manage the interface for communicating with the controlling thread of the renderer - the RenderInterface is that something.

In the next post we will walk through the various components building the foundation of the data-driven rendering architecture and go through some examples of how to configure them to do something fun from the render_config file.

Stay tuned.