64 bit avisynth?

[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]

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.


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.


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 (http://forum.doom9.org/showthread.php?s=&threadid=38296) has version 1.1b available but I can only find source code for 1.1a. Anyone have it?

[Prettz]

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.

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

Edit: FluxSmooth thread (http://forum.doom9.org/showthread.php?s=&threadid=38296) 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]

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: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]

Edit: FluxSmooth thread (http://forum.doom9.org/showthread.php?s=&threadid=38296) 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]

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?

[Humbula]

Is there a new version of avisynth for x64 yet?

See my post. Prezz said squid_80 compiled a "new" one...

[bestsoft666]

There was a workaround too to force the optimizations anyway and then AMD performed very well indeed.

[Rodger]

So is there a 64bit build/realease to download and test?

[squid_80]

http://www.members.optusnet.com.au/squid_80
Unless someone else has done their own work, that's as recent as it gets.

[Rodger]

How do I "replace" the 32bit version with the files included in ZIP-file.

Is there a how to?

[BiOSsCZ]

Please help :

http://img231.imageshack.us/img231/3525/vd64de3.png

[Adub]

Did you even read your own error message? It is pretty self explanatory.

[squid_80]

The 64-bit version of DGDecode is based on 1.4.8 (or possibly 1.4.6). You have to use that version of DGIndex to create the .d2v.

[BiOSsCZ]

The 64-bit version of DGDecode is based on 1.4.8 (or possibly 1.4.6). You have to use that version of DGIndex to create the .d2v.

I have version 1.4.6.0
Where this version find? Thank you. (1.4.8)

[squid_80]

Actually it is based on 1.4.6. The .d2v file should start with "DGIndexProjectFile13".

[BiOSsCZ]

Actually it is based on 1.4.6. The .d2v file should start with "DGIndexProjectFile13".

I am not from USA, too I don't understand..
Please send last version DGDecode64.dll

THX

[squid_80]

http://members.optusnet.com.au/squid_80/DGDecode64.zip

[kemuri-_9]

since x264 does not currently have feasibly usable x64 windows version,
for those using x64 avisynth, it would be necessary to pipe to x86 x264 using an avs2yuv x64 version which i have built:
avs2yuv_x64.exe (http://kemuri9.net/dev/avs2yuv/avs2yuv_x64.exe)