[CI] : Add Mini builds for x64 and x64 SSE2

[rtissera]

This PR adds support for building DuckStation-Mini to x86_64 and x86_64 SSE2 targets.

[stenzek]

I'm a little confused about the use case here - mini is only intended for systems that aren't running a window manager, and is missing a ton of functionality (most important being the ability to update itself). Like super low spec arm boards for example, and afaik there aren't any x86 machines like this.

Not 100% against the idea, but it would need to have a use case that's not already covered.

[rtissera]

I understand your valid point.
I felt like the mini flavor could fit well on Steam-Deck-like handhelds or constrained N100-class devices.

[stenzek]

Don't those still have a window manager/compositor? I don't own any of these, but I was under the impression that SteamOS etc ran gamescope even in game mode.

[rtissera]

Yes, SteamOS is based on gamescope compositor, it can run the full Qt build for sure, just Mini is lighter.
I understand your valid concerns regarding the "it's only a subset of the regular build".
Maybe I can have a look in auto-update-mini-build functionality, if that's your main point of concern.

[stenzek]

Performance-wise it's exactly the same code running. Startup time is actually slightly worse in the mini variant since it needs to create the GPU device for BPM. The Widgets UI doesn't need to.

Basically, running the Qt appimage with -bigpicture is no different to Mini, unless you want to run without a WM.

There's also some other issues, like fullscreen mode switching not working because SDL doesn't let you disconnect a GL context from a window, that work fine in the full build.

[rtissera]

Ok, understood, wrong assumptions from my side then.

I did more CI work if you are interested that I can throw in another PR, especially CI build infrastructure + mini build for riscv64 (maybe the full one is more approriate, but cross building Qt to RV64 is going to be another story...).
Let me know your thoughts...

If you feel like the mini bulid for x64 is inappropriate feel free to close this PR.

[stenzek]

RV64 would be relatively straightforward to add - just need to include it in the matrix here and in the docker images (https://github.com/duckstation/containers). I was using the Qt interface on my board, but didn't bother with CI since I don't think it'd get much/any use.

Edit: Actually, there might not be an appimage stub/runtime for rv64. Probably not much work to add that.. but again, is it even worth it?

[rtissera]

New RV64 boards (RVA23 compliant) are coming and squeezing a lot more performance.
I can come back to you later with current results on SpacemiT K1/X1 based boards if you want.
Granted, RVV is currently not into the RV64 dynarec but that's a totally unrelated issue.

[stenzek]

RVV is really only useful for the software renderer, MDEC, and some book-keeping in the hardware renderer (vector wrapper classes). This is an issue because this is all compile-time, not runtime generated code (same reason I have to have a separate SSE2 build).

The software renderer can potentially have multiple versions compiled in the same binary - I PoC'ed it with 256-bit AVX, but never ended up enabling it because the benefit was so small. Dynarec doesn't benefit from vectorization outside of icache checks, and this is very minimal.

While I do have unit tests for the vector classes, it's not something I'd want to ship until I had hardware myself that I could validate more extensively.