NEON-based YUV->RGB conversion

[icculus]

This could really benefit ARM-based things like the Raspberry Pi, which might not have shaders in the libretro core to accelerate the YUV->RGB conversion, but have NEON, so it can lessen the CPU cost.

This is less important to the immediate concerns on Intel processors, but SSE could be nice, too.

[icculus]

Okay, status update:

I had written some NEON code for this for the Nintendo Switch before, which we shipped in Star Wars Republic Commando. It made video playback go from unusable to full speed.

BUT: it required aarch64 instructions, which we can't rely on for the Raspberry Pi, since the things are usually running in arm32 mode! Also, I got the NEON version running on an M1 Mac, and it didn't make one bit of difference to the speed, so there really wasn't any platform where this was worth keeping.

So I spent some time with the existing C code, and optimized a bunch of inefficiencies out of it.

This is still a CPU killer, but it's significantly faster now. On x86-64, it's probably 30-40% faster now.

On the Raspberry Pi, it's not such a dramatic improvement (but maybe my test is eating too much memory, so there are other bottlenecks?), but I think it's maybe dropped from 14 milliseconds per frame to 12. It might be juuuuust enough to keep this ahead of the game enough to keep audio flowing.

It may still be worth seeing if there's a NEON approach that works with this now that the normal C code has changed so much, too.

@vanfanel, if you want to try the latest in revision control again, I'd be curious if this helps (but it might not).

[vanfanel]

I have just tried latest GIT code just now, and the same audio dropouts in the Libretro core are still present.
However, please incorporate 64bit NEON code: 64bit is the standard now in Aarch64, included the Pi3 and Pi4, the 64bit Raspberry Pi OS is not a BETA anymore, it's considered stable.
There are many orther aarch64 SBCs, and Debian and derivatives run on that by now.

Don't look back at 32bit armhf as the standard, that's legacy for Pi1 and Pi2 now which won't run the core properly anyway.

[icculus]

I'm working on rewriting the NEON code; I've got something faster than the previous attempt that I'm still debugging. Stay tuned!

[vanfanel]

Woho! Thanks for the update! I for one will stay veeeeery tuned for this 👯

[icculus]

Okay, I pushed it. This is a good improvement over the existing code, and in aarch64 mode it'll likely be better since it won't run out of NEON registers.

This was tested on a Pi4 in 32-bit mode. I had to add -mfpu=neon to the compiler command line, I'm not sure if this will be necessary for aarch64. It worked on aarch64 macOS, too.

[vanfanel]

I just rebuilt from latest sources. These are the flags I use (I am on Aarch64):

cmake .. -DCMAKE_BUILD_TYPE=Release -DDIRKSIMPLE_SDL_DEFAULT=OFF \
-DCMAKE_CXX_FLAGS="-march=native -mtune=native" \
-DCMAKE_C_FLAGS="-march=native -mtune=native"

However, I see no difference with this version: I can still hear sound drop-outs during gameplay, very noticeable in the begining of the "Dirk resurrection" scene, for example.

[icculus]

Okay, we're going to move on to OpenGL then. 🤷‍♀️

[vanfanel]

I suspect OpenGL won't change much and the same dropouts will be present.

Just an idea: wouldn't it be possible to have the game logic converted to C? Really, I am sure it's LUA causing those audio dropouts on low-end ARM.