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.
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.
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.
As mentioned in the Overview post, the renderer has its own representation of game
RenderInterfaceis responsible for creating, updating and destroying the
Owner of the four main building blocks of our data-driven rendering architecture:
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 ), 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
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 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
Sets up / shuts down the graphics API by calling the appropriate functions on the
Creation and destruction of the swap chains.
Creating and destroying swap chains associated to a
Window. Done by forwarding the calls to the
Loading of the
render_config/ configuring the data-driven rendering pipe.
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 the
RenderInterfaceresponsibility to make sure that all the different sub-systems (
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
Creates or destroys a corresponding
RenderWorldand sets up mapping information to go from
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
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 certain
ShadingEnvironmentis 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
Reflects the “state delta” (from the last frame) for all objects on the simulation thread over to the render thread. For more details see .
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 to
render_world) and posting one or many
PresentFrameMsgmessages to the renderer.
Providing statistics from the
As mentioned in the
RenderContextpost, we gather various statistics and (if possible) GPU timings in the
RenderDevice. Exactly what is gathered depends on the implementation of the
RenderInterfaceis 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
While most systems tends to create, dispatch and release
RenderResourceContextsfrom the rendering thread there can be use cases for doing it from another thread (e.g. the resource thread creates
RenderInterfaceprovides the necessary functions for doing so in a thread-safe way without having to block the rendering thread.
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