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
RenderInterfaceis 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
WorldscalledRenderWorlds. TheRenderInterfaceis responsible for creating, updating and destroying theRenderWorlds.Owner of the four main building blocks of our data-driven rendering architecture:
LayerManager,ResourceGeneratorManager,RenderResourceSet,RenderSettingsWill 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 theRenderDevice.Loading of the
render_config/ configuring the data-driven rendering pipe.The
render_configis 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 theRenderInterfaceresponsibility to make sure that all the different sub-systems (LayerManager,ResourceGeneratorManager,RenderResourceSet,RenderSettings) are set up correctly from the loadedrender_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
WorldsCreates or destroys a corresponding
RenderWorldand sets up mapping information to go fromWorld*toRenderWorld*.
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
Camerainto a certainViewport. TheShadingEnvironmentis 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_chainis a handle referencing which window that will present the final result.When the user calls this function a
RenderWorldMsgwill 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
Worldto theRenderWorld.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_worldcalls to do), the application will present the result by looping over all swap chains touched (i.e referenced in a previous call torender_world) and posting one or manyPresentFrameMsgmessages to the renderer.Providing statistics from the
RenderDevice.As mentioned in the
RenderContextpost, we gather various statistics and (if possible) GPU timings in theRenderDevice. Exactly what is gathered depends on the implementation of theRenderDevice. TheRenderInterfaceis 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
RenderContextsandRenderResourceContexts.While most systems tends to create, dispatch and release
RenderContextsandRenderResourceContextsfrom the rendering thread there can be use cases for doing it from another thread (e.g. the resource thread createsRenderResourceContexts). TheRenderInterfaceprovides 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.