Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
4th August 2018, 03:59 | #4161 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Here's a build that supports Pentium III. The revision number is higher because it came from some work I'd done to make it compile a little bit more easily/cleanly with MinGW, so nothing markedly different from the latest build from pinterf (especially since I built it with MSVC 2017).
|
4th August 2018, 06:00 | #4162 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Thanks so much, this is so nice of you...
Gives me something to play with for the next couple of days. Of course I need to stick with my old MaskTools and MVTools, and this means that I also keep my older QTGMC, LSFMod and SRestore scripts because the "modernized" scripts depend on the latest PinterF versions. I am curious if I will still get some speed gains. Two questions: 1. I know that AVS+ can autoload C-Plugins. Do I have to make any changes in my autoload folder? Right now I autoload my C-Plugins with the help of an AVSI script which loads the C-Plugins. 2. Of cource my P3 Coppermine is single threaded. Would it still make any sense to add the "Prefetch" command to the end of my AVS scripts? Thanks again manolito |
4th August 2018, 07:30 | #4163 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
2. No. It would even reduce performance.
__________________
Groucho's Avisynth Stuff |
|
4th August 2018, 10:02 | #4165 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Qyot27, Top man, your efforts are always much appreciated, alas, my PIII's now all long dead.
1), I like to load C plugins via avsi (from separate sub directory of 'Plugins') as I just dont like them in my plugs (maybe in case I revert to Std for some temp reason). [I usually enable on demand just by uncommenting a line in avsi]. {just an option to consider, at least keep a copy of original avsi in a SCRIPT sub directory of your Plugins archive}
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 4th August 2018 at 10:19. |
4th August 2018, 18:15 | #4166 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
Of course there are people who take auto-loading to a new level: https://forum.doom9.org/showthread.p...94#post1844394
__________________
Groucho's Avisynth Stuff |
|
5th August 2018, 08:01 | #4167 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Just gave qyot27's Non-SSE2 version from this post
https://forum.doom9.org/showthread.p...75#post1847975 a whirl on my ancient computer, and I am impressed... To avoid any installation mistakes I installed the latest pinterf version first, then replaced the files with the ones from the qyot27 build. During installation I opted for uninstalling the old AVS version and migrate the old plugins. Worked on the first attempt. AVStoDVD issued a non-fatal warning about a wrong AviSynth version on startup, but that was it. All my standard scripts worked out of the box. I have 76 plugins in my autoload folder, and so far none of them caused a crash. BTW is there an easy method to identify ancient 2.0 C-plugins? Only my old and beloved DVDtoSVCD absolutely refused to work under AVS+. It needs AVS 2.57 anyways, I have to use Groucho's AVS switcher to make it work. Next I did a few speed comparisons. The specs of this ancient machine are: Celeron P3 Coppermine @ 1.1 GHz Non-SSE2 Single Core 576 MB system RAM Win XP SP3 32-bit The unmodified scripts ran a tiny bit slower than under AVS 2.61 Alpha (42 fps vs. 46 fps). Just for fun I then added Prefetch commands to the end of my scripts, and to my big surprise this was very stable and did not compromise speed. Even using "Prefetch(8)" caused no problems. And remember this is under a single core CPU with very low system RAM. Quite impressive... So again a big thanks to qyot27 for this build. Even if it has no advantages on my old machine it will definitely make it much easier for me to maintain my AviSynth installations on my various computers because I will only have to deal with one identical installation for all of them. Cheers manolito Last edited by manolito; 5th August 2018 at 08:10. |
5th August 2018, 08:41 | #4168 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
"AVSMeter avsinfo"
If you want to specify a custom plugin directory: "AVSMeter avsinfo -c"
__________________
Groucho's Avisynth Stuff |
5th August 2018, 08:47 | #4169 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Quote:
Although you might be able to chop something out of this (dont know how it fares under AVs+, no idea what 'not supported' means in that case). https://forum.doom9.org/showthread.p...95#post1641795 C v2.0 plugs I got (maybe not all of them) Code:
avisynth_c.dll # The loader, not C v2.0 AVSCurveFlow.dll AVSShock.dll equlines.dll IBob.dll SmartDecimate.dll Transition.dll
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? |
|
5th August 2018, 22:46 | #4170 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Good to know that it worked; when I tried moving it over to my P3 machine to test it myself, I ran into redist problems (and couldn't resolve them because the Windows Installer service on that install is screwed up something fierce), so I was flying blind a little bit.
I did, however, whip up a patch to let the SIMD level be selected during configuration. It seemed to work, since when I told it to optimize for AVX, the .dll would no longer run on this (Apollo Lake-based, only has up to SSE 4.2) computer. |
6th August 2018, 02:55 | #4171 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Now I am just curious how big the speed sacrifice using this non-SSE2 version vs. the standard version is. I still assume that the various filter plugins will be the bottleneck and not AviSynth itself...
Cheers manolito |
6th August 2018, 08:37 | #4172 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
It's not impossible you may encoder speed loss with internal core avs filters. The old version you were using had internal asm MMX optimized code. The new avs+, everything has moved to intrinsics, but i think they need at least SSE2. So, it's possible that now you have only pure code C path, instead of MMX optimized code. But i don't know exactly what qyot27 has done, so it's up to him to confirm or not what i've said.
__________________
My github. |
6th August 2018, 09:04 | #4173 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
In a non-SSE2 build MMX code is still there since it was also moved from the classic Avisynth or got rewritten to intrinsics.
New stuff (mostly for high bit-depth) was implemented in C-only at the beginnings and the SSE2 option gave quite a good optimization for these parts. Since then most of the things have hand-written SSE2/SSE4 optimization, some have AVX2. I haven't stopped or removed the C implementation, all filters and function have the C version. |
6th August 2018, 20:27 | #4175 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
All the MSVC optimization flags (/arch:SSE2 vs. /arch:SSE or /arch:IA32) do is optimize the C portions to emit SIMD instructions in the compiled binary, it's not necessary to match it with the intrinsics; the intrinsics will compile to the proper SIMD-enhanced versions with or without /arch set. GCC largely works the same way with its -march/-mtune/-mCPU flags (except that GCC's handling of branched intrinsics is a complete rat's nest).
|
6th August 2018, 22:48 | #4177 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Quote:
EDIT: Dont be a scaredy-cat David, recent versions of avs+ have had some nice speed improvements and I'm sure that r2728 crashes way faster than the old r2506 that you are using.
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 6th August 2018 at 23:25. |
|
7th August 2018, 03:26 | #4178 | Link | |
Registered User
Join Date: May 2016
Posts: 197
|
Quote:
But I know that AVSInpaint is indeed a bit buggy. I have already asked pinterf about the different behaviour of AVSInpaint on AVS+ and AVS 2.6 (after all, it might have been a bug in AVS+) and it turned out to be a bug in AVSInpaint (as expected): Code:
if (AlphaFrame) avs_release_video_frame(LogoFrame); if (LogoFrame) avs_release_video_frame(LogoFrame); I managed to compile both x86 and x64 versions of AVSInpaint; I actually did this already in May, but back then I created the necessary x64 AviSynth.lib by using avisynth.def from github and dlltool (part of MinGW64) and "dlltool -l avisynth.lib -d avisynth.def /c/Windows/System32/AviSynth.dll" from the 2664 AVS+ dll and although the resulting plugin worked, I wanted to wait for an officially released lib file (pinterf mentioned that he would add (as he has now) them to his releases) and of course I forgot about them, but your post reminded me of this. Here are the builds. Could you confirm that you don't get any more crashes with them and that they work as intended? I also think to have found a bug in AVS+. capi.h contains these lines: Code:
#ifdef MSVC #ifndef AVSC_USE_STDCALL # define AVSC_CC __cdecl #else # define AVSC_CC __stdcall #endif #else # define AVSC_CC #endif #define AVSC_INLINE static __inline #ifdef BUILDING_AVSCORE # define AVSC_EXPORT __declspec(dllexport) # define AVSC_API(ret, name) EXTERN_C AVSC_EXPORT ret AVSC_CC name #else # define AVSC_EXPORT EXTERN_C __declspec(dllexport) # ifndef AVSC_NO_DECLSPEC # define AVSC_API(ret, name) EXTERN_C __declspec(dllimport) ret AVSC_CC name # else # define AVSC_API(ret, name) typedef ret (AVSC_CC *name##_func) # endif #endif Code:
__attribute__((dllimport)) int avs_is_yv24(const AVS_VideoInfo * p); Code:
__attribute__((dllimport)) int __attribute__((__stdcall__)) avs_is_yv24(const AVS_VideoInfo * p); |
|
7th August 2018, 04:09 | #4179 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
There was a capi-related commit fairly recently messing with the dllexport/dllimport stuff, but there was no description of what it was supposed to fix. It did indeed used to compile just fine with MinGW-w64 regardless of 32-bit* and 64-bit, and I'd addressed a compatibility workaround with calling convention in my branch, but it was incredibly hackish.
*32-bit GCC builds would not work with FFmpeg, though, due to 32-bit calling conventions. That is, unless using the regressed HEAD version of the header that allows for building AviSynth+ with GCC. But then 32-bit MSVC builds won't work. That hack above was to mitigate this and default to the program still working with 32-bit MSVC builds. Last edited by qyot27; 7th August 2018 at 04:17. |
Thread Tools | Search this Thread |
Display Modes | |
|
|