This PR revives PR #3593 and updates the code to up-to-date to changes in the intervening months. There is still work to do for MacOS to be playable especially on 3d games:

• Fix macOS SDL frontend
• Much more testing needed on games.

Here are some tips to build on a MacOS machine:

• OSX version 10.14 or higher (this could be moved to 10.13)

Get Homebrew and run the following on command line:

brew install mbedtls
brew install zstd
brew install openssl
brew install gpm
brew install pkgconfig
brew install sdl2
brew install qt5 # note if you have a QT erorr do brew remove qt than brew install qt5
brew install cmake
brew install conan
git clone --recursive https://github.com/yuzu-emu/yuzu
cd yuzu
git submodule update --init --recursive

When building (from yuzu folder):

export Qt5_DIR=$(brew --prefix)/opt/qt5
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j4

Be it Gentoo, Arch, or Debian, random revisions will randomly give me this specific error dynarmic: POSIX SigHandler: Exception was not in registered code blocks (rip 0x007fb288160861) Segmentation fault While others will be fine.

This is yuzu 1699, but applies to multiple versions. Using GDB I get this output

Thread 1 "yuzu" received signal SIGSEGV, Segmentation fault. 0x00007ffff518d861 in ?? () from /lib64/libc.so.6

This will also occur in the latest mainline build.

System: Host: Mels-PC Kernel: 5.10.27-gentoo-x86_64 x86_64 bits: 64 compiler: N/A Desktop: KDE Plasma 5.20.5 tk: Qt 5.15.2 wm: kwin_x11 dm: SDDM Distro: Gentoo Base System release 2.7 CPU: Info: Quad Core model: Intel Core i7-7700 bits: 64 type: MT MCP arch: Kaby Lake rev: 9 L2 cache: 8192 KiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 57616 Speed: 4186 MHz min/max: 800/4200 MHz Core speeds (MHz): 1: 4186 2: 4186 3: 4188 4: 4051 5: 4052 6: 4097 7: 4139 8: 4124 Graphics: Device-1: Intel HD Graphics 630 vendor: Micro-Star MSI driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:5912 Device-2: NVIDIA GP104 [GeForce GTX 1080] vendor: eVga.com. driver: nvidia v: 460.67 bus ID: 01:00.0 chip ID: 10de:1b80 Display: x11 server: X.org 1.20.11 compositor: kwin_x11 driver: intel,nvidia unloaded: fbdev,modesetting,nouveau,vesa alternate: nv resolution: OpenGL: renderer: GeForce GTX 1080/PCIe/SSE2 v: 4.6.0 NVIDIA 460.67 direct render: Yes

Project Mjölnir: Part 3 - Controller Profiles and Vibration Rework

This is the final part of a multipart rewrite to yuzu's HID (Human Interface Device) frontend and backend implementations.

Wrapping this up, we bring you the final part of Project Mjölnir with 2 big features - Controller Profiles and Vibration Rework, both requiring many other miscellaneous improvements to all aspects of HID in the frontend and backend.

Controller Profiles

The placeholder since Part 1 of the input rewrite is no more! Controller Profiles are finally here!

Due to the way input is handled in yuzu, we had to create a profile system that adapts the existing system to ensure maximum compatibility. As a result, controller profiles are formatted similarly to the [Controls] section of the qt-config.ini file.

Controller Profiles currently save the following data:

• Emulated Controller (Only Left and Right Joycons)
• Real Input Device used (engine/guid/port)
• All buttons
• All axes
• All vibration devices (auto-generated by yuzu)
• All motion devices (via the Motion 0 and 1 buttons)

Everything else, such as the docked/undocked state, vibration and motion enabled, per player vibration (enabled and strength modifier), player connection status are NOT saved the input profile.

Controller profiles are saved under config/input in the yuzu AppData directory or user directory for portable installations.

Profiles are loaded by clicking on the dropdown/combobox and selecting the desired profile as shown below.

Vibration Rework

After the initial work on rumble done by german77, there were a few games where rumble didn't work, and the implementation was incomplete, not supporting vibrations beyond the first connected player.

The Nintendo Switch has the capability to 1. Distinguish between left and right vibration devices or motors and 2. Vibrate them independently of one another. This poses a challenge for libraries like SDL, which do not expose these capabilities. Furthermore, sending these vibrations in quick succession would result into performance issues for some controllers, as evidenced by the various reports using the Xbox controllers.

In order to solve these issues, we had to look into how HID encodes the vibration device handle - a unique handle used to distinguish between different controllers.

After decoding the device handle, it consists of the following:

A u8 npad_type, a u8 npad_id, and finally, a u8 device_index

These are all the information needed to vibrate a vibration device/motor at the correct location.

Armed with this knowledge, we can implement more vibration related HID commands such as InitializeVibrationDevice, GetVibrationDeviceInfo and IsVibrationDeviceMounted, and properly implement commands such as SendVibrationValue, SendVibrationValues and GetVibrationValue.

By implementing these commands, we have fixed all the games that previously had issues with rumble or exhibit no rumble at all, such as Hollow Knight, Fire Emblem Three Houses, 1-2 Switch, Xenoblade Chronicles and many more.

This has also allowed us to implement per player vibrations - allowing for vibrations to be separated per player and per vibration device. This means that if you have single joycons connected via programs such as BetterJoy, you can select the "Any" input device, map both joycons to the left and right buttons/analogs/motions respectively, and both joycons will be able to vibrate! The process of "mapping" a vibration device is done automatically so there is no setup required!

We have also allowed for enabling/disabling vibrations per player, and controlling the vibration strengths for each, allowing for fine tuning of rumble to meet your needs.

Performance issues are also resolved by adding a few heuristics to reduce vibration state changes, and a toggle to enable/disable accurate vibrations, This toggle reduces the effective vibration rate - the rate at which vibrations are sent. By default this is set to disabled.

Controllers that do not support vibration are automatically detected and will have their rumble capabilities disabled in the backend. Resulting in no vibrations sent to SDL/GCAdapter.

Keep in mind that all these changes to vibration required a significant overhaul to the rumble system. In order for vibrations to work, you must open the Configure window and click on Ok once to allow the vibration devices to be "mapped" properly.

Misc. changes

There are many other improvements that streamlines the user experience, some of which are detailed below:

• Cleaned up many UI element sizes between all three themes - now button/combobox/spinbox sizes and spacing are more consistent
• The controller applet now auto-accepts a valid singleplayer configuration. Multiplayer configurations will still have to be manually accepted.
• Mouse clicks now register (only if touch is disabled under Controls -> Advanced)
• The Player 1 controller is automatically connected on boot if none are connected
• Testing period for motion is reduced to 5 seconds from 8
• Input devices no longer revert to "Any" and selecting an input device would properly block inputs from other input devices
• The "Defaults" button now restores the automapped bindings for the selected input device
• Rewrite and correct all input parameters in all HID service commands
• Per game configs are moved to config/custom
• Return of "Map Analog Stick" for manual mapping - fixes analog stick mapping for controllers without SDL_GameController bindings
• The input config in the controller applet is replaced by a button to create input profiles - this will be used in a future PR

This fixes #3743, fixes #4738, fixes #4800, fixes #4818 and fixes #4928

When playing Pokemons Legends Arceus after some time (not much) running the game smootly and stable the FPS goes down to 0 (sound keeps playing) and keep in this state forever. This happens in Windows 11 and Ubuntu Linux too. This happens in both OpenGL and Vulkan. My PC Specs: Ryzen 7 2700, AMD Radeon RX 5700, 20GB RAM

Screenshot of the issue

This is an approach to implement a basic controller rumble. It enables vibrations on Pro Controllers that can use sdl_haptics. The first button of player settings is used as a reference to know which controller corresponds to which player.

From testing and debugging I found that controller_ids should be splitted into 4 bytes. The second rightmost byte always contains the player number.

Most of the code added should be changed with a better method. I'm looking to fix it until everyone it's happy with the code.

Closes #3894

Title describes the problem. Essentially Sunshine and Galaxy both crash on the steam deck (in both desktop mode and gaming mode). Mario64 runs, although not very well. First concern is priority.

Operating System info:

NAME="SteamOS"
PRETTY_NAME="SteamOS"
VERSION_CODENAME=holo
ID=steamos
ID_LIKE=arch
ANSI_COLOR="1;35"
HOME_URL="https://www.steampowered.com/"
DOCUMENTATION_URL="https://support.steampowered.com/"
SUPPORT_URL="https://support.steampowered.com/"
BUG_REPORT_URL="https://support.steampowered.com/"
LOGO=steamos
VARIANT_ID=steamdeck
BUILD_ID=20220718.1
VERSION_ID=3.2

Yuzu Version:

scm_rev

Yuzu configuration:

Graphics API: Vulkan resolution: 720p/1080p CPU: Auto AA: no AA

Logs:

yuzu_log.txt

Any help on figuring this out would be very much appreciated. From what I understand this game had already been crashing before but thanks to the hard work of the Yuzu team 3D All-Stars was functioning before. I've also seen videos of it working on the deck in other contexts so I'm not really sure what's happening. Thanks a whole bunch!

Shader Decompiler Rewrite

This new Pull Request introduces yuzu’s new shader decompiler! The shader decompiler is the module which takes care of transforming the native Maxwell 2nd Gen Assembly shaders from the switch into different shading languages such as GLSL, SPIR-V and GLASM.

Motivation

The current shader decompilation pipeline was designed early on to mainly support GLSL code emission, with incorrect assumptions regarding hardware behavior. As new games began to make better use of the hardware, maintaining the decompiler became more challenging. Thus we wanted to redesign the decompiler to be more decoupled from the backends, and allow for easier integration with the backends and more accurate code emission.

There have also been massive improvements to RE and behavior verification tools. The accuracy of the new decoder was constantly unit tested using the nxgpucatch homebrew.

Design

The new shader decompiler has multiple steps: Decoding, Transforming to IR, Reconstructing Control Flow, Optimizations and, finally, transformation to desired high level language.

Decoding and IR

The design of the new decoder and IR were heavily inspired by our sister project: Dynarmic.

Dynarmic is an extremely fast ARMv8/ARMv6k/ARMv7 to x86-64 just in time recompiler, which is used in yuzu for CPU emulation. For the purposes of the shader decompiler, dynarmic’s code for the decoder and IR were fully repurposed for GPU shader decompilation.

Reconstructing the Control Flow

For the elimination of branches and converting the code into structured code we use: “AM Erosa, LJ Hendren’s Goto Elimination Technique”. The technique works by representing all the branches as conditional gotos and use movement operations and enclosures to eliminate gotos. It uses 3 kinds of movements: Outward, Lifting, and Inward movements. This technique is guaranteed to eliminate all Gotos.

Optimizations Passes

The new shader decompiler uses the same optimization passes dynarmic uses on the IR plus some unique ones adapted to the particular shader type. The base ones from dynamic: Deadcode pass, SSA transformation (not really an optimization itself, but a language in SSA form is easier to optimize) and Constant propagation. We also added some passes to transform from FP16 to FP32 instructions when the GPU itself doesn’t support FP16 or has a faulty implementation, and similarly with Int64 to Int32 pass.

Credits

Main development: @ReinusesLisp @ameerj and @FernandoS27 Linux porting/testing @lat9nq Dynarmic, all contributors, especially @Merrymage and @Lioncash. Testing: Yuzu Team(@BSoDGaming, @gidoly, @GoldenX86, @kelebek1 @Morph1984, @MysticExile, @its-Rei, @ToxaGaming)

fixes #6530, fixes #6336, fixes #6391, fixes #6290, fixes #6151, fixes #6001, fixes #5996, fixes #5926, fixes #5910 fixes #5913, fixes #5811, fixes #5791, fixes #5767, fixes #5763 fixes #5749, fixes #5748, fixes #5307, fixes #4994, fixes #4992, fixes #4844 fixes #4864, fixes #4813, fixes #4749, fixes #4748, fixes #4747, fixes #4707, fixes #4551, fixes #4387, fixes #4339, fixes #4252, fixes #4253, fixes #4077, fixes #4038, fixes #330

Until yesterday (feb 2nd) I was able to build yuzu-mainline from source. I saw that vulkan was merged today, and now I'm unable to build. I tried Qt 5.12 and Qt 5.14 and both gives the same errors:

yuzu-mainline/src/yuzu/configuration/configure_graphics.cpp:8:10: fatal error: QVulkanInstance: No such file or directory
 #include <QVulkanInstance>
          ^~~~~~~~~~~~~~~~~
compilation terminated.
src/yuzu/CMakeFiles/yuzu.dir/build.make:374: recipe for target 'src/yuzu/CMakeFiles/yuzu.dir/configuration/configure_graphics.cpp.o' failed
make[2]: *** [src/yuzu/CMakeFiles/yuzu.dir/configuration/configure_graphics.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....

yuzu-mainline/src/yuzu/bootmanager.cpp:18:10: fatal error: QVulkanWindow: No such file or directory
 #include <QVulkanWindow>
          ^~~~~~~~~~~~~~~
compilation terminated.
src/yuzu/CMakeFiles/yuzu.dir/build.make:182: recipe for target 'src/yuzu/CMakeFiles/yuzu.dir/bootmanager.cpp.o' failed
make[2]: *** [src/yuzu/CMakeFiles/yuzu.dir/bootmanager.cpp.o] Error 1

I'm running Linux Mint 19.3 based on Ubuntu 18.04. To access newer versions of Qt I installed in a different path, I use the following commands to build:

LD_LIBRARY_PATH="/opt/qt514/libH" cmake .. -DCMAKE_BUILD_TYPE=Release

LD_LIBRARY_PATH="/opt/qt514/lib:$LD_LIBRARY_PATH" make -j16

Do I need to install anything else not in the documentation for it to build?

My computer specs: AMD Ryzen 1800X, 32GB of RAM, Nvidia GTX 1070, Driver: 440.48.02

Thanks!

Reviving https://github.com/yuzu-emu/yuzu/pull/4165 to make yuzu work on macOS. This PR only fixes the build to compile and work on macOS, the UI frequently crashes/freezes and no games work yet. I plan to tackle the crash issues and MoltenVK integration next if this gets merged. The backcompat hacks are also a bit of a mess, would appreciate tips on how to fix it.

Build instructions:

If you're on M1, follow https://stackoverflow.com/a/68443301 to dual-install both x86 and Arm brew environments, else you will have to deal with many compiler path headaches. Make sure to run as x86 shell: arch -x86_64 zsh

# install dependencies
brew install zstd openssl pkgconfig sdl2 cmake conan autoconf automake glslang libtool qt5 ninja nasm
# brew installs libtoolize as glibtoolize so do a soft link
ln -s /usr/local/bin/glibtoolize /usr/local/bin/libtoolize
git clone --recursive [email protected]:sguo35/yuzu.git
cd yuzu
git checkout macos
git submodule update --init --recursive

When building make sure you have in your bash environment:

 export Qt5_DIR=$(brew --prefix)/opt/qt5
 export SDKROOT=$(xcrun --sdk macosx --show-sdk-path)
 export LIBRARY_PATH="$LIBRARY_PATH:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
 export LIBRARY_PATH="$LIBRARY_PATH:/usr/local/opt/zstd/lib"
 export PATH="/usr/local/opt/[email protected]/bin:/usr/local/opt/zstd/bin:$PATH"
 export LDFLAGS="-L/usr/local/opt/[email protected]/lib -L/usr/local/opt/zstd/lib"
 export CPPFLAGS="-I/usr/local/opt/[email protected]/include -I/usr/local/opt/zstd/include"
 export PKG_CONFIG_PATH="/usr/local/opt/[email protected]/lib/pkgconfig -L/usr/local/opt/zstd/lib/pkgconfig"
 export OPENSSL_ROOT_DIR="/usr/local/opt/[email protected]"
 export OPENSSL_INCLUDE_DIR="/usr/local/opt/[email protected]/include"

Build:

mkdir build
cd build
cmake .. -GNinja
ninja

Hello! Whenever I try to open the configuration window, yuzu segfaults.

• yuzu-linux-20191007-08340e999
• Arch Linux (5.3.4-zen)
• backtrace: https://gist.github.com/FaithLV/4ebc5309edf512a931329c989ba38e1e
• yuzu_log.txt is empty

First when launching yuzu I had an issue of missing libsndio.so.6.1, so I symlinked to libsndio.so.7.0.

Reimplement the buffer cache using cached bindings and page level granularity for modification tracking. This also drops the usage of shared pointers and virtual functions from the cache.

• Bindings are cached, allowing to skip work when the game changes few bits between draws.
• OpenGL Assembly shaders no longer copy when a region has been modified from the GPU to emulate constant buffers, instead GL_EXT_memory_object is used to alias sub-buffers within the same allocation.
• OpenGL Assembly shaders stream constant buffer data using glProgramBufferParametersIuivNV, from NV_parameter_buffer_object. In theory this should save one hash table resolve inside the driver compared to glBufferSubData.
• A new OpenGL stream buffer is implemented based on fences for drivers that are not Nvidia's proprietary, due to their low performance on partial glBufferSubData calls synchronized with 3D rendering (that some games use a lot).
• Most optimizations are shared between APIs now, allowing Vulkan to cache more bindings than before, skipping unnecessary work.

This commit adds the necessary infrastructure to use Vulkan object from OpenGL. Overall, it improves performance and fixes some bugs present on the old cache. There are still some edge cases hit by some games that harm performance on some vendors, this are planned to be fixed in later commits.

Regression tracking:

• [x] Fire Emblem: Three Houses crashing before showing anything on Vulkan.
• [x] Xenoblade Vulkan won't load fonts.
• [x] Fire Emblem Warriors black screen at boot.
• [x] Animal Crossing: New Horizons black screen.
• [x] Fire Emblem: Three Houses crashes on OpenGL assembly shaders.
• [x] Age of Calamity doesn't render on GLSL.
• [x] Bravely Default 2 Demo black screen.
• [x] Bravely Default 2 crashes on Vulkan.
• [x] Final Fantasy X crashes at boot on Vulkan.
• [x] Dragonball Fighters Z doesn't render on GLSL.
• [x] Hollow Knight has pixelated fog on GLSL.
• [x] Hollow Knight crashes on Vulkan.
• [x] Link's Awakening boot screen doesn't render on GLSL.
• [x] Oninaki vertex explosions.
• [x] Shin Megami Tensei 3 has broken graphics on GLSL.
• [x] ~~Mario and Rabbids has graphical issues.~~ Happens on mainline Vulkan
• [x] Several games softlock on Vulkan.
• [x] Astral Chain can crash/softlock on some cutscenes.
• [x] ~~Final Fantasy Maxima crashes on Vulkan.~~ Unrelated to this PR, fixed in #5796.
• [ ] Crash Nitro Fueled no longer boots with high accuracy on Intel.
• [x] Pokémon Let's go Eevee is slower on Intel.
• [x] Astral Chain crashes on Vulkan when trying to use a null descriptor as index buffer.
• [ ] Link's Awakening has animation issues with chain chomps on Pascal and older generations on Vulkan with high GPU accuracy.

Is there an existing issue for this?

• [X] I have searched the existing issues

Affected Build(s)

Mainline 50d4380

Description of Issue

Yuzu crashes after game intro with an assertion fail. This happens on all games I have available, e.g. Bubble Bobble 4 Friends. This behavior is showing up since updating to Mesa 22.3.1.

Graphics Setting: OpenGL GLSL Hardware: Mesa Intel(R) HD Graphics 5500 (BDW GT2)

Error Message: yuzu: ../src/intel/isl/isl_surface_state.c:547: isl_gfx8_surf_fill_state_s: Assertion `info->y_offset_sa % y_div == 0' failed.

Expected Behavior

No crash / assertion fulfilled.

Reproduction Steps

Start a game, pass the intro screen, and the crash occurs.

Log File

[ 0.088765] Input input_common/drivers/udp_client.cpp:UDPClient:139: Udp Initialization started [ 0.088790] Input input_common/drivers/udp_client.cpp:StartCommunication:331: Starting communication with UDP input server on 127.0.0.1:26760 [ 0.223205] Frontend yuzu/main.cpp:GMainWindow:354: yuzu Version: yuzu Development Build | master-09c9be370 [ 0.223209] Frontend yuzu/main.cpp:LogRuntimes:244: Qt Compile: 5.15.7 Runtime: 5.15.7 [ 0.223211] Frontend yuzu/main.cpp:GMainWindow:370: Host CPU: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz | AVX2 | FMA [ 0.223256] Frontend yuzu/main.cpp:GMainWindow:372: Host CPU Cores: 2 [ 0.223257] Frontend yuzu/main.cpp:GMainWindow:375: Host CPU Threads: 4 [ 0.223280] Frontend yuzu/main.cpp:GMainWindow:376: Host OS: Debian GNU/Linux bookworm/sid [ 0.223296] Frontend yuzu/main.cpp:GMainWindow:377: Host RAM: 7.65 GiB [ 0.223306] Frontend yuzu/main.cpp:GMainWindow:379: Host Swap: 7.88 GiB [ 0.390984] Frontend yuzu/game_list.cpp:LoadCompatibilityList:731: Game compatibility list is empty [ 0.456401] Loader core/file_sys/patch_manager.cpp:PatchRomFS:440: RomFS: Update (v0.0.0) applied successfully [ 0.493252] Loader core/file_sys/patch_manager.cpp:PatchRomFS:440: RomFS: Update (v0.0.0) applied successfully [ 2.478138] Frontend yuzu/main.cpp:BootGame:1663: yuzu starting... ... [ 6.835904] HW.GPU video_core/engines/maxwell_3d.cpp:ProcessFirmwareCall4:317: (STUBBED) called [ 6.842128] Service.VI core/hle/service/vi/vi.cpp:AdjustRefcount:109: (STUBBED) called id=1, addval=00000001, type=00000000 [ 6.843000] Service.VI core/hle/service/vi/vi.cpp:AdjustRefcount:109: (STUBBED) called id=1, addval=00000001, type=00000001 [ 6.847448] Service.VI core/hle/service/vi/vi.cpp:GetNativeHandle:121: (STUBBED) called id=1, unknown=0000000F [ 6.941011] Service core/hle/service/sm/sm_controller.cpp:QueryPointerBufferSize:68: (STUBBED) called [ 9.083387] Service core/hle/service/sm/sm_controller.cpp:QueryPointerBufferSize:68: (STUBBED) called [ 9.086368] Service.Audio audio_core/sink/sdl2_sink.cpp

System Configuration

CPU: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz | AVX2 | FMA GPU/Driver: Mesa Intel(R) HD Graphics 5500 (BDW GT2), i915, Mesa 22.3.1 RAM: 8 GB OS: Linux, Debian Testing (bookworm), 6.0 Linux kernel

Only externals/cmake-modules/GetGitRevisionDescription.cmake is a true external, from rpavlik/cmake-modules (thus the dir name). externals/cmake-modules/WindowsCopyFiles.cmake and all the find-modules are developed in-house and thus belongs to the root CMakeModules dir. Also remove useless redefinitions of CMAKE_MODULE_PATH in subdirs.

This policy is only useful for external subprojects and thus belongs to externals/CMakeLists.txt. Also remove the now inexistent DYNARMIC_NO_BUNDLED_FMT option.

Co-Authored-By: Narr the Reg [email protected]

This will make sure that the sanitized (deadzone/range-adjusted) stick input will be written to the file instead of the raw inputs, as the playback will not run the sanitization again. This means that the file will contain all the stick values that are actually received by the game instead of the ones issued by the user, making sure that playback also syncs with different playback methods.

Implemented FSR 1.0 in the OpenGL renderer. I can only test it with an AMD gpu at the moment, but I hope it works fine with NVIDIA/Intel cards too.

https://user-images.githubusercontent.com/17367726/210182429-abd37b9e-ca60-4bec-ae0a-7f0b42fedf95.mp4

How?

The GLSL sources AMD provided of FidelityFX FSR 1.0 can basically be used in OpenGL too as is, even though GPUOpen only mentions support in Vulkan. In the original Vulkan example, the rendering was done in a compute shader with a custom rasterizer. To make it work in Yuzu's OpenGL renderer in a easy way, the EASU/RCAS functions are called here in a normal fragment shader drawn to a fullscreen triangle. The performance should roughly be the same.

FSR 1.0 has two passes: An upscale pass to an intermediate framebuffer of the output resolution and a subsequent sharpening pass to the target framebuffer. The intermediate framebuffer is resized at RendererOpenGL::DrawScreen everytime the output resolution has changed (e.g. user resized the Yuzu window).

I had to somehow fuse the FSR functions defined in vk_fsr.cpp with the new gl_fsr.cpp, so I moved these functions into video_core/fsr.(h/cpp). Perhaps there is a better place for these functions?

Why?

Of course the Vulkan API offers better performance than OpenGL and should always be preferred, but there are some games that do have graphical glitches and OpenGL acts as a good fallback there. Either way should be a nice feature to have FSR in OpenGL too.

Scaleforce	FSR 1.0

Make failure messages less scary as discussed in https://github.com/yuzu-emu/yuzu/pull/9515.

Also don't try to find a library via pkg-config when a CMake config file with unsuitable version has already been found. The pkg-config will fail too and it makes the message better.