64 bit avisynth?

[squid_80]

http://avisynth2.cvs.sourceforge.net...rev=Avisynth64

Avisynth.h lives under \core.
I haven't been able to work on the main code for a long time.

[XBoy]

Originally Posted by squid_80

http://avisynth2.cvs.sourceforge.net...rev=Avisynth64

Avisynth.h lives under \core.
I haven't been able to work on the main code for a long time.

Any plans to port the MT plugin over to 64bit?

My AMD X2 3800+ can't keep up

[Prettz]

squid_80: Thanks so much for taking the time to compile all this stuff for us! I have no idea how long it takes you to recompile someone else's project, but I'm wondering if you plan to do the latest version of DGDecode (1.4.9), since the version on your site is 1.4.6? I'm only asking because I'd like to take advantage of the improvements in DGIndex 1.4.9 in the near future.

Also, for what it's worth, here's some filters that I always use. Not meaning to sound demanding, just putting these out there as suggestions for when you've got time to recompile more filters:
FluxSmooth
Unfilter
RemoveGrain (it's got an SSE3 implementation with a mode that's meant to replace Undot)
MSharpen

I really wish I could help you out with recompiling old stuff to 64-bit, but the best compiler I've got on my computer is the first version of VS .NET. It's probably of no use for making optimized 64-bit builds.

[IanB]

The big drawback with the 64 bit implementations is you have to loose all the inline assembler code. Many filters don't have C or C++ versions of their algorithm, and for those that do they are usually orders of magnitude slower than the inline assembler version.

Ask Squid, it is anything but trivial to port inline assember into a form usable in the 64 bit environment. Inline assemblers greatest attraction is you can write all the use once frilly code in C++ then you get to do raw inner meat in assembler complete with still being able to reference all the C++ variables.

Remember MMX code is already 64bit and SSE2 is 128bit. Porting the frilly code to 64 bit effectivly gains you nothing. Note! I am not saying writing fresh in 64bit gains you nothing, hell for a start you get twice as many registers, I am just saying porting to 64 bit is a pain.

Blame Micro$oft they chose to remove the inline assembler feature from their 64bit compiler.

[squid_80]

Intel's compiler does support inline assembly, that's how I was able to do tdeint, masktools, clouded's motion.dll and awarpsharp in quick succession (although awarpsharp took extra work since it has no source code!). Unfortunately my version is old and won't integrate with VS2005 so I have to do everything from the command line.
After 2.6 gets released I planned to do a proper build of the core with all built-in functions included using ICC. I know it's not nice having code that can only be compiled by a certain (expensive) compiler but I consider that MS's fault, not mine.

[XBoy]

What about using custom build rules to integrate into VS2005 similar to how YASM integrates?

also, could you put mt_masktools and fft3dfilter on your list to do? (It's for my vista media center http://www.avsforum.com/avs-vb/showthread.php?t=719041)



BTW, you know when's 2.6 coming out?

[squid_80]

I don't really see the point having a 64-bit media center. (I don't see the point of 64-bit vista full-stop.)

[Leak]

Originally Posted by squid_80

I don't really see the point having a 64-bit media center. (I don't see the point of 64-bit vista full-stop.)

While I agree with you on the media center bit, the latter has a point as soon as you slap 4 or more GB of RAM into a machine.

Or did you mean that Windows XP 64bit still exists as an upgrade choice for Vista 64bit?

np: Autechre - IO (Quaristice)

[squid_80]

Originally Posted by Leak

Or did you mean that Windows XP 64bit still exists as an upgrade choice for Vista 64bit?

That's what I meant - if you're going to use >4gb ram and want faster speed, it's stupid to use an OS that's a memory hog and runs slower than it's predecessor.

[XBoy]

Originally Posted by squid_80

That's what I meant - if you're going to use >4gb ram and want faster speed, it's stupid to use an OS that's a memory hog and runs slower than it's predecessor.

I got more than 4gb of ram

anyhow...


One question, does 32bit vista running on a 64bit processor allow 64bit data manipulation, or is it moot since optimized code would usually just use the MMX/SSEx (64/128bit) registers?

[squid_80]

It's mainly moot (ok that sounds odd) because SIMD (single instruction multiple data i.e MMX/SSE) code can already do 64/128 bits processing, but:
- 64-bit mode has 8 more SSE registers
- 64-bit mode has 8 more general purpose registers which can be helpful in SIMD loops which use many pointers/counters
- for x32 non-SIMD code, 64bit data manipulation is still possible (with C/C++ at least, using the __int64 type) but two 32-bit registers are used. Typically this means 2-3 times as many instructions as the same operation performed in 64-bit mode.
Also because the general purpose registers are larger it's possible to do tricks like horizontal adding via multiply that weren't possible before.

[Prettz]

Originally Posted by IanB

The big drawback with the 64 bit implementations is you have to loose all the inline assembler code. Many filters don't have C or C++ versions of their algorithm, and for those that do they are usually orders of magnitude slower than the inline assembler version.

Ask Squid, it is anything but trivial to port inline assember into a form usable in the 64 bit environment. Inline assemblers greatest attraction is you can write all the use once frilly code in C++ then you get to do raw inner meat in assembler complete with still being able to reference all the C++ variables.

Oh I know. I've looked at a lot of the avisynth code before (pre-SoftWire at least), and have a decent amount of experience doing inline assembler with VC++ 6.0.

Originally Posted by IanB

Remember MMX code is already 64bit and SSE2 is 128bit. Porting the frilly code to 64 bit effectivly gains you nothing. Note! I am not saying writing fresh in 64bit gains you nothing, hell for a start you get twice as many registers, I am just saying porting to 64 bit is a pain.

But to use 64-bit you need all the .dlls used to be 64-bit, right? So since every script I've ever written uses FluxSmooth, I'm stuck with 32-bit everything right now.

Originally Posted by IanB

Blame Micro$oft they chose to remove the inline assembler feature from their 64bit compiler.

Did they ever give an official explanation on why they did this?

[squid_80]

I will do fluxsmooth if you promise to give me feedback on whether it works properly or not.

Edit: FluxSmooth thread has version 1.1b available but I can only find source code for 1.1a. Anyone have it?

[Prettz]

Originally Posted by IanB

The big drawback with the 64 bit implementations is you have to loose all the inline assembler code. Many filters don't have C or C++ versions of their algorithm, and for those that do they are usually orders of magnitude slower than the inline assembler version.

I just occurred to me to ask: are you sure about this? I had read long, long ago that Intel made their C++ compiler specifically to be compatible with VC++, and I assume their agreement continues to this day. Ignoring the practical question of "can you afford buying Intel's compiler?", isn't it technically still possible to compile C++ code with inline assembly (assuming you convert the assembly code to its 64-bit equivalent manually)? I assume squid doesn't have any version of Intel's compiler, but I'm asking this just generally.

The assembly won't take advantage of the added registers, sure, but it's a hell of a lot better than nothing; since the asm algorithms using MMX/SSE tend to already do things impossible through C/C++ code without using VC/ICL-specific mnemonics.

Originally Posted by squid_80

I will do fluxsmooth if you promise to give me feedback on whether it works properly or not.

Edit: FluxSmooth thread has version 1.1b available but I can only find source code for 1.1a. Anyone have it?

I only just got my Vista 64-bit box up and running and my first overclocking experience is going poorly. But I'll try.

[squid_80]

Originally Posted by Prettz

I just occurred to me to ask: are you sure about this? I had read long, long ago that Intel made their C++ compiler specifically to be compatible with VC++, and I assume their agreement continues to this day. Ignoring the practical question of "can you afford buying Intel's compiler?", isn't it technically still possible to compile C++ code with inline assembly (assuming you convert the assembly code to its 64-bit equivalent manually)? I assume squid doesn't have any version of Intel's compiler, but I'm asking this just generally.

I think you missed my post from a bit higher up:

Originally Posted by squid_80

Intel's compiler does support inline assembly, that's how I was able to do tdeint, masktools, clouded's motion.dll and awarpsharp in quick succession (although awarpsharp took extra work since it has no source code!). Unfortunately my version is old and won't integrate with VS2005 so I have to do everything from the command line.

[Rodger]

Just to let you know...

since there is no localization for WinXP 64bit it is a big pain for non-english version users to work with it.
A lot of directories are different and some software even denies installation on those "MUI"-Versions.

WinXP 32bit is a damn great OS, I know.
But WinXP64bit is no alternative to Vista64bit! And as much as I can tell....vista runs surprisingly round and smooth on my system.

[Klipper]

Originally Posted by squid_80

Edit: FluxSmooth thread has version 1.1b available but I can only find source code for 1.1a. Anyone have it?

You can find it here -> http://bengal.missouri.edu/~kes25c/FluxSmooth-1.1b.zip w/ source

[Humbula]

Originally Posted by Prettz

squid_80: Thanks so much for taking the time to compile all this stuff for us!

Where can I find the new 64 bit version? And is it v2.5.7?

[XBoy]

Is there a new version of avisynth for x64 yet?

[XBoy]

I'm trying to compile the version here: http://avisynth2.cvs.sourceforge.net...rev=Avisynth64

but I'm running into some missing links:

avisynth.obj : error LNK2001: unresolved external symbol "struct AVSFunction * Levels_filters" (?Levels_filters@@3PAUAVSFunction@@A)

Where are these?

Also, where's the directshow dll portion?