When that setting is enabled, m_xfb_entry is initially not present (during the phase where a shader compilation progress bar would be shown). The main path checks for m_xfb_entry, but the software renderer fallback path didn't.
Fixes another aspect of https://bugs.dolphin-emu.org/issues/13172.
Before, it used a fallback where it returned a default object, where the width and height were set to 0. Presenter::Initialize() used GetSurfaceInfo to set the backbuffer size, then used that size when initializing the on-screen UI (even for the software renderer, where the on-screen UI isn't currently present), which meant that ImGui got a window size of 0 and thus resulted in a failed assertion.
Although BindBackbuffer checks for size changes, it doesn't help because ImGui has already been initialized, and the size hasn't actually changed since initialization occured.
Fixes one aspect of https://bugs.dolphin-emu.org/issues/13172.
The HLSL compiler incorrectly decides isnan can't be true, so this
workaround was originally added in 52c82733 but lost during the
conversion to SPIR-V.
When faced with this error, users often don't try disabling dual core,
even though the error message suggests it. Perhaps the message is just
too long and lists too many things?
To try to improve the situation, I'm rewording the message and making it
say different things depending on what settings you are using.
This works around an Intel driver bug where, on D3D12 only, dual-source blending behaves incorrectly if the second source is unused on. This bug is visible in skyboxes in Super Mario Sunshine, which first draw clouds and sun flare in greyscale and then draw the sky afterwards with a source factor of 1 and a dest factor of 1-src_color (this results in the clouds being tinted blue). This process is done on an RGB888 framebuffer, so alpha update is disabled. (Color update is enabled; note that if you look at this in Dolphin's fifo analyzer, it won't be enabled because they use the BP mask functionality to only change the blending functions and not alpha/color update, for whatever reason.)
While the NV extension is totally fine, the KHR extension should be able to support more hardware.
For NVIDIA, the hardware either supports both or neither, it just needs a driver from the last two years.
For AMD, the drivers from late 2022-12 seems to bring support for the KHR extension.
For Intel, the KHR is also supported for some years.
Frame duplicate detection was inverted. Huge problem for 60fps games
where it would see all frames as "duplicates" and nothing would ever be
presented.
A lot of the remaining complexity in Renderer is the massive Swap function
which tries to handle a bunch of FrameBegin/FrameEnd events.
Rather than create a new place for it. This event system will try
to distribute it all over the place
Almost all the virtual functions in Renderer are part of dolphin's
"graphics api abstraction layer", which has slowly formed over the
last decade or two.
Most of the work was done previously with the introduction of the
various "AbstractX" classes, associated with texture cache cleanups
and implementation of newer graphics APIs (Direct3D 12, Vulkan, Metal).
We are simply taking the last step and yeeting these functions out
of Renderer.
This "AbstractGfx" class is now completely agnostic of any details
from the flipper/hollywood GPU we are emulating, though somewhat
specialized.
(Will not build, this commit only contains changes outside VideoBackends)
Texture cache occasionally mutates textures for efficiency.
Which is awkward if we want to borrow those textures from texture cache
to do something else, such as a graphics debugger, or async presentation
on another thread.
Content locking provides a way to signal that the contents of a texture
cache entry should not change. Texture cache will be forced to use
alternative strategies.
The whole ownership model was getting a bit of a mess, with a some
of special cases to deal with. And I'm planning to make it even more
complex in the future.
So here is some upfront work to convert it over to reference counted
pointers.
This is the behavior in the x64 and ARM64 vertex loaders. I don't know if it makes sense (the whole skipped vertex system seems jank, but several games behave incorrectly without it).
Pokechu22