Beta 10 - About caching

Ok, so I was just writing a post about integrating the bitmap-caching settings to the existing bitmap-components, but then I realized it's already there. Maybe this Was added in the latest patch, or maybe I was just blind and didn't realize it earlier. Great.

So it looks like only the internal bitmap operations are calculated at the caching resolution and not the whole thing. I was expecting the entire processing to be done at lowered resolution. I wonder how this works internally..? This is probably still work in progress - are you expecting to get more speed advantages from this? At the moment there doesn't seem to be much speed difference even between 100% and 3.125%. Does seem to be more memory efficient though.

The new bitmap-cache component also doesn't seem to work well with other bitmap-components. Would be great if it would simply tell the preceding bitmap-component to re-apply its caching configuration, instead of re-caching the cache (or whatever it does, which seems to be very slow and memory intensive).

Ideally how I imagine the bitmap-cache working at 50% resolution is that everything before it gets effectively processed at 1/4 the sample count and then cached. I'm sure there's some overhead and stuff to slow things down. Still, hoping we can get a significant speed advantage with this.

This is good progress with a lot of potential

Yes, to be clear, I'm really happy with the bitmap-caching in general. I've already been able to reduce rendering times to 1/4 on some filters.

My original post was more about some specific areas, where the caching doesn't seem to work as well as expected. Mainly that lowering the caching resolution shows little to no performance boost in some cases, or even slows things down. It could well be that my initial testing setup was too simple and producing misleading results. Testing with more complex networks has shown better performance. I'll continue testing.

This is not the case where any additional cache would speed things up. This is a bitmap cache, and adding bitmaps into a procedural pipeline is more likely to slow the process rather than speed it up. You should always check filter performance with and without the cache, and generally prefer fully procedural rendering.

Quote
emme wrote: everything before it gets effectively processed at 1/4 the sample count and then cached.

As far as I understand (could be wrong though), it's just the opposite. Everything is sampled at full size and then the bitmap is resized, so the benefit applies to components after the cache, not before it.

Quote
emme wrote: At the moment there doesn't seem to be much speed difference even between 100% and 3.125%.

This is because the subtree you're plugging into the Bitmap Cache is fast enough. You will get the maximum speed advantage when 1) the Bitmap Cache subtree is slow to render, 2) the cache resolution is lower than 100%, and 3) the Bitmap Cache component is connected to multiple inputs.

Quote
emme wrote: The new bitmap-cache component also doesn't seem to work well with other bitmap-components.

This is probably due to our cache reuse mechanic. When the output of a bitmap-based component is plugged into a bitmap-cached input, the input doesn't re-render the cache, but instead reuses the output cache of the connected component as its own input cache. A corollary: cache settings for the bitmap-cached input will be ignored in this situation.

Quote
emme wrote: Ideally how I imagine the bitmap-cache working at 50% resolution is that everything before it gets effectively processed at 1/4 the sample count and then cached.

It works exactly as you describe. 100% means 1x sample count, 50% means 1/4 sample count, 25% means 1/16 sample count etc. Note that the sample counts are impacted by the Anti-Aliasing settings of the input.

Quote
GMM wrote: As far as I understand (could be wrong though), it's just the opposite. Everything is sampled at full size and then the bitmap is resized, so the benefit applies to components after the cache, not before it.

Of course not We sample per cache pixel, so less cache pixels = less samples.

This is all good to hear. Makes sense. Thanks Vladimir

Quote
Sphinx. wrote: I.e. consider this chain of bitmap components: A -> B -> C A creates the cache, do its thing and passes on the cache to B etc..

Correct. Component A creates the output cache, component B reuses it as the input cache for the cached input (ignoring its cache settings) and produces its output cache, which then gets reused by C's cached input.

Quote
Sphinx. wrote: Now B is connected to a normal sampler, i.e. Invert, which requries a persistent and unique B cache. I guess that would ruin the strategy?

Correct. A creates the output cache, B samples it and produces samples, C renders the input cache because it has no cache to reuse from component B.

Rachel, I tried the above with This Way filter, setting the cache resolution to 25%, and the render time stayed the same or slowed down slightly.

I tried setting the "blur" (at the beginning) to 25%. I also tried adding a bitmap cache component between the "subtract" (rotation map) and the bomber/offset and setting it to 25%. No luck either way.

I understand how to use the lookup/tile (solid fill)/free rectangle components to reduce sampling and speed up filters, but I'm not sure I understand how the bitmap cache settings can be used similarly...

Here is a modified Koch Crystals. The cache is placed at the end of a group that recursively calls itself up to 5 times. Here is a list of filters that benefit from the cache.

Koch Crystals 3 to 4 times faster
Koch Square 50% faster
Impressionist Curve 2 times faster
Impressionist Channels 2 times faster
Pentaflower 25% faster
Heptaflower 25% faster
Hexaflower 50% faster
Octoflower 50% faster
Detail Painter 2 times faster
Gosper Crystal 2 times faster
Distorted Echo Mask 2 times faster
Detail Painter 2 to 3 times faster

Koch Crystals cache.ffxml

The quality is fine as far as I can tell. It's all down to knowing what part of the cache tool to use and when. It's a cache, anti-aliasing tool, and resolution (blur like) tool. And much appreciated. I do push those pixels around.