Might be helpful to diagnose performance problems on user devices.
Additionally, moves the texture replacement controls to the top. They
should probably be moved somewhere else entirely...
See #17918
Haven't been using these for a while.
I've come to the conclusion here that I think it's better to try to
deal with the issues using safe workarounds like copies, instead of
relying on features with somewhat iffy driver support that are not
universal across APIs anyway.
Accessed from the in-game dev menu just like the Vulkan frame profiler.
With this we can easily see that actually submitting the GL commands is often the bottleneck on old
devices like a Galaxy S3.
Fixes#17451, while also keeping the Dante performance fix from #17032.
Of course, it's possible that something else could slow down now... But
hopefully not. This could also fix other problems.
This is a conceptually cool trick that just doesn't seem to be worth
it, compared to the old approach of copy + blend-in-shader. I haven't
found any game that benefits more than absolutely minimally, and having
two paths to test isn't great, when the win is so small.
So I'm disabling it. I'm keeping the code for now, but might clear it
out later.
Fixes#17069
Fixes#17182
Not exactly sure what behavior we really want, but I think this one is
OK, and at least more similar to the old one. Now we save
already-replaced textures if the named replacement texture is missing, and there
isn't already a hash-named one in new or the "root".
Fixes#17014
Even if our depth-testing-equal heuristic believes that the game needs
lower depth resolution.
This removes some depth-fighting artifacts (that are present on the real
PSP, but nice to avoid) in Outrun, Split/Second and Cars: Race-o-Rama -
essentially reverting these to the behavior we had before the heuristic.
(The heuristic is good though - it means less compat.ini hacks going in
the other direction).
In the case of Outrun, this relies on two passes that pass exactly the
same vertex coordinates twice resulting in the exact same final
geometry. This is actually guaranteed by the spec if the vertex math is
exactly the same and "invariant" is set on the position output, though
I guess you never know.. Haven't seen any issues at least.
Also sneak in disabling some validation messages from using extra Vulkan
validation layers other than the default.
Henrik Rydgård