summaryrefslogtreecommitdiff
path: root/src/Makefile.am
AgeCommit message (Collapse)Author
2018-02-22*: embrace new generic settings paradigmVito Caputo
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
2018-02-20setup: add simple stdio setup_interactively()Vito Caputo
Preliminary means for interactively configuring settings and defaults
2018-02-20settings: introduce abstract settingsVito Caputo
Settings will be used to express configurable parameters in the rendering modules and fb backends. The goal is to address both commandline argument setting of parameters, automatic use of defaults, as well as interactive configuration including the outputting of the resulting settings in a form usable as a commandline for future reuse. Since settings can be numerous and highly varied from one module or backend to another, a form similar to the Linux kernel's cmdline or QEMU's approach has been adopted. For example, a complete DRM backend, card selection and config would be: rototiller --video=drm,dev=/dev/dri/card0,connector=LVDS-1,mode=1024x768@60 If any of the above were omitted, then the missing settings would be interactively configured. If you added --defaults, then any omissions would be automatically filled in with the defaults. i.e. rototiller --video=drm,dev=/dev/dri/card4 --defaults would use the preferred connector and mode for that card. rototiller --video=drm --defaults would do the same but also default to the /dev/dri/card0 path. for brevity, I omitted rendering modules from above, but the same approach applies simply to --module=: rototiller --module=sparkler --video=drm --defaults If you ran rototiller without any arguments, then a fully interactive setup would ensue for module and video. If you ran rototiller with just --defaults, then everything is defaulted for you. A default rendering module will be used (the original roto renderer, probably). Note that this commit only adds scaffolding to make this possible, none of this is wired up yet.
2018-01-01drm_fb: implement drm fb backendVito Caputo
Largely mechanical copying of the drm code into the new fb_ops_t abstraction. Dormant for now.
2017-04-22rototiller: add threaded renderingVito Caputo
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.
2017-02-12julia: add a morphing Julia set rendererVito Caputo
This is unoptimized, with a palette slapped together in vim, but still pretty neat!
2017-02-07plasma: add a plasma rendererVito Caputo
2017-01-18*: move source into src/ subdirVito Caputo
Restoring some organizational sanity since adopting autotools.
© All Rights Reserved