CPU specific modules (neon, SSE4, etc).

[illume]

As a user I want to install and distribute pygame where the CPU specific optimizations are included for optimized functions.

As part of the PR Adds MMX, SSE2 & Arm NEON optimised versions of blit_blend_premultiplied() some more SIMD optimized functions were made. However there's no runtime detection for those functions, so some are disabled by default.

[illume]

This is based on some of the discussion in #1711 ...

---

Here's another way we could hack up distutils based on python modules and compilation flags. (obviously these ways would be out of scope for this PR)

Currently Setup.SDLX.in has stuff like this.

surface src_c/surface.c src_c/alphablit.c src_c/surface_fill.c $(SDL) $(DEBUG)

Adding CPU specific modules could be done by adding flags (-mfpu=neon) to the end like this:

surface_fpu_neon src_c/surface.c src_c/alphablit.c src_c/surface_fill.c $(SDL) $(DEBUG) -mfpu=neon

Then the init machinery (__init__.py) can load the correct surface (or surface_fpu_neon) module based on the CPU capabilities. I guess all the other C based routines would also be sped up because of better compiler optimizations too.

[MyreMylar]

Was just quoting that :)

I think it would require us to:

• Pull out the SSE2/ARM NEON optimised functions into a separate .c file.
• Test it to see if it works. In theory with the current state of the code the intrinsic functions are never run at runtime anyway if there is no platform support, so that part shouldn't need any changes.

All we are really trying to do is isolate the impact of the -mfpu=neon option to a single bit of code rather than have it accidentally affect the whole project.

[illume]

Another possibility is compiling the whole wheel into a separate package.
Such as pygame_neon or pygame_sse42. This could potentially work better with other tools. Then the main pygame could try and import that.

Speaking of other tools: things like cx_freeze and pyinstaller need to be considered.

Also, we can distribute our own wheels however we want, but how can other distro packages (such as Debian pygame) take advantage of the solution?

[MyreMylar]

A discussion of problems Google had with compiler specific modules using AVX:

https://randomascii.wordpress.com/2016/12/05/vc-archavx-option-unsafe-at-any-speed/

[MyreMylar]

I discussed this a little bit on the end of this issue too:

#1229

[illume]

There was some more discussion in here about an issue with neon compilation on pi: #2373

[ankith26]

The arm-neon optimisations are much needed, as they give a significant speed boost for pygame (checked on a raspberry pi 3). They might also be of advantage to other arm based systems, like android and the new M1 macs. Also, my theory is that with Apple shifting to ARM, and the switch proving effective, more companies are likely follow the lead. Soon we might see more ARM systems entering the market, and one fine day in the future, ARM might even end up overtaking intel/amd.
So setting up arm optimisations and enabling them by default sure seems like a good idea to me.

Creating seperate files, conditional compilation, runtime detection, all that sounds very good. But its a bit too complicated, and is a lot of work. I have a much simpler solution, and that is changing this line of code

pygame/setup.py

Line 136 in 91df485

if consume_arg('-enable-arm-neon'):

With

# ref: https://en.wikipedia.org/wiki/Uname
if platform.machine() in ["armv7l", "armv8l", "arm64", "aarch64"]:

Yes, this is compile-time platform detection and wheels compiled for these platforms will only work on these platforms (isn't that the point of wheels anyways). Things like creating an armv7l wheel and later renaming the wheel to armv6l will no longer work if this change is applied (that is a bad idea anyways, because you never know what other problems doing that creates). This change might create some issues for the folk at piwheels, so we must make a decision considering that in mind (we do not want to bother the people at piwheels, if we end up doing a change like this, we might have to consider building arm linux wheels ourselves or something like that).
Also, the current behavior applies the compiler flag -mfpu=neon to all the files. I am in favour of retaining this behavior, because it seems to optimise more stuff. This might need more testing (I have not come across any issues while testing on my pi3b, though)

[MyreMylar]

This build issue was discussed a while ago with piwheels here in case anyone else is missing the context:

#1229

Essentially right now piwheels hosts an 'arm6' and an 'arm7' wheel publicly but in 99% of cases those are actually the same 'arm7' wheel built from source & renamed automatically by script. Having actually separate arm7 and arm6 wheels is instead a manual hand compilation process which (I think) was only being done for new releases of openCV.

Why this matters is because on raspberry pi, piwheels is the default repository when users do a pip install pygame rather than the PyPI that most other platforms use (and that we upload to) and I suspect where they get the pygame from that gets preinstalled on Raspberry Pi's as well.

So while making separate arm6 & arm7 wheels seems like an easy solution for us working on pygame, it is not for the piwheels maintainers.

[MyreMylar]

...though I see in this blog post:

https://blog.piwheels.org/new-opencv-builds-including-opencv-4-4-x/

..That piwheels are, as of September last year, building OpenCV automatically too. So maybe there is something to be worked out here with @bennuttall to have separate genuine arm6 and arm7 wheels of pygame.

[bennuttall]

I'd be happy to build armv7 wheels separately (because it's pygame) if possible.

Is there a way to supply the compiler flag to the pip command?

[MyreMylar]

Is there a way to supply the compiler flag to the pip command?

Do you mean - does this work:

python setup.py install -enable-arm-neon

Because if so, yes.

I don't know of the top of my head if pip passes along arguments to setup.py if it can't find a wheel. I'm generally not much of an expert on our building process, but I did add that one flag.

I believe we would just need that neon flag enabled for the arm7 (pi3 & pi4) wheel and disabled for the arm6 (pi Zero etc) wheel.

[bennuttall]

I meant something like pip wheel pygame==2.0.0 -enable-arm-neon (I guess that won't work as enable-arm-neon is not a pip flag) - but maybe an env var like ENABLE_ARM_NEON=1 pip wheel pygame==2.0.0

I ask because that's the normal way we build wheels - using the pip wheel command - it means you get the source dist that was released to PyPI for any given version, rather than cloning from github and finding the right commits to build from.