mirror of
https://github.com/ARMSX2/ARMSX3.git
synced 2026-08-24 16:58:52 -07:00
The fallback CPU table was missing cores found in recent handheld SoCs (Cortex-A510, A715, X3, A520, A720, X4). Because get_cpu_name() bails out when any detected MIDR is unknown, a single missing core sent the whole lookup to the cortex-a78 fallback whenever LLVM host detection returned "generic". Display names were also reused as LLVM -mcpu values, which happens to work for the Cortex names but not for Qualcomm Oryon: the display name lowercased to "x-elite", which is not an LLVM processor, so the JIT silently lost per-CPU scheduling. Entries now carry an explicit canonical LLVM name alongside the human-readable one; get_cpu_brand() keeps using the latter. The Qualcomm entry is named "Oryon" rather than "X-Elite" because MIDR 0x51/0x001 only identifies an Oryon core, not the SoC it sits in. MIDRs cannot identify the SoC at all, which made bug reports ambiguous. Android's own SOC_MANUFACTURER/SOC_MODEL are now passed to the core and logged as a separate "SoC:" line, so SoC identity, core topology and the resolved LLVM target are three distinct values. The LLVM target reported by system info now comes from the same resolution path the JIT uses, rather than from the fallback alone, so it no longer disagrees with the target actually compiled for. The Vulkan renderer logs one verdict for the adapter it selected, recording whether BC1-BC3 support keeps DXT textures compressed or whether they are decoded on the CPU. It sits in render_device::create rather than where the flag is resolved, because physical_device::create runs for every GPU of every instance, and not in TextureUtils, whose fallback branches run per texture and per mip level. SoC information travels through a new optional _rpcsx_setSocInfo export instead of an added _rpcsx_initialize parameter. The core is dlopen()ed and can be updated independently of the JNI glue, so changing an existing export's signature would make older glue call it with a garbage argument. Older glue simply never calls the setter, and newer glue null-checks the symbol against older cores. No JIT feature policy and no texture decoding behaviour changed. Verified on an AYN Odin 3 (ayn CQ8725S, 8x Oryon, Adreno 830) running Turnip 26.2.99: SoC line reads "ayn CQ8725S (Snapdragon 8 Elite-class)", the brand line reports Oryon rather than X-Elite, the JIT resolves to oryon-1, and a single BC verdict reports the GPU path. That BC result applies to the Turnip driver tested; stock-driver behaviour is unmeasured.