job-planning.hpp File Reference

Go to the source code of this file.

Description

Aggregation of planning data to generate actual frame calculation jobs.

These render jobs are generated periodically by an ongoing process while rendering is underway. For this purpose, each CalcStream of the play/render process operates a RenderDrive with a job-planning pipeline, rooted at the »master beat« as defined by the frame grid from the Timings spec of the current render process. This pipeline will assemble the specifications for the render jobs and thereby possibly discover prerequisites, which must be calculated first. From a usage point of view, the job-planning pipeline is an iterator: for each independent calculation step a new JobPlanning record appears at the output side of the pipeline, holding all collected data, sufficient to generate the actual job definition, which can then be handed over to the Scheduler.

Implementation of the Job-Planning pipeline

JobPlanning acts as working data aggregator within the Job-Planning pipeline; for this reason all data fields are references, and the optimiser is expected to elide them, since after template instantiation, JobPlanning becomes part of the overall assembled pipeline object, stacked on top of the Dispatcher::PipeFrameTick, which holds and increments the current frame number. The underlying play::Timings will provide a frame grid to translate these frame numbers into the nominal time values used throughout the rest of the render calculations.

There is one tricky detail to note regarding the handling of calculation prerequisites. The typical example would be the loading and decoding of media data, which is an IO-bound task and must be complete before the main frame job can be started. Since the Job-Planning pipeline is generic, this kind of detail dependency is modelled as prerequisite JobTicket, leading to an possibly extended depth-first tree expansion, starting from the »master frame ticket« at the root. This tree exploration is implemented by the IterExplorer::Expander building block, which obviously has to maintain a stack of expanded child dependencies. This leads to the observation, that at any point of this dependency processing, for the complete path from the child prerequisite up to the root tick there is a sequence of JobPlanning instances placed into this stack in the Explorer object (each level in this stack is actually an iterator and handles one level of child prerequisites). The deadline calculation directly exploits this known arrangement, insofar each JobPlanning has a pointer to its parent (sitting in the stack level above). See the IterExplorer unit test to understand this recursive on-demand processing in greater detail.

See also

JobPlanning_test

JobTicket

Dispatcher

EngineService

Definition in file job-planning.hpp.

#include "steam/common.hpp"
#include "vault/gear/job.h"
#include "steam/engine/job-ticket.hpp"
#include "steam/play/output-slot.hpp"
#include "steam/play/timings.hpp"
#include "lib/time/timevalue.hpp"
#include "lib/itertools.hpp"
#include "lib/nocopy.hpp"

Classes
class	JobPlanning
	View on the execution planning for a single calculation step. More...

Namespaces
	steam
	Steam-Layer implementation namespace root.
	steam::engine
	Lumiera's render engine core and operational control.