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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 16th March 2010, 06:10   #181  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
Quote:
Originally Posted by JoshyD View Post
Could anyone with an AMD processor test this version of avisynth64 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 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.

Last edited by turbojet; 16th March 2010 at 06:20.
turbojet is offline   Reply With Quote
Old 16th March 2010, 10:37   #182  |  Link
osgZach
Registered User
 
Join Date: Feb 2009
Location: USA
Posts: 676
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.
osgZach is offline   Reply With Quote
Old 16th March 2010, 13:20   #183  |  Link
noee
Registered User
 
Join Date: Jan 2007
Posts: 530
Quote:
Originally Posted by JoshyD View Post
Could anyone with an AMD processor test this version of avisynth64 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:

Code:
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()
noee is offline   Reply With Quote
Old 16th March 2010, 15:14   #184  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
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

Last edited by turbojet; 16th March 2010 at 15:17.
turbojet is offline   Reply With Quote
Old 16th March 2010, 16:56   #185  |  Link
noee
Registered User
 
Join Date: Jan 2007
Posts: 530
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.
noee is offline   Reply With Quote
Old 16th March 2010, 17:10   #186  |  Link
osgZach
Registered User
 
Join Date: Feb 2009
Location: USA
Posts: 676
*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
osgZach is offline   Reply With Quote
Old 16th March 2010, 17:41   #187  |  Link
JoshyD
Registered User
 
Join Date: Feb 2010
Posts: 84
@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 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.

Last edited by JoshyD; 16th March 2010 at 18:59.
JoshyD is offline   Reply With Quote
Old 16th March 2010, 18:30   #188  |  Link
osgZach
Registered User
 
Join Date: Feb 2009
Location: USA
Posts: 676
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
osgZach is offline   Reply With Quote
Old 16th March 2010, 18:55   #189  |  Link
JoshyD
Registered User
 
Join Date: Feb 2010
Posts: 84
@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

Code:
inc regA
or
dec regA
should almost always be replaced with

Code:
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.

Last edited by JoshyD; 16th March 2010 at 19:38.
JoshyD is offline   Reply With Quote
Old 16th March 2010, 19:13   #190  |  Link
osgZach
Registered User
 
Join Date: Feb 2009
Location: USA
Posts: 676
Ah, cool.. I know nothing about ASM Language so you already know more than I do

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).
osgZach is offline   Reply With Quote
Old 16th March 2010, 20:19   #191  |  Link
levi
Registered User
 
Join Date: Mar 2003
Posts: 116
Quote:
Originally Posted by JoshyD View Post
@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.
levi is offline   Reply With Quote
Old 16th March 2010, 21:46   #192  |  Link
noee
Registered User
 
Join Date: Jan 2007
Posts: 530
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.
noee is offline   Reply With Quote
Old 17th March 2010, 04:52   #193  |  Link
levi
Registered User
 
Join Date: Mar 2003
Posts: 116
Any chance for a tomsmocomp port?
levi is offline   Reply With Quote
Old 17th March 2010, 06:13   #194  |  Link
Audionut
Registered User
 
Join Date: Nov 2003
Posts: 1,281
With the latest builds I get an error with

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



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.
__________________
http://www.7-zip.org/
Audionut is offline   Reply With Quote
Old 17th March 2010, 12:26   #195  |  Link
VincAlastor
Registered User
 
Join Date: Sep 2009
Location: Berlin
Posts: 173
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
VincAlastor is offline   Reply With Quote
Old 17th March 2010, 16:35   #196  |  Link
osgZach
Registered User
 
Join Date: Feb 2009
Location: USA
Posts: 676
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

Plus the more time I spend screwing with this, the less time I have to get JoshyD's hosting set up..
osgZach is offline   Reply With Quote
Old 17th March 2010, 17:31   #197  |  Link
squid_80
Registered User
 
Join Date: Dec 2004
Location: Melbourne, AU
Posts: 1,963
Quote:
Originally Posted by VincAlastor View Post
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).
squid_80 is offline   Reply With Quote
Old 17th March 2010, 18:23   #198  |  Link
osgZach
Registered User
 
Join Date: Feb 2009
Location: USA
Posts: 676
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?
osgZach is offline   Reply With Quote
Old 17th March 2010, 18:54   #199  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,120
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.
hajj_3 is offline   Reply With Quote
Old 17th March 2010, 18:56   #200  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
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.
Guest is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 07:53.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.