* Fast accurate DATE is always enabled, it was faster than standard DATE
* The less fast version is always enabled too. It is likely barely used
so perf impact will be small on few game that could hit this path.
Nice rendering has a higher priority
* The "slow" path will depends on the date option.
Note normally it isn't too slow (-10%) if GL_ARB_shader_image_load_store
is supported but AMD crimson is an epic fail.
Faster :) Reduce further the cost of accurate date
The optimization will clear the stencil to 1. So all pixels will have a
single sample that pass both the depth & stencil test. No primitive
overlaps So the destination alpha test can be done directly in the
shader.
Game often uses date to allow a single pixel pass. If this
use case is detected, stencil buffer will be cleared after first pixels
that pass both depth&stencil test.
It seems to reduce the load on the GPU.
Note: with the help of texture barriere, maybe we could implement the algo
with a single pass.
So just reuse GT hle shader :) Acid stage is now correct. However it might need
some tuning for others stages.
Still look awful with uspcaled resolution (note internal game framebuffer is around 160x128)
This reverts commit 53690cf9d0.
Quoting user:
For aliasing, the option allow of reduce a little but always very
visible compared with DX11 even with anisotropic OFF, , furthermore
many textures bug added with option activated (predictable but not see
on DX11 with anisotropic ON).
TL;DR doesn't worth it.
Note: it seem to work on DX because DX uses HW texturing in clamp region
mode (and others invalid case). OpenGL uses SW texturing to ensure accuracy
By default, anisotropic filtering was disabled when textures aren't countinuous.
This hack allows to force it. It can help to reduce aliasing but it would create
unexpected effect on texture boundaries.
Again, someone ought to add the option on Windows too
Texture coordinate could be dummy/float/int integral/int normalized.
Old behavior:
* VS was in charge to select the texture coordinate
* int integral format wasn't supported
New behavior:
* Always compute all formats
* FS will be in charge to select the good format
Impact:
* VS will be slightly slower but it reduces shaders permutation from
little to 0 (won't be bad for CPU)
* FS speed isn't impacted as 2 separate code paths were already required
to support both format
* Rasterizer will be 33% slower but unlikely to be the limited factor of
the GPU
* In future we could directly use the integral format in the FS.
V2: remove useless PSin_t
It would be on by default. Unsafe & fast path.
The hack is a security if someone encounters any issue
v2: update Windows gui file
v3: fix typo in tooltip and linux gui
Initially it was free to do the SW blending because safe fbmask
will already do a sw blending.
Unsafe version uses a fast path with a limited blending. Therefore
SW blending isn't free anymore.
Improve the speed of the previous speed hack (xenosaga 1)
The hack relies on the undefined behavior of the hardware so it can
potentially generate rendering corruption.
This new hack drops the cache flusing when only the alpha channel is masked.
Alpha is a direct copy of the fragment. Normally masked bits will be constant
everywhere (RT, FS output, texture cache) so it would likely work.
Just in case, code is only enabled with the new shiny hack
runion/rempty/rinter requires x < z and y < w
Help issue #762 (accurate blending issue)
If you want to shine, please put better GSVector code (AVX512 is 2 instruction :p)
Gregory Hainaut