Notably, runtime-built SSSE3 version of VPERM.
Some other instructions are refactored and vectorized.
Aarch64 impl of multiple instructions including VPERM.
- NV GPUs have a tendancy to be off by a very small margin, breaking rendering when greaterThan/lessThan checks are used.
- NOTE: Currently this setting is using the sRGB flag which indicates 8-bit output.
Only one game is currently known to care about this behaviour so this is good enough for now.
* Update asmjit dependency (aarch64 branch)
* Disable USE_DISCORD_RPC by default
* Dump some JIT objects in rpcs3 cache dir
* Add SIGILL handler for all platforms
* Fix resetting zeroing denormals in thread pool
* Refactor most v128:: utils into global gv_** functions
* Refactor PPU interpreter (incomplete), remove "precise"
* - Instruction specializations with multiple accuracy flags
* - Adjust calling convention for speed
* - Removed precise/fast setting, replaced with static
* - Started refactoring interpreters for building at runtime JIT
* (I got tired of poor compiler optimizations)
* - Expose some accuracy settings (SAT, NJ, VNAN, FPCC)
* - Add exec_bytes PPU thread variable (akin to cycle count)
* PPU LLVM: fix VCTUXS+VCTSXS instruction NaN results
* SPU interpreter: remove "precise" for now (extremely non-portable)
* - As with PPU, settings changed to static/dynamic for interpreters.
* - Precise options will be implemented later
* Fix termination after fatal error dialog
- This is a hack, ideally we should be using coverage-based masking when writing the exploded texture.
- We do not have access to the fragment coverage mask and it is non-trivial to integrate it in a competent manner.
- Try to use REP MOVSB when the size of the transfer is above a certain threshold
- This threshold is determined by the ERMS and FSRM cpuid flags
- The threshold values are (roughly) taken from GLIBC
- A threshold of 0xFFFFFFFF indicates that the cpu has neither flag
- This is just not part of spec, there is no enforcement for multiple of block size for width or height of s3tc compressed images.
- This restriction does indeed exist for ASTC and ETC but we're not using those formats.
macOS defines uint64 as an alias of unsigned long long. Drop the length
modifiers to resolve the warning on macOS:
rpcs3/rpcs3/Emu/GDB.cpp:107:37: warning: format specifies type 'unsigned long *' but the argument has type 'u64 *' (aka 'unsigned long long *') [-Wformat]
sscanf_s(val.c_str(), "%" HEX_U64, &result);
~~~~~~~~~~ ^~~~~~~
Also use std::from_chars to implement hex_to_{u8,u32,u64} instead of
sscanf.
Drop AVX2 path for now, since it usually operates on small data.
Rely on automatic SSE vectorization on recent compilers.
Side refactoring on JIT.h to workaround weird conflict issue.
