AviSynth+ thread Vol.2

[DTL]

We got some random crashes at the JincResize plugin (at least in AVS 32bit) - https://forum.doom9.org/showthread.php?t=186053 . It typically happen in SIMD processing functions and looks like out of allocated memory access (0xc___5 code). Mostly happen with production release builds and hard to catch in debugger with debug build.

The SIMD processing functions are 'simple' https://github.com/Asd-g/AviSynth-Ji...e_avx2.cpp#L49 (witout scalar epilogue down to single sample at the end of line) and looks like designed to work only with enough padded lines from AVS core.

The question: Is it known the guaranteed lines padding to work with this design of processing plugins and how it can changed in different AVS (and AVS+) versions ? In the old days of SSE 128bit it can be lower (or not even desigbed to be mod of 128bits) and in the era of AVX-512 it is expected to be at least mod of 512 bit ? The more line padding waste some RAM (and the lower image width - the more RAM wasted relatively).

Also can we got a user-defined control (via some script command) of the frame buffers line padding so it can be some hint to some plugins or user-selection of some balance between RAM usage and performance or some way to increase stability of some plugins with 'unsafe' design of the frame buffer processing functions (but with some more RAM usage if set to too high padding) ?

[wonkey_monkey]

Originally Posted by pinterf

Why not frame properties?

Well, mainly because conceptually these things are not per-frame properties (you shouldn't have to get a frame, whether that's frame 0 or any other, to find them), but also because it provides, without cluttering up frame properties, a specific, simple, but very extensible method for reaching back up the filter chain for whatever reason an author might find for doing so.

E.g.: I've written a filter (as part of a suite) that allows you to specify a coordinate on a video, and has use cases where you might add 100 or more such points (each with varying properties). That doesn't seem like it would be a practical or performant use of frame properties to me (but again, maybe I'm the only one who writes such grotesque filters!). Each instance would have to read the existing properties to make sure it appended without overwriting any previous records, for example, which just seems a bit wasteful to me, especially if it's also a non-trivial actual video filter.

Instead, by talking directly to the preceding filter (which can also pass messages further up, if required), I can pass a pointer to a container and get all of those preceding filters to push their data into it. You could also use a filter to modify a preceding filter's behaviour (probably against the ethos of a filter chain, but potentially a useful trick), which you couldn't do with frame properties.

Originally Posted by DTL

So you can not simply use pointers to original frames (in most use cases).

It wouldn't be a pointer to a frame, it would be a pointer to the filter instance (or just one of its variables) which generated the clip. With that you could access its methods, which might include one that generates and returns the padded, hierarchical data, or what have you (mvtools is maybe not the best example since passing such data as frames does make some sense; but there are other cases where it's not visual data, or isn't even per-frame data).

I dunno, maybe it is a silly idea that few other people would ever have a reason to use. But - if I'm not mistaken - it would be pretty much zero-cost to implement, practically a one-liner like GenericVideoFilter::GetAudio.

[Jamaika]

I have a question about the ColorBars plugin.
http://avisynth.nl/index.php/ColorBars
string pixel_type = "RGB32"
Set color format of the returned clip.
May be any of the following: "YUY2", "YV12", "YV24" (v2.60), or (default) "RGB32".
AVS+ "RGB32", "RGB64", "YUY2", or any planar RGB, 4:2:0 or 4:4:4 format.
I use ffmpeg with avisynth 3.7.3+.
End result black screen. Is RGB32\64 supported by ffmpeg 64bit?
ColorBars(width=640, height=480, pixel_type="rgb32")

[pinterf]

Originally Posted by DTL

We got some random crashes at the JincResize plugin (at least in AVS 32bit) - https://forum.doom9.org/showthread.php?t=186053 . It typically happen in SIMD processing functions and looks like out of allocated memory access (0xc___5 code). Mostly happen with production release builds and hard to catch in debugger with debug build.

The question: Is it known the guaranteed lines padding to work with this design of processing plugins and how it can changed in different AVS (and AVS+) versions ?

Frame and scanline alignment is 64 bytes. So pitch and rowsize is guaranteed to have 64 bytes granularity.

An unaligned simd load can cause C0000005 as well. I loosely follow that topic; try replacing all _mm_load_xxxx / _mm256_load_xxx / _mm512_load _xxx to _mm_loadu versions and check if errors still occur.

[DTL]

Originally Posted by pinterf

Frame and scanline alignment is 64 bytes. So pitch and rowsize is guaranteed to have 64 bytes granularity.

Can we expect some user-side control via script to increase (change/set) alignment size ? At the AVS+ environment init at least. Also API control for plugins auto-set (if possible ?). 64 byes is ony 1 AVX512 dataword load and for some formats like float32 it takes also not much samples and sometime 128byte or 256bytes loads may make some better performance (at large frame sizes like 4K 8K) or can work as some test if running out or last line happen and crash.

Also 64bytes starte from the first AVS version or some AVS+ and also exist in latest AVS 2.60 ?

Also the second important question - the N-bytes alignment make also line stride integer number of alignment. But last line of buffer also have padding to the N-1 byte allocated and valid or not ?



Image url https://ibb.co/K5WJ8vZ

In this 3 lines frame buf example of the stride of 0x100 - we make allocation of 0x2E0 bytes (like frame 736x3 dec size) with _aligned_malloc(0x2E0, 64) . Will be the addreses up to 0x300-1 valid ? If not - the 64bytes SIMD read of the end of last line can crash ? Also SIMD write can cause memory corruption if even addresses are in same RAM page and valid for read/write.

The description of _aligned_malloc() at https://learn.microsoft.com/en-us/cp...?view=msvc-170 do not describe where located the last valid address ?

[pinterf]

Originally Posted by DTL

Can we expect some use-side control via script to increase alignment size ? 64 byes is ony 1 AVX512 dataword load and for some formats like float32 it takes also not much samples and sometime 128byte or 256bytes loads may make some better performance (at large frame sizes like 4K 8K) or can work as some test if running out or last line happen and crash.

Also 64bytes starte from the first AVS version or some AVS+ and also exist in latest AVS 2.60 ?

Also the second important question - the N-bytes alignment make also line stride integer number of alignment. But last line of buffer also have padding to the N-1 byte allocated and valid or not ?



Image url https://ibb.co/K5WJ8vZ

In this 3 lines frame buf example of the stride of 0x100 - we make allocation of 0x2E0 bytes (like frame 736x3 dec size) with _aligned_malloc(0x2E0, 64) . Will be the addreses up to 0x300-1 valid ? If not - the 64bytes SIMD read of the end of last line can crash ? Also SIMD write can cause memory corruption if even addresses are in same RAM page and valid for read/write.

64 byte alignment is documented and plugins can rely on that. Even Avisynth core is using that fact. (In a resizer and in Expr?)

Last line is safe. Originally height * aligned row_size is allocated, so it is safe to use full simd at the very end of the last line as well. Note: the last line is safe up to row_size and not pitch size. Pitch can be double of row_size for example after a SeparateFields

Avs 2.6 aligned frame buffers to 16 bytes, but the user had the opportunity to Crop to completely unaligned frame starting point.

So early plugins had to check the pointers all the time. Some history:
https://github.com/pinterf/RgTools/b...grain.cpp#L952

[DTL]

Originally Posted by pinterf

64 byte alignment is documented and plugins can rely on that. Even Avisynth core is using that fact. (In a resizer and in Expr?)

Last line is safe. Originally height * aligned row_size is allocated, so it is safe to use full simd at the very end of the last line as well. Note: the last line is safe up to row_size and not pitch size.

Avs 2.6 aligned frame buffers to 16 bytes,

It is nice to have this in documentation so the plugins developers can put to documentation note about minimum required AVS(+) version.

As for _aligned_malloc(size, alignment) WinAPI - I think because the 'alignment' may be very high and API do not knows anything about internal treatment of allocated area - no any safe addresses exist after aligned_address+size ? And user must calculate size to allocate with space for last SIMD read/write size ?

[pinterf]

Originally Posted by DTL

It is nice to have this in documentation so the plugins developers can put to documentation note about minimum required AVS(+) version.

As for _aligned_malloc(size, alignment) WinAPI - I think because the 'alignment' may be very high and API do not knows anything about internal treatment of allocated area - no any safe addresses exist after aligned_address+size ? And user must calculate size to allocate with space for last SIMD read/write size ?

Alignment parameter is only for the beginning address. The size can be anything the user want.

[DTL]

Originally Posted by pinterf

Alignment parameter is only for the beginning address. The size can be anything the user want.

The main question was "Are there any valid/safe to read/write addresses exist after aligned_address+size ?". If the 'alignment' param is unlimited and can be very large like 4MBytes - it is mostly probably no.

Practically some non-crashable addresses may last till the end of typical 4KBytes RAM page after aligned_address+size. But if start address changes - the crash will happen. So it is the way to have random crashes at different runs.

[pinterf]

Originally Posted by DTL

The main question was "Are there any valid/safe to read/write addresses exist after aligned_address+size ?". If the 'alignment' param is unlimited and can be very large like 4MBytes - it is mostly probably no.

https://en.cppreference.com/w/c/memory/aligned_alloc
theoretically the size must be multiple of alignment. It may fail - or not.

[pinterf]

Originally Posted by wonkey_monkey

...
instead, by talking directly to the preceding filter (which can also pass messages further up, if required), I can pass a pointer to a container and get all of those preceding filters to push their data into it. You could also use a filter to modify a preceding filter's behaviour (probably against the ethos of a filter chain, but potentially a useful trick), which you couldn't do with frame properties.

It wouldn't be a pointer to a frame, it would be a pointer to the filter instance (or just one of its variables) which generated the clip. With that you could access its methods, which might include one that generates and returns the padded, hierarchical data, or what have you (mvtools is maybe not the best example since passing such data as frames does make some sense; but there are other cases where it's not visual data, or isn't even per-frame data).

I dunno, maybe it is a silly idea that few other people would ever have a reason to use. But - if I'm not mistaken - it would be pretty much zero-cost to implement, practically a one-liner like GenericVideoFilter::GetAudio.

Your ideas are never silly. You are one of the rare Avisynth developers who create *new* plugins and ideas. (Unlike me, who is just a plugin maintainer/fixer/enhancer).

So you'd like to create a wormhole or a message queue between filter instances?

[wonkey_monkey]

Originally Posted by pinterf

So you'd like to create a wormhole or a message queue between filter instances?

Pretty much, but the details can be left to authors as long as they can pass an AVSValue upward. In that way it's complementary to frame properties, which propagate downward.

I'm not too clear on exactly what's required to do this but I'm guessing IClip needs to handle a base case and maybe return a void AVSValue, while GenericVideoFilter's override will pass the value up to the parent (sorry, child! )

Could it be as simple as:

AVSValue IClip::ReceiveMessage(AVSValue input) { return AVSValue(); }

AVSValue GenericVideoFilter::ReceiveMessage(AVSValue input) { return child->ReceiveMessage(input); }

?

Or to go really barebones:

void IClip::ReceiveMessage(void* input) { }

void GenericVideoFilter::ReceiveMessage(void* input) { child->ReceiveMessage(input); }

and let authors figure everything else out for themselves!

[LigH]

Originally Posted by Jamaika

I have a question about the ColorBars plugin.

ColorBars is a core filter, not a loadable plugin DLL.

There are several possible FourCC's for 32-bit RGB in AVI. But I guess ffmpeg will use an internal video format identifier instead when using an internal AviSynth demultiplexer...

Originally Posted by Jamaika

I use ffmpeg with avisynth 3.7.3+.

The current documentation is in the AviSynth+ Docs. I hope you can find more details there.

[Jamaika]

Originally Posted by LigH

ColorBars is a core filter, not a loadable plugin DLL.

There are several possible FourCC's for 32-bit RGB in AVI. But I guess ffmpeg will use an internal video format identifier instead when using an internal AviSynth demultiplexer...

Thank you for your answer. I was surprised by the creators' answer.
When we enter RGB32, only the alpha channel is displayed.
To unlock the rest, use the function RGBAdjust(ab=255)

And one more thing contrary to wiki documentation. No RGB is supported using KNLMeansCL. And everything is clear.
What isn't clear to Jamaika. Does OpenCL support Intel processors without graphics card? It is about the CPU option.

[LigH]

In general, OpenCL is an abstraction library for complex calculations. It does not require GPGPU support per se, it can be implemented in CPU SIMD instructions too. But it usually gains a lot of efficiency from massive parallelism in GPGPU's.

PS: Who do you mean by "the creator"?!

[Jamaika]

Originally Posted by LigH

In general, OpenCL is an abstraction library for complex calculations. It does not require GPGPU support per se, it can be implemented in CPU SIMD instructions too. But it usually gains a lot of efficiency from massive parallelism in GPGPU's.

I have an inactive CPU for Intel. How do I set the BIOS? What drivers should I install for Intel i5-13600K?

Originally Posted by LigH

PS: Who do you mean by "the creator"?!

https://github.com/pinterf/KNLMeansCL/pull/9

[LigH]

Originally Posted by Jamaika

I have an inactive CPU for Intel. How do I set the BIOS? What drivers should I install for Intel i5-13600K?

I don't think you need to set any special option in the BIOS, as a CPU-only OpenCL driver would just use CPU instructions available for every application.

I do not have any intel CPU. So I can only guess that Intel® CPU Runtime for OpenCL™ Applications with SYCL support might be the one you are interested in; no warranties.

[Jamaika]

Thanks LigH. I thought it was impossible. I was convinced that OpenCL was overriding Windows. I also don't see an option to connect openCL GPU and CPU although press wrote about it some time ago. For x264 it's always GPU.It even works. Is OpenCL needed today when there is CUDA?
Intel processor without graphics card:
https://ibb.co/fHQCsbv

[LigH]

Originally Posted by Jamaika

Is OpenCL needed today when there is CUDA?

I remember that Universe Sandbox is not able to use CUDA because it only supports single precision calculations. It works well with OpenCL.

[tormento]

Originally Posted by Jamaika

No RGB is supported using KNLMeansCL.

Dunno your needs but for noise reduction BM3D is vastly superior, even if lot heavier and unfortunately it needs CPU for the temporal part.