[Pixman] [PATCH 3/3] MIPS: DSPr1: Basic infrastructure for DSPr1 optimizations

[Nemanja Lukic]

> I welcome extending support to more MIPS variants, and it's surely
> a good thing to have. Just the goal needs to be a bit more clear.
> 
> The point of runtime features detection is that the Linux distro
> maintainers can build a single library binary, which can run on a lot
> of devices and use CPU specific optimizations where they are available.
> 
> Do you know what kind of popular linux distributions are available
> for MIPS right now and whether the pixman packages shipped in these
> distributions are able to use DSPr2 optimizations properly?
> 

Popular linux distributions available for MIPS can be found at:
http://www.linux-mips.org/wiki/Distributions

I'm not sure if packages are built with MIPS32r1 or not in these
distibutions, but our current state on Pixman repo has this check in
configure for MIPS DSPr2:
#if !(defined(__mips__) &&  __mips_isa_rev >= 2)
#error MIPS DSPr2 is currently only available on MIPS32r2 platforms.
#endif
So if packages are not built with -mips32r2 in CFLAGS (or toolchain is not
configured to automatically add this flag), they will not be able to use
DSPr2 optimizations properly.

> We can use ARM as an example. The vast majority of ARM devices support
> NEON SIMD, however there a few exceptions (Tegra2 and Marvell SoCs).
> Because of these exceptions, Linux distributions don't enable NEON in
> CFLAGS when building their packages and just target the lowest common
> denominator. However pixman is still able to use NEON optimizations
> even in such conservative Linux distributions as Debian thanks to
> the runtime CPU features detection.
> 
> Now let's look at MIPS again. Hypothetically, some Linux distribution
> may decide to build packages and select MIPS32r1 as the lowest common
> denominator. And if some users install this distribution on their
> MIPS32r2+DSPr2 devices, will they still benefit from the DSPr2
> optimizations in pixman?
> 

As said above, with current state of the code, no they will not. I would
suggest, than, that we first remove configure check mentioned above, since
it is useless, and utilize runtime CPU feature detection, similar to what is
already done for NEON optimizations (forcing needed CFLAGS in configure.ac
in order to include optimizations at build time, and then choose at runtime
whether to use them).
Also, since the initial work for MIPS DSPr2, a couple of years ago, things
have changed, in terms of what can be detected at runtime on MIPS CPU. I'm
not sure about kernel version, I think it is 3.7, but from the august last
year, /proc/cpuinfo in section "ASEs implemented" can distinguish DSPr1 and
DSPr2 ISA extensions.

> The examples of MIPS32r1 are the Broadcom SoCs that you mentioned and
> also http://en.wikipedia.org/wiki/Ingenic_Semiconductor (which, I
> believe, was the SoC used in real Android tablets).
> 
> Now I admit that I did not really search too hard for the relevant
> MIPS related information about all this stuff. Actually, you are
> probably the one who is the most interested in doing this mini
> research to come up with a nice story about how your patches
> are going to improve the situation in the real world :-)

So, to summarize, I would suggest than, that this patch set, also include
one more commit that removes check mentioned above, which will than enable
same mechanism as we have in ARM NEON. Regardless of the way packages on the
linux distro will be compiled, we will include DSPr2 (and MIPS32r2 and
DPSr1) optimizations and rely on the runtime detection to use them or not.
I'll prepare new patch set, and upload it for review.

Thanks,
Nemanja Lukic