Man, do I miss the times when people just typed out two concise sentences of actual information instead of drowning everything in an LLM-generated wall of fluff and wasting everyone's time in the process.
Either way, I think we're categorically uninterested in spending several months of effort to make a handful of games run on hardware that they clearly weren't designed for.
I do think it would be an interesting thing to follow on though, although I'm probably going to just fork. Also yea sorry for the LLM use I'm not a native english speaker, needed to figure out how to phrase this well.
VKD3D_CONFIG=software_mesh_fallback),x1 2026-06
With the release of modern titles like Final Fantasy VII Rebirth and Alan Wake II, hardware-
accelerated Mesh Shading (DirectX 12 Ultimate Feature Level 12_2 / Shader Model 6.6) has become a hard requirement for execution.
Currently, legacy architectures (Nvidia Pascal, AMD RDNA 1) and hybrid console-derivative silicon (such as the AMD Oberon APU / BC-250) are entirely locked out. They either hard-crash on launch or fall back to unplayable single-digit frame rates because standard PC drivers (RADV / amdgpu) report 0% mesh shader compliance.
However, the physical silicon on some of these architectures—specifically the Oberon APU—is mathematically capable of this workload. On the PlayStation 5, the exact same silicon processes heavy geometry pipelines by routing meshlet expansion through low-level software compute shaders into the NGG (Next-Generation Geometry) engine, bypassing standard DX12 hardware-primitive scheduling blocks entirely.
Furthermore, on the PC side, hardware modifications have proven that these salvaged APUs (like the ASRock BC-250) can be unlocked via register manipulation to expose the full, defect-free 40 Compute Unit (CU) layout. The raw compute power is there, but the standard PC API bridge is missing.
I would like to propose the implementation of a universal, opt-in software emulation fallback layer within VKD3D-Proton for DispatchMesh / Mesh Shader pipelines using standard Vulkan Compute Shaders. When enabled via an environment variable (e.g., VKD3D_CONFIG=software_mesh_fallback), VKD3D-Proton would:
Spoof Capability: Intercept the engine's capability queries and report fake support for Feature Level 12_2 / SM 6.6 to bypass artificial launch blocks.
Dynamic Shader Translation: Intercept incoming DispatchMesh commands and dynamically compile/translate the mesh/task shader instructions into a generic Vulkan Compute pipeline instead of passing them down as native hardware mesh primitives.
Meshlet Management: Manually handle vertex grouping, frustum culling, and primitive amplification within the compute shader space, dumping the finalized vertex buffer straight into the legacy geometry pipeline.
While a similar fallback was previously discussed for Nvidia Pascal and deemed too inefficient due to Pascal's internal architecture, the landscape has changed:
The Oberon/RDNA1 Case: RDNA1-derived architectures feature highly efficient general compute blocks and an NGG design that aligns closely with how the PS5 handles software-driven mesh expansion
Target Audience: This would provide a massive compatibility lifeline not just for niche salvaged hardware like the BC-250, but also for millions of users still running mainstream RDNA 1 (RX 5000 series) and Pascal cards who are currently facing a hard generation lock. Even if the performance incurs a software translation tax compared to native RDNA2/3 hardware scheduling, a stable 30–40 FPS compute fallback would be an immense win for open-source gaming preservation and hardware longevity.
I have already verified that the 40-CU physical layout runs completely stable under Linux with zero artifacts or defects when forced. I am willing to assist the developer community with testing, log dumps, and benchmarking on this specific architecture.
Thank you for your incredible work on Proton and VKD3D. I look forward to hearing your thoughts on the architectural viability of this pipeline!