SEt's Avisynth 2.5.8 MT compiled for *X86_64*, Latest Build 4/16/2010

[aegisofrime]

Hi,


thread title says x86_64 so can i assume that it works on 32 bit versions of avisynth as well. can anyone confirm please.

Thanks,

Nope, it doesn't. You can't mix 64-bit filters with 32-bit filters, AFAIK.

[osgZach]

I did a clean download last night and grabbed everything again. To make sure I had all the recent updates.

Did a test last night.. Took 2h:37m. And no crash. LEt's hope it stays that way :p

The problem did not appear to be source access either, I think it was something like Trim or Decimate.. I'm guessing trim. I set Mode 3 after TGMC



LoadPlugin("C:\yatta\plugins64\decomb.dll")
LoadPlugin("C:\yatta\plugins64\dgdecode.dll")
LoadPlugin("C:\yatta\plugins64\telecidehints.dll")
LoadPlugin("C:\yatta\plugins64\fieldhint.dll")


function Preset0(clip c) {
#Name: Default
c
return last
}
SetMTMode(2,0)
DGDecode_Mpeg2Source("L:\Ep 01\VTS_01_1.d2v")



FieldHint(ovr="L:\Ep 01\VTS_01_1.d2v.fh.txt")

#MT("TempGaussMC_beta2().SelectEven()",threads=2,overlap=4)
TempGaussMC_beta2().SelectEven()
SetMTMode(3)

PresetClip0=Preset0()

PresetClip0.Trim(0,41023)


DClip = Decimate(cycle=5,quality=3,ovr="L:\Ep 01\VTS_01_1.d2v.dec.txt").assumefps(last.framerate)

[squid_80]

Are you perhaps confusing SSSE3 instructions with SSE3? I think you'll find the pmulhrsw instructions are the issue.

[levi]

Xeon quad core E5530 2.40 ghz w/ turbo(hyperthreading)

x264(x86) + set avisynth 2.6(x86)
First Pass Output to null = 27.18

x264(x64) + JoshyD avisynth 3-13-10(x64)
First Pass Output to null = 29.54

I've seen an 8% speed improvement


SetMTmode(3,3)
mpeg2source("my.d2v")
SetMTmode(2,3)
tdeint()
crop(4,4,1916,1076)
LanczosResize(1280,720)

[JoshyD]

@Squid_80
You've got it. It's pshufb that throws the first error on my (really old) Athlon64. Then, those pmulrhrw's probably cause an issue as well. Reading some programming message boards, apparently pshufb has been giving AMD developers trouble. I'd guess the subtleties between SSE3 and SSSE3 do as well. Back to the drawing board for AMD people. Thanks for taking a look, being the only eyes looking over your source can drive a person a bit crazy.

@levi
Why only 3 threads? Are you accounting for x264 also taking up some cores? I think x264's defaults to creating 1.5x the amount of threads it detects your system can run. I was hoping for some more speed gains. Any chance on seeing some straight single threading tests on the same system? I want to re-build tdeint to see if I can't eek out some more performance as well.

@osgZach
It's great that there aren't any crashes anymore! I don't think trimming frames from a source should kill multithreading, but decimate has an unusual access pattern. I guess you can't win them all.

[osgZach]

Crap keyboard.. lost my post to ill-place Forward/Backward keys...

Anyway. Its technically 2 different sources being mixed in, so whatever the case the problem probably lies somewhere in there, with one or both of them.. I know Mode 3 was recommended for Trim at the very least.

Any chance of grabbing the latest DGindex/decode source (1.5.8) and seeing if it will compile for x64? I'd give it a shot but if it needed changes I'd be clueless about that stuff..

It would certainly make managing Yatta a lot easier (right now I have to setup two copies, using older x86 source to make projects, since the x64 DLL we have is only 1.4.6).
If anyone that has time could look into it for that matter, it'd be great.

[squid_80]

I just had a look on my HDD and it seems at some point I did make an x64 build of DGDecode 1.5.4: http://www.mediafire.com/?dl4fc2yyyzz

It seems to work but I have no idea if it's faster than the old build or if anything apart from the .d2v identifier was changed. Too bad the author has no regard for backwards compatibility.

[noee]

FWIW, just did a test with an SD MPEG2 source, encoding with x264, using the 3/13 AVISynth64:

AVS:
#LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\DGDecode.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\tivtc.dll")
SetMTmode(2,8)
Mpeg2Source("lotr.d2v")
#Insert Deinterlacer
tfm(last,d2v="lotr.d2v").tdecimate()
#Applying Resizing
LanczosResize(720,352,0,62,-0,-66)

x264 v1471
64: x264-64bit.exe --crf 20 --preset medium --threads auto --tune film --sar 32:27 --output "C:\Temp\lotr64.mkv" lotr64.avs
32: x264.exe --crf 20 --preset medium --threads auto --tune film --sar 32:27 --output "C:\Temp\lotr.mkv" lotr.avs

64bit chain: encoded 16356 frames, 79.40 fps, 1345.89 kb/s
32bit chain: encoded 16356 frames, 70.57 fps, 1345.89 kb/s

Using Athlon II (620) O/C'd to 3.5Ghz
Win7 Ult x64

[osgZach]

Thanks Squid, I suppose its better than nothing :D

I don't have any issues with using old versions, as long as nothing major has changed since then.. But when I open the D2V files from two different versions and they look different it kind of makes me nervous I'm not getting the best indexing of my source.

[JoshyD]

@noee
I'm guessing this means that you've gotten tivtc with working results? If so, that's great news. Those results seem about in line with expected. Somewhere between 10-20% faster when using x64 code.

@Squid80
You've got a DGDecode listed on your webpage along with source, but checking the version info indicates it's 1.4.6. Any chance you have the 1.5.6 source on hand and I could take a peek at it? Also, may I add that to the first post?

@kemuri-_9
Can I link your FFMS2.dll on the first post? I can move it over to mediafire if you don't want to waste bandwidth on hosting it locally.

@turbojet
Autocrop is built and working for me. Link is on the first post.

[osgZach]

@noee

@Squid80
You've got a DGDecode listed on your webpage along with source, but checking the version info indicates it's 1.4.6. Any chance you have the 1.5.6 source on hand and I could take a peek at it? Also, may I add that to the first post?





DGIndex/Decode/VFAPI sources are all available at Neuron2's web site. Which was why I was surprised there were no newer x64 compiles..

http://neuron2.net/dgmpgdec/dgmpgdec.html

Also some other things we may not have can probably be found here.

http://www.neuron2.net/mine.html

[levi]

@levi
Why only 3 threads? Are you accounting for x264 also taking up some cores? I think x264's defaults to creating 1.5x the amount of threads it detects your system can run. I was hoping for some more speed gains. Any chance on seeing some straight single threading tests on the same system? I want to re-build tdeint to see if I can't eek out some more performance as well.

3 MT threads plus letting x264 do what it wants usually gives me the best performance.

I tested single threaded as you requested - it gives same 7-8% increase.

tdeint is pretty slow. As was mentioned, leakkerneldeint is a much faster one. I would much rather see you give that one a go vs. trying to get further performance gains with tdeint.

@Squid80
thanks for dgdecode 1.5.4 x64

[noee]

I'm guessing this means that you've gotten tivtc with working results? If so, that's great news.

Yes, I've reviewed the results and it appears to be correct. I'll run a couple of more tests a little later today.

[kemuri-_9]

@kemuri-_9
Can I link your FFMS2.dll on the first post? I can move it over to mediafire if you don't want to waste bandwidth on hosting it locally.

sure, you can post it in the first post and leave it how it is on referencing my website (i'm totally not concerned about the bandwidth for the server it's on)
I'll generally be updating it as bug reports come in, so it would be helpful for me to update it directly.

[JoshyD]

tdeint is pretty slow. As was mentioned, leakkerneldeint is a much faster one. I would much rather see you give that one a go vs. trying to get further performance gains with tdeint.


Did a quick and dirty port of LeakKernelDeint, link is on the main page. Nice to have it for use in avisynth64, but it's hardly speed limited to begin with. This version should be at least as fast as the 32bit plugin.

[levi]

Another note, this build has the same flaw as Set's previous builds - If I turn hyper-threading off in the bios (therefore only using my 4 xeon cores) the same test (with your 64bit build) gives 31 fps - which is another 5% faster & completely counter-intuitive. It's a mystery that was never solved.

----------------------------------------------------------

much better performance with LeakKernelDeint port.

Xeon quad core E5530 2.40 ghz w/ no hyperthreading

x264(x86) w/ 5 threads + set avisynth 2.6(x86)
First Pass Output to null = 57.4

x264(x64) w/ 5 threads + JoshyD avisynth 3-13-10(x64)
First Pass Output to null = 63.5

I've seen an 10% speed improvement


SetMTmode(3,2)
mpeg2source("my.d2v")
SetMTmode(2,2)
ord = last.getparity() ? 1 : 0
LeakKernelDeint(ord,sharp=true)
crop(4,4,1916,1076)

LanczosResize(1280,720)

[JoshyD]

Alright, I've gotten a DgDecode 1.5.8 built and running correctly on my system. It will only decode with SSE2 or SKALSSE algorithms for now, I'll work on getting the others back. Link is on the main page. It's not exactly x64 optimized, but at least it's the latest build.

[squid_80]

I'm not sure where the source code for my 1.5.4 build is. I didn't even know I had it.

The problem with DGDecode (the reason why I didn't compile new versions for x64) is that to get maximum speed, I found I had to hand compile some source files with ICC and others with VS - that's why I said it's possible the 1.5.4 build is slower than the older 1.4.8. Run some benchmarks if you want to check the difference. Also the source code only comes as a .zip file, there is no CVS/SVN/Git that allows for easy merging of files so updating it is tiresome.

[levi]

FYI - CelticDruid has some 64 bit - multithreaded xvid builds @ http://esby.free.fr/CelticDruid/mirror/XviD/

1.2.0 CVS (http://esby.free.fr/CelticDruid/mirror/XviD/XviD64-setup.exe)

1.3.0 CVS (http://esby.free.fr/CelticDruid/mirror/XviD/XviD64-setup.exe.1)

[MuLTiTaSK]

http://www.xvidvideo.ru/xvid-video-codec/

[levi]

http://www.xvidvideo.ru/xvid-video-codec/

Sweet, :thanks:

JoshyD

Think I found a bug...

LanczosResize(576,320) causes crash on Veedub64 open. LanczosResize(1280,720) works fine :eek:

[aegisofrime]

Thanks for the DGDecode JoshyD! Now all we need is nnedi2 and my DVD deinterlacing toolchain is complete...

JoshyD: I finally got around to testing it on my Phenom II rig. Upon starting the script with x264 I get this error:

http://img123.imageshack.us/img123/2696/67910090.jpg

Here's my script if it matters:

loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\DirectShowSource.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\EEDI2.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\MT.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\mt_masktools25.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\mvtools2.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\RemoveGrain.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\Repair.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\FFT3dGPU.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\DGDecode.dll")
loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\VerticalCleaner.dll")
import("C:\Program Files (x86)\AviSynth 2.5\plugins\TempGaussMC_beta2.avsi")
import("C:\Program Files (x86)\AviSynth 2.5\plugins\LimitedSharpenFaster.avs")

SetMTMode(2,4)
DGDecode_mpeg2source("D:\Raws\Test.d2v")
/*TempGaussMC_Alpha3(2, 1, 1, EdiMode="EEDI2")
crop( 0, 0, 0, -2)
Spline36Resize(720,480)

Distributor()

MT("LSFMod()")*/

As you can see, I have commented out everything but the source filter, to isolate the source of the error. It still persists with this.

[osgZach]

I'm not sure where the source code for my 1.5.4 build is. I didn't even know I had it.

The problem with DGDecode (the reason why I didn't compile new versions for x64) is that to get maximum speed, I found I had to hand compile some source files with ICC and others with VS - that's why I said it's possible the 1.5.4 build is slower than the older 1.4.8. Run some benchmarks if you want to check the difference. Also the source code only comes as a .zip file, there is no CVS/SVN/Git that allows for easy merging of files so updating it is tiresome.

I definitely noticed a big difference in speed after switching to the newer one.. I haven't tried the 1.5.8 compile yet (because I use reference for iDCT) but Squid's original older version is a hell of a lot faster..

The same script actually runs SLOWER than single threaded 1.5.8 in 32 bit.. I thought I broke something on my system when I started seeing the clock go up to 4... 5 hours. But I had to go to bed so I just let it run and when I woke up later and checked on it, it had frozen after hitting the 6,000 frame range.

Which was weird, the program was NOT hard locked or anything, the status window was just frozen.. nothing updating, etc.. But abord worked and the program was responding, etc..

Kind of makes me feel bad for bugging you guys for a more updated build now that I see its going to take a lot of manual hands on work to get it running decently. That plus I have to throw out 37 d2v's from 1.5.8 to go down to 1.4.6 based build, then had to throw those out to go to 1.5.6 or w/e the newer one he did was. heh.. Of course the real time-killer is redoing the metrics off of them in Yatta.. that takes a good 10 minutes or so for each one I think.. adds up to a few hours or something like that.

Looking at the readme for the one hosted on Squid's page it seems like it only does iDCT through SSE2 also ? It didn't complain so I figured all the modes were there, but was just curious HOW important a difference there is between the various iDCT modes.. I always use references cause I figured why not, its fast enough and is supposed to be the most "accurate".. But I really don't know what iDCT is about either, so.. just wondering.

Update
I've been giving the 1.5.8 compile a try and it looks pretty solid from what I can tell. It seems to have about the same performance as the previous 1.4.6 based compile by Squid80. The ETA is pretty stable below the 3 hour mark (goes up and down, currently 2h:35m) and I used SSE2 32-bit on the iDCT. This is the same script I posted back as working / non crashing under the 1.4.6 based version, so hopefully this one won't crash either. Averaging about 3.5fps according to rough math estimates ( (8500 frames / 40m) / 60s ) FPS meter runs anywhere between 2 to 5 fps.

Very good performance I think.

[JoshyD]

@levi
I think there you did find a bug, I've done a quick fix for it, one I should have done a while ago. Can you try the latest DLL from the first post and see if that still crashes out? If so, some clip info may be in order so I can fix it properly.

@aegisofrime
One or more of those plugins was compiled with open mp enabled, and then statically linked. The error basically means more than one binary in your chain tried to initialize the library, which is discouraged. I don't think x264 uses OpenMP, I know my avisynth does in places, but the latest plugins shouldn't. Hence, there shouldn't be any errors. I've been known to be a bit inconsistent on my compile environments, but I thought I killed off open mp support in all the latest builds. I'll double check this, but could you get the latest build of each plugin as well to see if it still errors?

The option is out there to require the OpenMP dll be in your system32 directory, and then not statically link to it when building. I just haven't done this to reduce the headaches of installing another version of avisynth.

I'm guessing it'll throw errors on the resizing still, but that remains to be seen. I'm still working on an SSE3 only version of vertical resize function.

@osgZach
What's the final speed verdict on the 1.5.8 compile? Is it slower than the 32bit build? If that's the case, bummer. Squid80 mentions hand compiling the sources with different compilers, and that sounds gross. I'd like to avoid this, but I want DgDecode working as fast or faster in the 64bit environment.



To everyone and anyone:
A general question to those in the know about OSS, is everything I'm doing legal under the GPLv2? I've been kicking around the idea of hosting the source code somewhere (SourceForge, Google Code) and wanted to make sure this was alright with a) the community at large and b) the license under which Avisynth was released under.

I've also been wanting to set up a (poorly done) website somewhere for documentation and filter linking that doesn't rely on the main page of this thread. Additionally, I'd like to create a "swiss army knife" archive of the most useful plugins for single click downloading. Also, I think a real installer would be useful to many people, especially those hesitant that 64bit Avisynth will break 32bit Avisynth functionality.

Feedback, as always, is much appreciated.

[Stephen R. Savage]

You are technically in violation of GPL, since you do not host the modified AMD64-compatible source code (for the plugins) or provide a written offer for it.

[osgZach]

I haven't done exclusive testing of 32 vs 64-bit. However my guesstimation is that currently it should be at least as fast or very close.

I only started seeing these 2-1/2 hour encode times once I began using MT anyway. Under x32 it was 4h:45m and looked to be around 3-1/2 or 4h under x64 single threaded.

I know that's not a kosher analysis but you'll just have to trust me that at the very least, I find 1.5.8_x64 to be well within acceptable performance. It pretty much matches previous 1.4.6_x64 times so I think that's as good an indicator as any.


As for GPL issues.. Avisynths source code is freely available right? I think other modded editions have been let loose here too as well. As long as you provide the source and credits, release under GPL with your own updates, I don't think there should be an issue? Just got to get it taken care of. Currently I don't think anyone cares that much about technicalities, as you seem to have good intentions here. Just got to make sure future releases in an "official" type way that you follow the GPL rules.

I'm sure experienced members like the various utility authors here can help you understand any GPL questions and make sure everything is in order.

If you need hosting, I may be willing to donate some space and a pretty web page for you, and if the bandwidth is only a couple GB a month that should be fine.. If bandwidth becomes an issue you could just make a project on Sourceforge and keep everything distributed under there? Link to it from the pretty web page ;)

[JoshyD]

@Stephen
A written offer on the downloads page will suffice in lieu of packing up all the sources immediately and getting them hosted somewhere? Packing the sources for ~15 plugins isn't hard either, it's just a matter of linking them all somewhere, preferably not muddying up the first post.
Side note: some of the source is just plain embarrassing to have others look over. When I started porting, I couldn't write assembly AT ALL. I understood most of it, but comparing my earlier coding "style" (style=non-existant) to the macros and such I have now, there's significant difference. The more recent code at least looks halfway competent.

@osgZach
I may have to take you up on the offer of a pretty webpage! My mediafire download stats have the binary being downloaded just north of 500 times since I posted the original about a month ago. Granted, those are not all unique downloads, but at least there's been some interest in the port. I wonder if interest will continue? I don't see anything preventing me from merging x64 changes into 2.6 once it sees the light of day, either. At any rate, I'd like to generate better documentation, an installer, you know, kind of round out the port a bit. One step at a time, for now, GPL compliance, because, hey, open source software is pretty awesome.

[osgZach]

Cool.. I will try to find some time within the next day or two, to do a fast and dirty mockup for a prospective site for you.

500 downloads isn't much as it is.. I don't think I've ever broken 50gb of usage in a single month, with my magazine and other randomly downloaded stuff I host sometimes. So I don't anticipate a huge problem.

[squid_80]

Back when I started avisynth64, Wilbert and IanB set up a branch for me to use in avisynth's CVS on sourceforge. Unfortunately I never got very far for various reasons (sorry!). But maybe they would let you take it over if you asked them.

[JoshyD]

Could anyone with an AMD processor test this version of avisynth64 (http://www.mediafire.com/?ynzzjzqzitj) and let me know if the vertical resize functionality is restored?

[turbojet]

Could anyone with an AMD processor test this version of avisynth64 (http://www.mediafire.com/?oyzmikdgxu1) and let me know if the vertical resize functionality is restored?

It works. 57.46 fps on that same source from last week so it's right up there with 2.6-x86 with very fast x264 settings when resizing to 1280x720. When slower settings are used x64 is 10-15% faster also true when not resizing and using very fast settings.

Thanks for autocrop and leakkerneldeint 99% of the time avisynth64 will be my choice the only exception being repal but maybe mvtools with newer srestore will work in those cases.

It looks like x64 is by far the more popular windows 7 version according to steam (http://arstechnica.com/microsoft/news/2010/02/windows-7-eclipses-vista-on-steam-64-bit-dominating-32-bit.ars) so hopefully x64 encoding is here to stay. A few years ago when squid_80 was working on avisynth64 xp x64 was and still is incompatible with many applications, vista was disliked by many. Also there wasn't many x64 encoding applications, virtualdub64 I think was just coming along, no x264_x64. So let's hope for a better turnout this time. 64 bit directshow filters I think were non-existent then as well, except maybe ffdshow64 which doesn't do much good without a 64 bit splitter. Windows 8 is rumored to not be available in x86 but then again windows 7 had the same rumor.

[osgZach]

FYI

I got that weird lockup problem again.. It happened on the 3rd job in the queue. This time I at least got a message out of it.. It said something along the lines of "Something appears to be stuck (thread deadlock) while trying to abort" and asked me if I just wanted to kill everything.

I'm assuming it's not Vdub itself since the program was otherwise responsive and interact-able.

[noee]

Could anyone with an AMD processor test this version of avisynth64 (http://www.mediafire.com/?oyzmikdgxu1) and let me know if the vertical resize functionality is restored?

No joy here. Athlon II x4 620.

I get choppy, stuttery playback. I'm resizing (cropping) a FullHD source, here's the .AVS:

SetMTMode(2,4)
#Source File
directshowsource("c:\output\Law Abiding Citizen.mkv",audio=false)
last = isRGB(last) ? ConvertToYV12(last) : last
last = isYUY2(last) ? ConvertToYV12(last) : last
#SetMTMode(2,8)
#Spline36Resize(1920,800,0,140,-0,-140)
Lanczos4Resize(1280,528,0,140,-0,-140)
#RemoveGrain(mode=2)
trim(0,7500)
distributor()

[turbojet]

I can confirm noee's issue and isolated it to SetMTMode(2). It appears the frames are delivered out of order and some frames break up. However it doesn't happen in every scene. Modes 5 and 6 are working okay. Modes 1,3,4 freeze x264 with mpeg2source or directshowsource only.

Also modes 2 and 6 have randomly rebooted my machine which is like noee's an athlon X4 620@3.5 ghz. This might be caused by avisynth64 but I wouldn't rule out the multiple runs of ffdshow64, coreavc2 or dgdecode.

I don't use setmtmode or mt unless I'm doing heavy filtering which is almost never so I don't know if the reboots and freezes of certain modes are typical. With a 'light' script like noee's you lose about 50% of the speed with setmtmode/mt.

LeakKernelDeint works as expected but about 3% slower than x86
DGDecode 1.58 works okay too but is 10-15% slower for me then x86, optimized for intel only?
TIVTC and autocrop works okay and roughly the same speed as x86

[noee]

With the "AMD only" version, I can't even get an encode to run without using SetMTMode(). If I comment it out in the above script, the encode just sits there doing nothing. Every now and then x264.exe will pop 1-2% CPU, but it just sits there for hours doing nothing.

[osgZach]

*scratches head*.. This is really starting to throw me for a loop.

Despite my previous success reports. It appears optimizations on Dgdecode 1.5.8 are indeed going to be needed. I restarted my queue this morning and came home to find the same file still encoding. It was around 4:45m for completion, as if it were running a non-MT x32 setup. Despite the previous encodes only taking the average 2:40m or so..

The next file in the queue started and I was seeing 4 - 5 hour completion ETA.. I played around with the MT settings in the script and I still could not get it to go higher than 2.5 ~ FPS range. I regrabbed DG Index 1.4.6, re-indexed the same file, redid the yatta project, and set the script to the exact same settings. It started off in the 3 hour range but now it has dropped to currently 2h:40m range.. The FPS does go up and down, but in general seems to stay in the 3 - 4fps range.

So currently, it seems Dgdecode 1.4.6 is still the best optimized version to use ? I really need more corroboration on this one though. Can anyone else verify a performance gap through comparing multiple sources? I am prediction when this encode finished, it will have only taken about 2:45m or less. Or very close.

Core 2 Duo 2.13Ghz @ 3.2Ghz
8GB DDR2
Windows 7 x64

[JoshyD]

@noee
Bizarre on the needing to set the MT mode to get it to run. That really shouldn't be happening. I'll look at the code a while, and see if anything pops out as just plain "wrong." Though, you don't need to call distributor at the end of the script. It's automatically called internally when using a valid MT mode. Also, placing that trim command directly after the source is created will stop the MT mode of avisynth from beginning to render frames outside your region of interest.

@osgZach
Thread deadlock = not good. I think it's time to remove some parallelism from my build and see if I can kill off the deadlock condition.

Overall, at least there's some resize functionality restored, still not to the point I'd like to see it though. I'll continue to wade through the code to see if I can get a flawless version of all the crucial functions that works for everyone.

In the meantime, could either of you try this updated AMD compatible binary (http://www.mediafire.com/?zlxnjjgntny) to see if it alleviates some of your cache and thread woes?

@squid80
Any chance you remember the problem sources when compiling 1.5.6? I'm willing to do it by hand, a nudge in the right direction would do be much appreciated.

[osgZach]

Might want to go off 1.4.6 as that seems to be the best one, and I think Squid said 1.5.6 would likely have performance issues. I would think it better to start with the modified source of the faster performing version?

But that's just my uninformed opinion.. I have to go back to VB 2008 for Dummies now :p

[JoshyD]

@osgZach
Funny thing is, I started with the 1.4.6 source and used WinMerge to selectively merge in changes from the 1.5.8 source that shouldn't have effected x64 compatibility. DgDecode 1.5.8 isn't optimimized for a specific architecture, we could be seeing performance loss because some of the inline asm remains hard coded for best use with 32bith processors. This means we don't get to use any extra registers available to us and there are some idiosyncrasies that arise when writing x64 assembler. Some instructions take longer to complete because of internal handling by the processor. The often used


inc regA
or
dec regA


should almost always be replaced with


add regA, 1
or
sub regA, 1


Somewhere in the Intel docs it mentions that the register dec or inc operates on automatically gets promoted to it's 64bit version, meaning a 64bit add vs a 32 bit add. These instructions usually crop up in loop counting. Inc and dec were designed to not change certain conditional flags for easier conditional branching. However, using add or sub is faster for 32bit operations, and breaks some contingency conditions (or something, can't remember the right word) allowing the processor to better predict what code to fetch and decode next.

Short story, a quick and dirty port can slow you down, a well thought out and carefully coded port can see nice speed gains.

To all:
If the crashing from SetMTMode and thread deadlocking becomes solved, and the vertical resizers for AMD processors work without issue, I'm going to change the horizontal resize code to use the same concepts as the vertical resize code. Horizontal resize speed, believe it or not, is the slowest part of Avisynth (internally, not counting filters which eat way more processing time) when running TGMC beta2, by a factor of 3 or so, which is pretty substantial. Here's hoping for some good news about the latest builds.

[osgZach]

Ah, cool.. I know nothing about ASM Language so you already know more than I do :p

That encode under 1.4.6_x64 just finished. 2h:30m for a 22m:48s video. I guess for now I'll have to stick with 1.4.6 and hope the speed holds up for other sources (4 down, 33 to go).

[levi]

@levi
I think there you did find a bug, I've done a quick fix for it, one I should have done a while ago. Can you try the latest DLL from the first post and see if that still crashes out? If so, some clip info may be in order so I can fix it properly.



avisynth64_3-15-10.rar fixes the issue. :thanks:

[noee]

Okay, that last "AMD" version worked with the resize in my script, but only when I removed the SetMTMode() call. It appears that when I use SetMTMode(), the frame corruption occurs. I've run two test so far with Spline36 and Lanczos without SetMTMode() and they are good.

[levi]

Any chance for a tomsmocomp (http://avisynth.org/warpenterprises/files/tomsmocomp_25_dll_20030629.zip) port?

[Audionut]

With the latest builds I get an error with

mt("TempGaussMC_beta2()",threads=4)

http://img189.imageshack.us/img189/438/95216591.png

Removing the threads=4 works but then its not multi-threaded.
I had this working on a older build.

setmtmode, doesn't have any speed increases for me.

[VincAlastor]

great job! thanks a lot!
would someone make a dg nv tools x64 version, please? ...neuron2 hasn't a 64 bit os. that were very nice. a debanding function like gradfunkmirror, too :)

[osgZach]

I hate computers. I can't get stable performance numbers. lol.. Somebody please shoot me.. I think I better stay away from SetMTMode() until a lot of this gets straightened out.. Especially the thread deadlocks - that hits randomly too.

I really don't want to use MT either.. can't solve the overlap misalignments :mad:

Plus the more time I spend screwing with this, the less time I have to get JoshyD's hosting set up.. ;)

[squid_80]

great job! thanks a lot!
would someone make a dg nv tools x64 version, please? ...neuron2 hasn't a 64 bit os.

That's a bit hard to do without the source code (although not super hard, given the format is documented).

[osgZach]

I don't think DGNv is open source anyway. It's a pay-for product.

Although if a coder he trusts were to ask, maybe he could work with them to produce 64-bit compiles?

[hajj_3]

yeah its a pay app, i can't see neuron giving anyone the code to make a 64bit version as its too risky. It would be nice though. He said he has no 64bit O.S and that if he had 1 he might create 64bit versions of it so if anyone is rich feel free to pay for a copy of win7 pro x64 for him.

[Guest]

I probably don't need a 64 bit OS to make the build. But I do need someone with 64-bit expertise to tell me how to make such builds. I have never made a 64-bit anything.