Re: mulithread rework

Quoting Con Kolivas <[email protected]>:
> I consider this experiment over. Thanks everyone for your replies, and I'm
> sorry I couldn't find something useful.

NB: the following message may be of interest if block

That's because the flow can be prioritized differently than it is in the current
implem:

You drew something like:
 XXXXXX->
 XXXXX->
 XXXX->
 XXX->
 X->

The arrows show the progress of threads.

I think a better suited flow would be, looking at only two thread flows:

 XUXXXX->Thread 1 progress
 LO
 X
 |
 v
Thread 2 progress

1) thread 1 and thread 2 work on two completely different set of
uncorrelated data. They should progress fast because no synchronisation
is required between them. I won't lie, this would work prefectly for the
first row and first column of MBs. Synchronization problems occur as soon
as threads would be dealing with unfinished left columns or unfinished top
rows. But as soon as their neighboring column/row is finished, the thread
progress should be fast.

2) Each time thread 1 or thread 2 makes progress, it looks at the O
macroblock neighbors U and L. If both U and L are completed, it pushes O
to the task queue.

Refinement) before pushing O to the task queue. I think it would be smart to
look how much progress thread 1 did, and thread 2 did. We push to the task queue
a couple (0, direction) where direction orients the progress of the thread
that will pick the task. If the progress of thread 1 and thread 2 are roughly
the same, pick a random direction, or maybe using the longest possible
direction (horizontal directly in most cases 4/3, 16/9).

Conclusion(?)

With this approach you should at least keep busy 2 threads, and sometimes
use some more. So we should have more than 30% improvement. I don't expect
a big big improvement because there will always be lot of starvation cases
where threads will just sleep quietly waiting for more blocks to be pushed.

Did you try something like that ?

-- 
Edouard Gomez