| Age | Commit message (Collapse) | Author |
|---|
|
This introduces a stricter coupling and requirement for modules
supplying a fragmenter in their prepare_frame() to only receive
fragments produced by *their* fragmenter at their render_fragment().
When modules don't explicitly perform any fragmenting they can't
really make much use of this number as it will reflect an arbitrary
fragmenting pass's perspective.
But when modules do perform their own frame fragmenting, they can
assume any fragment supplied to their render function will have been
generated by it. This needs to be enforced a bit in the code.
The current use case is montage using a fragmenter for tiling the
montage in a threaded render. The fragment numbers map to the
modules to be rendered in the tiles. As long as modules can assume
their fragmenter will always be what produces their fragments, this
is perfectly fine.
|
|
The put_pixel helpers really needed reworking to properly handle
subframe fragments modules like montage will utilize. I had the
stride present as it's convenient for a number of modules that
maintain a buf pointer as they progress down a row, but the pitch
is more applicable to put_pixel for scaling the y coordinate.
Now there's both pitch and stride so everyone's happy with what's
most convenient for their needs.
|
|
For the sake of sdl_fb, move page flipping into the main thread
and run module render dispatch from another thread instead.
This eliminates the fb flipper thread, moving its functionality
into fb_flip() which synchronously consumes and performs a single
flip from the same queue as before - the function is verbatim
the loop body of the flipper thread.
Now main() calls fb_flip() in a loop where it previously dispatched
pages for rendering.
Rendering dispatch is now performed in a created thread.
See the comment in fb.c for more explanation of this shuffle.
|
|
The fb_ops entrypoints and their descendants are purely readers
of the settings, so constify their settings_t instances and the
operative functions which only read settings.
|
|
This should probably be split into multiple commits, but
for simplicity sake it's all cut over at once.
drm_fb.c sees major changes, migrating the remaining drm-specific bits
from drmsetup into it, behind the settings API.
rototiller.c sees a bunch of scaffolding surrounding the settings API
and wiring it up into the commandline handling and renderers and video
backends.
fb.[ch] see minor changes as settings get plumbed to the backend
drmsetup.[ch] goes bye bye
|
|
Remove everything drm-related from fb.c, utilizing the implementation in
drm_fb.c instead.
|
|
Hooks for fb acquire/release, page allocate, free, and flip.
This should encompass everything currently needed for the drm backend,
which will move behind this abstraction in a later commit.
|
|
Mechanical cosmetic change
|
|
|
|
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.
|
|
fb_fragment_put_pixel_unchecked() assumed the x,y coordinates of
the fragment were always 0.
|
|
Modules need to know the overall dimensions of the frame the fragment
they're rendering is part of. Previously it wasn't really necessary
since the fragments supplied to the modules had always been the full
page, but that's changing.
This commit also changes the julia module to use the frame dimensions,
others will need updating as well.
|
|
Currently just a memset wrapper... but maybe could get noop'd if
the flipper thread started supporting pre-zeroing pages in its thread,
just need a zeroed state in the fb page.
|
|
Modules seem to be duplicating this, just pull it into fb.h since we're
already dependent on the fb.h abstractions in the modules. Slippery slope!
|
|
Simple x,y coordinate check
|
|
Restoring some organizational sanity since adopting autotools.
|
