| Age | Commit message (Collapse) | Author |
|---|
|
Fragmenting is often dimensioned according to the number of cpus,
and by not supplying this to the fragmenter it was made rather
common for module contexts to plumb this themselves - in some
cases incorporating a context type/create/destroy rigamarole
for the n_cpus circuit alone.
So just plumb it in libtil, and the prepare_frame functions can
choose to ignore it if they have something more desirable onhand.
Future commits will remove a bunch of n_cpus from module contexts
in favor of this.
|
|
Mechanical renaming of "zero" to "clear" throughout for this
context.
|
|
Currently when a threaded renderer performed
til_fb_fragment_zero() in render_fragment() vs. prepare_frame(),
the til_fb_fragment.zeroed maintenance would stay isolated to the
ephemeral fragment generated by the fragmenter.
With this commit, when all ephemeral fragments rendered in a
threaded fashion for a given frame returned a set .zeroed member,
the outer frame's .zeroed member gets set.
This should enable proper threaded zeroing of the frame in
render_fragment().
Note that since it's careful to actually count the number of
zeroed ephemeral subfragments and only propagates when that count
matches the number of subfragments rendered in the entire frame,
it's also supported to use til_fb_fragment_zero() conditionally
on just some fragments while not zeroing others and the entire
frame will not get its .zeroed member set. Imagine a renderer
which randomly zeroes out some fragments, while drawing into
others, this will be honored as a non-zeroed frame on the whole.
|
|
Largely mechanical rename of librototiller -> libtil, but
introducing a til_ prefix to all librototiller (now libtil)
functions and types where a rototiller prefix was absent.
This is just a step towards a more libized librototiller, and til
is just a nicer to type/read prefix than rototiller_.
|
