This simplifies the GPU accuracy setting by removing the intermediate Balanced mode and setting High as the default on desktop platforms.
It introduces a dedicated setting for GPU fence behavior, allowing the synchronization policy to be configured independently of GPU accuracy.
The Vulkan buffer cache now tracks GPU recording timeline ticks and waits only when necessary, reducing unnecessary synchronization while maintaining correctness for hard-to-trace graphical bugs.
GPU buffer readback has also been refined to synchronize only the affected upload regions when needed, and default DMA behavior has been updated to align with the new GPU accuracy model.
### TL;DR
The fix for particles freezing and unfreezing in mid-air in `Super Mario Odyssey` has been improved, resulting in less of a performance hit.
This game requires the new `Enable GPU Buffer Readback` option to be enabled to fix this issue.
The vertex explosions that occurred in `Super Mario Bros. Wonder`, especially in World 4, have been completely eliminated. You can now enjoy a smooth experience without graphical glitches exploding across the screen.
This game requires the new `GPU Fence Behavior` option to be set to `Strict` to fully fix this issue.
The flickering issue inside certain Shrines in `The Legend of Zelda: Tears of the Kingdom` has also been fixed.
For now, this game requires the new `GPU Fence Behavior` option to be set to `Accurate` to fully fix this issue.
These options are intended to fix graphical bugs in games that require better synchronization behavior between CPU and GPU, so other games may be affected as well.
Co-authored-by: xbzk <xbzk@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4182
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
3970 revert fixes crash caused by scheduler
4177 fix mario galaxy and metroid prime 4 not booting
Co-authored-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4187
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
This is the first step into the conversion on full GPU video decoding for Android; currently due to the VIC structure, I couldn't set it on surface mode to prevent the latency when sending video decoded (which is processed by GPU now), because currently we convert YUV420 into the Nvidia's format each frame constantly on CPU, aside the requirements from other extensions to work + VIC rewrite, which is a work currently not planned to happen on this PR; the actual configuration for video decoding is ByteBuffer, using GPU to decode NVDEC data (all codecs supported, h264, vp8 and vp9) and send it to CPU for display purposes, which is more faster than relying purely on CPU for any drawing task, saving devices resources/ heating, the downside on this will be the slight latency when a new frame is displayed, which is gonna be a black frame for less than a second, nothing major to harm the experience rather than actually trying our best to take advantage on hardware accelerated.
Aside this, I also added a bunch of minor Vulkan fixes to grant drivers less thinkering when receiving spir-v instructions, meaning this has new bans for extensions on QCOM (following reported issues on other projects working around Adreno driver behavior), this more than providing performance aims to enhance the stability on the driver, performance it's gonna likely to be hit based on the UBO's (StorageBufferAccess) operations and SSBO (uniformStorageBufferAccess), there was an already existing path for the emulation which forces to wide them into 32bit packed operations. I also included some smaller changes/ bugs + VUID's fixes from earlier changes on my work.
Special Thanks:
-> Mr. Smoly Gidolard (@gidoly)
Sources:
1.- https://github.com/microsoft/DirectXShaderCompiler/issues/2842
2.- https://github.com/mlc-ai/web-llm/issues/836
3.- https://github.com/ggml-org/llama.cpp/issues/5186
4.- https://github.com/encounter/aurora/pull/202
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4191
Based on the register of the ASTC implementation from Ameerj (yuzu), currently our conversion from ASTC on Desktop tends to duplicates the unpacking of ASTC converted textures, leading to bad performance; since there are some graphical effects that actually access on the band of 32bits (RGAF32) than the common 16bits (RGAF16) from our ASTC path decoding method, which commonly uses ARGB8 (degradation -> LDR) transformation to reduce the memory cost per conversion; meanwhile it could actually provide initially better performance; the engine tended to get stalled when this writted stage effect got skipped; mostly because CPU tends to look for an unimplemented texture/ format query (from which doesn't exist on our MaxwellToVK); unlike what's commonly believed HDR was a format to write enviroment effects even before their appearance on video output (since Switch doesn't have HDR, only SDR on certain engines).
The test result on this PR showed games like Astral Chain and other heavy reliant on ASTC decoding improved their performance and stability by around 15%; meanwhile could it be tied to a hardware gain, it's clearly a gain for direct access on what's required on most games. This PR also contains few Vulkan bug fix I encountered along this implementation.
Special Thanks:
-> Mr. Smoly Gidolard (@gidoly)
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4190
lizzie