[theora-dev] GSoC - Theora multithread decoder

[Timothy B. Terriberry]

Leonardo de Paula Rosa Piga wrote:
> Coarse grain functions are the best functions to be parallelize to
> become the overhead worthwhile, but the current implementation has one,
> at most two. The parts that I suggested in my initial plan are fine

The reason the current decoder does this is cache coherency. The idea is
that only a few (16 to 32) rows need to be kept in L1/L2 cache between
each stage of the pipeline, which is a big reason the current decoder is
as fast as it is on high resolution content.

It's possible break this pipeline back up into separate stages that
operate on the entire frame at once (e.g., just make the MCU size the
height of the frame). You lose cache coherency, but get coarse-grained
parallelism. Only testing will determine which is the better strategy.

> the decoding time should be reduced in 33%, but it was just 10% for
> pthread an 5% for openMP.

The chroma coefficients are usually quantized much more coarsely, so
they very likely don't account for a full 33% of the decode time even on
a uniprocessor. Fewer coded blocks and fewer tokens to unpack in the
blocks that are coded means fewer and smaller iDCTs, fewer invocations
of the loop filter, etc.

It's sad that OpenMP didn't do better... I was hoping with the option
available to them to do platform-specific tricks, they could cut down on
the overhead of pthreads, but I guess that stuff's just not "there" yet.

> These version will run the functions (c_dec_dc_unpredict_mcu_plane +
> oc_dec_frags_recon_mcu_plane) and
> (oc_state_loop_filter_frag_rows + oc_state_borders_fill_rows) in
> parallel. The upper bound for the gain is 60%, that is, let T2 be a
> video decoded with the pipelined implementation. T2 should be at most 0.4To.

I think you mean "at least". Let us know what your test results look
like (good or bad)! Keep in mind that, if possible, the same thread that
does oc_dec_dc_unpredict_mcu_plane+oc_dec_frags_recon_mcu_plane on a set
of blocks should also be the one to do
oc_state_loop_filter_frag_rows+oc_state_borders_fill_rows on the same
set of blocks (and hopefully the scheduler doesn't muck things up by
moving the thread to a different physical CPU inbetween).