80% faster encoding? [hardware]

[CruNcher]

Still my questions:

1. Do H.264 decoders based on CUDA have the same Profile/Level/B-Frame/Ref-Frame restrictions as the existing DXVA decoders? (I have to assume: Yes)
2. Will programs based on the CUDA SDK fall back to "Software" mode when there is no recent NVIDA hardware or will CUDA simply reject to work?

Nvidia balanced everything out for Blu-Ray,HD-DVD and Broadcast (so did ATI) playback where is the Problem with that i don't understand user issues with this.
It's pretty stable since all the filters and stuff adapted to Cyberlinks Decoder and Level 4.1 is really not that restrictive see DivX gonna use Level 4.0 and that is also not much more restrictive, tough if you get problems with B-pyramid i guess X264 is to blame for that not Nvidia and if you get VBV problems it's the same.
And for sure the restrictions here wont cause a Quality Problem with all your Encodes ever but if you as crazy and do stuff like --bframes 16 --ref 16 and more insane things that is just crazy and calling for trouble (do your really thrust X264 adaptive decissions that much over your own viewieng experience ?, hell i even don't thrust its partition decissions :P on a visual level, does that make me a fool or outsider in your eyes ?) I think you would be suprised how much speed or efficiency you just throw out of the Window for some sources (without any subjective visible difference) in the end (but yeah seeing some 100 pixels more in a frame by frame comparision makes you belive this stuff) but that you might invested a 50% speed lose for that small neglible difference per frame isnt of interest right?.
Imho Psy RD and Psy Trellis are the real advantages (especialy for Film Like sources) but they come @ a high price (RD without it is most of the times especialy @ high bitrates useless), tough @ lower complexity levels X264 has only VAQ to push it forward Visualy and that's what DivX are targeting for these lower complexity levels and there it will be a close call, with a better VBV implementation it could even end that alot of people become upset with X264 :( (i know the DivX Encoder isn't as far yet and still slower tough they are targeting this interoperability for Hardware Devices from the ground up,and they really be carefull in dont messing it up and still trying to gurantee a very good visual quality even with these restrictions upon them, the same situation btw that Ateme has to fight since years with).

@neuron2
Hmm Donald i guess you have no access over the API to Nvidias Shader based Motion Adaptive Deinterlacer right ?

[Guest]

@neuron2
Hmm Donald i guess you have no access over the API to Nvidias Shader based Motion Adaptive Deinterlacer right ? Don't know. Do I?

[G_M_C]

[...] I think CUDA support is unlikely to arrive in our lifetime[...]

I concur, see also my post;

That's Nv's problem; Actually, this discussion is about the ENcoding of things.

But your reply points to one of the problems; The development of a HW-assisted ENcoder is made more difficult by the fact that Ati/AMD's hardware works in totally different way than Nv's. It is made even more difficult because both are very secretive about their stuff.

Developing HW-assisted software in general would benifit from having some common programming language. There seems to be a slow movement to get such a language, but actual usabillity is still far off into the future.

My guess will be that Intel will eventually "win out"; Simply because they will focus on "general usabillity", but mainly because they are simply big enough and do not have to be so secretive about their hardware and Nv/Ati are now. Iwould not be surprised when in the further future Intel might also just bring Larrabee to us in a "many-core" solution; something like a 32-core larrabee paired up with a 4-core Nehalem, but all on 1 die.

All-in-all, Nv/Ati had better get their acts together and device some common C#-language that works on both their GPU's, or they will eventually get left out.

But thats my 0,02$ on HW-assisted programming as it stands now; And why HW-assisted x264 will not come in the near future..

The big problem remains that it is virtually impossible to write any kind of HW-assisted software that is usable by everybody (so the same thing LoRd_MuldeR is concerned about). Simpy because there is no common programming language, no common ground in hardware, and no common way to compile these programms. So you need more than 1 version; 1 for every different kind of graphics-card, and if your "really in luck" (note: sarcasm) also for every generation of graphics board ...

There really needs to be a common language/compiler etc. to make this whole venture more feasable imho.

[CruNcher]

@G_M_C
ATI is moveing away from their CAL/METAL base to OpenCL, but i doubt Nvidia will skip their whole CUDA idea not in the distant future at least :D
Tough imho GPU gets more succesfull each day more Video stuff is coming out wich has GPU suport on the comercial side of things @ least, here something very interesting with GPU support (http://www.motiondsp.com/products/IkenaReveal) (and it's easy to see for what GPU ;) )

@neuron2
lol Do you ? :)

[Gusar]

There really needs to be a common language/compiler etc. to make this whole venture more feasable imho.Enter Intel Larrabee. It's x86. You can write plain old C code for it and compile it with your compiler of choice (MSVC, gcc, ...). CUDA is not the answer for hardware accelerated decoding/encoding (just read about Dark Shikari's adventures with it), Larrabee is - well, we'll see once it's released.

[lucassp]

You don't need large amounts of GPGPU/CUDA specific programming to access the VP2 Decoder. nVidia simply offered direct access to the VP2 Decoder through CUDA...and we can use CUDA freely.

Even though it's BluRay, HD DVD, DVB-S/T limited, it's still way faster than any software decoder.

[G_M_C]

Enter Intel Larrabee. It's x86. You can write plain old C code for it and compile it with your compiler of choice (MSVC, gcc, ...). CUDA is not the answer for hardware accelerated decoding/encoding (just read about Dark Shikari's adventures with it), Larrabee is - well, we'll see once it's released.

That's what i said & what think ;)
click (http://forum.doom9.org/showthread.php?p=1173558#post1173558)

You don't need large amounts of GPGPU/CUDA specific programming to access the VP2 Decoder. nVidia simply offered direct access to the VP2 Decoder through CUDA...and we can use CUDA freely.

Even though it's BluRay, HD DVD, DVB-S/T limited, it's still way faster than any software decoder.

That's nV, but what if you have a Ati card ... or a Intel onboard ? That's the problem; Interchangability !

[lucassp]

You can write plain old C code for it and compile it with your compiler of choice (MSVC, gcc, ...)

False. You still need a custom compiler. It has been discussed before.

@G_M_C: ATi should do the same thing. They should offer access to UVD through the FireStream SDK.

I don't think Intel has H264 decoding capabilities yet.

[Sharktooth]

a compiler with larrabee support or a custom compiler.
that means, nothing is "automatic"...

[G_M_C]

False. You still need a custom compiler. It has been discussed before.


a compiler with larrabee support or a custom compiler.
that means, nothing is "automatic"...

And how it that different from having to use CUDA or some other "GPU-specific" compiler/language ?

Larrabee might be on it best when used with a specific compiler, but it uses x86 code; And x86 code is much more general than CUDA/BROOKE whatever GPU-language. That why Larrabee will probably more eaily to use, there are simply many many more people with x86-knowledge, than there are people with CUDA-knowledge. And given Intels-trackrecord for making very decent (if not very good) compilers, you can expect a Larrabee to arrave togeter with its Larrabee-enabled compiler.

[slavickas]

err guys you have too much free time spaculating what Laterbe will be? (ok you can ;) be imho it has nothing to do with this thread)

somewhat on topic: anybody recently checked IPP's H.264 decoder feature wise? maybe it could be substitute for lavc , hey even quite likely it will get laterbee support whenever it gets released

[lucassp]

And how it that different from having to use CUDA or some other "GPU-specific" compiler/language ?

The VP2 is a stand alone part of the GPU silicon. The only way we (Open Source Community) can access it is by using the CUDA API. You have to use CUDA to send the stream to the GPU and to get the resulting image from there. You don't need to write any highly parallel/CUDA algorithm to do this.

[G_M_C]

The VP2 is a stand alone part of the GPU silicon. The only way we (Open Source Community) can access it is by using the CUDA API. You have to use CUDA to send the stream to the GPU and to get the resulting image from there. You don't need to write any highly parallel/CUDA algorithm to do this.

Yes, on nVidia-hardware. What if I have a Ati/AMD HD4870 ? CUDA wont work on that ... Thats the whole problem with GPU-assisted programms, you need to make more than 1 version.

[Guest]

I don't have to make multiple versions. If someone wants to use my HW assisted Nv support, then they buy an Nv card. If not, they fall back to the SW decoding. I might *choose* to support other platforms, but I don't have to, just like I don't have to support Linux.

[lucassp]

Yes, on nVidia-hardware. What if I have a Ati/AMD HD4870 ? CUDA wont work on that ... Thats the whole problem with GPU-assisted programms, you need to make more than 1 version.

That's why I'm hoping ATi will include UVD access into its FireStream SDK or OpenCL.

For the moment even an CUDA/VP2 based AviSynth filter would be nice if it can get rid of libavcodec's problems.

[Sergey A. Sablin]

somewhat on topic: anybody recently checked IPP's H.264 decoder feature wise? maybe it could be substitute for lavc , hey even quite likely it will get laterbee support whenever it gets released

not sure about new high444 profile, but everything else seems to work. paff shall definitely work.
and it shall be no doubts that it will support larrabee.

[Dark Shikari]

not sure about new high444 profile, but everything else seems to work. paff shall definitely work.
and it shall be no doubts that it will support larrabee.It sounds like you've tested the IPP decoder--out of curiosity, how fast is it?

[Sharktooth]

@G_M_C: even more ppl know C/C++... and still have problems with CUDA...
the x86 thing is all fuzz. basically larrabee is nothing more than a stream processor. most pll will use C or other languages to access it thru the APIs...

[Sergey A. Sablin]

It sounds like you've tested the IPP decoder--out of curiosity, how fast is it?

last time it was half a year ago... so just from the top of my head - 15% slower than coreavc maybe (on the content I've used). and it was previous release of IPP (5.2 beta or something)

[crypto]

I don't have to make multiple versions. If someone wants to use my HW assisted Nv support, then they buy an Nv card. If not, they fall back to the SW decoding. I might *choose* to support other platforms, but I don't have to, just like I don't have to support Linux.
I like the idea. And it is alway good to have an alternative, if someone runs into problems with libavcodec.

[edison]

The whole thing of Larrabee is not just x86, it is "1 scalar x86 ALU + 1 SIMD16 ALU" for each core, you need to learn the new ISA extension: LRBni for achieve full performance. If not, you can get only 1/17(maybe lower this) performance of Larrabee .

[Sulik]

I have a feeling that Larrabee will end up much more similar to CUDA than to standard x86 development, and will have similar data flow restrictions and performance pitfalls.

Even though it does have the advantage of the familiar x86 ISA, most of the asm code developped on x86 today is there to take advantage of SIMD instructions, which will be quite different than SSEx on Larrabee (maybe why intel/MS are trying to push everyone to use intrinsics rather than inline assembly, even though it actually makes the code less readable - to me at least).

Though the generalized L1 cache vs shared memory might avoid some of the severe performance problems of CUDA on the current generation of GPUs, no one really knows how much CUDA perf will improve in the next generation of GPUs available by the time Larrabee hits the shelves.

[MfA]

From what Intel has presented it seems Larrabee won't even have a fast SAD instruction (or any fast byte wide SIMD instructions at all for that matter, everything is upgraded to 32 bit before processing).

[canTsTop]

Is it really GPU that much more powerful than CPU? :devil:

http://www.youtube.com/watch?v=fKK933KK6Gg

[CruNcher]

it just shows the difference imho between single thread serial processing (shoot,wait,shoot,wait) and multi thread parallel processing (shoot all at once) also a CPU can do that but it's correct the GPU has much more cores to shoot @ once with currently, tough as Dark_Shikari said it's currently with CUDA much harder to programm this (and manage it to be efficient) :) see the Patio Problem ETI had to solve with their H.264 encoder.
Would be very well compareable with the Size of the 2 Devices here the CPU being small and known since years how it works and the GPU Big heavy machine new uknown land for many and harder todo maintainence work on. I guess next time when those 2 guys are invited by Intel the thing looks different again then you have 2 of these bigo machines and other things count.

http://www.youtube.com/watch?v=lX24AGLyYU4

http://www.youtube.com/watch?v=U7R90A7ZqLU <- even more powerfull then the current PSP (SD H.264) in Video Tegra does HD H.264 720p
http://www.youtube.com/watch?v=0UQVHJ3UFaA <- aswell Gaming
http://www.youtube.com/watch?v=XXYshhuJzh4 <- Power Draw is amazing (ARM11 Core + GPU accelleration running on Windows Mobile thus currently) :)
http://www.youtube.com/watch?v=DeupVAMnvFA <- the whole industry freaks out
http://www.youtube.com/watch?v=TVs6As1_ZT4 <- 3D GPS this year Mobile Devices (like HD (3D) Phones) next year and HD PMPs end of this year :)
http://www.youtube.com/watch?v=OvBqtx43x90 <- im quiete sure it's gonna use Nvidias APX 2500 Platform maybe with Android on top of it :)

[Guest]

Hmm Donald i guess you have no access over the API to Nvidias Shader based Motion Adaptive Deinterlacer right ? Actually, it turns out that I do. And to the 3:2 engine as well.

[Ranguvar]

Niiiice....