| Age | Commit message (Collapse) | Author |
|---|
|
Add a hook for post-render serialized frame completion,
some of the renderers may have state to cleanup after rendering
a frame.
A future commit may change add a return value to control flow for
features like multi-pass rendering within a given module.
The raytracer for example may want to add concurrently executed
post filters, and having a non-void return from finish_frame()
would be a tidy way to tell rototiller "go back to prepare->render
for this context" as many times as necessary, keeping the pass state
in the context.
For now its return is void however, as I just need a cleanup hook
as the raytracer becomes more stateful per frame with a BIH spatial
index in the works.
|
|
Rather than laying out all fragments in a frame up-front in
ray_module_t.prepare_frame(), return a fragment generator
(rototiller_fragmenter_t) which produces the numbered fragment
as needed.
This removes complexity from the serially-executed
prepare_frame() and allows the individual fragments to be
computed in parallel by the different threads. It also
eliminates the need for a fragments array in the
rototiller_frame_t, indeed rototiller_frame_t is eliminated
altogether.
|
|
|
|
introduces create_context() and destroy_context() methods, and adds a
'void *context' first parameter to the module methods.
If a module doesn't supply create_context() then NULL is simply passed
around as the context, so trivial modules can continue to only implement
render_fragment().
A subsequent commit will update the modules to encapsulate their global
state in module-specific contexts.
|
|
This is a simple worker thread implementation derived from the ray_threads
code in the ray module. The ray_threads code should be discarded in a
future commit now that rototiller can render fragments using threads.
If a module supplies a prepare_frame() method, then it is called
per-frame to prepare a rototiller_frame_t which specifies how to divvy
up the page into fragments. Those fragments are then dispatched to a
thread per CPU which call the module's rendering function in parallel.
There is no coupling of the number of fragments in a frame to the number of
threads/CPUs. Some modules may benefit from the locality of tile-based
rendering, so the fragments are simply dispatched across the available CPUs
in a striped fashion.
Helpers will be added later to the fb interface for tiling fragments, which
modules desiring tiled rendering may utilize in their prepare_frame()
methods.
This commit does not modify any modules to become threaded, it only adds
the scaffolding.
|
|
Adding more context to the name in anticipation of adding a prepare_frame()
method to the module struct.
|
|
Make consistent with the source directory structure naming.
|
|
This is unoptimized, with a palette slapped together in vim, but still
pretty neat!
|
|
|
|
Restoring some organizational sanity since adopting autotools.
|
