| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a Graphics setting, "Use NVIDIA DLSS in place of a game's DLSS" (nvidia_dlss, off by
default). When it is on, in Windows builds configured with EGLANTINE_STREAMLINE_SDK, the
evaluation Eglantine already replaces with FSR 3.1 goes to NVIDIA DLSS on GeForce RTX cards, with
the same inputs (colour, depth, motion vectors, jitter). When DLSS can't run, FSR 3.1 runs as
before.
Only Streamline's MIT-licensed headers are compiled in; nothing of NVIDIA's is linked or shipped.
At run time Eglantine looks for sl.interposer.dll in the user folder's "streamline" folder (or
EDEN_STREAMLINE_DIR, or "streamline" next to the executable), checks its Streamline signature and
starts Streamline with manual hooking. Streamline's plugins come from that folder or the NVIDIA
app's downloads. DLSS itself is nvngx_dlss.dll in the same folder, else the newest DLSS 310 or
later that the NVIDIA app has downloaded, checked for NVIDIA's Authenticode signature and copied
as streamline/nvidia-app/nvngx_dlss.dll. Like other tools that call DLSS outside a game, it uses
its own fixed project id with the custom engine type.
- Preset K for all modes (EDEN_NX2_DLSS_PRESET overrides it): the default Performance model (M)
and L draw thin dark horizontal lines in some frames at 2x resolution scale; K doesn't.
- HDR input with auto exposure; the mode follows the render/output ratio.
- Buffer device address stays enabled when DLSS needs it, for DLSS only.
- The upscaler waits for the device instead of submitting when it is destroyed: by then the
game's channels are released, and a submit read the state tracker's stale flags (a crash when
stopping a game).
With the setting off, or in builds without the SDK path (the setting is hidden there), nothing
changes.
Testing: Windows 11, RTX 5080, Fire Emblem: Fortune's Weave docked at 1x (720p -> 1440p) and 2x
(1440p -> 2880p), CLI runs and GUI play, stopping and restarting games with DLSS on. Not tested on
other GPUs or games.
Assisted-by: Claude Opus 5.5 (implementation, debugging)
Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
So CreateInstance was enumerating instance extensions twice, and that could race if the driver returned a different list the second time. On some AMD iGPU drivers, we could enable an extension from the first list, then fail the second check with VK_ERROR_EXTENSION_NOT_PRESENT.
Fix this by enumerating once and passing that same snapshot into RequiredExtensions.
Fixes: https://github.com/eden-emulator/Issue-Reports/issues/414
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4072
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pr aims to make a first step into giving Eden's Vulkan backend maintenance with better formatting, understanding and reduce the redundancy between some wrong implementations:
-> ProvokingVertex: Has been reworked completely, now the wiring to ExtendedDynamicState3 (ProvokingVertexMode) it works safe, the gating of the extension no longer requires user enabling on UI, it will be enabled automatically based on what features of the extension are available on driver, depending if first or last mode are available and also will be properly set under TrasformFeedback operations; this way we're gonna ensure all drivers, including Android stock drivers on QCOM, Mali and other mobile vendors drivers access correctly to the extension, fixing some graphical issues (flickering textures or wrong sccisors on vertex that required first mode) generated by the missing first mode handling or the proper clearing on pipeline state. This change will increase/ decrease slightly the performance on some games that changes dynamically between first and last modes, but will also ensure a clear path to GPU to use resources smartly, reducing VRAM consumption in PC and MEM/GPU percentage of use on Android (marginal to 5 - 8% approx).
-> Removal VK_EXT_multi_draw: It has passed some months since the first try to implement this feature, but wasn't completed so functionality was null to negative, taking space in source and using small CPU cicles for initialization during device creation that reduced CPU effectiveness by 2 - 5%, aside that, after reviewing the situation of formally introducing handling for multidraws to reduce the floods of constants draw calls into 1 per batch, seems to not pay the overhead when the multidraw capacity is less or equal to 1, aside that, for the time being batching multidraws will introduce indirections on each batch of command draws, that graphical issues will appear and reducing performance can happen, something it was gonna solve. For the time being it's discarded, but, may be analyzed the chance to introduce it properly in a later date.
-> Removal VK_EXT_indexing_descriptor: Currently the implementation of this feature was partial, with not proper handling on layouts; just the initial checks on device creation and chained up to the pNext feature, currently this extension will require a buffer cache and texture cache rework to set layouts and reduce the amount of use of descriptor into making it a less expensive cost effective, aside that to generate a path for the Bindless Texture and Bindless Buffer, allowing to track state of textures in runtime and ensuring the state of some compiled shaders doesn't change if it's no needed, among other benefits, besides that, enabling this feature was only generating innecessary checks on GPU, so consumption would be higher than it should be.
-> Removal of VK_EXT_swapchain_maintenance1: The use of this feature was really conditional to certain support on newer drivers and cards, which wasn't available for all platforms, I concluded that if the support for this instance wasn't really there, the cost effective between the try to initialize it and running it, won't be good as when it didn't exist on our Vulkan device, with also the constant factor of not being completely implemented, right now I'm aiming to reduce the complexity on Vulkan side to keep it as simple as it could for a future video_core rework, which may start somewhere these weeks.
-> Refined the Maintenance features: Meawhile this features are usually inherent to Vulkan core functionality, sometimes drivers doesn't expose them well, which leads to Eden run Vulkan without really noticing the existence of maintenance features on driver to improve stability, so we're tied to declare them and load them when a device creation starts by asking if driver supports and which, currently 1 - 5 are core maintenance features, meanwhile the 7 - 9 are more experimental and not being available everywhere, so right now to help drivers give attention to this features we not only load them, but also calculate with features bits which features inside Maintenance5 are available to use, that was the initial purpose, but we weren't using the full potential of the extension; I made cleaned part of the unneeded log code for the initialization of this Maintenance5 and it's feature flags, but also making an operation to sanitize depth/ stencil when One is not available in swizzle operations, making it easier to draw it; it's also needed to mention that Maintenance9 was removed from source code until we can have better handling on Arrays2D, aside that, the use of the extension was really conditional to certain drivers being capable of use it, so I remove it.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3839
Co-authored-by: CamilleLaVey <camillelavey99@gmail.com>
Co-committed-by: CamilleLaVey <camillelavey99@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
system is created (#3688)
- our logging code was bigger than spdlog itself, why???? just keep it simple
- fix issues when logging before logging system is even started
- removes the "initialized logging twice" issue
- removes uneeded indirection in file logging
- uses direct formatting instead of jumping hoopla-around the fmt::format() ressult
- code duplication and dead code removal as usual
I did explore dup2() but I think it's not worth the hassle
I did try `fwopen()` but it's better if things are just kept as-is.
there is a lot of noise because I removed a bunch of redundant files on logging and just put everything in one file
now normally this wouldn't be a good idea, however consider: the complexity of logging; it's less than 500 lines... does it really need a whole subsystem?!?!?! ITS JUST LOGGING
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3688
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: DraVee <chimera@dravee.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
requirement) for maintainance 1 (#3514)
fixes VVL, but doesnt make it a hard requirement so drivers which cant load it for some reason just, dont
Validation Error: [ VUID-vkCreateInstance-ppEnabledExtensionNames-01388 ] | MessageID = 0xe5e52180
vkCreateInstance(): pCreateInfo->ppEnabledExtensionNames[3] Missing extension required by the instance extension VK_EXT_surface_maintenance1: VK_KHR_get_surface_capabilities2.
The Vulkan spec states: All required extensions for each extension in the VkInstanceCreateInfo::ppEnabledExtensionNames list must also be present in that list (https://docs.vulkan.org/spec/latest/chapters/initialization.html#VUID-vkCreateInstance-ppEnabledExtensionNames-01388)
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3514
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: DraVee <dravee@eden-emu.dev>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
|
|
| |
(#3147)
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3147
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
|
|
| |
Still had the issues with libusb, but that should get solved with the other PRs anyways
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2805
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
| |
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2546
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
|
| |
|
|
| |
* VVL has implemented the more modern alternative, thus we don't need to support it anymore
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
general: fix compile for Apple Clang
|
| | | |
|
| |/
|
|
| |
Co-authored-by: bylaws <bylaws@users.noreply.github.com>
|
| |
|
|
|
| |
This formats all copyright comments according to SPDX formatting guidelines.
Additionally, this resolves the remaining GPLv2 only licensed files by relicensing them to GPLv2.0-or-later.
|
| | |
|
| |
|
|
|
|
|
| |
Workaround an issue on Nvidia where creating a Vulkan instance from an
active OpenGL thread disables threaded optimization on the driver.
This optimization is important to have good performance on Nvidia
OpenGL.
|
| |
|
|
|
|
|
| |
For listing the available physical devices we can use Vulkan 1.0.
Now that MoltenVK supports 1.1 we can require it for running games.
Add missing documentation.
|
| |
|
|
|
|
| |
Report device enumeration errors with exceptions to be consistent with
other initialization related function calls. Reduces the amount of code
to maintain.
|
| |
|
|
|
|
|
|
| |
Initialize debug callbacks (messenger) from a separate file. This allows
sharing code with different backends.
Change our Vulkan error handling to use exceptions instead of error
codes, simplifying the initialization process.
|
|
|
Simplify Vulkan's backend initialization code by moving it to a separate
file, allowing us to initialize a Vulkan instance from different
backends.
|
