GPU Accelerated H.264 Encoder

[Guest]

You're knocking down a straw man. I was responding to:

"It's ridiculous how difficult CUDA is. I was flabbergasted at the complexity of a simple "Hello World" CUDA program."

That is a problem much simpler than mine. I distinguish between the difficulty of parallelizing algorithms and the difficulty of prgramming using the CUDA API. Do not conflate them.

Now show me your parallel data reduction in 3 lines of C code, or admit that you too are blustering.

[LoRd_MuldeR]

Originally Posted by neuron2

You're knocking down a straw man. I was responding to:

"It's ridiculous how difficult CUDA is. I was flabbergasted at the complexity of a simple "Hello World" CUDA program. That is a problem much simpler than mine."

I would disagree here. CUDA cannot use printf() or similar, so the "Hello world!" of CUDA looks a bit different than what a classical "Hello world!" looks like. Probably the most popular example ("Hello world!") program for CUDA that is shown as the very first example in all the "getting started" guides is the parallel matrix multiplication - already a bit more complex than your color conversion, as it isn't as "local".

Originally Posted by neuron2

I distinguish between the difficulty of parallelizing algorithms and the difficulty of prgramming using the CUDA API. Do not conflate them.

Well, obviously you do not count all the "memory access pattern" mess (different for global and shared memory!) as a part of the CUDA API. Well, I agree that this is not really part of the API itself, but it's a very important aspect of the hardware. And if you ignore that hardware aspect, your program will never run fast on CUDA. So understanding the API to get "something" running on CUDA is one thing, understanding all the hardware aspects that have to be taken into account to get your program fast (and that is all reason why we use CUDA) is a completely different thing. If we look at the CUDA programmers guide, there is about ~10% API documentation and about ~90% hardware aspects ("performance guide"). Compared to that, programming for the CPU requires MUCH less knowledge of the hardware (up to some point, of course).

Originally Posted by neuron2

Now show me your parallel data reduction in 3 lines of C code, or admit that you too are blustering.

I didn't say the C code will be parallel too

For C code thread-parallelization is some kind of "extra boost", that in the optimal case will give you 2x or 4x speed-up, but still is optional. For CUDA thread-parallelization is essential. Using only a single thread on CUDA would be like making the code 1000x slower. Anyway, with C + OpenMP I would simply put a simple #pragma in front of my "3 lines" loop and the parallelization is there...

[Guest]

Originally Posted by LoRd_MuldeR

I didn't say the C code will be parallel too

That is my point, which you fail to see because you appear more interested in having a debate with me. I'm not interested in that so I'll bow out.

[hust_xcl]

Originally Posted by TheImperial2004

Totally agree . But !

I believe that the major issue here is to synth. the data between two different entities . What if the GPU is just too fast for the CPU to keep up with ? Of course we will need the CPU to do some calculations . If the CPU is 9x slower than the GPU , then whats the point ? In that case , the GPU will have to wait for the CPU to respond and complete its part of the job , *only* then the GPU will continue doing its part . Lagging is the major issue here . Feel free to correct me though

I agree too. Frequently transferring data between cpu and gpu will cost too much time.
Instead, data should be transferred by large pieces and with low frequency.

[hust_xcl]

Originally Posted by royia

Crossing my fingers for you.
Just for knowledge, are you aiming for Open CL or CUDA?

I wish I could help :-).

iRoyia, I have to suspend the work because the emulation mode does not support shared memory. while my old computer can only run in that mode. After I buy a new nv card, I will restart.
IMHO,
1.Interpolation can be optimized by cuda.
2. Full search is more suitable than diamond search to be used to offload me on gpu.
My algorithm is:
(1) Transfer an original frame and a reference frame to gpu
(2) For 7 search modes (16x16, 16x8, 8x16…), each one employs a full search of 8x8 search range around original point(0,0) on gpu.
(3) transfer all the mvs back to cpu
(4) in the analysis process, cpu makes use of the mvs ( predicated mv should be near 0) calculated by gpu.
If the mv is on the border of 8x8 search range, a refined search should be employed to enhance the search result.

[hust_xcl]

Originally Posted by Dark Shikari

That doesn't magically mean that it can be made faster on a GPU.

Dark Shikari：
Is there anyone working for it ? I hope i can give some help.

[TheImperial2004]

Full search is more suitable than diamond search to be used to offload me on gpu.

I failed to see this ... How could a full search be faster than a diamond one ? Even for a GPU ... ? Unless you meant something else by "more suitable" ...

[ajp_anton]

Offloading a full search makes more sense than offloading a diamond search.

[TheImperial2004]

Offloading a full search makes more sense than offloading a diamond search.

So -in theory- a full search won't give a big performance hit compared to a diamond one (For a GPU) ? Or did you mean that a full search is easier to offload than other searching algorithms ?

[Sharktooth]

he means diamond search is already pretty fast and there's is little or no need to offload it to the GPU... while full search is very time consuming and offloading it to the GPU would give a much, much bigger advantage.

[TheImperial2004]

he means diamond search is already pretty fast and there's is little or no need to offload it to the GPU... while full search is very time consuming and offloading it to the GPU would give a much, much bigger advantage.

hmm . That makes sense , I've never used diamond before -Always UMH- and it is fast enough on my Q8200 . Would like to see what full search can do for quality

[LoRd_MuldeR]

Originally Posted by TheImperial2004

hmm . That makes sense , I've never used diamond before -Always UMH- and it is fast enough on my Q8200 . Would like to see what full search can do for quality

Look at the built-in x264 presets. Nothing uses ESA or even TESA, except for the "placebo" preset. That should tell you what to expect from a "full" search

[TheImperial2004]

Look at the built-in x264 presets. Nothing uses ESA or even TESA, except for the "placebo" preset. That should tell you what to expect from a "full" search

Seems to be "less useful" for everyday encodes , even for archiving .

[Sharktooth]

ESA/TESA gain in respect to UMH is not significant and both are very slow. however, offloading the workload to the GPU would mean you get that marginal quality gain for free and you would also give some speed since no ME is done by the CPU.

[Dark Shikari]

Originally Posted by Sharktooth

ESA/TESA gain in respect to UMH is not significant and both are very slow. however, offloading the workload to the GPU would mean you get that marginal quality gain for free and you would also give some speed since no ME is done by the CPU.

Only if the GPU is fast enough to keep up with the CPU.

[Sharktooth]

sure, otherwise it will slow it down...

[hust_xcl]

Originally Posted by Sharktooth

he means diamond search is already pretty fast and there's is little or no need to offload it to the GPU... while full search is very time consuming and offloading it to the GPU would give a much, much bigger advantage.

Consider parallel me for all blocks on gpu, diamond search may cost more time than full search. Eg. 10 blocks, one of them search 80 points; even other only search 5 points, gpu should wait all the blocks to finish each me. In that case, diamond search will cost more time than 8x8 full search

[schweinsz]

Originally Posted by hust_xcl

(4) in the analysis process, cpu makes use of the mvs ( predicated mv should be near 0) calculated by gpu.
If the mv is on the border of 8x8 search range, a refined search should be employed to enhance the search result.

I believe that the GPU for H.264 encoding matters only if the GPU can do interpolation, integer-pel and sub-pel ME, mode decision, transform and quantization.
If you only offload the integer-pel ME and interpolation, it is less significant.

[Dark Shikari]

Originally Posted by hust_xcl

Consider parallel me for all blocks on gpu, diamond search may cost more time than full search. Eg. 10 blocks, one of them search 80 points; even other only search 5 points, gpu should wait all the blocks to finish each me. In that case, diamond search will cost more time than 8x8 full search

That's not the reason that diamond is the problem. You can simply limit the number of iterations to avoid that.

The reason diamond is problematic is that to get even remotely decent performance, you have to have coalesced loads for the GPU threads.

[hust_xcl]

Originally Posted by Dark Shikari

That's not the reason that diamond is the problem. You can simply limit the number of iterations to avoid that.

The reason diamond is problematic is that to get even remotely decent performance, you have to have coalesced loads for the GPU threads.

you are right!