| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
size. This saves on a number of multiplications and fixes an issue where we were multiplying the y-scaling factor by the srcRectangle's height + 1 which was causing a crash in some GC titles
|
|
The hybrid XFB PR made it apply to both EFB copies and XFB copies.
|
|
They don't have a basename, therefore were being saved to empty files, and potentially can be compressed.
|
|
|
|
This will generate one shader per copy format. For now, it is the same
shader with the colmat hard coded. So it should already improve the GPU
performance a bit, but a rewrite of the shader generator is suggested.
Half of the patch is done by linkmauve1:
VideoCommon: Reorganise the shader writes.
|
|
Unsure why this was happening in the first place.
|
|
ScaleRectangleFromTexture, which does a draw, and
CopyRectangleFromTexture, which where possible, does a bit-for-bit copy.
|
|
|
|
VideoConfig: Make AspectMode and StereoMode enum classes
|
|
Resolves around 5 -Wmissing-brace warnings on macOS.
|
|
Makes for more strongly-typed identifiers (and doesn't pollute
surrounding namespaces)
|
|
|
|
|
|
the xfbs created from overlapping copies
|
|
be looked up from cache directly if they were defined previously and their hash hasn't changed
|
|
caused a hash change which would cause us to do a lookup from memory that gave us an incorrect result in XFB2Ram
|
|
only check EFBs
|
|
|
|
texture size they are meant to represent
|
|
|
|
|
|
|
|
hasn't changed since the last frame
|
