h264 multithreading, chapter 2
Hi, Even though I previously dismissed speeding up h264 decoding by splitting entropy decoding from the rest in two threads I decided to take a quick shot at it. The attach patch gives ~20-30% speedup on single sliced CABAC content. Basically, the code decodes up to 128 macroblocks in one thread while doing prediction+idct+deblock of the previously decoded 128 blocks in another thread. 20-30% is not exceptionally much, I would have expected a bit more. If you have a look in the patch you'll notice that it brutally copies the relevant fields back and forth from the H264Context. I tried embedding the H264mb into H264Context so i could reduce it into one single memcpy(), this does not make any difference (expect that it makes the patch about 3000 lines longer :-) I also tried passing an additional pointer around to all functions to entirely get rid of the memcpy()ing. This does not make any significant change either (And I know from my first attempts with slice-level multi threading that this slows down the single threaded case). All this kind of makes sense (i think) if you ponder that the data needs to be transfered from CPU1's cache to CPU2's cache (if it's even still around in CPU1's cache). Even with some type of shared cache mechanism (I'm not actually sure how core2 duo does this) the probability that the data from the previous 128 macroblocks still is in place is probably minimal. I tried lowering the number of macroblocks processed per round, but the overhead of thread synchronization quickly defeats any gain (If you only do one macroblock per round, it's about 7-8 times as slow :-) well well... It is (obviously) not intended/ready for any formal review. MBAFF support is lacking, there is some code-duplication and other ugliness. But rather before I spend any more time on it I'd like to know if people think it is worth finishing. If we in the future also add frame based parallelism we would end up with three different techniques, (== bloated == hard to maintain), then again, perhaps one of them can be removed when we've got the full picture. I dunno... Ideas, hints, test-results, flames are welcome..
The attach patch gives ~20-30% speedup on single sliced CABAC content.
That's actually better than I would have thought.
But rather before I spend any more time on it I'd like to know if people think it is worth finishing.
Well, as already discussed previously : - slice based parallelism depends on the video, so will not be always possible. Furthermore, it scales as much as the encoder was scaled, so though it's an easy solution, it's not a pretty one - cabac / reconstruction parallelism : relatively good speed up, though it will depends on the bitrate of the video ( low bitrate -> bad scaling, very high bitrates -> bad scaling too ), and no scaling over 2 CPUs. There again, not necessarily pretty, but effective. More effective imho than slice based, and sufficient for decoding anything up to 1080i30 40 Mbit/sec on a C2D, I would say. - frame based, which I think should be the "best" method : a priori very scalable ( if x264's threading efficiency is achieved ), no constraint on the video except for vertical downward motion vectors, but, alas, not tested, so scalability is hypothetical. All that to say I'm torned between a theorically clean ideal solution, and a dirty but already working one. One thing is sure, I don't like slice based parallelism :) Regards, Mathieu Oh, and thanks for the patch, since I'm the lucky owner of a C2D, even though I call your threading method "dirty", that will allow me to play back all the stuff I wasn't able to play :)
The attach patch gives ~20-30% speedup on single sliced CABAC content.
That's actually better than I would have thought.
But rather before I spend any more time on it I'd like to know if people think it is worth finishing.
Well, as already discussed previously :
- slice based parallelism depends on the video, so will not be always possible. Furthermore, it scales as much as the encoder was scaled, so though it's an easy solution, it's not a pretty one well but i can tell that it works pretty well, at least for all german HDTV broadcasts i have tested. And it gives a nearly 1:1 balancing over
Mathieu Monnier schrieb: the cores, that is really hard to beat by other methods, except frame-parallel decoding.
- cabac / reconstruction parallelism : relatively good speed up, though it will depends on the bitrate of the video ( low bitrate -> bad scaling, very high bitrates -> bad scaling too ), and no scaling over 2 CPUs. There again, not necessarily pretty, but effective. More effective imho than slice based, and sufficient for decoding anything up to 1080i30 40 Mbit/sec on a C2D, I would say. i have doubts here, with deblocking the decoding is really cpu-demanding with these resolutions. If you shave off 20-30% "only", it wouldn't be enough. One core would be maxed out, the other at 30%. Not good...
- frame based, which I think should be the "best" method : a priori very scalable ( if x264's threading efficiency is achieved ), no constraint on the video except for vertical downward motion vectors, but, alas, not tested, so scalability is hypothetical. Has the tiny disadvantage that decoding is delayed up to N-1 frames when N frames are decoded in parallel, but that shouldn't be a problem. Can use free cpu time of any core better than slice-parallel decoding (with N = 2 * #cores or so).
-- Greetings, Thorsten
i have doubts here, with deblocking the decoding is really cpu-demanding with these resolutions. If you shave off 20-30% "only", it wouldn't be enough. One core would be maxed out, the other at 30%. Not good...
I estimate that compensation + deblocking @ 1080i30 can be done in real time on the single core. Perhaps it's too optimistic for low end C2D ( E4200 @ 1.8GHz ). If it is, one can try to deblock in a separate thread ( but that makes it even uglier ) Regards, Mathieu
i have doubts here, with deblocking the decoding is really cpu-demanding with these resolutions. If you shave off 20-30% "only", it wouldn't be enough. One core would be maxed out, the other at 30%. Not good...
I estimate that compensation + deblocking @ 1080i30 can be done in real time on the single core. Perhaps it's too optimistic for low end C2D ( E4200 @ 1.8GHz ). If it is, one can try to deblock in a separate thread ( but that makes it even uglier ) well i have a 2Ghz C2D here and it may work mostly, but can get pretty close sometimes, it is risky for e.g. a home theater system. It is much better to balance over two cores and have much more margin left. The other disadvantage - beside more complex code - is that it is
Mathieu Monnier schrieb: limited to 2 cores. Slice-parallel and frame-parallel can use more than 2 cores. So yes, i like frame parallelism too, but the slice-parallel isn't that bad either :-) -- Greetings, Thorsten
On Tue, Sep 25, 2007 at 10:44:19PM +0200, Andreas ?man wrote:
Hi,
Even though I previously dismissed speeding up h264 decoding by splitting entropy decoding from the rest in two threads I decided to take a quick shot at it.
The attach patch gives ~20-30% speedup on single sliced CABAC content. Basically, the code decodes up to 128 macroblocks in one thread while doing prediction+idct+deblock of the previously decoded 128 blocks in another thread.
20-30% is not exceptionally much, I would have expected a bit more.
If you have a look in the patch you'll notice that it brutally copies the relevant fields back and forth from the H264Context.
I tried embedding the H264mb into H264Context so i could reduce it into one single memcpy(), this does not make any difference (expect that it makes the patch about 3000 lines longer :-)
I also tried passing an additional pointer around to all functions to entirely get rid of the memcpy()ing. This does not make any significant change either (And I know from my first attempts with slice-level multi threading that this slows down the single threaded case).
All this kind of makes sense (i think) if you ponder that the data needs to be transfered from CPU1's cache to CPU2's cache (if it's even still around in CPU1's cache). Even with some type of shared cache mechanism (I'm not actually sure how core2 duo does this) the probability that the data from the previous 128 macroblocks still is in place is probably minimal.
I tried lowering the number of macroblocks processed per round, but the overhead of thread synchronization quickly defeats any gain (If you only do one macroblock per round, it's about 7-8 times as slow :-)
well well...
It is (obviously) not intended/ready for any formal review. MBAFF support is lacking, there is some code-duplication and other ugliness. But rather before I spend any more time on it I'd like to know if people think it is worth finishing.
If we in the future also add frame based parallelism we would end up with three different techniques, (== bloated == hard to maintain), then again, perhaps one of them can be removed when we've got the full picture. I dunno...
you already summarized everything ... i hope we will have frame based prallelism soon, when will you implement it? :) after that we can decide if this makes sense or not ... we could decide before but that would be a decission based on guessing which isnt good we might end up wasting time cleaning and reviewing code and likely even fixing bugs and then just find out theres no speed gain from it relative to frame based ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates
Hi, Michael Niedermayer wrote:
you already summarized everything ... i hope we will have frame based prallelism soon, when will you implement it? :)
My plan was to start with this after the PAFF-dust has settled. I need to get my head around the PAFF stuff and see how/if it affects the frame level parallelism.
after that we can decide if this makes sense or not ... we could decide before but that would be a decission based on guessing which isnt good
we might end up wasting time cleaning and reviewing code and likely even fixing bugs and then just find out theres no speed gain from it relative to frame based ...
Yes, that's probably wise, i just had a few hours to spend and thought i'd share the stuff so far.
Hi On Wed, Sep 26, 2007 at 03:37:35PM +0200, Andreas ?man wrote:
Hi,
Michael Niedermayer wrote:
you already summarized everything ... i hope we will have frame based prallelism soon, when will you implement it? :)
My plan was to start with this after the PAFF-dust has settled. I need to get my head around the PAFF stuff and see how/if it affects the frame level parallelism.
btw, if you look at the PAFF patch, dont hesitate to help with reviewing it posting suggestions for simplifying, ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus
2007/9/26 Michael Niedermayer <michaelni at gmx.at>:
Hi
On Wed, Sep 26, 2007 at 03:37:35PM +0200, Andreas ?man wrote:
Hi,
Michael Niedermayer wrote:
you already summarized everything ... i hope we will have frame based prallelism soon, when will you implement it? :)
My plan was to start with this after the PAFF-dust has settled. I need to get my head around the PAFF stuff and see how/if it affects the frame level parallelism.
btw, if you look at the PAFF patch, dont hesitate to help with reviewing it posting suggestions for simplifying, ...
[...] -- Michael ? ? GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG+mrzYR7HhwQLD6sRAuw0AJ9p4Pu0oly8hrgPpXGsPQI07FR9+gCdH5cg A7PHSDhObOXYwKafSfqAUv4= =KUGS -----END PGP SIGNATURE-----
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
I wonder if i can make use of this on a cell / ps3 to increase cabac decoding performance on the SPE processors Biggest issue would be to get the right parts copied out of the context prior and not post the decode_mb_cabac Anyone willing to help me on that ? -- Kristian Jerpetj?n Tlf: +4721694436 Mob +4792822774 Email: kristian.jerpetjoen at gmail.com
participants (5)
-
andreas＠olebyn.nu -
kristian.jerpetjoen＠gmail.com -
manao＠melix.net -
michaelni＠gmx.at -
tjordan＠macrosystem.de