MIPS Creator CI20 Now Available, Costs $65 USD

[ssvb]

Ingenic's MXU application specific extensions are supported by specially patched binutils. Upstreaming them is planned but has not happened yet:
https://groups.google.com/forum/#!to...20/NqB9cGgSoj0

Thanks for the link! This looks like some sort of a progress over "The assembler is also available from Ingenic, in the form of an bash/awk script" from 2009. Having a working assembler and the hardware allows to obtain a lot of information via a trial and error method. And appears that somebody is already reconstricting the MXU documentation in a wiki page here: http://wiki.dingoonity.org/index.php...evelopment:MXU. However a proper MXU documentation directly from the vendor would be very nice to have.

Anyway, based on what I see in the wiki, the MXU unit only has 32-bit registers, which puts it roughly into the same category as the MIPS DSP ASE or ARMv6 SIMD. This is not impressive at all. For comparison, modern ARM processors have much wider 128-bit NEON registers, which are much better suited for graphics/multimedia heavylifting.

It lists onlx MXU ASE, but that could be due to the kernel not having detection for other ASEs implemented. Or maybe the SoC doesn't support them after all.

Thanks for the /proc/cpuinfo information. Sadly the DSP ASE is not there, but this might be not very surprising considering that DSP ASE and MXU ASE are very similar to each other.

Was the system using a recent linux kernel? At least this CPU should support mips32r2 instructions, but such information does not seem to be properly listed and the following mips32r2 runtime detection code would not work right.

[ssvb]

PowerVR?

Looks like this is a no-go for linux users unless they allow distributing their closed-driver like the raspberrypi gpu driver can be.

That's a very valid point. I myself have no prejudice agains blobs (when security/privacy is not important). And a healthy competition between the blobs and free software drivers is a good thing for everyone. But blob suppliers are expected to take efforts to co-exist with the rest of the system peacefully:
1. No blobs in the kernel. This is pretty much obvious.
2. No blobs in the X server process. The GLES blobs are loaded on the client side anyway, so there is no reason to taint the X server. And there is nothing to hide in the DDX.
3. A permissive license for the blobs, which explicitly allows redistribution. So that the linux distributions are allowed to provide packages for the blobs.

For example, ARM Mali drivers satisfy the (1) and (2) requirements, but fail on (3). This causes a lot of inconveniences for the end users, because they must follow somewhat lengthy manual installation instructions from the community wiki pages or the vendor website. And sometimes deal with distro-specific quirks.

The PowerVR drivers currently seem to fail on both (2) and (3).

The Raspberry Pi at least has always handled the blobs in the right way.