pinterf
commented
1 year ago The place you found is not where the allocation rules are ensured. It just allocates the given number of bytes (and a bit more for partly debug ('deadbeef', but yes, the +16 bytes are there in non-debug builds for some reason) and cuda ('margin') reasons)
Avisynth plus aligns pitch and frame pointers at 64 byte boundaries. I changed this at the very beginning of my involvement in the project.
This is done by setting a frame_align to 64 from FRAME_ALIGN, which is defined as 64 in avisynth.h.
When Nekopanda (in Neo branch) fixed a lot of MT issues and introduced the possibility of a CUDA-only pipeline, then it was changed not to be constant, at least not for a non-CPU device. The 'frame_align' and 'plane_align' variables were introduced then. Allocation rules for CUDA are different, 64 bytes alignment may be too much.
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/avisynth.cpp#L2346
The actual alignment in a video frame, setting the beginning offset and the pitches are all done in NewVideoFrame https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/avisynth.cpp#L3576 or https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/avisynth.cpp#L3636
DTL2020
Currently CPUDevice->Allocat() uses simple new method of memory allocation.
It is https://github.com/AviSynth/AviSynthPlus/blob/45404659f0fed07e369978924efd417221bdc782/avs_core/core/DeviceManager.cpp#L180
(If I found this place correctly - the Asd-g tell current AVS provide upto AVX512 64-bytes aligned start addresses for each row ?)
It is not guaranteed to be SIMD aligned for SSE/AVX/AVX512 ? But also it is not guaranteed to be safe for long-tr temporal processing filters with many sequential frames parallel access for reading. If the reading addresses will overload number of ways in cache set it will lost performance significantly. Typical number of ways in cache sets of L1 is about 8 so with tr>4 in some large-tr temporal filter may cause already possible performance penalty. The example of bad allocation start address is 4-KBytes page-aligned allocations.
2 possible solutions exist:
Fast but poorer in non-supervision controllable memory allocation - allocate more RAM in some number of cachelines max and add random offset of cacheline sized to each start address. It not require tracking of all used start address offsets but can hit same used addresses because random number generator can return equal numbers. Also some address space is poorerly used (maybe more RAM waisted). It is solution used in large-page mod - https://github.com/DTL2020/AviSynthPlus-LP-mod/blob/62d7c268f279d4f6917b323e6806082847603b67/DeviceManager.cpp#L198
Make some global class in AVS core to watch for the sequential frames starting addresses allocations and simply advance with cacheline size each next frame starting address allocation and reset addition value to zero after all required addresses are used (the total max offset can be calculated from current CPU cache params like number of ways and cache size and cacheline size). So all sequential frames in AVS environment will have guaranteed offset to hit different cache sets and the probability of performance penalty for large-tr temporal filters will be probably removed completely.
This hardware-limit issue also described in Intel Software Optimization manual: 3.6.7 Capacity Limits and Aliasing in Caches There are cases in which addresses with a given stride will compete for some resource in the memory hierarchy. Typically, caches are implemented to have multiple ways of set associativity, with each way consisting of multiple sets of cache lines (or sectors in some cases). Multiple memory references that compete for the same set of each way in a cache can cause a capacity issue. There are aliasing conditions that apply to specific microarchitectures. Note that first-level cache lines are 64 bytes. Thus, the least significant 6 bits are not considered in alias comparisons. 3.6.7.1 Aliasing Cases in the Pentium® M, Intel® Core™ Solo, Intel® Core™ Duo and Intel® Core™ 2 Duo Processors Pentium M, Intel Core Solo, Intel Core Duo and Intel Core 2 Duo processors have the following aliasing case: • Store forwarding — If a store to an address is followed by a load from the same address, the load will not proceed until the store data is available. If a store is followed by a load and their addresses differ by a multiple of 4 KBytes, the load stalls until the store operation completes. Assembly/Compiler Coding Rule 49. (H impact, M generality) Avoid having a store followed by a non-dependent load with addresses that differ by a multiple of 4 KBytes. Also, lay out data or order computation to avoid having cache lines that have linear addresses that are a multiple of 64 KBytes apart in the same working set. Avoid having more than 4 cache lines that are some multiple of 2 KBytes apart in the same first-level cache working set, and avoid having more than 8 cache lines that are some multiple of 4 KBytes apart in the same first-level cache working set. When declaring multiple arrays that are referenced with the same index and are each a multiple of 64 KBytes (as can happen with STRUCT_OF_ARRAY data layouts), pad them to avoid declaring them contiguously. Padding can be accomplished by either intervening declarations of other variables or by artificially increasing the dimension. User/Source Coding Rule 8. (H impact, ML generality) Consider using a special memory allocation library with address offset capability to avoid aliasing. One way to implement a memory allocator to avoid aliasing is to allocate more than enough space and pad. For example, allocate structures that are 68 KB instead of 64 KBytes to avoid the 64-KByte aliasing, or have the allocator pad and return random offsets that are a multiple of 128 Bytes (the size of a cache line). User/Source Coding Rule 9. (M impact, M generality) When padding variable declarations to avoid aliasing, the greatest benefit comes from avoiding aliasing on second-level cache lines, suggesting an offset of 128 bytes or more. 4-KByte memory aliasing occurs when the code accesses two different memory locations with a 4-KByte offset between them. The 4-KByte aliasing situation can manifest in a memory copy routine where the addresses of the source buffer and destination buffer maintain a constant offset and the constant offset happens to be a multiple of the byte increment from one iteration to the next.