In the last newsletter, I gave you all a small peek behind the curtain as to why hardware acceleration in GarlicOS will be landing later than expected.
Since then, I've spent a lot of time chasing red herrings, hoping to get a little closer to figuring out what is causing the subpar performance in RetroArch.
So far, I have been able to confirm the following:
The performance issue is limited to RetroArch; standalone emulators and ports aren't affected at all.
The issue stems from the RetroArch core binary, not the emulation cores. This was tested by loading the cores into the Stock-OS RetroArch binary, which is, for the most part, ABI-compatible.
The issue is not linked to our custom RetroArch audio driver, which was my initial guess given its experimental Unisoc soundcard support. This was tested by forcing a null-audio driver, completely circumventing the custom audio driver.
I have a few more ideas as to what could be causing the issue, but I fear more trial and error will be required before I can move on to greener pastures.
Given the lengthy debugging process and the now unclear timeframe, I hope to clean up the existing codebase and push the bug fixes and enhancements made so far to GitHub, giving other developers a chance to review the latest changes as well.
Rough sailing, but we'll get there.

A new build of Duo is currently undergoing internal testing, bringing support for sandboxed instances.
This will enable us to fully isolate instances from the host system, solving issues like gamepad jailing and global-exclusive application support.
Furthermore, it will allow us to spin up self-terminating guest instances, giving us full granular control over what files instances are allowed to access or not.
This could prove useful in scenarios where a user wants to quickly share their rig's horsepower with local or remote guests without jeopardizing their own host system's security in the process.

I've been reverse-engineering parts of Windows' Local Session Manager as of late and think I might have found a promising lead for what might come next for Duo.
Using a bit of emulation and some sneaky C++ class extension, it might be possible to force remote sessions to appear as if they were connected locally.
If this pans out, we might be able to fix certain games, like the eFootball series, that actively refuse to run whenever they detect a remote session.
My current proof-of-concept prototype is able to force-enable the console-only Windows display settings so far, which shows promise, but is a far cry from the endgame we're chasing.
Time will tell, I guess.
I've been assigned a high-priority project at my day job that needs rescuing after the previous project lead dropped out unexpectedly, putting me in an unexpected three-week crunch that should keep me occupied until somewhere around the 26th to 29th of August.
This will leave less time to focus on private projects, which means things will slow down until I get my company-approved two-week leave right after.
This means things should see a noticeable spike in activity around the beginning of next month when I'm finally free to decide how to spend my time again.
I'll keep you guys posted!
- Black-Seraph
Aric Brose
2024-09-24 20:13:24 +0000 UTCGeorge Boden
2024-08-29 22:18:13 +0000 UTCihazcat
2024-08-14 17:08:52 +0000 UTCNoon Sok
2024-08-14 06:04:05 +0000 UTC