AviSynth+ thread Vol.2

[kedautinh12]

Thanks

[Groucho2004]

Avisynth+ 3.6.2.-test5 (20201208) (https://drive.google.com/uc?export=download&id=1qQT_VV5wnuCTfClcJ57-eUO0NATHR2KD)
I added this build to the Universal Installer. Should be handy to switch between versions for testing.

[StainlessS]

Thankyou P & G.

[Fjord]

This is a bug, because this AverageX family is not checked against format mismatch errors. ... it will ... cause memory overread --> exception. If not, it's only pure luck.

Thanks. Oops. I had "luck" with AverageR and AverageG, so I "forgot" that it didn't make sense to calculate R, G & B stats on a YUV clip in the first place. :rolleyes:
I will convert YUV to RGB [ConvertToPlanarRGB()] before using AverageR/G/B.

[LigH]

Thankyou P & G.

Procter & Gamble?! :p

[StainlessS]

Parental & Guidance, or Propylene & Glycol (as opposed to V & G).

[gispos]

Avisynth+ 3.6.2.-test5 (20201208) (https://drive.google.com/uc?export=download&id=1qQT_VV5wnuCTfClcJ57-eUO0NATHR2KD)

20201208 3.6.2-test5
-----------------------
- Resizers: throw error on too small dimensions vs. taps
- Add ShowCRC32 debug filter. Parameters are the same as in ShowFrameNumber
- Overlay: allow 4:1:1 input
- Overlay: fix crash when mask is YUV411 and greymask=false
- Overlay: may work quicker, most input/overlay/mask/output clip format conversions moved to filter constructor
- RemoveAlphaPlane: do nothing on YUY2 instead of throwing an error message
- AviSource: support non-printing characters in fourCC code: allow [number] style, e.g. G3[0][16]
- AviSource: add Y410 (YUVA444P10) format support. Allow 'Y410' pixel_type hints.
- AviSource: decode b64a, b48r, v210, P210, P010, P016, P216, v410, Y416, r210, R10k, v308, v408, Y410 fourCCs natively.
- Fix: Average...: check for valid colorspace (e.g. no AverageB for a YUV clip)
- Add: AverageA
- New: Average...: allow YUY2, RGB24/32/48/64 inputs

20201112 3.6.2-test4
--------------------
- Fix: Overlay: Actual frame of a mask clip would be freed up too early in MT environment
- Fix: ConvertBits to ignore dither parameter instead of throwing error, in a 8 to 8 bit case


Can't open an avisynth script with AviSource. What has changed?

https://i.postimg.cc/W1dHsFJL/Avi-Source-Error.jpg (https://postimages.org/)

[StainlessS]

Can't open an avisynth script with AviSource. What has changed?
https://i.postimg.cc/W1dHsFJL/Avi-Source-Error.jpg (https://postimages.org/)

Confirmed.
Worked OK in all + versions [prior to 3.6.2 test 5] in latest Groucho2004 Universal Avisynth Installer whotsit.

Import() works as it should though, was quite a surprise to me when I originally found that
AviSource loaded Avs scripts, so I'm no longer surprised any more :)

[pinterf]

Confirmed.
Worked OK in all + versions [prior to 3.6.2 test 5] in latest Groucho2004 Universal Avisynth Installer whotsit.

Import() works as it should though, was quite a surprise to me when I originally found that
AviSource loaded Avs scripts, so I'm no longer surprised any more :)
Checking...

[pinterf]

Checking...
oops, poor old formats like YV24 were forgotten in test5, fix is on the way

[pinterf]

New build.
Avisynth+ 3.6.2 test6 (20201210) (https://drive.google.com/uc?export=download&id=1ZdSd_TAPRmdkFGerLaIrDVrsIE8pUBGx)

20201210 3.6.2-test6
-----------------------
- AviSource: fix test5 regression which refused handling old formats like YV24

20201208 3.6.2-test5
-----------------------
- Resizers: throw error on too small dimensions vs. taps
- Add ShowCRC32 debug filter. Parameters are the same as in ShowFrameNumber
- Overlay: allow 4:1:1 input
- Overlay: fix crash when mask is YUV411 and greymask=false
- Overlay: may work quicker, most input/overlay/mask/output clip format conversions moved to filter constructor
- RemoveAlphaPlane: do nothing on YUY2 instead of throwing an error message
- AviSource: support non-printing characters in fourCC code: allow [number] style, e.g. G3[0][16]
- AviSource: add Y410 (YUVA444P10) format support. Allow 'Y410' pixel_type hints.
- AviSource: decode b64a, b48r, v210, P210, P010, P016, P216, v410, Y416, r210, R10k, v308, v408, Y410 fourCCs natively.
- Fix: Average...: check for valid colorspace (e.g. no AverageB for a YUV clip)
- Add: AverageA
- New: Average...: allow YUY2, RGB24/32/48/64 inputs

20201112 3.6.2-test4
--------------------
- Fix: Overlay: Actual frame of a mask clip would be freed up too early in MT environment
- Fix: ConvertBits to ignore dither parameter instead of throwing error, in a 8 to 8 bit case

[kedautinh12]

Thanks

[StainlessS]

Yo da' man, tanks :)

[Soulvomit]

@Soulvomit, Sorry, I should have suggested that.you can try another source filter like ffms2 or lsmashThanks, friends. ffms2 did it. :)

[Ceppo]

I was thinking it would be nice to have a block-based TemporalSoften to have an MDegrain with no motion search. Also the sum of square difference would be nice.

[qyot27]

AviSynth+ 3.7.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases)

Haiku support
PowerPC support
Support for building the core as a static library (mcmtroffaes)
Fixes for MinGW-w64 compilation
Shibatch, TimeStretch, and ImageSeq GCC build support
Shibatch, TimeStretch, and ImageSeq non-Windows support
Fix: AddBorders did not pass frame properties
Fix: propSet, propDelete and propClearAll not to ruin visibility of variables
(property read functions are still kept being runtime only)
AviSource: fix test5 regression which refused handling old formats like YV24
Resizers: throw error on too small dimensions vs. taps
Add ShowCRC32 debug filter. Parameters are the same as in ShowFrameNumber
Overlay: allow 4:1:1 input
Overlay: fix crash when mask is YUV411 and greymask=false
Overlay: may work quicker, most input/overlay/mask/output clip format conversions moved to filter constructor
RemoveAlphaPlane: do nothing on YUY2 instead of throwing an error message
AviSource: support non-printing characters in fourCC code: allow [number] style, e.g. G3[0][16]
AviSource: add Y410 (YUVA444P10) format support. Allow 'Y410' pixel_type hints.
AviSource: decode b64a, b48r, v210, P210, P010, P016, P216, v410, Y416, r210, R10k, v308, v408, Y410 fourCCs natively.
Fix: Average...: check for valid colorspace (e.g. no AverageB for a YUV clip)
Add: AverageA
New: Average...: allow YUY2, RGB24/32/48/64 inputs
Fix: Overlay: Actual frame of a mask clip would be freed up too early in MT environment
Fix: ConvertBits to ignore dither parameter instead of throwing error, in a 8 to 8 bit case
Fix: GeneralConvolution missing internal rounding on 8-16 bit formats
support for Win10 long file path option
project: Improve inclusion of the ghc filesystem helper library
project: Add a GitHub action workflow
posix: fix crash when autoloading imports
internally refactored ConvertAudio
ConvertBits(8): fix dither=1 (floyd) for RGB48/RGB64
Fix: Blur right side garbage: 16 bit+AVX2+non mod32 width
Fix: check fn signature with implicite "last" first (3.6 regression)
Fix: function parameters provided as arrays (e.g. GrunT callback of WriteFileIf)
Fix: ConvertBits (YUV): proper rounding when bit depth is reduced and origin is 10-16 bits
(added rounder before bit-shift)
New: Histogram("color2") to support 10+ bits.
Allow bits=x (x=8,9,10,11,12) parameter for this kind of histogram as well.

Due to the addition of support for Haiku, PowerPC, and building the core as a static library, the version needed to be bumped. Otherwise, you can consider this equivalent to a final release of 3.6.2, as those things largely don't affect Windows (although another big part of this was fixing up MinGW-w64/GCC build support).

[StainlessS]

Awesome, thanks very much you guys, you're the best.

[pinterf]

Happy New Release! Thank you, qyot27.

[manolito]

AviSynth+ 3.7.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases)
Otherwise, you can consider this equivalent to a final release of 3.6.2, as those things largely don't affect Windows

Does this mean that there are no real differences or fixes compared to the latest pinterf 3.6.2 test 6 version?

Since I am Windows only do I loose anything if I stick to the latest pinterf test 6 version?

[qyot27]

There were a couple fixes related to passing around frame properties and SSE2, and fixing a segfault-on-exit issue with SSRC (although that *might* have only affected Linux in the first place). Most of the rest after test 6 was various build system tweaks/cleanup and the non-Windows features.

[r0lZ]

Good job ! Huge thanks !

[Losko]

Great release, THANK YOU :thanks:

[wonkey_monkey]

[list] Haiku support


Oh, Haiku support?
I have no clue what that is
But it sounds clever

[ChaosKing]

It's the open source version of BeOS https://en.wikipedia.org/wiki/BeOS

[FranceBB]

There were a couple fixes related to passing around frame properties and SSE2, and fixing a segfault-on-exit issue with SSRC (although that *might* have only affected Linux in the first place). Most of the rest after test 6 was various build system tweaks/cleanup and the non-Windows features.

Got it. I'll update from Test 6 to the stable release anyway, just to make sure. :)

New: Histogram("color2") to support 10+ bits.

And by the way, thank for this!! :D

[ryrynz]

It's the open source version of BeOS https://en.wikipedia.org/wiki/BeOS

That was a Haiku, I was going to do something similar with StainlessS's post but it took too long to make something good so I didn't :P

[Boulder]

FranceBB has an interesting point here: https://forum.doom9.org/showthread.php?p=1933580#post1933580.

How should one handle chroma location? In UHD sources, it's type 2 but in Avisynth, you handle it as type 1 as far as I've understood. The question is: can something be done about it in Avisynth, and if not, should one tell the encoder that the source actually is type 1?

Disclaimer: I'm blind enough to never have noticed the issue. I do recall some earlier discussion regarding issues with red colour and x265 encodes, but I think it never really came to any conclusion.

[FranceBB]

I think ffms2 and Lwlibav convert the chroma location from Type2 to the old MPEG-2 version, so from:


X X
X X


(where the Chroma sample sits right on top of the top left Luma sample)

to


X X
c
X X


(where X is Luma and "c" is Chroma)

therefore, specifying --chromaloc 2 is wrong if your input is an Avisynth Script.
Ever since I began encoding with x265 years ago, I used FFmpeg to open the AVS Script, convert the chroma location back to Type 2 and then pipe to x265 to encode the video like so:


ffmpeg.exe -i "AVS Script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe --y4m -



Still, I'd love to see Avisynth and its plugin be able to support the "new" chroma location, just like it happened with the MPEG-1 variant and the MPEG-2 variant.
If you think about this, though, so far plugins generally assumed that the chroma location is MPEG-2 and you have to manually specify if it's MPEG-1 as they don't get it automatically, wouldn't it be better to somehow make the indexer pass this information through so that plugins will be aware of this? I know that someone has to be aware of his own source, but still, prevention is better than cure (TL;DR sometimes it's better to babysit the users a bit).

[poisondeathray]

avsresize has chromaloc_op, so you change from one to another


- chromaloc_op (default left):
```
"left" ("mpeg2") (0),
"center" ("jpeg", "mpeg1") (1),
"top_left" (2),
"top" (3),
"bottom_left" (4),
"bottom" (5)

Format is" `"[locS]=>[locD]"`
Example JPEG to MPEG2: `"center=>left"`

[qyot27]

I think ffms2 and Lwlibav convert the chroma location from Type2 to the old MPEG-2 version, so from:


X X
X X


(where the Chroma sample sits right on top of the top left Luma sample)

to


X X
c
X X


(where X is Luma and "c" is Chroma)

therefore, specifying --chromaloc 2 is wrong if your input is an Avisynth Script.
Ever since I began encoding with x265 years ago, I used FFmpeg to open the AVS Script, convert the chroma location back to Type 2 and then pipe to x265 to encode the video like so:


ffmpeg.exe -i "AVS Script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe --y4m -



Still, I'd love to see Avisynth and its plugin be able to support the "new" chroma location, just like it happened with the MPEG-1 variant and the MPEG-2 variant.
If you think about this, though, so far plugins generally assumed that the chroma location is MPEG-2 and you have to manually specify if it's MPEG-1 as they don't get it automatically, wouldn't it be better to somehow make the indexer pass this information through so that plugins will be aware of this? I know that someone has to be aware of his own source, but still, prevention is better than cure (TL;DR sometimes it's better to babysit the users a bit).

Would that be this?
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/include/avisynth.h#L745

That's been there a loooooong time; way back during the 2.6 alphas. But I can't seem to find a part of the callable API that can query it (unless that's what PlanarChromaAlignment is in avisynth.cpp, but that seems like just a placeholder). It's not there at all in avisynth_c.h/avisynth_c.cpp.

Finding and fleshing out stuff like that probably should be a priority for the next API bump. I've started a discussion on Github about it, as a brainstorming/tracker of API stuff to consider:
https://github.com/AviSynth/AviSynthPlus/discussions/206

[Boulder]

avsresize has chromaloc_op, so you change from one to another


- chromaloc_op (default left):
```
"left" ("mpeg2") (0),
"center" ("jpeg", "mpeg1") (1),
"top_left" (2),
"top" (3),
"bottom_left" (4),
"bottom" (5)

Format is" `"[locS]=>[locD]"`
Example JPEG to MPEG2: `"center=>left"`

Thank you, I didn't remember avsresize at all :)

So it basically means that I should use z_ConvertFormat(chromaloc_op="top_left=>mpeg2") right after loading the source with DGSource and z_ConvertFormat(chromaloc_op="mpeg2=>top_left") at the end of the filtering chain? I could change the parameter in x265 but I think it's safer to use the value that is considered standard.

[StvG]

I think ffms2 and Lwlibav convert the chroma location from Type2 to the old MPEG-2 version, so from:...
Source filters doesn't change the chroma location. They are aware of the different chroma locations (ffmpeg is aware of).

Thank you, I didn't remember avsresize at all :)

So it basically means that I should use z_ConvertFormat(chromaloc_op="top_left=>mpeg2") right after loading the source with DGSource and z_ConvertFormat(chromaloc_op="mpeg2=>top_left") at the end of the filtering chain? I could change the parameter in x265 but I think it's safer to use the value that is considered standard.
If you're using filters that doesn't recognize chroma location top_left you can use what you wrote.
If you're using filters that are aware of chroma location top_left (I currently know only avsresize with frame properties) then you can omit these conversions.

[Kogarou]

Does avs+ 3.7 have support for the CUDA filters made for the nekopanda fork? I noticed some of the fork's code got merged into mainline avs+ almost a year ago, yet it seems it doesn't work at all.
As one guy said before:
So I was experimenting with the CUDA version of Avisynth+ which was merged into the main Avisynth+ branch. It seems that it results in a memory leak. While using MeGUI, it gets stuck on the pre-processing phase, then the memory usage goes through the roof (99% RAM usage with 16 GB installed) before the app locks up.

(...)

The same script run under the Nekopanda version of Avisynth (r2827) is able to run just fine. The memory usage was around 1 GB or so on average.

IIRC I tried to do the same thing under 3.6.1, with the same result as this guy. Is there anything that needs to be changed for these scripts to run, or is the merge still a WIP? :(

[pinterf]

Does avs+ 3.7 have support for the CUDA filters made for the nekopanda fork? I noticed some of the fork's code got merged into mainline avs+ almost a year ago, yet it seems it doesn't work at all.
As one guy said before:


IIRC I tried to do the same thing under 3.6.1, with the same result as this guy. Is there anything that needs to be changed for these scripts to run, or is the merge still a WIP? :(
Present Avisynth+ does not support CUDA. Since the existance of nekopanda fork was hidden (at least for me) for years, the two source base went apart and were different enough that even the integration of multithreading changes took me more than a month. Changes were so widespread that finally I was not able to import the fixes alone but I had to pull almost everything.
All I could do that I did not ruin and did not omit the existing CUDA parts from the source when I was porting back multithreading fixes and the new language elements (e.g. functions objects) from nekopanda fork.
So the code is there (I hope). But CUDA option is not enabled. I was trying to keep them behind #ifdef ENABLE_CUDA, thus never tested.
Nekopanda fork has special Avisynth interface. Avisynth+ interface was heavily changed on my side as well. Those cuda-special plugins would require complete rebuild after the necessary source changes (interface usage) as well.

EDIT: i was able to build Avisynth+ with the CUDA option, but it is only a necessary prequisite. I had a look at the supporting filters (https://github.com/nekopanda/AviSynthCUDAFilters) as well. Sources must be updated. Rebuild was not a straightforward task, starting with the easiest problem that since 2018 CUDA SDK stepped to 11.2 from 8.0, and of course using again the "classic" avisynth+ headers. Still there are filters with build errors which I'm gonna fix later this week, just for curiosity.

[patul]

Wow pinterf, you never cease to amaze me, I wish I have a small fraction of your skills, curiosity, adaptability and the ability to read other people's code with ease.. I was a programmer myself during my younger days, but no where near the required level even just to understand the code.

Thank you for keep doing what you do best.

[pinterf]

I have encountered a serious obstacle.
On my main PC I have no NVidia CUDA, only an Intel HD630. My other PC has a historical hardware. Processor-wise it is an Intel i7-860 which would be O.K. but the video card is a GeForce GTX460 which is simply too old. NVidia do not make new drivers for it, End Of Life was 2018. The latest CUDA SDK which can produce code for GTX460 is version 9.1. (now NVidia have v11.2). But unfortunately CUDA 9.1 SDK is incompatible with VS2019, neither could I make it work with a VS2017 (consistent 0xC0000005 during the build process). So this project and my curiousity is stopped here, since I do not want to invest into a GT 1030 level card which I think is a minimum even for this fun project. The other choice I was consireding was a GT 730 since it is a bit cheaper - but still over my budget - I dropped the idea since it is slower than my old 9 years old card.

[wonkey_monkey]

Any consideration for OpenCL? Open standard, supported on more hardware, supported by Nvidia via CUDA...

[pinterf]

Any consideration for OpenCL? Open standard, supported on more hardware, supported by Nvidia via CUDA...
No-no. I just want to look at what Nekopanda created some years ago. And as a side effect, to look into another new technology.

[StainlessS]

2nd user NVidia might be worth consideration.
Here a bunch o' guys I use all the time.
[Known in the UK as CEX, branches in several other countries, site domain Webuy.com ] https://uk.webuy.com/search?stext=NVidia&sortBy=sellprice&sortOrder=asc
Many of those are Out-Of-Stock, but give and idea of what might be out there and the gelt involved.
You can click on (RHS) In Stock Online, AND In Stock In Store - to see what is currently available.
EDIT: Above sorted in ascending order by price.

There are other Used Part sellers too of course.

Or maybe someone has a 'spare card' gathering dust.

[FranceBB]

Ask the community? I'm sure someone must have a spare old NVIDIA card somewhere to give you and I'm sure they'll be happy to give it to you if we're gonna have CUDA support.
I do have an old card with CUDA, but it's buried somewhere at my parents place, so more than 160 miles from where I live and I'm not planning to get there anytime soon considering that we're still in the middle of a pandemic.
Anyway, I'm sure there's gonna be someone with an NVIDIA card willing to help you (and therefore the entire community) out.
I mean, people give gamers those kind of things for silly stuff, so they might give you, the last real Avisynth developer, a card for these far more serious stuff!

[StainlessS]

I hear that there is a pretty good postal service in Deutschland, if only you knew where it was. [EDIT: The card, not Deutschland]

[pinterf]

Haha, or I'm gonna ask my son for his 1660Super OC. University tasks, Fortnite and Ethereum mining can wait :) I bought him a PC with this card in October, video card prices have almost doubled since then.
EDIT 1030 is on the way.

[FranceBB]

I hear that there is a pretty good postal service in Deutschland, if only you knew where it was. [EDIT: The card, not Deutschland]

The conversation would be like:

"Mum, do you know where the GPU of my old computer is?"

- What is a GPU?

And that would be the deal breaker xD

Haha, or I'm gonna ask my son for his 1660Super OC. University tasks, Fortnite and Ethereum mining can wait :)

"University tasks"... suuuuure... That's how I used to get my parents buying me stuff back in the days hahahaha
Sadly, it doesn't work anymore since I'm a "grown man with a job who lives on his own and should buy things himself" xD

Still, with a living legend as Ferenc as a father, I wonder why that young lad isn't interested in encoding... :(


1030 is on the way.

:D yay, we're gonna have CUDA!!

https://media1.tenor.com/images/7bafc4dc0036792b32a5e5aa6c5ac9ff/tenor.gif?itemid=7241283

[StainlessS]

yay, we're gonna have CUDA!!

"It ain't necessarily so ...":- https://www.youtube.com/watch?v=vMYM75JFrIY

No-no. I just want to look at what Nekopanda created some years ago. And as a side effect, to look into another new technology.

[pinterf]

Still, with a living legend as Ferenc as a father, I wonder why that young lad isn't interested in encoding... :(

Oh, there are hundreds of similarly interesting topics at Computer Science Engineering. Two of them are studying there. I wish I were young again, now the only thing I was able to help in was C/C++ (but finally I was lost there as well :) )

[feisty2]

now the only thing I was able to help in was C/C++


you may help with introductory programming language theory if you know C++ reasonably well. C++'s type system is powerful enough to express all 3 extensions to the simply typed lambda calculus on the lambda cube. It even allows you to play with some undecidable problems like type inference for polymorphic recursive functions since the type system itself is Turing complete.

[feisty2]

I wonder why that young lad isn't interested in encoding...

because writing video processing scripts is not a terminal interest. The initial interest in stuff like avisynth shifts over time, that's how curiosity works, once you get the hang of something, your interest moves on to a more fundamental topic cuz you wanna know how things work under the hood, you wanna know why. this process won't stop until your interest reaches the boundary of human knowledge.

in the case of avisynth, there're many possible paths how your interest may evolve. one may wonder why applying a certain avisynth filter produces certain "effects" -> image processing algorithms -> low level computer vision -> applied machine learning / information theory -> theoretical machine learning / information geometry -> … and the chain goes on. you may have obtained a PhD in a seemingly unrelated field long before your interest stabilizes.

[pinterf]

The biggest difference between me and the youngs that they learn things on courses, in didactic units. I follow a heuristic method of learning, only random fragments of the actual problem are reaching me. I'm solving these problems after seeing examples which I'm trying to understand with more or less success.

Having this new GT1030 toy made the progress a bit quicker than having no CUDA at all :) I have made Nekopanda's CUDA things work with my actual Avisynth+ (work in progress). KTGMC is 4 timer quicker than the similarly parameterized QTGMC, though their output is not identical. Note that KTGMC is not a replacement for QTGMC, it has much less working parameters. So stay tuned.

[FranceBB]

in the case of avisynth, there're many possible paths how your interest may evolve. one may wonder why applying a certain avisynth filter produces certain "effects" -> image processing algorithms -> low level computer vision -> applied machine learning / information theory -> theoretical machine learning / information geometry -> … and the chain goes on. you may have obtained a PhD in a seemingly unrelated field long before your interest stabilizes.

True. In my case, Avisynth led me to understand more of what was behind encoding, so working in the frequency domain, working with transforms, so Z-Transform, Laplace Transform, Fourier Transform, Discrete Cosine Transform, Wavelet Transform, Hadamard Transform, Karnhunen-Loeve Transform etc. The more I knew about this world, the more I wanted to know, so my passion shifted from merely applying filters in Avisynth to Linear Algebra to Control Systems to Digital Signal Processing, but always related to encoding. I mean, in the end, it's my day-by-day job, it's my passion and it's what I wanted to do when I began studying at university and what I'm still doing (and what I plan to keep doing in the future). I'm still doing a master degree in Computer Science Engineering while I'm working for Sky (in Europe, unlike in the U.S, you don't "pick" master degree vs PhD, you first get the master degree, THEN you get your PhD) and I'm studying lots of unrelated things which are indeed interesting and might turn out to be useful, but that I never thought I would have been studying. I mean, I'm never going to use Verilog or VHDL or design rugged devices, directly control FPGAs etc. I mean, it was interesting, but not what I wanted to see and study...


Having this new GT1030 toy made the progress a bit quicker than having no CUDA at all :) I have made Nekopanda's CUDA things work with my actual Avisynth+ (work in progress). KTGMC is 4 timer quicker than the similarly parameterized QTGMC, though their output is not identical. Note that KTGMC is not a replacement for QTGMC, it has much less working parameters. So stay tuned.

That's really cool! :D

[tormento]

so more than 160 miles from where I live
When a european man uses imperial units, a CUDA core of his video card core dies. :p