summaryrefslogtreecommitdiff
path: root/src/mem_fb.c
AgeCommit message (Collapse)Author
2023-07-13til_args,*_fb: introduce --title= and wire up to til_fb_tVito Caputo
For meta-demo use cases like alphazed is experimenting with, it's desirable to change the window title from "rototiller" to "alphazed" or whatever if in windowed mode. This adds a way to do that in the obvious fashion... --title="alphazed" etc.
2023-06-19mem_fb: keep spare pages on a free listVito Caputo
Snapshotting made page alloc/free more frequent, and modules/mixer really hammers on snapshots in fade mode... drizzle as well, but mixer snapshots both module outputs per frame. So by keeping these around the reclaimed page snapshots can be held onto at within the fb as spares for quicker allocation. In practice it should just hit a high water mark of a working set for spare pages, once in a steady state, assuming snapshots aren't leaking. Future commits will replicate this change in {drm,sdl}_fb
2023-06-13*: smattering of random small fixes to silence -WallVito Caputo
I thought the build was already using -Wall but that seems to not be the case, maybe got lost somewhere along the line or messed up in configure.ac After forcing a build with -Wall -Werror, these showed up. Fixed up in the obvious way, nothing too scary.
2023-05-28til_setup,*: note settings path in til_setup_tVito Caputo
This commit adds passing the settings instance to til_setup_new() which is used for deriving a path for the setup via til_settings_print_path() on the supplied settings. That path gets an allocated copy left in the returned til_setup_t at til_setup_t.path This path will exist for the lifetime of the til_setup_t, to be freed along with the rest of the baked setup instance when the refcount reaches 0. The incoming til_settings_t is only read @ til_setup_new() in constructing the path, no reference is kept. Basically the til_settings_t* is just passed in for convenience reasons, since constructing the path needs memory and may fail, this approach lets the existing til_setup_new() call error handling also capture the path allocation failures as-is turning til_setup_new() into a bit more of a convenience helper. Note that now all code may assume a til_setup_t has a set and valid til_setup_t.path, which should be useful for context creates when a setup is available.
2023-05-28*: use NULL for free() in til_setup_new()Vito Caputo
Commit 7c8086020 switched the til_setup_new() api to support NULL free_func for free(). This mechanical change pivots to that instead of the awkwardly cast free() parameters.
2023-05-11til_settings: introduce til_setting_spec_t concept vs. descVito Caputo
For recursive settings the individual setting being described needs to get added to a potentially different settings instance than the one being operated on at the top of the current setup_func phase. The settings instance being passed around for a setup_func to operate on is constified, mainly to try ensure modules don't start directly mucking with the settings. They're supposed to just describe what they want next and iterate back and forth, with the front-end creating the settings from the returned descs however is appropriate, eventually building up the settings to completion. But since it's the setup_func that decides which settings instance is appropriate for containing the setting.. at some point it must associate a settings instance with the desc it's producing, one that is going to be necessarily written to. So here I'm just turning the existing til_setting_desc_t to a "spec", unchanged. And introducing a new til_setting_desc_t embedding the spec, accompanied by a non-const til_settings_t* "container". Now what setup_funcs use to express settings are a spec, otherwise identically to before. Instead of cloning a desc to allocate it for returning to the front-end, the desc is created from a spec with the target settings instance passed in. This turns the desc step where we take a constified settings instance and cast it into a non-const a more formal act of going from spec->desc, binding the spec to a specific settings instance. It will also serve to isolate that hacky cast to a til_settings function, and all the accessors of til_setting_desc_t needing to operate on the containing settings instance can just do so. As of this commit, the container pointer is just sitting in the desc_t but isn't being made use of or even assigned yet. This is just to minimize the amount of churn happening in this otherwise mostly mechanical and sprawling commit. There's also been some small changes surrounding the desc generators and plumbing of the settings instance where there previously wasn't any. It's unclear to me if desc generators will stay desc generators or turn into spec generators. For now those are mostly just used by the drm_fb stuff anyways, modules haven't made use of them, so they can stay a little crufty harmlessly for now.
2022-08-07til: experimentally fragment-centric page apiVito Caputo
It seems like it might be most ergonomic and convenient for everything to just use til_fb_fragment_t and rely on ops.submit to determine if the fragment is a page or not, and if it is how to submit it. This commit brings things into that state of the world, it feels kind of gross at the til_fb_page_*() API. See the large comment in til_fb.c added by this commit for more information. I'm probably going to just run with this for now, it can always get cleaned up later. What's important is to get the general snapshotting concept and functionality in place so modules can make use of it. There will always be things to cleanup in this messy tangle of a program.
2022-07-15mem_fb: introduce --video=mem; a dummy in-memory video backendVito Caputo
The immediate impetus for adding this is to enable running rototiller even on headless machines just for the sake of getting some FPS measurements. It'd be nice to get a sense for what FPS rototiller would experience on larger modern machines like big EPYC or Threadripper systems. But it seems most of those I can get access to via others running them on work hardware or the like can at most just run it over ssh without any display or risk of disrupting the physical console. But this is probably also useful for testing/debugging purposes, especially since it doesn't bother to synchronize flips on anything not even a timer. So a bunch of display complexity is removed running with video=mem as well as letting the framerate run unbounded. Having said that, it might be nice to add an fps=N setting where mem_fb uses a plain timer for scheduling the flips. Currently the only setting is size=WxH identical to the sdl_fb size= setting, defaulting to 640x480.
© All Rights Reserved