<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<br><br>> Date: Sun, 21 Mar 2010 10:04:08 -0400<br>> From: tterribe@email.unc.edu<br>> <br>> >> There is some scope for multithreading the per-frame pipeline, but<br>> >> that only scales to three or four threads.<br>> <br>> The work I had in the pipeline was for parallel _decoding_ first,<br>> because this is considerably easier. If it works out, parallel encoding<br>> can be done within the same framework. The design work for this is<br>> already done, and I had started on the implementation, but it got put<br>> down as priorities changed and will probably not get picked up again<br>> before the 1.2 release.<br><br><div><span class="Apple-tab-span" style="white-space:pre"> </span>The problem with starting with a parallel decoder is that decoding is much easier. Correct me if I'm wrong but decoding requires much less computation than encoding. As a result, thread overhead will be exaggerated for decoding and won't reflect real-world use since parallel processing will mostly be used for encoding...</div><div><br><div><br><div>> It's unclear how well it will scale. Years ago we did a (very simple)<br>> parallel decoder that only partitioned things by color plane, and the<br>> speed-up was disappointing. There was also a GSoC project that attempted<br>> to improve on this, but it was not successfully completed. In theory you<br>> could have a separate thread for every MCU (64 pixels of height for<br>> 4:2:0, 32 pixels for 4:2:2 and 4:4:4). However, within-frame parallelism<br>> is fairly fine-grained, and the overhead of a standard mutex-based<br>> library like pthreads is pretty enormous for this kind of thing. People<br>> have reported getting speed-ups on FFT workloads as small as 10,000<br>> cycles with lock-free algorithms (by comparison, a single pthread mutex<br>> acquisition could take thousands of cycles by itself), but they made<br>> very specific assumptions about architecture, cache line size, etc.<br>> <br>> In short, this requires some non-trivial engineering to get it to work<br>> well, and for the moment my priorities are still on improving encoder<br>> quality before worrying about encoder speed. If there are qualified<br>> people out there willing to work on this, I'd be happy to explain the<br>> details of what needs to be done.<br><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>It sounds like you're considering building threads into libtheora itself. Since it targets an arguably small set of platforms, this is not an outrageous idea but I think it will be better to leave threading to the client and support parallelism through the API much like Vorbis. This way, people can choose their threading implementation or port libtheora to future platforms...</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Thank you...</div><div><br></div></div></div> <br /><hr />Take your contacts everywhere. <a href='http://go.microsoft.com/?linkid=9712958' target='_new'>Try Messenger for mobile</a></body>
</html>