Is it hard to recompile filters for 64 bit?

[Chengbin]

With more and more computers with 64 bit, not many Avisynth filters are in 64 bit. This raises the question, is it time consuming to recompile filters for 64 bit? If not, then why aren't more filters being recompiled?

[thewebchat]

Hmm, it could be:

1) Nobody cares about 64-bit.
2) Nobody cares about 64-bit AviSynth.
3) Nobody cares about 64-bit AviSynth enough to rewrite thousands of lines of assembly code.
4) Nobody cares about 64-bit AviSynth to reverse engineer plugins to obtain the source code to rewrite.

[Blue_MiSfit]

If I was a plugin developer, I wouldn't be too excited about rewriting all my ASM code for x86_64. Simply recompiling the plain C routines will produce a very slow binary - especially compared to an assembly optimized 32 bit build!

The gain by using 64 bit x264 is good enough IMO ;)

~MiSfit

[kemuri-_9]

Avisynth itself is 32bit and utilizes a large number of sections of inline asm that is inherently incompatible with 64bit compilation with the primarily supported compiler (MSVC).

1) all of said inline assembly would have to abstracted out into assembly files to be processed with an assembler: one of masm, nasm, or yasm being a likely choice.
2) then from there it could be compiled for x86_64 without assembly optimizations (so it would be slow, but working)
3) port x86 asm to x86_64 to regain the optimizations that was there for x86.

this applies to most plugins in addition to avisynth itself

by no means is this is a small feat, which is why it hasn't been done yet,
and it makes no sense for plugin authors to perform aforementioned items until avisynth itself has done it

imo the primary gain of going to x86_64 for avisynth would not be for speed over the current x86 version, but for the raised allocatable memory limit.

[davidhorman]

With more and more computers with 64 bit

Until the operating systems running on said computers stop supporting the plethora of 32-bit programs that are already in existence, I don't think you'll see much progress on this (non-)problem, especially since most video formats have at most 8 bits per channel and 3 channels (24 bits).

This begs the question

Oh man, I'm sorry (and this really isn't aimed at you, Chengbin!) but I'm going to have to leap to the defence (that's right, defenCe!) of the English language here. Your post raises a question. Begging the question is entirely different (or at least it used to be, *sigh*). And if anyone tells me they "could care less" my head may well explode ;)

David

[Chengbin]

Oh man, I'm sorry (and this really isn't aimed at you, Chengbin!) but I'm going to have to leap to the defence (that's right, defenCe!) of the English language here. Your post raises a question. Begging the question is entirely different (or at least it used to be, *sigh*). And if anyone tells me they "could care less" my head may well explode ;)

David

Happy? ;)

Avisynth itself is 32bit and utilizes a large number of sections of inline asm that is inherently incompatible with 64bit compilation with the primarily supported compiler (MSVC).

1) all of said inline assembly would have to abstracted out into assembly files to be processed with an assembler: one of masm, nasm, or yasm being a likely choice.
2) then from there it could be compiled for x86_64 without assembly optimizations (so it would be slow, but working)
3) port x86 asm to x86_64 to regain the optimizations that was there for x86.

this applies to most plugins in addition to avisynth itself

by no means is this is a small feat, which is why it hasn't been done yet,
and it makes no sense for plugin authors to perform aforementioned items until avisynth itself has done it

imo the primary gain of going to x86_64 for avisynth would not be for speed over the current x86 version, but for the raised allocatable memory limit.

Yes, the main reason to go 64 bit is to break the RAM limit.

Isn't there a 64 bit Avisynth? Does it do it in that version?

[thewebchat]

I'm pretty sure that squid_80 only rewrote the bare minimum lines of code needed to build a working AviSynth64 and stripped out the non-essential functions that didn't work.

[kemuri-_9]

briefly looking through the code, I've only found things like

#ifndef _AMD64_
... // use inline assembly
#else
... // use standard C
#endif


so squid_80 only did point 2) (and skipping #1) of my list for his x86_64 avisynth build

[squid_80]

I'm pretty sure that squid_80 only rewrote the bare minimum lines of code needed to build a working AviSynth64 and stripped out the non-essential functions that didn't work.
Sort of - I ported what was commonly used, like the resizers and some other stuff. Most of the plugins that I built contain fully converted (but not optimal) assembly code.
The cleanest solution to the problem would probably be replacing the majority of the inline assembly code with softwire code, since it's been 64-bit compatible for a while now.

[osgZach]

I know more than x64 support, I'd love to see more software take advantage of GPU hardware. It's not an easy task and I'm sure there are hurdles to overcome.. But it seems in particular we are all, invariably stuck using one or two tools that are years old, no longer maintained, or some other thing along those lines..

I really have to ask "why?", though.. OSS was supposed to be this boon of progress but it seems these days it comes down to standard answers of "X isn't interested in maintaining their work anymore", "if you want it do it yourself" (kind of defeats the community aspect of OSS if no one wants to organize a new project?), "what's the point? the current tools work fine" (there is ALWAYS room for improvement and advancement in technology).

almost seems like there is a prevelant self defeating attitude when it comes to OSS video editing/encoding solutions.. Or the really useful tools end up being not very user friendly.

But on the other hand, I learn something new every day.. all the same, I'd prefer the cost of learning not be via encoding runs in the tens of hours.


I'm not trying to bash any programmer. I just don't understand the mindset I guess.. If you're a really good programmer and you understand that working on OSS isn't going to make you much (if anything) and will cost a lot of time... why start if you're not prepared to remain devoted or at least ensure a proper handover to someone else to keep development going? The end result seems to be we invariably end up dependent on old software that may have its own quirks or bugs, isn't necesarrily as fast as evolving hardware could allow for, etc..

People who volunteer their time and effort should be applauded as always.. But at least handoff development to someone else, or do your best to garner interest so someone will pick it up eventually.. The community can only win if there was a brave devoted soul(s) out there, who could pick up old software and bring it up to date.

[thewebchat]

Cool thread hijack there.

[Myrsloik]

Take my software, please

[osgZach]

Not really a hijack since its essentially the same problem. There are a couple GPU based filters out there (Donald Graft did a couple IIRC) but I don't think I've seen anything too recent..

Whether you want to discuss x64 or GPU assisted filters, it all comes down to the same problem..

Nobody's interested / doesn't care / doesn't have the time and/or skill, etc.

If I ever rubbed a lamp and a genie came out, that would be awesome.. Cause I'd wish for a huge bank account and never have to work, and also wish for the ability to learn anything I set my mind on, in a matter of hours or days.. Then it would be totally cool to put that to use making an awesome Video encoding suite all open source.

But I have a bigger chance of being elected President than that, so...

[tedkunich]

Nobody's interested / doesn't care / doesn't have the time and/or skill, etc.



You DO realize that this is FREE software, right? The programmers do not get paid for what they do; it is done in their free time (what little they may have) - be grateful that it supported at all.

T

[osgZach]

That's my whole point dude.

OSS was supposed to be this boon of innovation and show the light to the world. With anybody able to contribute there would always be development, bugs would be fixed, features would be added, etc.

But that single one flaw always comes up when people actually start asking for stuff.
I support OSS and I like the idea, but it could do without some of the elitsm that some folks tend to display and the whole attitude of "be grateful you get anything", if OSS wants to be taken seriously like people were hyping it up to be in the past.

It's a cold hard fact. I make do with what I got, always have and always will. I don't complain out of spite, but you can interpret that however you want.

I am simply bothered by the fact that the only reaction to what essentially was a hyped up promise is "be grateful you get anything". That wasn't supposed how OSS was originally sold or "marketted" to the mass of users who wanted alternatives to expensive commercial products that (ironically) would eventually stagnate and die out, or force expensive upgrade paths on people.

I guess you could call that disenfranchisement, but I'm perfectly happy to hold up great working OSS alternatives to retail products, and recommend them to my friends. But I'm equally happy to point out a flaw in the community when I see one.

Doom9 members have & continue to do great work. I don't think anyone is disputing that.

[thewebchat]

???

When did anyone make any promises, hyped or otherwise, about GPU acceleration? The only "hype" I can recall is AVS 3.0, and that's been dead for a long time now.

[osgZach]

I wasn't implying anything specific about GPU acceleration. If I meant to do that, I would have said GPU acceleration and not "OSS". I was speaking on Open Source software / the OSS movement in general..

Again this comes back to the whole "be grateful for what you get" mentality that really, just bothers me. I've read several variations of this philosophy in several threads already, and it just seems to stick out in contrast to what the OSS movement was, from what I recall, really supposed to be about. By the community - for the community. That's where threads like this come in I guess..

I'm not trying to put a gun to anyones head and force them to make a program, or other piece of software for me. But at the same time, from a standpoint of ideals, I just think its a little contrary that almost every time someone asks if something is ever going to come out, someone invariably comes along and spews garbage about being thankful for what we already have, as if we're just whiny brats and not already grateful. Just because we make a suggestion or ask why something has never been done before or isn't being worked out.

I've tried to stray from attacking anyone in particular as its really not the fault of anyone in this thread. Just trying to point out what I see as a flaw in the thought process of some in the OSS community in general. It's disheartening to be told "shut up, kid. Just enjoy the free vanilla", when someone asks for a different flavor. I probably erred in judgement in responding in this thread in particular (although I don't think its OT as I was just commenting on what I observed, already posted). But anyway, I was hoping to find at least one person who could understand where I was coming from, or at least agree partly.

Nothing more, nothing less.

[thewebchat]

Yes, I do agree that "stfu," "rtfm," and "patches plz" are generally not helpful, and possibly indicative of an attitude/arrogance issue, but you have to consider the pragmatic viewpoint as well. Unless someone volunteers to do X Task, it's highly probably that it won't happen. Moreover, I'm sure you know that the more you have people pestering you about something, the less you want to do it. This applies online as well as in real life.

[osgZach]

Agreed. I wholly appreciated the work people do, and if I did have the necessary skills I would love to be able to contribute in that way with an active project to develop / update the tools we all use as technology progress allows us.

I have the same issue with my "retro" magazine. The stats and e-mail feedback say plenty of people love to download and read through it, but I haven't put out a new issue in a couple years because I just can't do it by myself, and no one wants to step up. As it is I am really burned out from trying to do it all myself, and would rather just be an Editor, so I can sympathize with programmers who lose interest and drive in their utilities and filters.

[saint-francis]

This has really gotten OT. I'm sorry to act like a mod but every time I see there is a new post in this thread I think "hey SF, there might be some developments in 64 bit avisynth!" While I agree that the topic of inconsistent OSS development is important to everyone and especially us, it should be moved to it's own thread in a different forum.

Sorry to stall the momentum.

[`Orum]

This is relevant to my interests, so I am considering porting AviSynth to x64. I'm tired of it crashing on 32-bit due to limited address space. :mad:

http://img4.imageshack.us/img4/9710/32bitfail.png

However, closed filters will need to be ported by their authors...

[squid_80]

More than likely it doesn't need that much memory, but is just using it for frame caching. Try using SetMemoryMax in the script to limit it.

[`Orum]

More than likely it doesn't need that much memory, but is just using it for frame caching. Try using SetMemoryMax in the script to limit it.

That's *with* SetMemoryMax(512). :devil:

Something is wrong in vsfilter, and it leaks memory like crazy. I'll work to fix it, but I want x64 AviSynth anyway. I also looked at assrenderer, but that only works in RGB32. For the time being I just MaskSub and overlay the complex scripts.

[squid_80]

VSFilter is actually one of the few filters I compiled for x64, available with all the other stuff here (http://members.optusnet.com.au/squid_80/).

[osgZach]

If you need someone to help test builds, I'll help in any way I can.