Add DXT1-5 decompression on ARM

[ginkage]

This is for #16542 — I went ahead and implemented the software texture decompression on ARM.

I've tested this with libmali, and it works beautifully, I was able to run a few (simple) games in 720p full-speed (e.g. Demon's Souls at 30 fps) on my Rock 5A. I've made it a blanket change for all AARCH64 (otherwise propagating the corresponding caps would be a pain), but I do believe that it could even benefit the Mesa driver: that is, instead of doing a texture copy (rpcs3 to driver) followed by decompression (on the driver side), we can decompress directly to the driver's memory, skipping the copy step.

The library I used for decompression, bcdec, is one of the fastest out there (see e.g. https://aras-p.info/blog/2022/06/23/Comparing-BCn-texture-decoders/) and is available with an "Unlicense" (basically, public domain), not to mention the code is pretty compact.

I've also added the new driver enumeration, just in case...

Note that I was unable to verify the OpenGL changes, though I did mirror the said changes, just in case: even Raspberry Pi 5 can't run RPCS3 with OpenGL (fails to create context), and I doubt anyone in their right mind will ever try using RPCS3 without a Vulkan backend on ARM, so this shouldn't matter that much. But, of course, all changes were made sure to be exclusively ARM-specific.

[AniLeo]

Raspberry Pi 5 can't run RPCS3 with OpenGL

It can, you have to override feature level to 4.5. Our entire RPI5 showcase is done on OpenGL.

[ginkage]

It can, you have to override feature level to 4.5.

Ah, interesting! Alas, on my RPi5, when I run with MESA_GL_VERSION_OVERRIDE=4.5, this build https://github.com/RPCS3/rpcs3-binaries-linux-arm64/releases/tag/build-cd87a646219024b136f7cc4d0ceeb1a19d5c43ad doesn't quite work. The game launches, but only shows black screen. Am I missing something else?

[ginkage]

Oh, you were also using Arch Linux (I'm guessing, for more up-to-date drivers, right?), rather than Raspberry Pi OS...
I guess I should follow suit for testing with OpenGL on RPi5.

[kd-11]

I've made it a blanket change for all AARCH64 (otherwise propagating the corresponding caps would be a pain), but I do believe that it could even benefit the Mesa driver: that is, instead of doing a texture copy (rpcs3 to driver) followed by decompression (on the driver side), we can decompress directly to the driver's memory, skipping the copy step.

1. Arm is not only used in embedded you know. High performance parts also run on arm, so this is unacceptable. Decoding a 4k image is going to be faster on a 4090 than cpu.
2. Move this code to it's own file, it should be self-contained thing. If you're using imported code from a separate project, store it in 3rd party. If you wrote it yourself, it can live in a decoders folder somewhere.
3. Make link-time optional if possible via a cmake var.

[ginkage]

Thank you for the review. All good points.

1. I'll try to propagate the capabilities more cleanly.
2. bcdec code is technically 3rdparty, but I've modified it somewhat: stripped down, adapted to rpcs3 types, moved around color bits... It's available as Unlicense (public domain), and there's no need to pull in the whole project when we only need 10% of it (modified, too). I'll move it to a separate file in the same folder.
3. Not really possible to make it link-time optional: all Linux-ARM64 builds potentially need this.

[ginkage]

I've reworked the code somewhat, please take a look. I'm happy to revert the changes to GL if you want to make sure that the GL side remains unaffected. For VK, I tried to stick with the current logic as close as possible.

[kd-11]

I've reworked the code somewhat, please take a look. I'm happy to revert the changes to GL if you want to make sure that the GL side remains unaffected. For VK, I tried to stick with the current logic as close as possible.

Firstly, this is nice, clean work. This is almost exactly what was required, thanks a lot.

Secondly, as for the 3rd party thing - it's better to move it there otherwise someone else will likely do it during some header cleanup and mess up the history. We do import partial things there too from projects such as GPUOpen.
If possible, please create a folder there called "bcdec" and put the hpp there.

Third, the attribution included is quite truncated and the license missing. Even with the permissive "unlicense" license available, it's good to acknowledge the authors with each distribution. As a FOSS project, we try to stick to FOSS licensing as much as possible, and in this case the MIT option looks good enough that we really should include the attribution and original license in our codebase. With MIT you can also just paste the license at the top of the file in full and be done with it.

CC @AniLeo for licensing thoughts.

[ginkage]

Re: 3rdparty licensing — understood, acknowledged, will do!

[ginkage]

...and done.

[ginkage]

Should be ready to merge?..