| Age | Commit message (Collapse) | Author |
|
Vulkan: Don't set a negative offset in scissor rect
|
|
|
|
|
|
|
|
|
|
|
|
This also better handles in-memory interlaced XFB data placed by the CPU
by considering the stride from the VI.
|
|
|
|
|
|
|
|
TextureCache: Fix GPU decoding of XFB copies
|
|
|
|
|
|
|
|
This can cause driver crashes or GPU hangs if we do.
|
|
Since loading textures can result in rendering, e.g. partial copies, we
don't want to disturb partially-bound GX state.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stitch together overlapping XFB regions in order of XFB copy creation.
|
|
This fixes severe image flickering in some cutscenes of Twin Snakes. The game appears to sometimes load a previously made XFB copy as a texture before it is actually rendered to the screen, which we took as an invitation to invalidate the XFB copy.
|
|
|
|
GetRAMCopyFilterCoefficients()
|
|
We want this setting to invalidate the cache because it may affect the appearance of textures in the rendered scene, therefore one would expect changing it while the game is running to have the expected effect immediately.
|
|
Now the arbitrary mipmap reference downsampling is just done in linear space,
these are no longer used.
|
|
This no longer converts from sRGB to linear for the reference mip
downsample - even if the original mipmap creation tool used an sRGB
colorspace (which isn't really guaranteed, and may even change per
game), this is a "fast" heuristic that's only an estimate anyway.
The average diff is also now stored in a u64, avoiding floating point
calculations in the per-pixel hot loop.
This should speed up the detection significantly, hopefully fixing
jank when loading in new textures.
|
|
Make arbitrary mipmap detection a config option
|
|
Using 8-bit integer math here lead to precision loss for depth copies,
which broke various effects in games, e.g. lens flare in MK:DD.
It's unlikely the console implements this as a floating-point multiply
(fixed-point perhaps), but since we have the float round trip in our
EFB2RAM shaders anyway, it's not going to make things any worse. If we
do rewrite our shaders to use integer math completely, then it might be
worth switching this conversion back to integers.
However, the range of the values (format) should be known, or we should
expand all values out to 24-bits first.
|
|
|
|
Multiplying 2x 8bit values is guaranteed to fit in 16bits, 4 channels then in
18bits, which means an 'int' shouild be sufficient to avoid overflows
|
|
TextureConversionShader: Don't sample from adjacent rows when not needed
|
|
Hopefully this better matches the user's view of a texture - as large changes in
colour should be weighted higher than lots of very small changes
Note: This likely invalidates the current heuristic threshold default
|
|
This is likely a "superuser" option at best, but I want to be able to play with
it without rebuilding if I want to tweak the heuristics
|
|
Under GFX::Enhancements::ArbitraryMipmapDetection - default enabled
|
|
Brings more common code under the Common namespace.
|
|
|
|
|
|
Also makes y_scale a dynamic parameter for EFB copies, as it doesn't
make sense to keep it as part of the uid, otherwise we're generating
redundant shaders.
|
|
|
|
Macros should be all upper-cased. This is also kind of a wart that's
been sticking out for quite a while now (we avoid prefixing
underscores).
|
|
Lowest hanging fruit I could find with a profiler.
Not sure this stuff actually needs to be done, but assuming it is, why
not do it quickly? 10x faster, goes from 1% CPU to 0.09%.
|
|
The option is named DisableCopyToVRAM under the Hacks section in
GFX.ini. It is intentionally not exposed to the GUI, as users should not
need to use it under normal circumstances. The main use is debugging
issues in the EFB-to-RAM shaders.
|
|
It's the inverse of supports-copy-to-vram.
|
|
This makes state tracking simpler, and enables easier porting to command
lists later on.
|
|
This is adapted from Bighead's code that was posted at
https://forums.dolphin-emu.org/Thread-dolphin-custom-texture-mipmaps?pid=460867#pid460867
In master, custom textures are never treated as having arbitrary mipmaps,
so we need either a change like this or a change that makes us apply the
arbitrary mipmap heuristic even when a custom texture is used.
|
|
|