View Full Version : Yadif or MCBOB ported to CUDA
Atak_Snajpera
18th June 2008, 21:30
Will be possible to port above deinterlacers to run on modern GPU?
Terka
19th June 2008, 11:26
maybee the question is if mvtools will be ported.
TheRyuu
19th June 2008, 15:14
I consider yadif to be fast enough on a cpu... what would be better would to see as Terka said, mvtools/stuff that mcbob is made of ported.
CiNcH
20th June 2008, 07:52
I consider yadif to be fast enough on a cpu
For 576i it is. What about 1080i? Decoding already requires a lot of CPU time. If done in shaders, also UVD and PureVideo could be used for decoding. Guess that the whole AviSynth thing is not well threaded too (Yadif and MCBOB most likely aren't too!?), so no real benefits from Multi-Core CPU's. Think that the AviSynth patch available can only put different plugins/filters into different threads.
Undead Sega
28th June 2008, 02:29
i would pay good money to make someone port MVTools to the GPU, just think of all the possibilities?
MCBob running at 10x time speed!
Dark Shikari
28th June 2008, 02:49
i would pay good money to make someone port MVTools to the GPU, just think of all the possibilities?Given my experience trying to port a basic SAD motion search to GPU, you might need a few hundred thousand dollars to get such a thing to even have a chance of happening :p
Undead Sega
28th June 2008, 03:11
well, i wouldnt pay that much, hahahaha, after all, this can be done by the intentions of its creator, who holds the source code to it, which would make life alot easier if this can be done. i think im going to the MVTools thread and post this up as well, hehehehe, maybe that might spark something.
Undead Sega
5th February 2009, 01:51
possibility now by any chance? :D
Sagekilla
5th February 2009, 02:23
I wish :( I think the situation is just as bad as it was before.
Biggest issue would probably be optimizing the core routines inside of all the functions. I.e. the metric used for block searching (SAD, SATD, etc). Like Dark Shikari said, unless you're willing to shell out -a lot- of money it's probably not going to be efficient.
burfadel
5th February 2009, 06:02
I think OpenCL it would be better than CUDA, CUDA is Nvidia only (and always will be) since there's OpenCL and (when Directx 11 comes out) support in Directx for the same thing - from what I've heard anyway!
Leak
5th February 2009, 11:38
I think OpenCL it would be better than CUDA, CUDA is Nvidia only (and always will be) since there's OpenCL and (when Directx 11 comes out) support in Directx for the same thing - from what I've heard anyway!
OpenCL is nice in theory - but it's hard to support something that isn't out in the wild yet (http://www.khronos.org/developers/resources/opencl/)...
burfadel
5th February 2009, 12:58
I guess thats true, although MPC Homecinema uses pixel shaders for its pixel shader deinterlacer (granted its blend), which is pretty easy to access as long as you're in VMR or EVR mode. Wouldn't the same Directx based programming be more suited to the purpose of these filters, at least then it will work on a much greater variety of cards and for a much longer time! :) I think pixel shaders are now referred to as stream processors with SM 4.0/4.1...?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.