summaryrefslogtreecommitdiff
path: root/src/drm_fb.c
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2023-09-03 14:46:50 -0700
committerVito Caputo <vcaputo@pengaru.com>2023-09-03 14:46:50 -0700
commit7bd8d205ee969452986b80de0dcd82ec9dff8180 (patch)
treed1b72147395036b8bcdbfff64f8d17b742882b6f /src/drm_fb.c
parent8bf8a9c90f36f4a3b894ca9bdfb1e9e993e86055 (diff)
modules/voronoi: spot-fix a crash Phil reported
The repro is: --seed=0x64f6820b '--module=compose,layers=blank\,pixbounce\\\,pixmap_size\\\=0.8\\\,pixmap\\\=err\,pixbounce\\\,pixmap_size\\\=0.4\\\,pixmap\\\=ignignokt,texture=voronoi\,cells\=512\,randomize\=on' '--video=mem,size=3840x2160' The major culprit seems to be the combination of high resolution, and small number of voronoi cells (cells=512), with randomize=on which exercises jumpfill every frame. The way jumpfill is implemented currently is racy by design to allow threading, and mostly works fine despite not really being how the algorithm is intended to work. The assumption has been, something like: "the seeds are already placed before the threaded phase, so the threaded jumpfill should at least find stable seed cells in the face of racing against other tiles being jumpfilled simultaneously" But it appears that assumption isn't always true, in that we won't necessarily find one of the seed cells at the start of the jumpfill when there aren't that many cells (512) compared to the area of the voronoi (3840x2160). By noticing when we've finished a tile's jumpfill with remaining unassigned cells, we can just repeat the jumpfill, with time passed, and the other tiles will have made progress on their work propagating more knowledge of where cells are... so the subsequent pass will probably leave nothing unassigned. This approach sucks, but stops the crashing. It'd also be possible to just change the way cells are looked up so there's no potential for a NULL pointer dereference, just have some uninitialized cell color which gets shown erroneously in the output. That avoids the computational cost of repeating the tile's jumpfill, and likely nobody would notice the likely single pixel of error for a single frame. I'm just doing this quick and dirty fix to prevent the crashing for now, and would like to just revisit voronoi more thoroughly with an eye towards decoupling the voronoi cost from the resolution. It's a cheap hack the way there's a distance entry per pixel, done just to simplify the implementation when I slapped it together on a Zephyr train ride.
Diffstat (limited to 'src/drm_fb.c')
0 files changed, 0 insertions, 0 deletions
© All Rights Reserved