Skip to content

Improve obsolete pipecache handling#21572

Open
jenshannoschwalm wants to merge 2 commits into
darktable-org:masterfrom
jenshannoschwalm:improved_cache_obsolete
Open

Improve obsolete pipecache handling#21572
jenshannoschwalm wants to merge 2 commits into
darktable-org:masterfrom
jenshannoschwalm:improved_cache_obsolete

Conversation

@jenshannoschwalm

Copy link
Copy Markdown
Collaborator

Currently we use gboolean cache_obsolete to enforce a complete invalidation of the pipe's cache before the next pixelpipe run.

We had that for years, it was introduced and required as a workaround while the hash calculation for piece and cachelines were not "complete". Using this flag leads to bad UI response as a reprocessed pipe will never get a cacheline hit after obsolete.

Instead of using a gboolean we now have uint32_t cache_obsolete_order, defaulting to INT_MAX.
If set to anything below, only the cachelines with iop_order >= cache_obsolete_order will be invalidated before the next pixelpipe run.
This allows a fine control for what cachelines shouldn't be used for a cache-hit thus we have a clearly faster response in many situations triggered by the user.

Two helpers were modified, both take the iop_order as an extra argument, note that using an iop_order of 0 will do a complete cache flush (as we had with the old gboolean).
void dt_dev_reprocess_center(dt_develop_t *dev, const int32_t iop_order)
void dt_dev_reprocess_preview(dt_develop_t *dev, const int32_t iop_order)

Currently we use `gboolean cache_obsolete` to enforce a complete invalidation of the pipe's cache
before the **next** pixelpipe run.
We had that for years, it was introduced and required as a workaround while the hash calculation
for piece and cachelines were not "complete".
Using the flag leads to bad UI response as a reprocessed pipe will never get a cacheline hit.

Instead of using a `gboolean` we now have `uint32_t cache_obsolete_order`, defaulting to INT_MAX.
If set to anything below, the cachelines with `iop_order >= cache_obsolete_order` will be invalidated
before the next pixelpipe run.
This allows a finer control for what cachelines shouldn't be used for a cache-hit thus we have
a clearly faster response in many situations triggered by the user.

Two helpers were modified, both take the iop_order as an extra argument, note that using an
iop_order of `0` will do a complete cache flush (as we had with the old gboolean).
`void dt_dev_reprocess_center(dt_develop_t *dev, const int32_t iop_order)`
`void dt_dev_reprocess_preview(dt_develop_t *dev, const int32_t iop_order)`
@jenshannoschwalm jenshannoschwalm added this to the 5.8 milestone Jul 19, 2026
@jenshannoschwalm jenshannoschwalm added feature: redesign current features to rewrite scope: UI user interface and interactions scope: performance doing everything the same but faster release notes: pending labels Jul 19, 2026
1. Request for details mask
2. Selecting a history item in history lib

both require cacheline invalidations, simplyfied code in both cases.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature: redesign current features to rewrite release notes: pending scope: performance doing everything the same but faster scope: UI user interface and interactions

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant