[pull] master from libretro:master#983
Merged
pull[bot] merged 22 commits intoAlexandre1er:masterfrom May 1, 2026
Merged
Conversation
The MMX fast path of conv_rgba4444_argb8888 hardcoded the alpha channel to 0xff instead of extracting it from the source's low nibble. The scalar fallback (lines 488-501) correctly does 'a = (col >> 0) & 0xf; a = (a << 4) | a' to expand the 4-bit source alpha into 8 bits. The MMX kernel kept the 'const __m64 a = _mm_set1_pi16(0x00ff)' constant from the sibling conv_rgb565_argb8888 / conv_0rgb1555_argb8888 functions (whose 16-bit sources have no alpha channel), so on x86 hosts where __MMX__ is defined (which includes all x86_64 builds, since gcc enables MMX by default alongside SSE2) RGBA4444 input was silently converted with full opacity regardless of source alpha. Same shape of bug as commit 9403719 (conv_rgb565_abgr8888 SSE2): SIMD kernel inherited from a sibling without adapting all the needed steps to the new format. Fix: extract alpha from the low nibble (in & 0x000f), expand to 8 bits via _mm_mullo_pi16(a, 0x0011) which computes a * 17 == (a << 4) | a for any 4-bit value. Verified bit-exact against the scalar fallback for every possible RGBA4444 input. Brute-force test of all 65,536 16-bit values: before fix: 61,440 of 65,536 outputs differ from scalar (94%; all inputs whose low nibble != 0xf produce wrong alpha) after fix: 0 of 65,536 differ Caller audit: hit by gfx/drivers/gl1.c:1810 (RGUI menu fallback expansion when GL_EXT_packed_pixels is unsupported -- triggers on ancient OpenGL implementations and the Vita gl1 build) and via the scaler chain when SCALER_FMT_RGBA4444 is paired with SCALER_FMT_ARGB8888 (libretro-common/gfx/scaler/scaler.c:183 and :232). On x86_64 the MMX path is hot in both contexts.
* Add files via upload * Update crop_borders.c * Add EMMIR NTSC default "crt" variant compiles and runs perfectly fine on linux Mint. * Add files via upload
…r setting
Two related fixes for the GameMode startup behavior on Linux:
1. configuration.c: Only call frontend_driver_set_gamemode() during config
load when gamemode_enable is actually true. Previously the probe ran
unconditionally with the current setting value, meaning every user on
every config load triggered a dlopen of libgamemode.so even when the
feature was off - producing log spam ("[GameMode] GameMode cannot be
enabled on this system...") for the majority of users who don't have
libgamemode installed.
Also stop force-disabling gamemode_enable in the config when the probe
fails. Silently flipping the user's preference to false and persisting
it to retroarch.cfg meant a transient failure (sandbox path issue,
library not yet installed, multi-arch mismatch, etc.) would require
the user to manually re-enable the option on every subsequent launch.
The user's intent should survive across sessions; if libgamemode shows
up later, the next launch picks it up automatically.
2. frontend/drivers/platform_unix.c: Latch the unavailable state inside
frontend_unix_set_gamemode() once gamemode_query_status() reports
failure. The result will not change for the lifetime of the process,
so subsequent calls (deinit cleanup, menu toggles) short-circuit
without re-entering the Feral client code and without re-emitting the
warning. The warning now fires exactly once per process when the user
has gamemode enabled but libgamemode is missing.
The redundant "[Config] GameMode unsupported - disabling..." follow-up
warning is removed - it added no information beyond what the GameMode
warning already conveys.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )