- Add TAA option to AntiAliasing enum in settings
- Implement TAA shaders for both OpenGL (GLSL) and Vulkan (SPIR-V)
- Add OpenGL TAA class with framebuffer management and temporal blending
- Add Vulkan TAA class following existing AntiAliasPass architecture
- Integrate TAA into OpenGL and Vulkan rendering pipelines
- Add UI translations and Android string resources for TAA option
- Implement Halton sequence jittering for temporal sampling
- Add motion vector validation and neighborhood clamping to reduce ghosting
- Configure aggressive temporal blending to minimize visual artifacts
- Add proper descriptor set management for Vulkan TAA implementation
The TAA implementation provides high-quality anti-aliasing by combining
information from multiple frames with per-pixel jittering, resulting
in smoother edges and reduced aliasing artifacts while maintaining
good performance and temporal stability.
Fixes: Black screen issues with proper descriptor set bindings
Fixes: Ghosting artifacts with improved temporal blending parameters
Fixes: Jitter visibility with reduced jitter intensity (50% scaling)
Signed-off-by: Zephyron <zephyron@citron-emu.org>
Moved ZBCManager to `video_core/zbc_manager.cpp/h` for modularity. Added
`gl_zbc_clear.cpp/h` for efficient OpenGL color, depth, and stencil clears.
Updated `RasterizerOpenGL::Clear` to use ZBC with fallback. Added stencil
type validation. Fixed color mask and logging. Updated `CMakeLists.txt`.
Enhances performance and code organization.
Signed-off-by: Zephyron <zephyron@citron-emu.org>
Frame generation was marked as WIP and not ready for production use.
This commit removes all frame generation related code and UI elements
to prevent users from enabling an incomplete feature.
Changes:
- Remove frame generation settings from Android UI (Kotlin/XML)
- Remove frame generation settings from Desktop UI (Qt/C++)
- Remove frame generation enums and settings from core (C++)
- Remove frame generation Vulkan renderer implementation
- Remove frame generation shader files
- Update CMake build configuration
Signed-off-by: Zephyron <zephyron@citron-emu.org>
- Add FSR2 to ScalingFilter enum alongside existing FSR
- Implement FSR2 classes for both Vulkan and OpenGL renderers
- Add fsr2_quality_mode setting with 4 quality levels (Quality, Balanced, Performance, Ultra Performance)
- Integrate FSR2 into present pipeline for both renderers
- Add UI support for FSR2 option in scaling filter dropdown
- Add FSR2 quality mode setting with dropdown selection
- Update translations and Android strings for new options
- Default to Performance mode for optimal balance
This provides users with FSR 2.0 as a scaling option, offering different
quality/performance characteristics compared to FSR 1.0. The implementation
uses quality-based sharpening values and integrates seamlessly with the
existing rendering pipeline.
Signed-off-by: Zephyron <zephyron@citron-emu.org>
Fix LTO linking issues on CachyOS with GCC 15.x
- Add LTO support to all core library targets (input_common, frontend_common,
network, shader_recompiler, web_service) that were missing LTO configuration
- Create citron_configure_lto() helper function for consistent LTO handling
- Implement CachyOS-specific detection via /etc/os-release and kernel version
- Apply conservative LTO flags (-flto=auto -ffat-lto-objects) only for
CachyOS + GCC 15+ to resolve linking errors with newer toolchains
- Other distributions continue using aggressive LTO settings for maximum performance
- Disable LTO on executable targets to prevent main function optimization issues
This resolves "undefined symbol" errors when building with -DCITRON_ENABLE_LTO=ON
on CachyOS while maintaining optimal LTO performance on other distributions.
Fixes linking errors including:
- Core::Frontend::EmuWindow symbols
- Core::System methods
- Settings::values
- Common logging functions
Tested on CachyOS with GCC 15.1.1 + LLD 20.1.8
Signed-off-by: Boss.sfc <boss.sfc@citron-emu.org>
Persistent buffer maps were already used by the texture cache, this extends their usage for the buffer cache.
In my testing, using the memory maps for uploads was slower than the existing "ImmediateUpload" path, so the memory map usage is limited to downloads for the time being.
