[GPU] Add FXAA post-processing
[UI] Add FidelityFX FSR and CAS post-processing
[UI] Add blue noise dithering from 10bpc to 8bpc
[GPU] Apply the DC PWL gamma ramp closer to the spec, supporting fully white color
[UI] Allow the GPU CP thread to present on the host directly, bypassing the UI thread OS paint event
[UI] Allow variable refresh rate (or tearing)
[UI] Present the newest frame (restart) on DXGI
[UI] Replace GraphicsContext with a far more advanced Presenter with more coherent surface connection and UI overlay state management
[UI] Connect presentation to windows via the Surface class, not native window handles
[Vulkan] Switch to simpler Vulkan setup with no instance/device separation due to interdependencies and to pass fewer objects around
[Vulkan] Lower the minimum required Vulkan version to 1.0
[UI/GPU] Various cleanup, mainly ComPtr usage
[UI] Support per-monitor DPI awareness v2 on Windows
[UI] DPI-scale Dear ImGui
[UI] Replace the remaining non-detachable window delegates with unified window event and input listeners
[UI] Allow listeners to safely destroy or close the window, and to register/unregister listeners without use-after-free and the ABA problem
[UI] Explicit Z ordering of input listeners and UI overlays, top-down for input, bottom-up for drawing
[UI] Add explicit window lifecycle phases
[UI] Replace Window virtual functions with explicit desired state, its application, actual state, its feedback
[UI] GTK: Apply the initial size to the drawing area
[UI] Limit internal UI frame rate to that of the monitor
[UI] Hide the cursor using a timer instead of polling due to no repeated UI thread paints with GPU CP thread presentation, and only within the window
Shim exports are called from GuestToHostThunk which dictates the calling
convention. The default system calling convention is different depending
on OS (Windows vs. everything else) and architecture. PR #1339 addresses
this for x64 Linux.
There is no reason for explicit `__cdecl`. Also, it is not available in
GCC. We could use `__attribute__((ms_abi))` or
`__attribute__((sysv_abi))` but that just adds complexity.
Fix issue in clang where args were inverted last to first due to the way
c++ implements function calls.
The function make_tuple, being a function, has undefined ordering of
resolution of the values of its parameters `Ps(init)` and would vary
between compilers. Namely clang would resolve them in order and msvc
would resolve them in reverse order.
This normally would not matter except for the fact that init maintains
a mutable state which is affected my the order of operations:
init.ordinal is a counter and also defines where in memory a value is
stored.
The C++ standard doesn't define an order of resolution of parameters in
a function but it will define an order in a brace-initializer.
Switching make_tuple for a brace-initializer enforces an order which is
the same between all compilers (tested gcc, clang and msvc).
Prior code was written to decrement ordinal due to the reverse
traversal.
This has been switched to incrementing thanks to the in-order
traversal.
C++17ification!
- Filesystem interaction now uses std::filesystem::path.
- Usage of const char*, std::string have been changed to
std::string_view where appropriate.
- Usage of printf-style functions changed to use fmt.
- Convert http to https, provide archive link when possible.
- Made CPU-JIT.png more readable on dark themes;
Added a white background so there isn't black text on a black
background.
This was a headache to work out, big thanks to the lack of documentation on .xexp files... a ton of guesswork was involved here but luckily it turned out well.
I did have to make some pretty major changes to the way XEX files are loaded though.
Previously it'd just load everything in one go: XEX headers -> decrypt/decompress data -> load imports/symbols -> set loader data table entries, etc...
Now it's changed to something like this:
- Load base XEX headers + decrypted/decompressed image data, return X_STATUS_PENDING
- In the LoadFromFile call used to load the XEX, search for XEXP patch file (only .xexp in same folder atm)
- If patch exists: load XEXP, decrypt headers/data, apply patch to base XEX, dispose of XEXP
- Finish XEX load via LoadXexContinue() (handles imports/symbols/loader data...)
This saves us from needing to reset the imports/function/symbol stuff after patching (since all the XEX code will be a lot different), but I'm not really sure if I went about it the best way.
Code is mainly just copy/pasted from kernel/util/xex2.cc, I've tried fixing it up to work better in a class, but there's probably some things I missed.
Also includes some minor improvements to the XEX loader, like being able to try both XEX keys (retail/devkit) automatically, and some fixes to how the base address is determined.
(Previously there was code that would get base address from optional header, code that'd get it from xex_security_info, code that'd use a stored base address value...
Now everything reads it from a single stored value instead, which is set either from the xex_security_info, or if it exists from the optional header instead.
Maybe this can help improve compatibility with any weird XEX's that don't have a base address optional header?)
Compressed XEX loader also has some extra checks to make sure the compressed data hash matches what's expected.
Might increase loading times by a fraction, but could save reports from people unknowingly using corrupt XEXs.
(still no checks for non-compressed data though, maybe need to compare data with xex_security_info->ImageHash?)
