jpsdr
12th August 2016, 13:53
I've made a plugin of the resampling functions, with internal multi-threading.
I can allready ear the "why" ?
The answer is "because"...:D
More seriously, i'll explain my point of view.
For multi-threading in image processing, if you have n cores, you have basicaly two ways :
Case 1 : You process n pictures in parallel.
Case 2 : You process n 1/nth part of the picture in parallel.
The internal core can only offer the case 1, because it has no idea how to handle junction/overlap of the splitted image, neither how to split it (even if the most common way is the vertical split), and even more if splitting is possible.
The case 2 is only possible internaly, because only the filter know how to split, join, handle overlap, etc...
Personnaly, i don't like the case 1, i think case 2 is a way better.
Differences may not be very obvious with few cores, but it will become with a lot of cores.
With case 2, the memory used is always the same, whatever the number of cores you have, when with case 1, it always increases. The more cores you have, the less memory each core is working on => the more chance you have to fit it in lower cache level => the more performance you can get. Forget it with case 1.
For example, if you have an high-end 10 cores with HT CPU, giving you 20 cores.
A UHD 4k YV12 picture has a size of around 12,5MB. The whole picture fit on the L3 cache, so the 20 cores will access their data within it. I'll let you guess the result with case 1...
A FHD 1080p YV12 picture has a size of around 3MB, fit in L3 but 1/20 gives 155KB, this fits on L2 cache, so each core will work with data from his own L2 cache. Case 1 doesn't even fit in L3 cache.
You may not have this point of view, but for those who share it, you can use my multi-threaded version.
This version works on all avs+ version, and on all 2.6.x versions.
Current version : 2.10.0
Sources are here (https://github.com/jpsdr/ResampleMT).
Binaries are here (https://github.com/jpsdr/ResampleMT/releases/download/2.10.0/ResampleMT_v2_10_0.7z).
Version history
2.10.0 : Implement core code update with AVX512.
2.9.8 : Minor changes (more code refactory).
2.9.0 : Revert and remove all ASM code, benchmark not good. Fix SSE crash & Bicubic.
2.8.0 : Add ASM code AVX/AVX2/AVX512.
2.7.1 : Update matrix class.
2.7.0 : Update to new SSE code.
2.6.0 : Update to new AVX2 code.
2.5.1 : Fix for optimized functions.
2.5.0 : Add chroma placement and new filters coeff calcul.
2.4.0 : Add force parameter, fix a crop issue and update Gaussresize.
2.3.9 : Update to new AVS+ headers.
2.3.8 : Add DTL pull-request (update on UserDefined2ResizeMT).
2.3.7 : Update to new AVS+ headers.
2.3.6 : Update on threadpool, no user limit (except memory).
2.3.5 : Fix on threadpool, using prefetch parameter created hang. Add negative prefetch for triming, read Multithreading.txt or Multithreading chapter here. Fix for RGB packed format.
2.3.4 : Fix on threadpool.
2.3.3 : Working fix for too small size vs size filter, update avs headers.
2.3.2 : Add UserDefined2ResampleMT function, fix for too small size vs size filter.
2.3.1 : Add SincLin2Resize function.
2.3.0 : Add SinPowResize function.
2.2.3 : Update of the threadpool, update to new avisynth headers.
2.2.2 : Minor code change after threadpool update, fix in the number of threads,
fix to perfectecly match avs+ output (V/H resize order was sometimes different).
2.2.0 : Update of the threadpool, add ThreadLevel parameter.
2.1.2 : Update of Matrix Class.
2.1.1 : Optimized CPU placement if SetAffinity=true for prefetch>1, SetAffinity back to default false.
2.1.0 : Merge new core resampler code, filter is MT_NICE.
2.0.3 : Fix a bug in the MTData, add check for inverting matrix in desample.
2.0.2 : Minor update on threadpool.
2.0.1 : Desample now handle properly croped and/or high value shifted original.
2.0.0 : Added the Desample functions.
1.5.8 : Fix possible deadlock in threadpool, and fix issue of filter "doing nothing".
1.5.7 : Fix in threadpool.
1.5.6 : Minor fix.
1.5.5 : Minor changes on threadpool.
1.5.4 : Minor update on threadpool.
1.5.3 : Update avs header, fix range mode issue.
1.5.2 : Some fixes, add range mode 4, set range mode default to 1, apply range only on last step.
1.5.1 : Change code to allow the merge of the plugins.
1.5.0 : Add range parameter.
1.4.0 : Add sleep and prefetch parameters.
1.3.0 : Update to the new resample core functions. Update to the new avs header and support of all supported video formats. Build with /MD instead of /MT.
1.2.6 : Use Mutex instead of CriticalSection on some places and some changes in the threadpool interface.
1.2.5 : Fix deadlock case in Threadpool interface. Remove CACHE_DONT_CACHE_ME and small changes in the threadpool interface.
1.2.4 : Add several parameters to allow more specific tuning of the threadpool if necessary.
1.2.3 : Minor change.
1.2.2 : Update of the threadpool and minor change.
1.2.1 : Update the threadpool interface, fix the deadloock on init and other small things.
1.2.0 : Update the threadpool interface.
1.1.0 : Use an external thread pool class but internaly to prevent the thread creation explosion.
1.0.2 : Test of finaly a bad idea...
1.0.1 : Fix Intel compiler warning.
1.0.0 : First release.
==================================================================
Desample
Desample functions added on v2.0.0
DeBilinearResizeMT
DeBicubicResizeMT
DeLanczosResizeMT
DeLanczos4ResizeMT
DeBlackmanResizeMT
DeSpline16ResizeMT
DeSpline36ResizeMT
DeSpline64ResizeMT
DeGaussResizeMT
DeSincResizeMT
DeSinPowResizeMT
DeSincLin2ResizeMT
DeUserDefined2ResampleMT
More information on Desample functions here (http://forum.doom9.org/showthread.php?p=1817097#post1817097).
==================================================================
The functions inside this plugin are :
PointResizeMT
BilinearResizeMT
BicubicResizeMT
LanczosResizeMT
Lanczos4ResizeMT
BlackmanResizeMT
Spline16ResizeMT
Spline36ResizeMT
Spline64ResizeMT
GaussResizeMT
SincResizeMT
SinPowResizeMT
SincLin2ResizeMT
UserDefined2ResampleMT
Parameters are exactly the same than the orignal resampling functions, and in the same order, so they are totaly backward compatible.
For the new kernel functions added, check the ReadMe file.
Several new parameters are added at the end of all the parameters :
threads -
Controls how many threads will be used for processing. If set to 0, threads will
be set equal to the number of detected logical or physical cores,according logicalCores parameter.
Default: 0 (int)
logicalCores -
If threads is set to 0, it will specify if the number of threads will be the number
of logical CPU (true) or the number of physical cores (false). If your processor doesn't
have hyper-threading or threads<>0, this parameter has no effect.
Default: true (bool)
MaxPhysCore -
If true, the threads repartition will use the maximum of physical cores possible. If your
processor doesn't have hyper-threading or the SetAffinity parameter is set to false,
this parameter has no effect.
Default: true (bool)
SetAffinity -
If this parameter is set to true, the pool of threads will set each thread to a specific core,
according MaxPhysCore parameter. If set to false, it's leaved to the OS.
Default: true (bool)
sleep -
If this parameter is set to true, once the filter has finished one frame, the threads of the
threadpool will be suspended (instead of still running but waiting an event), and resume when
the next frame will be processed. If set to false, the threads of the threadpool are always
running and waiting for a start event even between frames.
Default: false (bool)
prefetch -
This parameter will allow to create more than one threadpool, to avoid mutual resources acces
lock/wait if "prefetch" is used in the avs script.
0 : Will set automaticaly to the prefetch value use in the script. Well... that's what i wanted
to do, but for now it's not possible for me to get this information when i need it, so, for
now, 0 will result in 1. For now, if you're using "prefetch" in your script, put the same
value on this parameter.
range -
This parameter specify the range the output video data has to comply with.
Limited range is 16-235 for Y, 16-240 for U/V. Full range is 0-255 for all planes.
Alpha channel is not affected by this paramter, it's always full range.
Values are adjusted according bit depth of course. This parameter has no effect
for float datas.
0 : Automatic mode. If video is YUV mode is limited range, if video is RGB mode is
full range, if video is greyscale (Y/Y8) mode is Y limited range.
1 : Force full range whatever the video is.
2 : Force limited Y range for greyscale video (Y/Y8), limited range for YUV video,
no effect for RGB video.
3 : Force limited U/V range for greyscale video (Y/Y8), limited range for YUV video,
no effect for RGB video.
4 : Force special camera range (16-255) for greyscale video (Y/Y8) and YUV video,
no effect for RGB video.
Default: 1
ThreadLevel -
This parameter will set the priority level of the threads created for the processing (internal
multithreading). No effect if threads=1.
1 : Idle level.
2 : Lowest level.
3 : Below level.
4 : Normal level.
5 : Above level.
6 : Highest level.
7 : Time critical level (WARNING !!! use this level at your own risk)
Default : 6
The logicalCores, MaxPhysCore, SetAffinity and sleep are parameters to specify how the pool of thread will be created and handled, allowing if necessary each people to tune according his configuration.
So, syntax is :
ResampleFunction([original parameters],int threads, bool logicalCores, bool MaxPhysCore, bool SetAffinity, bool sleep, int prefetch,int range)
==================================================================
JincResizeMT
Current version : 1.1.0
Sources are here (https://github.com/jpsdr/JincResizeMT).
Binaries are here (https://github.com/jpsdr/JincResizeMT/releases/download/1.1.0/JincResizeMT_v1_1_0.7z).
JincResizeMT(clip, int target_width, int target_height, float src_left, float src_top, float src_width, float src_height, int quant_x, int quant_y, int tap, float blur, string cplace, int threads, int opt, int initial_capacity, float initial_factor, int range, bool logicalCores, bool MaxPhysCore, bool SetAffinity, bool sleep, int prefetch, int ThreadLevel)
)
Jinc36ResizeMT/Jinc64ResizeMT/Jinc144ResizeMT/Jinc256ResizeMT(clip, int target_width, int target_height, float src_left, float src_top, float src_width, float src_height, int quant_x, int quant_y, string cplace, int threads, int range, bool logicalCores, bool MaxPhysCore, bool SetAffinity, bool sleep, int prefetch, int ThreadLevel)
)
See the ReadMe file for more informations and descriptions of the functions and their parameters.
==================================================================
Multi-threading information
CPU example case : 4 cores with hyper-threading.
If you leave all the multi-threading parameters to their default value, it's set to be "optimal" when you're not using prefetch or if you are under standard avisynth, all the logical CPU will be used.
If you put SetAffinity to true it will allocate the threads on the CPU contiguously. Physical CPU 1 will have threads (0,1), ... physical CPU 4 will have threads (6,7), allowing optimal cache use. Make test to see what's best for you.
Now, if you are using prefetch on your script, things are different !
If you're using it with the max number of CPUs (8 in our exemple case), you still can make tests, but i would strongly advise to disable the internal multi-threading by using threads=1. In this case, there is no threadpool created, and all the other multi-threading related filter parameters have no effect, even prefetch.
If you're using prefetch on your script, with less than your CPU number, you may want to try to mix the external and internal mutli-threading, setting the internal multi-threading to a lower number of threads, and setting the prefetch parameter of the filter. This parameter will set the number of internal threadpool created, the best is to match the prefetch script value. If you don't set it (leave it to 1) or set a lower value than prefetch on your script, you'll have several instances (or GetFrame) created, but they'll not be running efficiently, because each instance (or GetFrame) will spend time waiting for a threadpool to be avaible, if not enough were created.
Unfortunately, as things are now, i have no way of knowing the prefetch value used in the avisynth script at the time i need the information, this is why you have to use the prefetch parameter in the filter.
In our CPU exemple case, you can have things like :
filter(...,threads=1)
prefetch(8)
or
filter(...,threads=2,prefetch=4)
prefetch(4)
or
filter(...,threads=4,prefetch=2)
prefetch(2)
or even
filter(...,threads=3,prefetch=4)
prefetch(4)
if you want to boost and go a little over your total CPU number.
Also, if your prefetch is not higher than your number of physical cores, you can try to put SetAffinity to true, but in that case, you have to set MaxPhysCore to false. The threads of each pool will be set on CPUs by steps.
For exemple, in our case :
filter(...,threads=2,prefetch=4,SetAffinity=true,MaxPhysCore=false)
prefetch(4)
Will create 4 pool of 2 threads, with the following :
pool[0] : threads(0 -> 1) on CPU 1.
pool[1] : threads(0 -> 1) on CPU 2.
pool[2] : threads(0 -> 1) on CPU 3.
pool[3] : threads(0 -> 1) on CPU 4.
filter(...,threads=4,prefetch=2,SetAffinity=true,MaxPhysCore=false)
prefetch(2)
Will create 2 pool of 4 threads, with the following :
pool[0] : threads(0 -> 1) on CPU 1.
pool[0] : threads(2 -> 3) on CPU 2.
pool[1] : threads(0 -> 1) on CPU 3.
pool[1] : threads(2 -> 3) on CPU 4.
Negative prefetch
The possibility to put negative prefecth to tune the prefetch parameter to optimal value has been added. The filter will throw an error if the number is not high enough to avoid waiting when requesting internal threadpool. For this to work properly, you have to put negative prefetch on ALL the filters of your script, and also ALL instances of the same filter.
Exemple :
filter(...,threads=2,prefetch=-2)
prefetch(2)
You'll see an error.
But with :
filter(...,threads=2,prefetch=-3)
prefetch(2)
You'll see no error, so the optimal is :
filter(...,threads=2,prefetch=3)
prefetch(2)
Once you've tune, put back a positive value.
I can allready ear the "why" ?
The answer is "because"...:D
More seriously, i'll explain my point of view.
For multi-threading in image processing, if you have n cores, you have basicaly two ways :
Case 1 : You process n pictures in parallel.
Case 2 : You process n 1/nth part of the picture in parallel.
The internal core can only offer the case 1, because it has no idea how to handle junction/overlap of the splitted image, neither how to split it (even if the most common way is the vertical split), and even more if splitting is possible.
The case 2 is only possible internaly, because only the filter know how to split, join, handle overlap, etc...
Personnaly, i don't like the case 1, i think case 2 is a way better.
Differences may not be very obvious with few cores, but it will become with a lot of cores.
With case 2, the memory used is always the same, whatever the number of cores you have, when with case 1, it always increases. The more cores you have, the less memory each core is working on => the more chance you have to fit it in lower cache level => the more performance you can get. Forget it with case 1.
For example, if you have an high-end 10 cores with HT CPU, giving you 20 cores.
A UHD 4k YV12 picture has a size of around 12,5MB. The whole picture fit on the L3 cache, so the 20 cores will access their data within it. I'll let you guess the result with case 1...
A FHD 1080p YV12 picture has a size of around 3MB, fit in L3 but 1/20 gives 155KB, this fits on L2 cache, so each core will work with data from his own L2 cache. Case 1 doesn't even fit in L3 cache.
You may not have this point of view, but for those who share it, you can use my multi-threaded version.
This version works on all avs+ version, and on all 2.6.x versions.
Current version : 2.10.0
Sources are here (https://github.com/jpsdr/ResampleMT).
Binaries are here (https://github.com/jpsdr/ResampleMT/releases/download/2.10.0/ResampleMT_v2_10_0.7z).
Version history
2.10.0 : Implement core code update with AVX512.
2.9.8 : Minor changes (more code refactory).
2.9.0 : Revert and remove all ASM code, benchmark not good. Fix SSE crash & Bicubic.
2.8.0 : Add ASM code AVX/AVX2/AVX512.
2.7.1 : Update matrix class.
2.7.0 : Update to new SSE code.
2.6.0 : Update to new AVX2 code.
2.5.1 : Fix for optimized functions.
2.5.0 : Add chroma placement and new filters coeff calcul.
2.4.0 : Add force parameter, fix a crop issue and update Gaussresize.
2.3.9 : Update to new AVS+ headers.
2.3.8 : Add DTL pull-request (update on UserDefined2ResizeMT).
2.3.7 : Update to new AVS+ headers.
2.3.6 : Update on threadpool, no user limit (except memory).
2.3.5 : Fix on threadpool, using prefetch parameter created hang. Add negative prefetch for triming, read Multithreading.txt or Multithreading chapter here. Fix for RGB packed format.
2.3.4 : Fix on threadpool.
2.3.3 : Working fix for too small size vs size filter, update avs headers.
2.3.2 : Add UserDefined2ResampleMT function, fix for too small size vs size filter.
2.3.1 : Add SincLin2Resize function.
2.3.0 : Add SinPowResize function.
2.2.3 : Update of the threadpool, update to new avisynth headers.
2.2.2 : Minor code change after threadpool update, fix in the number of threads,
fix to perfectecly match avs+ output (V/H resize order was sometimes different).
2.2.0 : Update of the threadpool, add ThreadLevel parameter.
2.1.2 : Update of Matrix Class.
2.1.1 : Optimized CPU placement if SetAffinity=true for prefetch>1, SetAffinity back to default false.
2.1.0 : Merge new core resampler code, filter is MT_NICE.
2.0.3 : Fix a bug in the MTData, add check for inverting matrix in desample.
2.0.2 : Minor update on threadpool.
2.0.1 : Desample now handle properly croped and/or high value shifted original.
2.0.0 : Added the Desample functions.
1.5.8 : Fix possible deadlock in threadpool, and fix issue of filter "doing nothing".
1.5.7 : Fix in threadpool.
1.5.6 : Minor fix.
1.5.5 : Minor changes on threadpool.
1.5.4 : Minor update on threadpool.
1.5.3 : Update avs header, fix range mode issue.
1.5.2 : Some fixes, add range mode 4, set range mode default to 1, apply range only on last step.
1.5.1 : Change code to allow the merge of the plugins.
1.5.0 : Add range parameter.
1.4.0 : Add sleep and prefetch parameters.
1.3.0 : Update to the new resample core functions. Update to the new avs header and support of all supported video formats. Build with /MD instead of /MT.
1.2.6 : Use Mutex instead of CriticalSection on some places and some changes in the threadpool interface.
1.2.5 : Fix deadlock case in Threadpool interface. Remove CACHE_DONT_CACHE_ME and small changes in the threadpool interface.
1.2.4 : Add several parameters to allow more specific tuning of the threadpool if necessary.
1.2.3 : Minor change.
1.2.2 : Update of the threadpool and minor change.
1.2.1 : Update the threadpool interface, fix the deadloock on init and other small things.
1.2.0 : Update the threadpool interface.
1.1.0 : Use an external thread pool class but internaly to prevent the thread creation explosion.
1.0.2 : Test of finaly a bad idea...
1.0.1 : Fix Intel compiler warning.
1.0.0 : First release.
==================================================================
Desample
Desample functions added on v2.0.0
DeBilinearResizeMT
DeBicubicResizeMT
DeLanczosResizeMT
DeLanczos4ResizeMT
DeBlackmanResizeMT
DeSpline16ResizeMT
DeSpline36ResizeMT
DeSpline64ResizeMT
DeGaussResizeMT
DeSincResizeMT
DeSinPowResizeMT
DeSincLin2ResizeMT
DeUserDefined2ResampleMT
More information on Desample functions here (http://forum.doom9.org/showthread.php?p=1817097#post1817097).
==================================================================
The functions inside this plugin are :
PointResizeMT
BilinearResizeMT
BicubicResizeMT
LanczosResizeMT
Lanczos4ResizeMT
BlackmanResizeMT
Spline16ResizeMT
Spline36ResizeMT
Spline64ResizeMT
GaussResizeMT
SincResizeMT
SinPowResizeMT
SincLin2ResizeMT
UserDefined2ResampleMT
Parameters are exactly the same than the orignal resampling functions, and in the same order, so they are totaly backward compatible.
For the new kernel functions added, check the ReadMe file.
Several new parameters are added at the end of all the parameters :
threads -
Controls how many threads will be used for processing. If set to 0, threads will
be set equal to the number of detected logical or physical cores,according logicalCores parameter.
Default: 0 (int)
logicalCores -
If threads is set to 0, it will specify if the number of threads will be the number
of logical CPU (true) or the number of physical cores (false). If your processor doesn't
have hyper-threading or threads<>0, this parameter has no effect.
Default: true (bool)
MaxPhysCore -
If true, the threads repartition will use the maximum of physical cores possible. If your
processor doesn't have hyper-threading or the SetAffinity parameter is set to false,
this parameter has no effect.
Default: true (bool)
SetAffinity -
If this parameter is set to true, the pool of threads will set each thread to a specific core,
according MaxPhysCore parameter. If set to false, it's leaved to the OS.
Default: true (bool)
sleep -
If this parameter is set to true, once the filter has finished one frame, the threads of the
threadpool will be suspended (instead of still running but waiting an event), and resume when
the next frame will be processed. If set to false, the threads of the threadpool are always
running and waiting for a start event even between frames.
Default: false (bool)
prefetch -
This parameter will allow to create more than one threadpool, to avoid mutual resources acces
lock/wait if "prefetch" is used in the avs script.
0 : Will set automaticaly to the prefetch value use in the script. Well... that's what i wanted
to do, but for now it's not possible for me to get this information when i need it, so, for
now, 0 will result in 1. For now, if you're using "prefetch" in your script, put the same
value on this parameter.
range -
This parameter specify the range the output video data has to comply with.
Limited range is 16-235 for Y, 16-240 for U/V. Full range is 0-255 for all planes.
Alpha channel is not affected by this paramter, it's always full range.
Values are adjusted according bit depth of course. This parameter has no effect
for float datas.
0 : Automatic mode. If video is YUV mode is limited range, if video is RGB mode is
full range, if video is greyscale (Y/Y8) mode is Y limited range.
1 : Force full range whatever the video is.
2 : Force limited Y range for greyscale video (Y/Y8), limited range for YUV video,
no effect for RGB video.
3 : Force limited U/V range for greyscale video (Y/Y8), limited range for YUV video,
no effect for RGB video.
4 : Force special camera range (16-255) for greyscale video (Y/Y8) and YUV video,
no effect for RGB video.
Default: 1
ThreadLevel -
This parameter will set the priority level of the threads created for the processing (internal
multithreading). No effect if threads=1.
1 : Idle level.
2 : Lowest level.
3 : Below level.
4 : Normal level.
5 : Above level.
6 : Highest level.
7 : Time critical level (WARNING !!! use this level at your own risk)
Default : 6
The logicalCores, MaxPhysCore, SetAffinity and sleep are parameters to specify how the pool of thread will be created and handled, allowing if necessary each people to tune according his configuration.
So, syntax is :
ResampleFunction([original parameters],int threads, bool logicalCores, bool MaxPhysCore, bool SetAffinity, bool sleep, int prefetch,int range)
==================================================================
JincResizeMT
Current version : 1.1.0
Sources are here (https://github.com/jpsdr/JincResizeMT).
Binaries are here (https://github.com/jpsdr/JincResizeMT/releases/download/1.1.0/JincResizeMT_v1_1_0.7z).
JincResizeMT(clip, int target_width, int target_height, float src_left, float src_top, float src_width, float src_height, int quant_x, int quant_y, int tap, float blur, string cplace, int threads, int opt, int initial_capacity, float initial_factor, int range, bool logicalCores, bool MaxPhysCore, bool SetAffinity, bool sleep, int prefetch, int ThreadLevel)
)
Jinc36ResizeMT/Jinc64ResizeMT/Jinc144ResizeMT/Jinc256ResizeMT(clip, int target_width, int target_height, float src_left, float src_top, float src_width, float src_height, int quant_x, int quant_y, string cplace, int threads, int range, bool logicalCores, bool MaxPhysCore, bool SetAffinity, bool sleep, int prefetch, int ThreadLevel)
)
See the ReadMe file for more informations and descriptions of the functions and their parameters.
==================================================================
Multi-threading information
CPU example case : 4 cores with hyper-threading.
If you leave all the multi-threading parameters to their default value, it's set to be "optimal" when you're not using prefetch or if you are under standard avisynth, all the logical CPU will be used.
If you put SetAffinity to true it will allocate the threads on the CPU contiguously. Physical CPU 1 will have threads (0,1), ... physical CPU 4 will have threads (6,7), allowing optimal cache use. Make test to see what's best for you.
Now, if you are using prefetch on your script, things are different !
If you're using it with the max number of CPUs (8 in our exemple case), you still can make tests, but i would strongly advise to disable the internal multi-threading by using threads=1. In this case, there is no threadpool created, and all the other multi-threading related filter parameters have no effect, even prefetch.
If you're using prefetch on your script, with less than your CPU number, you may want to try to mix the external and internal mutli-threading, setting the internal multi-threading to a lower number of threads, and setting the prefetch parameter of the filter. This parameter will set the number of internal threadpool created, the best is to match the prefetch script value. If you don't set it (leave it to 1) or set a lower value than prefetch on your script, you'll have several instances (or GetFrame) created, but they'll not be running efficiently, because each instance (or GetFrame) will spend time waiting for a threadpool to be avaible, if not enough were created.
Unfortunately, as things are now, i have no way of knowing the prefetch value used in the avisynth script at the time i need the information, this is why you have to use the prefetch parameter in the filter.
In our CPU exemple case, you can have things like :
filter(...,threads=1)
prefetch(8)
or
filter(...,threads=2,prefetch=4)
prefetch(4)
or
filter(...,threads=4,prefetch=2)
prefetch(2)
or even
filter(...,threads=3,prefetch=4)
prefetch(4)
if you want to boost and go a little over your total CPU number.
Also, if your prefetch is not higher than your number of physical cores, you can try to put SetAffinity to true, but in that case, you have to set MaxPhysCore to false. The threads of each pool will be set on CPUs by steps.
For exemple, in our case :
filter(...,threads=2,prefetch=4,SetAffinity=true,MaxPhysCore=false)
prefetch(4)
Will create 4 pool of 2 threads, with the following :
pool[0] : threads(0 -> 1) on CPU 1.
pool[1] : threads(0 -> 1) on CPU 2.
pool[2] : threads(0 -> 1) on CPU 3.
pool[3] : threads(0 -> 1) on CPU 4.
filter(...,threads=4,prefetch=2,SetAffinity=true,MaxPhysCore=false)
prefetch(2)
Will create 2 pool of 4 threads, with the following :
pool[0] : threads(0 -> 1) on CPU 1.
pool[0] : threads(2 -> 3) on CPU 2.
pool[1] : threads(0 -> 1) on CPU 3.
pool[1] : threads(2 -> 3) on CPU 4.
Negative prefetch
The possibility to put negative prefecth to tune the prefetch parameter to optimal value has been added. The filter will throw an error if the number is not high enough to avoid waiting when requesting internal threadpool. For this to work properly, you have to put negative prefetch on ALL the filters of your script, and also ALL instances of the same filter.
Exemple :
filter(...,threads=2,prefetch=-2)
prefetch(2)
You'll see an error.
But with :
filter(...,threads=2,prefetch=-3)
prefetch(2)
You'll see no error, so the optimal is :
filter(...,threads=2,prefetch=3)
prefetch(2)
Once you've tune, put back a positive value.