Why no GPU version of Avisynth?

[Hiritsuki]

Why avs were able to make a MT version of this multithreads
So why no one thought to make gpu version of avs?

Let gpu to computing avs certain operations much faster than the cpu
At least mediaplayerclassic indeed rely on the shader to operate gpu

If you have offensive ability, forgive me :(

[osgZach]

I don't know the internals of Avisynth but I will say this. I'm pretty sure Avisynth is a relatively big program, and its taken a long time to get it to where it is.
GPU computing, in comparative terms is relatively new, and there are many cases where, using a CPU (or multi-core CPU) is still a lot more efficient.

We have one or two filters, that can use the GPU to do stuff (FFT3DGPU, etc) but I don't think anyone feels it is necesarry that Avisynth be a GPU dependent program, either. There is also the question of time and skill of the programmer. I think Avisynth is maintained by one person, although others do contribute code. So there is no real easy answer I could personally give, other than to say it "is not that simple". Some would argue it is not necessary, too. I would be inclined to agree. If Avisynth were ported to and maintained only for GPU's that would leave a lot of users out in the cold. This already happens because it is dependent on Windows libraries, but then to restrict it further to people with semi to highly expensive GPU's would be a big negative. Maintaining multiple forks is nice - but that is a big job and can cause many problems too.

Avisynth as an entity doesn't really need the benefit of a GPU anyway. What really needs to be the focus in the future, is on getting more GPU accelerated plugins. The plugins are what gives Avisynth a lot of its power, and where a lot of the CPU intense algorithms come from. They are the best candidates for GPU acceleration. However, it is again, a question of time and skill. Also desire I suppose.

The community has a fond saying, "If you want to see something done, and no one is doing it, do it yourself". While I haven't always agreed with the black and white nature of that statement, it is very true that if you or anyone else have the skills to port a plugin or whatever, (or god Forbid, Avisynth itself) to a different architecture (x64, GPU, etc) many here with specialized knowledge will be happy to try and assist you in your effort.

[Hiritsuki]

I'm not programer and I don't know this , just to bring up an idea.
After all use GPU to computing is more and more faster than CPU even MultiThreads.

[Didée]

If CPUs are so poor and ridiculously slow, in comparison to GPUs being so allmighty and bazillion-times faster ...

... then, why do PCs still use CPUs at all? Why not switch everything to GPU?


Think about that. There probably is a reason. ;)

[osgZach]

I'm sure you may know this Didée, but there has actually been a debate going on for a while now about that very idea. Something along the lines of combining a CPU and GPU on the same chip and letting the GPU handle parallel processing and stuff like that, which GPU's excel at (I think Nvidia are currently working on something like this)

However I think it is worth considering we are likely going to get more questions like this from the average joe, as the general public (as is usually the case) is fed a generally convoluted idea of this stuff in the news. Usually its played up like "GPU computing is the future! GPU's are much faster than traditional CPU's in certain tasks" which the laymen extrapolates into "GPUs make everything faster".

Mob mentality I guess. I for one am excited to see what the future brings with the recent advancements in multi-core technology, smaller die sizes, etc. Although I think we are a long ways off from a true CPU/GPU hybrid (look how big and Graphics card is & how much power a gaming dedicated GPU sucks up after all) I think it would be possible to at least get some mid-range quality performance crammed into a single chip (although the question of where the dedicated RAM will go is left to deal with). Although I am more interested in the idea of a multi-platform CPU that can handle instructions from different architectures.. x86, x64, RISC based stuff (could be a real boon to console emulation too I think). We could get some really cool machines for multipurpose tasks.

But.. I guess that's off topic.. sorry

[TheFluff]

@osgZach: http://catb.org/jargon/html/W/wheel-of-reincarnation.html
all of this has happened already and will happen again

[LoRd_MuldeR]

Why avs were able to make a MT version of this multithreads
So why no one thought to make gpu version of avs?

Let gpu to computing avs certain operations much faster than the cpu
At least mediaplayerclassic indeed rely on the shader to operate gpu

If you have offensive ability, forgive me :(

Only specific problems can be solved efficiently on the GPU. That's because the GPU is a massively parallel processor. So the problem must contain a lot of exploitable parallelism to be suitable for a GPU implementation. We need a few thousands threads to run in parallel, if we want to leverage the power of a GPU! There are many problems that are inherently sequential and thus will never fit on the GPU. And even if a problem is highly parallel (and thus is suitable for the GPU), you can't simply take the existing CPU code and throw it on the GPU. No! Instead you have to move from a single-threaded implementation (or from an implementation that uses no more than 2 or 4 maybe 8 threads) to and implementation that uses several thousands threads! This makes it necessary to invent completely new algorithms in many cases.

Conclusion: Certainly not all Avisynth functions are suitable for a GPU implementation. And even those that are would have to be ported individually, which would be HUGE project :scared:

[EDIT]

And there's another problem: Moving data between the main memory and the GPU memory is a serious bottleneck! If you can't do everything on the GPU, which you certainly can't, then the frames needs to be "uploaded" to the GPU memory before each GPU function call and they need to be "downloaded" to the main memory before each CPU function call. That will be a problem, especially for Plugin calls!

Example: I was working on a project. The task was to implement an image detection algorithm on the GPU. We had existing CPU code. And in the CPU code there was one single "step" that took ~90% of the time. So we ported that step to the GPU and got a nice 12x speed-up. But the overall speed was slower, bummer! Uploading the data to the GPU took more time than we saved with the faster computation...

[Hiritsuki]

I don't know this how to cahnge (I'm not programer) just know that is difficult
but it's also bring great benefits for encoding.
Now tnlmeans This slow rate of filter , if runing in GPU it's will break this bottleneck.
Sorry to have offended if I say please forgive me

[LoRd_MuldeR]

I don't know this how to cahnge (I'm not programer) just know that is difficult
but it's also bring great benefits for encoding.

Again: You can't say "using the GPU gives great benefit over a pure CPU implementation", because that statement is much too general. And thus it's simply wrong.

Whether using the GPU can give a benefit or not highly depends on the individual problem. There are things that work great, but there are many things that don't work at all.

Some of the most prominent problems with GPGPU have already been explained in this (http://forum.doom9.org/showpost.php?p=1386957&postcount=7) post...

(Example: The fact that all the "GPU encoders" we have seen on the market so far did perform very poorly, shows that current GPU's aren't very suitable for H.264 encoding)

[Didée]

Agree with all what you said ... but, sorry one thing, the following
(Example: The fact that all the "GPU encoders" we have seen on the market so far did perform very poorly, shows that current GPU's aren't very suitable for H.264 encoding)
is not a valid conclusion. The "fact" all GPU encoders perform poorly is not sufficient to conclude that GPUs are not suited for the task. You can only conclude that the existing packages of {implementation-using-GPU} are weak.

[Hiritsuki]

I know it, GPU to encode x264 is weak
But using shader to rendering is faster than CPU that's I said,
because GPU usually have ten or hundred shaders.
For example my graphic card is gtx260+ have 216 shaders,
I think that pc for use of high-end CPU should not bar the use of low-end graphics card.

[osgZach]

I firmly believe GPU encoding is going to be awesome in the future. There is no question, there is room for great speed increases when encoding on a GPU. Especially for those who may have a GPU able to do so better than a lackluster CPU. I think its wrong to say they perform poorly though, having played around with some. They just produce poor results. That's not the same as poor performance.

Hiritsuki, they key factor in determining good candidates for GPU computing, is how well the tasks that a specific program or filter does, will scale in parallel. Certain operations run way way faster when you can execute many of them at once, obviously. But not all programs or filters work this way, or benefit from such a system.

[LoRd_MuldeR]

The "fact" all GPU encoders perform poorly is not sufficient to conclude that GPUs are not suited for the task.

That is correct. But that's not what I said ;)

I said "The fact that all the 'GPU encoders' we have seen on the market so far did perform very poorly, shows that current GPU's aren't very suitable for H.264 encoding". If the current GPU generation really was as awesome for H.264 encoding as the GPU vendors try to make us believe, someone would have managed to throw a competitive GPU encoder on the market by now. Many companies put a lot of effort into this. But still it didn't happen! More than three years after CUDA was introduced, I'm still waiting to see a GPU encoder that can compete with the state-of-the-art CPU encoders quality-wise and beat them speed-wise. So either the current GPU generation isn't that great for H.264 encoding -or- all the people/companies who have been working on GPU-based encoders are incompetent idiots (while all the "smart" encoder developers completely ignore the GPU market). Somehow I doubt that the latter does apply. This of course doesn't mean we won't see a competitive GPU encoder in the future. I just wouldn't expect one soon...

[osgZach]

Fermi has turned out to be a big pile of stink from the looks of it.. very unfortunate.. and of course what GTX275's are left are now selling at higher prices than before :rolleyes:

[aegisofrime]

Fermi has turned out to be a big pile of stink from the looks of it.. very unfortunate.. and of course what GTX275's are left are now selling at higher prices than before :rolleyes:

Fermi is hot and power hungry yes, but from what I read on Anandtech's review it's compute performance is nothing short of impressive.

Lord Mulder did mention once that it's more programmable than the Radeon 5xxx series too.

[osgZach]

Well from a consumer prospective, its definitely a shoddy investment. Unless you have a very specific purpose in mind for it, other than the purpose it was really built for (Gaming). Performance per watt, it is pretty bad.

As for its programmability, I can't comment on that. If its true that is awesome, but is that GPGPU tasks in general? (i.e universal stuff you can do on ANY card?) or is that a CUDA thing? Because CUDA is proprietary so no surprised there if its "more programmable" than an ATI/AMD card, at this point.

[Hiritsuki]

Not have to use CUDA to make common tasks can be programmed in such a way as fft3dgpu.

[osgZach]

Yes, we are aware of that..

[aegisofrime]

Well from a consumer prospective, its definitely a shoddy investment. Unless you have a very specific purpose in mind for it, other than the purpose it was really built for (Gaming). Performance per watt, it is pretty bad.

As for its programmability, I can't comment on that. If its true that is awesome, but is that GPGPU tasks in general? (i.e universal stuff you can do on ANY card?) or is that a CUDA thing? Because CUDA is proprietary so no surprised there if its "more programmable" than an ATI/AMD card, at this point.

I agree it's a shoddy investment. The Radeon 5870 is a way better deal. I know because I have been arguing about how the GTX 480 is a poorer product in my local forum against a horde of green-faced nVidia fanboys :)

As for programmability, allow me to link you to the compute page of Anandtech's GTX 480 review:

http://www.anandtech.com/show/2977/nvidia-s-geforce-gtx-480-and-gtx-470-6-months-late-was-it-worth-the-wait-/6

One problem was the lack of OpenCL and DirectX 11 tests in general: As you know these are the so called "universal standards" out there. An OpenCL test they managed to test put it twice the speed of a GTX 285. On folding@Home though, it's 4 times faster. I can see folders buying a farm of these things!

[LoRd_MuldeR]

Lord Mulder did mention once that it's more programmable than the Radeon 5xxx series too.

Huh, more programmable? I don't think so. Both, GeForce-400 and Radeon-HD-5000, support OpenCL plus DX11 ComputerShaders, so their compute capabilities aren't very different.

But Fermi does have significant improvements (compared to the previous GTX-200 series) with respect to GPGPU, indeed. At least in theory ;)

The "shared" memory that is integrated in each multi-processor is much bigger now. Also access to the "global" memory is now cached (using some of the "shared" memory as cache).

So potentially we could see a nice speed-up for GPGPU applications. Code modifications may be needed to fully utilize the bigger "shared" memory though.

And it only helps if you were short of "shared" memory before, which doesn't apply to all applications, of course. Cached memory access should help all applications, more or less.

As always we will have to wait and see some benchmarks for individual applications...

[osgZach]

F@H people do some pretty insane stuff I'm sure.. as for buying a Farm, they're better off just buying cards for a couple people every month, cause that's what they would pay in power bills if they kept them all to themselves.. might as well give the rest of us some benefits, LOL

[MfA]

So why no one thought to make gpu version of avs?
Very basically, no one is interested in doing it :)

[Hiritsuki]

If no one is interested in doing it , why fft3dgpu is be made?:confused:

[aegisofrime]

If no one is interested in doing it , why fft3dgpu is be made?:confused:

If it's speed increases you want, then support the 64-bit project by JoshyD. That brings real speed increases. For example TempGaussMC on 720p content runs at 8+ FPS on 64-bit mode as opposed to 5+ FPS on 32-bit. It's probably easier to program (and port) as well, and that is the main stumbling block for anyone trying to do a GPU version of an Avisynth filter.

Lord Mulder, I must have misremembered your exact quote and I apologize. Thanks for clarifying on the advantages of Fermi though :)

[Hiritsuki]

But I used TNLMeans and most CPU progress is runing in avs not x264.exe
even 64-bit is increased speed but just (if 1 cpu is 0.1- FPS) 3- FPS on 720p

[LoRd_MuldeR]

If no one is interested in doing it , why fft3dgpu is be made?:confused:

That is one specific plugin! Obviously the author of that plugin noticed that his plugin was suitable for a GPU implementation (which doesn't apply to all plugins!) and he was willing to port it to the GPU (which doesn't apply to all plugin authors!). Furthermore: If we can port individual plugins to the GPU while the core filters of Avisynth remain on the CPU, where is the problem? Should plugin authors not be allowed to write GPU-based plugins, just because the core still is CPU-only? That would be silly. And of course you can't force the Avisynth authors to port the core to the GPU, just because GPU-based plugins exist...

[Hiritsuki]

That's I wondered answer :thanks:
So.. GPU's plugin & CPU's AVS is the best solution.
Sor. everyone in this thread answer my question much and :thanks:

[MfA]

That's not really true, it has improved a lot with the latest generation of cards ... but still, pushing image data across main memory all the time is not optimal.

In the end you want all the filters, including the internal AVS ones, to be GPU native.

[Hiritsuki]

Now I understand that about timeline's filter is can't working in the GPU.... even GPU working images is faster than CPU.

[CruNcher]

Only specific problems can be solved efficiently on the GPU. That's because the GPU is a massively parallel processor. So the problem must contain a lot of exploitable parallelism to be suitable for a GPU implementation. We need a few thousands threads to run in parallel, if we want to leverage the power of a GPU! There are many problems that are inherently sequential and thus will never fit on the GPU. And even if a problem is highly parallel (and thus is suitable for the GPU), you can't simply take the existing CPU code and throw it on the GPU. No! Instead you have to move from a single-threaded implementation (or from an implementation that uses no more than 2 or 4 maybe 8 threads) to and implementation that uses several thousands threads! This makes it necessary to invent completely new algorithms in many cases.

Conclusion: Certainly not all Avisynth functions are suitable for a GPU implementation. And even those that are would have to be ported individually, which would be HUGE project :scared:

[EDIT]

And there's another problem: Moving data between the main memory and the GPU memory is a serious bottleneck! If you can't do everything on the GPU, which you certainly can't, then the frames needs to be "uploaded" to the GPU memory before each GPU function call and they need to be "downloaded" to the main memory before each CPU function call. That will be a problem, especially for Plugin calls!

Example: I was working on a project. The task was to implement an image detection algorithm on the GPU. We had existing CPU code. And in the CPU code there was one single "step" that took ~90% of the time. So we ported that step to the GPU and got a nice 12x speed-up. But the overall speed was slower, bummer! Uploading the data to the GPU took more time than we saved with the faster computation...

Yep best current practical software example of this bottleneck would be http://forums.adobe.com/thread/614922?tstart=0 Adobe Flash Player 10.1 due to all the interactivity layers and so the need for copying a lot of frames between CPU/GPU Memory it becomes slow mostly on non mem copy optimized Nvidia Cards that are in fairly decent Desktop systems :)
So getting Fullscreen Flashed HD to work efficiently on a little older system (without dropping like crazy) becomes a complete new adventure for optimizing the system instead of the old goal improving CPU Freq @ all cost you now need to go the other way and improving Mem copy performance @ all cost, though some companies seem to have found pretty interesting solutions even for very heavy frames see for example Elemental Technologies and of course CoreCodec.

So all the people that cry GPU GPU GPU don't know the pain if you want to modify some frame for outside use, though Nvidia already started to improve this Fermi i think has a additional optimization to this problem another enhanced Ion version way :P
Btw especially for Flash you can see the heavy usage + of supporting a CPU bound application with the GPU (and especially the Video DSP for Web Video) resources get shared 50% between both :) nice drop in overall CPU core utilization (more free for Actionscript,Java and other interface,interactivity cycles), but still due to the mem copy problem it's semi efficient in the final result @ all on i would say pretty heavy amount of Desktop systems :P
Most ISVs currently utilize the GPU for all the stuff that runs entirely on the GPU or only a very small part on the CPU mostly playback features are used and in that case it's even not the GPU itself which does the most work but the DSP part see for example Adobes Mercury Playback Engine or other GPU Playback applications all are using Bitstream Decoding (and in a fast way the last years also Open Source adapted to this see MPC-HC and ffdshow both are able to utilize it some years back Video acceleration (no one dreamed of entire Decoding available for everyone back then) was a very commercial thing only and these days Open Source is even most of the times faster implementing it, that makes me happy :).

And Nvidia are one in their business strategy who realized this would help them (help your users/customers and you become the mofo of the industry) as well as their users so even Linux got a big push up in the last years with VDPAU and Nvidia working closely with the community on this being able to fix issues fast and optimize ISVs applications that way certainly paid of for them, even if they still don't provide a Open Source Driver alternative like ATI does :)
Of course some would say you have to sell your soul to Nvidia but what they offer to push themselves this way you wouldn't ever gotten for free back in the old days, so yeah it is ehmm in some way seductive todo (even with all the implications like caging yourself into 1 proprietary space) ;) so (Best example look in the Game industry how many follow that call and in some ways also the additional money) in other words (The Software ecosystem Nvidia build up on their GPU is impressive and the way they let a wide group of people participate is very huge, though still for some not huge enough ;) )
Imho Technology wise ATI/AMD was always 1 tad ahead of Nvidia like Intel is of AMD but they never tried to race infront they seem to be happy with how the current situation is especially in Watt per Performance where their Next Generation will be another step ahead of Fermi obviously (Though they are not happy with Nvidia being number 1 with their Software ecosystem and they see everywhere missuses of Nvidia here, somehow understandable as some of Nvidias practices especially @ Game ISVs are @ the Edge) :)
Though ATI was once the lead in Video that imho changed completely since VP1 Nvidia did big work on this running far away from ATI in terms of Quality ok Technology wise ATI also was infront here but all the bugs in the Drivers with UVD made it unusable and it's still somehow whacky compared to Nvidias now thx to ISVs optimized VPx also Donald Graft takes a big part in this fixing many small ugly bugs in nvcuvid.dll together with Nvidia Engineers (for the H.264 part) :)