View Full Version : x2643dgpu?
Blue_MiSfit
13th May 2006, 22:36
I had a thought the other night... Is it theoretically fesasable to run (portions if not all) x264 on a GPU in the same way that fft3dgpu does?
The only drawback that I can see is that the interface between the GPU and the rest of the system is probably slower than the CPU's FSB or HyperTransport...
Maybe it could be used as a pseudo-multiprocessing environment...
I dont know anything about programming HLSL though, so I think I will just shut my mouth right now ;)
It was just an idea. What do you guys think?
~misfit
Kostarum Rex Persia
14th May 2006, 04:01
Very good idea, but I think it will be very hard to implement.
Revgen
14th May 2006, 04:33
Very good idea, but I think it will be very hard to implement.
It shouldn't be that hard.
All we need to do is kidnap tsp and akupenguin and lock them in a dungeon with a computer.:D
bob0r
14th May 2006, 16:52
It shouldn't be that hard.
All we need to do is kidnap tsp and akupenguin and lock them in a dungeon with a computer.:D
In all honesty, where do you think the Cats are now? :D
Blue_MiSfit
15th May 2006, 09:23
Man, if only some consortium of professional video encoders and developers could be formed(or something like that).
There would be some source of revenue to pay people for their time, provide devs with systems to develop for (64 bit dual core) etc... But I dont see anything like that happening in this world of mostly open source software. It would make a really cool non profit though...
It would just make organizing things so much easier, perhaps unite the community toward a common goal... I dont know, just ranting at this point :)
MeteorRain
18th May 2006, 03:18
x264 is still in early stage development. maybe we could wait for x264 becoming mature and then consider put it onto GPU? ;)
imcold
18th May 2006, 19:15
What do you mean by becoming mature? It's great already for a long time ;)
ChronoCross
18th May 2006, 19:35
What do you mean by becoming mature? It's great already for a long time ;)
I agree that it is great. I think yby mature he meant adding the entire spec including interlacing, exteneded profile and alternate colorspaces. better to focus on the spec right now than things like gpu offloading.
Manao
18th May 2006, 20:55
interlacingA lost of time if you ask me. If given te choice, I'd always deinterlaced prior to encoding.extended profileReally useless this time. Extended profile is roughly baseline + bframes. No cabac is allowed, and the bunch of additionnal features concerns solely streaming and error resiliance.alternate colorspacesUmpf. It still lacks 4:2:2 content out there. And 4:2:2 decoders even more.
Anyway, attempting to use the gpu in x264 isn't contradictory with extending the features supported by x264.
imcold
18th May 2006, 21:00
IIRC pengvado doesn't like the idea of adding interlacing stuff in x264 :D Extended profile = High profile (FRext project)? "Use more than 8 bits per sample of source video accuracy" is pretty much useless for most for (almost?) all of us. I think that full standart covering isn't that neccessary, but since I don't work on x264, my opinion is insignificant :D
Anyways... wherever will the path of x264 go, I will follow.
Recently I've found this though:
http://www.pixeltools.com/h264_paper.html
Variable block sizes for spatial transform*. Future profiles will allow transform of variable size blocks (4x8, 8x8, etc.) with the same level of flexibility as motion estimation blocks. This will provide more flexibility and further reduction of bitrate.
Interesting?
Revgen
18th May 2006, 21:23
I'd at least like to see Y8 (4:0:0) support. My B&W movies would encode alot faster. One poster did a test that showed a 30% improvment in encoding speed. I know that there is a lack of decoding support for this feature, but nothing is going to happen if nobody tries.
akupenguin
18th May 2006, 22:05
Any encoding speedup due to knowing the video is B&W does not depend on using the Y8 colorspace. x264 could just as easily not process the chroma planes either way, the only difference is one cabac_encode_decision() per macroblock saying that chroma is empty.
Of course, that means that the hard part is modifiying everything to make chroma optional. Once you've done that, there's no reason not to just mark the stream as 4:0:0.
For decoding speed, you can use `mplayer -lavdopts gray -vf format=y8`, whether or not the video contains color. Which, btw, means that the hard part there is already done, and adding high profile 4:0:0 support is just as simple as parsing the colorspace flag.
devaster
8th June 2006, 19:17
to porting it on gpus:
maybe use a CG runtime and replace some functions that are much speeder on gpus ...
specially matrix and mathematic operations
Rrrough
8th June 2006, 19:26
I wonder if GPU hardware support for encoding functions can only be accessed via DirectX or if this could also be realized via OpenGL, which would be a more platform-independent approach. Any ideas ?
Cheers
devaster
8th June 2006, 19:28
iam reading a cgs manuals now and i see some modifications for the code (what i have wrote)
rrrough: in manuals are the usable functions available in standard lib ....
Theliel
8th June 2006, 20:11
yes, in GEMS GEMS2 or CG tutorials (good for Nvidia) we can found interesting functions that could be replace some lines in x264 code. however, i think that only akupenguin and CIA can said us if it's viable.
devaster
8th June 2006, 20:22
ill would make a build based on cg for nvidia , i am now modifying sources and place it somewhere ...
ShAQ
26th June 2006, 22:45
ill would make a build based on cg for nvidia , i am now modifying sources and place it somewhere ...
Please, keep us updated about the status of your project. Thanks in advance!
Sirber
26th June 2006, 22:49
Sad I'm on ATI. Best luck with your project!
shon3i
26th June 2006, 23:01
I think that x264 need more speed and real AQ, and some more low bitrate tools like AQ and other stuff which is supported by AVC standard and x264 dosen't support it (if that tools exists)
devaster
27th June 2006, 01:01
for now i have rewrote complete dct algorithm and some another parts ...
now i havent time for this rewroting that is going hard ...
sorry peoples...
(i am not using brook...)
Sirber
27th June 2006, 04:00
do you have any plans for ATI? It's not that I beg for ATI support... just thinking it would be... kinda.... nice thing to have ... :D
devaster
27th June 2006, 04:04
if i use a dx9 itstead opengl it may be functional on ati cards...
i thing when i use a hlsl and fxl compiler from dx sdk instead Cg...
but this is a sound from future ...
CruNcher
27th June 2006, 13:01
devaster that's really interesting, did you plan todo the same for the ffmpeg decoder part ?
Theliel
27th June 2006, 13:42
good work devaster. I wait for your work :). rewrite code are very slower, dont worry. When I'll finished exams this weeks i can help you to translate some parts if you want.
devaster
27th June 2006, 18:58
cruncher :
as i have wrote if i would have some time maybe ...
bond
27th June 2006, 20:10
when will you release the code? ;)
devaster
27th June 2006, 21:12
bond:
i dont now ...
maybe next week when i use a ms accelerator code but then must be x264 runing on .net 1.1 min. :(
advantage : x264gpu wuld be runnable on all cards with hardware dx9 :)
Deinorius
27th June 2006, 21:30
It would be ok for me, if it needs .NET 2.0. ;) Essentially it runs much faster. :D
But if you mean DX9, do you mean Shader Model 2.0 oder 3.0. It's a great difference.
devaster
27th June 2006, 21:49
recomended is 256mb ram and pixel 3.0
bond
27th June 2006, 21:51
i heavily doubt .net will make it to the svn :D
Sirber
27th June 2006, 22:06
recomended is 256mb ram and pixel 3.0All I know about my card is "Support for Microsoft® DirectX® 9.0 programmable vertex and pixel shaders in hardware", dunno if it's PS2 or PS3 :(
http://www.ati.com/products/radeonx800/specs.html
devaster
27th June 2006, 22:43
bond:
ee i wouldnt make any update to svn . never .
it is a my excersise , and i thing it may be usable for someone ...
sirber :
i thing it would be functional ...
i have a question : why is not enabled a sse2 assembly dct ???
Revgen
28th June 2006, 03:58
All I know about my card is "Support for Microsoft® DirectX® 9.0 programmable vertex and pixel shaders in hardware", dunno if it's PS2 or PS3 :(
http://www.ati.com/products/radeonx800/specs.html
X800 supports 3.0. So you're safe.
devaster
28th June 2006, 04:11
3.0 ps are only recomended ...
Deinorius
28th June 2006, 10:31
@Sirber, revgen
Stop stop stop! The X800 Series doesn't support Shader Model 3.0. It has been supported since the X1k Series by ATI like X1800.
Sirber, you will have to buy a new card. :P
@devaster
Only recommended? You mean, it would run with SM 2.0 too? O.O
Hmm.. of course, you're programming it otherwise than ATI will use it with Avivo. Will it use the CPU too? It's still the best way, if CPU and GPU works together.
Sirber
28th June 2006, 12:36
Sirber, you will have to buy a new card. :P
Any recommendations for my AGP system? :p
Sharktooth
28th June 2006, 12:46
I higly doubt .NET will be faster than native binaries...
xyloy
28th June 2006, 12:50
Any recommendations for my AGP system? http://forum.doom9.org/images/smilies/tongue.gif
The nVidia 7600 GT/GS will soon be available in AGP 8X version(third quarter of 2006). It will be produced also next year.
More info here (http://digitimes.com/mobos/a20060619PR207.html)
But I don't know if it will have any Shader Model 3.0 support.. Sorry. ^_^;
(but I hope it will have GPU H.264/AVC acceleration :D )
Daodan
28th June 2006, 12:56
I've seen on sale various 7800GS for agp, which is quite a good card. Also on the net something about 7900GT but haven't seen it in offers yet. For ATI only x1600 but I think the 7800 should be better.
Deinorius
28th June 2006, 13:02
Any recommendations for my AGP system? :p Buy a new PCIe Board. ;)
That's no joke. AGP Cards are too expensive for the performance. Best AGP Card is a 7800 GS+ with a 7900 GT GPU. It costs here in Austria at least 384 €. A 7900 GT costs less then 300 €. For this difference you can get a good AMD Board.
Which CPU do you have? Athlon 64 on S939? How about a Asus A8N-E (http://www.geizhals.at/eu/a129388.html)? It has everything except of Firewire and costs only 70 €. Don't know where you exactly live, so search at your place. :D
For Video encoding you need better Shader Performance, which you get by ATI (You have Avivo too, if it gets importance in future. ;)). If you don't want to spend too much money for graphics, wait for the X1700 GPUs which will release in summer, maybe September. ^^
@xploy
Every Geforce since 6 has Shader Model 3.0 Support, which means Geforce 7 Cards have this support too.
@Sharktooth
You may be right. :sly:
devaster
28th June 2006, 13:30
@devaster
Only recommended? You mean, it would run with SM 2.0 too? O.O
Hmm.. of course, you're programming it otherwise than ATI will use it with Avivo. Will it use the CPU too? It's still the best way, if CPU and GPU works together.
microsoft accelerator run on 2.0 ps too , it use dx9 not only dx9c
in cg i may select a specific profile - using ps2.0 or ps3.0
yes it uses cpu too i rewrite only some specific parts for gpus (dcts for example)
Deinorius
28th June 2006, 13:45
That makes sense. There won't be every command programmable for GPUs I think.
Most interesting thing will be, how much faster is it with and without Avisynth filters. ;)
devaster
28th June 2006, 14:01
i have installed nvperfhud there i will see it ...
its a cool app...
Deinorius : gpu is very good for a massive paralel and matrix arithmetic and albegras operations only , cpu is for adds a single numbers ... LOL
but it depends on a balanced load for gpu and cpu ...
CruNcher
1st July 2006, 23:58
devaster is it possible to get the decoded frames of Nvidias Purevideo Decoder (DXVA) going throug Video Rendering Mixer 9 somehow into a file ?
CruNcher: It should be posible by using a custom allocator-presenter that saves the texture WRM9 render to for each frame.
CruNcher
3rd July 2006, 11:55
thx tsp i read about custom allocators in the dshow sdk :)
huang_ch
16th December 2006, 06:14
Just saw this thread during searching... Any recent news about this?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.