[Performance]Plane-granularity processing in compatible filterchain

[DTL2020]

Where possible it is better for data locality in CPU caches to process data in the smallest possible chunks in each filter in a filterchain. Currently for multi-planes formats we have natural plane-granularity and if filters do not use inter-plane dependency the filter manager may try to process data between filters as a chain of plane processing instead of a frame (set of planes).

This may need AVS filters API update:

1. Checking method like bool IsPlaneBasedProcessingSupported(void) to ask filter if it can process single plane of multi-planes formats at the filter graph creation.
2. Maybe a new GetPlane() method to request plane only processing. Maybe some hack is possible to feed a set of single-plane formats to filter and use standard GetFrame() method. But it may need to create several instances of a filter for each plane and it may cause other performance issues. But this enables us to use any old filters without changes. This may be sort of script-based method:
   p1,p2,pn=SeparatePlanes()
   p1=Filter1(p1)
   p1=Filter2(p1)

p2=Filter1(p2)
p2=Filter2(p2)

pn=Filter1(p1)
pn=Filter2(pn)

CombinePlanes(p1,p2,pn) where Filter2 interconnects with Filter1 with GetFrame() methods as today but process only 1 plane each time.

Example of filter-chain with plane-based processing between 2 filters (example for 1D resize filters) - https://github.com/DTL2020/AviSynthPlus/blob/034a47e2c91ad9d84ad24492d37a18f99b58d996/avs_core/filters/resample.cpp#L2372

This can be expanded to a chain of other filters in total filtergraph until we reach non-supported filter or special end of chain filter-aggregator of planes at the output of AVS to consumer process. Or simply use the end of the chain filter always in frame-based processing mode. So its GetFrame() method will output fully processed all planes.

This is partially noted in
#445
and
#439

[DTL2020]

As more expansion of the idea about low granularity data chunks processing - some filters also can process samples-independent areas of a plane. So the filter manager may estimate optimal data size of a plane for fit in all levels of CPU cache (or user can set with some service function in a script) and the new method GetPlane() may also request a region of a plane to process with a supported chain of filters. This may help in processing large plane sizes in UHD formats. So method GetPlane() may have a RECT structure argument to set the region of interest to process in this call to function. Or at least a range of rows to process if we usually have rows located at linear RAM addresses blocks.
Filters of samples-independent processing may be Levels(), Invert(), RGBAdjust(), ColorYUV() (at some settings ?), and many others.

End of the sub-chain filter needs to get a list of regions to collect and fill the target plane with all regions where regions-based processing is finished.

[DTL2020]

In general AVS filtergraph filters are not connected directly via GetFrame() but via cache. And cache objects are VideoFrames. So it looks we need to add plane states in VideoFrame object (as VideoFrameOfPlanes) at least
bool bReady
with default false.
If VideoFrame got by GetFrame() method all plane ready states are true (for compatibility with old filters and not able to do plane separate output). If VideoFrame is initialized by source filter via GetPlane(frame n, plane m) method - only plane m gets ready state. And if the cache get request of GetPlane(frame n, plane m) and plane m of frame n is not ready - it makes GetPlane(frame n, plane m) request to the source filter.

[DTL2020]

Made some working example of Invert() filter with optional separated processing of a planes in a filtergraph. Made separate repository to keep this example from fork to save from lost while sync fork in the future (may be better to create a branch ?). https://github.com/DTL2020/AvisynthPlus-plane-base-filter-example/tree/main

With 2 filters in a graph and frame size of 4:4:4 with plane size about CPU caches (about 2..3 MB) it runs about 12% single threaded and about 17% multithreaded faster. Though this implementation still not MT friendly completely and at startup and after seek operation returns several bad frames (about number of MT cache frames ?).

ColorBarsHD(2500, 1000)

#Invert() - several filters in a chain also supported, first is planes-splitter via GetPlaneOfFrame() and last if aggregator in GetFrame()
Invert()
Invert()

At i3-2120 CPU:
350fps, 25 MByes, 25% CPU load single threaded
AVS+ 3.7.5 release - 311fps, 25 MBytes, 25% CPU load single threaded

Prefetch(4):
400 fps, 143 MBytes, ~90% CPU load
AVS+ 3.7.5 release - 340fps, 143 MBytes, 88% CPU load

[DTL2020]

Finally was able to make separate branch 'master-1' in the forked AVS+ and commit full files/folders structure.

In this commit added partial plane processing in the Invert() filter example - DTL2020@3460e98 .

Still not yet implemented user-definition of stripe size from script environment so plane internally cutted to 10 rows stripes.

This implementation still not MT friendly in AVS+ at least because uses local filter variables (pointers). Looks like the beginning of no-MT AVS. Need more thinking how to make at least plane-granularity mode to be compatible with AVS+ MT caches.