<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><div>Hello,</div><div> </div><div>In your describe, seems similary my previous FPGA architecture, it is based on task pool.</div><div>the biggest problem isn't on the interface, the bottleneck is transfer bandwidth and dispose latency.</div><div>Of course, RDO context is another bottleneck.</div><pre><br>Best regards,</pre><pre>Min</pre><pre> </pre><pre>At 2014-03-25 01:04:57,"Nicolas Morey-Chaisemartin" <nmorey@kalray.eu> wrote:
>Hi everyone,
>
>My company (Kalray) is looking into writing a HEVC encoder based on x265 on its many core processor (MPPA-256).
>Because of our architecture (distributed, limited memory among other things), a direct port of x265 is not a viable solution.
>
>Our plan is to write a custom encoder core optimized for our platform and use it as an accelerator for x265 running on a x86 processor.
>This should look something like that
>
>/-------------------------\                 /---------------------\
>|  x86                    |                 | 1 or more MPPA-256  |
>|                         ||                     |
>|  x265 preAnalysis +     |<= PCI Link => | Kalray Encoder Core |
>|  Rate Control           ||                     |
>|                         ||                     |
>\-------------------------/                \---------------------/
>
>The idea for the encoder core is to implement a CTU encoder.
>This leaves us some flexibilty on how we want to dispatch the CTU accross the cores (Tiles, frame parallelism, etc.)
>
> From what I could gather after a quick glance at x265 code is that right now, x265 is using HM "as is" to do the actual encoding. Meaning except for a few exceptions, HM code is use directly to try out the different modes, estimate cost, generate bitstream, etc.
>
>Therefore, our idea was to use HM structures as a "stable" interface between x265 and our encoder core. From these structures we can extract all the required info (pixels, reference frames, QPs, etc.) and convert/transfer it to our core.
>
>What is your opinion on this approach?
>Is HM classes (at least structure wise) an interface stable enough to do this?
>
>We are still in the design phase about this so any idea is more than welcome.
>
>Regards
>-- 
>Nicolas Morey Chaisemartin
>Phone : +33 6 42 46 68 87
</pre></div>