<div dir="ltr">On Thu, Apr 25, 2013 at 1:59 PM, Siarhei Siamashka <span dir="ltr"><<a href="mailto:siarhei.siamashka@gmail.com" target="_blank">siarhei.siamashka@gmail.com</a>></span> wrote:<div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I tried to look for some documentation about Broadcom 7420, but it<br>
appears to be scarce. This was possibly the best information I could<br>
find:<br>
<br>
    <a href="http://www.broadcom.com/docs/articles/MPR_11-22-10.pdf" target="_blank">http://www.broadcom.com/docs/articles/MPR_11-22-10.pdf</a><br>
<br>
And it says "This CPU implements the MIPS32 v2 instruction set with<br>
Broadcom-specific DSP and multi-threading extensions."<br>
<br>
Pixman library (cairo software rendering backend) supports some<br>
assembly optimizations for MIPS32r2 and DSP ASE thanks to the<br>
ongoing work of Nemanja Lukic. These optimizations may potentially<br>
provide some performance improvement on your hardware, but are only<br>
enabled for MIPS 74K cores in the runtime detection code:<br>
<br>
    <a href="http://cgit.freedesktop.org/pixman/tree/pixman/pixman-mips.c?id=pixman-0.29.2#n68" target="_blank">http://cgit.freedesktop.org/pixman/tree/pixman/pixman-mips.c?id=pixman-0.29.2#n68</a><br>
<br>
Tweaking the runtime detection code, you can also enable it on your<br>
CPU. I'm a bit worried about the "broadcom-specific" description of<br>
the DSP extensions in BCM7420. But it might still make sense to give<br>
it a try. Also some of the optimizations (simple blits and fills) in<br>
fact do not use DSP instructions and should also run fine on any<br>
MIPS32 core.<br></blockquote><div><br></div><div style>Thanks for your suggestions! Unfortunately your concerns about the chip are valid. It's actually an r1 processor. Broadcom has supposedly implemented some of the DSP extensions on a separate DSP chip, although I haven't had any luck enabling them up to this point. I'll have to talk with support and see what I can figure out. For the record I did enable this code on my board but it crashed horribly with illegal instructions. I'll have to take a look at sorting out which code will work on MIPS32.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mixing software rendering and hardware acceleration sometimes may not<br>
provide the best performance. If you have to do cache flush/invalidate<br>
operations too often, they can diminish any benefits of hardware<br>
accelerated solid fills and simple non-scaled blits.<br>
<br>
If you want a fair comparison of the hardware acceleration vs. software<br>
rendering backend, using assembly optimized blits and fills (with optimal<br>
prefetch, etc.) is quite important. Generic C implementation of blits<br>
and fills may be severely underperforming.<br></blockquote><div><br></div><div style>I agree, this is good advice. I've run similar tests on previous platforms using the generic C implementations. In those cases using the 2D hardware for blits and fills was necessary to get any reasonable performance from Cairo, at least for my use case. I think the key will be for me to figure out which parts of the ASM fast-path code I can use on my chip.</div>
<div><br></div><div>-- </div><div style>Mike </div></div></div></div>