Skip to content

FEX-2407

Compare
Choose a tag to compare
@Sonicadvance1 Sonicadvance1 released this 04 Jul 01:35
· 935 commits to main since this release
d3399a2

Read the blog post at FEX-Emu's Site!

I hope you're ready to game, because your Arm system just got support for AVX.
And AVX2. And FMA3. And F16C. And BMI1. And BMI2. And VAES. And VPCLMULQDQ.

Yeah, we've been busy.

We did a little team-building exercise this month: "bring up AVX on 128-bit
hardware in a week". Now our team is built, and AVX games run on FEX:




AVX on 128-bit Arm

Computers traditionally perform one operation at a time. The hardware decodes
an instruction, evaluates the operation on a single pair of numbers, and
repeats for the next instruction. In mathematical terms, the instructions
operate on scalars.

That design leaves performance on the table.

Many programs repeat one operation many times with different data. Modern
instruction sets exploit that repetition. A single "vector" instruction can
operate on multiple pieces of data at once. Programs will perform the same
amount of arithmetic overall, but there are fewer instructions to decode and
the arithmetic is more predictable. That enables more efficient hardware.

A "scalar" instruction adds a pair of numbers; a "vector" instruction adds
multiple pairs. How many pairs? That is, what length is the vector?

That's a design trade-off. Increasing the vector length decreases the number of
instructions we need to execute while increasing the hardware cost.
Supporting large vectors efficiently requires a large register file and many
arithmetic logic units. Besides, there are diminishing returns past a certain
vector length.

There is no-one-size-fits-all vector length. Different instruction sets make
different choices. In x86, the SSE instruction set uses 128-bit vectors, while
AVX and AVX-512 instructions support 256-bit and 512-bit respectively. For Arm,
the traditional ASIMD (NEON) instructions use 128-bit vectors. Depending on the
specific Arm hardware implementation, the flexible new SVE instructions can use
either 128-bit or 256-bit.

For performance, we try to translate each x86 instruction to an equivalent arm64
instruction. There's no perfect 1:1 correspondence, but we can get close. For
vector instructions, we translate 128-bit SSE instructions into equivalent
128-bit ASIMD instructions.

In theory, we can do the same for AVX, mapping 256-bit AVX instructions to
256-bit SVE instructions. Mai implemented that last year, speculating that their
work would enable AVX on future 256-bit SVE hardware.

...

That hardware never came. Some recent hardware supports SVE but only 128-bit.
Others don't have that, supporting only ASIMD. We had a shiny AVX-256
implementation with no 256-bit hardware to use it with.

Our position remains that efficient AVX emulation requires 256-bit SVE. Unfortunately,
many games today have a hard requirement on AVX. We want to let you play
those games on your Arm devices, so we need to plug our noses and implement
256-bit AVX on 128-bit hardware.

The idea is simple; the implementation is not. To translate a 256-bit
instruction, we decompose it into two 128-bit instructions operating on each
half of the 256-bit vector. In effect, we partially "undo" the vectorization.

This plan has a gaping hole: the register file. Arm has more general purpose
registers than x86, so we statically assign each x86 register to an Arm
register. If we didn't, accessing certain x86 registers would require slow
memory accesses. All efficient x86-on-Arm emulators therefore statically map
registers.

This scheme unfortunately fails with AVX emulation. Our Arm hardware has 128-bit
vectors, but we're emulating 256-bit AVX vectors. We would need twice as many Arm
vector registers as x86 vector registers, and we don't have enough.

Still, running AVX games suboptimally is better than not running at all. Yes,
we're out of registers -- we'll just have to keep some in memory. The assembly
isn't pretty, but it works well enough.

Building on Mai's SVE-256 implementation of AVX, Ryan whipped together a
version supporting both SVE-128 and ASIMD. That means it should work on
all arm64 devices, all the way back to ARMv8.0.

F16C, FMA, and more

AVX isn't the only x86 extension new games require. After beating AVX, x86 has a
post-AVX questline for emulator developers, with extensions like F16C.
Fortunately, nothing could scare Ryan and Mai after AVX, and they tackled the
new extensions without a hitch.

Speeding up translation

Dynamically assigning AVX registers means we can't translate instructions
directly and expect good results. While we don't need a full optimizing
compiler, we do need enough intelligence for basic inter-instruction
optimizations. FEX has had some optimizations since day one, but the priority
has always been on bringing up new games. There's been even less focus on the
translation time -- not how fast the generated arm64 code executes but how
fast we can generate the arm64 code. Translation overhead contributes to slow
loading screens and in-game stutter, so while it flies under the issue radar,
it does matter. So, Alyssa optimized the
FEX optimizer this month by merging compiler passes. That both simplifies the
code and speeds up translation. Since the start of June, we've reduced
translation time 10%... and more optimization is coming.

Happy gaming :-)


Raw Changes

FEX Release FEX-2407

  • ARM64

  • Adds new FMA vector instructions (00cf8d5)

  • AVX128

  • Fixes vmovlhps (e2d4010)

  • Minor optimization to 256-bit vpshufb (5821054)

  • Fixes scalar FMA accidentally using vector wide (4626145)

  • Minor optimization to vmov{l,h}{ps,pd} (cf24d3c)

  • Some quick bugfixes (739ac0f)

  • Enable all the things (e519bf5)

  • Fixes wide shifts (a031a49)

  • F16C support (4d821b8)

  • Implement support for gathers (6226c7f)

  • FMA3 (7d939a3)

  • fix VPCLMULQDQl (5da205d)

  • More instructions Part 4 (77aaa9a)

  • Fix vmovntdqa failing to zero upper 128-bits (7ff9622)

  • Fixes SSE4.2 string compare instructions (dce1b24)

  • More instructions Part 3 (8c751d7)

  • More instructions (ddb9f6d)

  • More various instructions (be8ff9c)

  • Some pun pickles, moves and conversions (7bbbd95)

  • Move moves! (f489135)

  • Arm64

  • Minor VBSL optimization with SVE128 (2e6b08c)

  • Remove contiguous masked element optimization (dc44eb4)

  • Implement support for emulated masked vector loadstores (3d26e23)

  • Arm64Emitter

  • drop out of date comment (825d2c9)

  • BMI2

  • Ensure rorx immediate masks by operation size correctly. (54a1f7d)

  • CMake

  • Add a clang version check (5d67223)

  • CPUID

  • Oops, forgot to enable AVX2 (58e949e)

  • Update labeling on some reserved bits (2da1e90)

  • CodeEmitter

  • Fixes vector {ldr,str}{b,h} with reg-reg source (2e84f21)

  • CoreState

  • Move InlineJITBlockHeader to the start of the struct (933d622)

  • Externals

  • Update vixl submodule (b092b7a)

  • FEX

  • Consolidate JSON allocators and fix 3691 (643e964)

  • FEXConfig

  • Clear up TSO emulation string (8d92902)

  • FEXCore

  • remove very out-of-date optimizer docs (1a0d135)

  • Fixes address size override on GPR sources and destinations (53b1d15)

  • Implement AVX reconstruction helpers (6edf461)

  • Disentangle the SVE256 feature from AVX (13ebfb1)

  • Fixes Call with 32-bit displacement and address size override (e4ff3da)

  • FEXGetConfig

  • Support the ability to get TSO emulation facts (2e009be)

  • Frontend

  • Expose AVX W flag (2e5fa1e)

  • HostFeatures

  • Always disable AVX in 32-bit mode to protect from stack overflows (e99e252)

  • Work around Qualcomm Oryon RNG errata (df96bc8)

  • IR

  • rename _VBic -> _VAndn (67e1ac0)

  • InstCountCI

  • add segment register cases (e7bdb86)

  • explicitly disable AFP everywhere (7c7d767)

  • JIT

  • delete silly assert (61ff1b3)

  • Linux

  • Calculate cycle counter frequency for cpuinfo (76f3391)

  • LinuxEmulation

  • Add a helper for getting the ThreadStateObject from CPU frame (89b05a2)

  • OpcodeDispatcher

  • Implement support for non-temporal vector stores (472a373)

  • Optimize x86 canonical vector zero register (a451420)

  • Handle F16C operations (94fd100)

  • Fixes bug in pshuf{lw,hw} (dfda673)

  • refactor Comiss helper (fac9972)

  • Adds initial groundwork for decomposed AVX operations (b2eb8aa)

  • Refactor address modes (db0bdd4)

  • refactor zero vector loads (c57e9e0)

  • RA

  • priorize remat over spilling (46ca53a)

  • SMCTracking

  • Fix incorrect mprotect tracking (d7348c8)

  • Scripts

  • add update_instcountci.sh script (1971404)

  • InstallFEX

  • update PPA URL (9744d8d)

  • Vector

  • Helper refactorings (3f232e6)

  • Windows

  • Small fixes for compat with newer toolchains/wine versions (4e5da49)

  • X86Tables

  • add Literal() helper (8f769ce)

  • Misc

  • Use number of jobs as defined by TEST_JOB_COUNT (f453e15)

  • Revert removing RCLSE (02a218c)

  • Optimize gathers slightly (ba04da8)

  • Largest x87 blocks of code from games (500ad34)

  • (1700d54)

  • OpcodeDispatcher: optimize nzcv with asimd masked load/store (2e32426)

  • Tiny opt for vzeroall (ad4d4c9)

  • Optimize vcvtps2ph (756fa2e)

  • Remove RCLSE (d1d41f5)

  • (1c24d63)

  • Fix VMOVLHPS instruction (3a310b8)

  • Adds back cmake error on x86-64 hosts (b2db04f)

  • Set tag properly in X87 FST(reg) (6e3643c)

  • Fixes AFP.NEP handling on scalar insertions (da21ee3)

  • VAES support (d2baef2)

  • Ignore python files for clang-format (053620f)

  • FXCH should set C1 to zero (87fe1d6)

  • First few commits from Ryan's AVX branch (29f6442)

  • json_ir_generator: don't print unrecoverable temps (f863b30)

  • Clean ups from my RCLSE branch (4965344)

  • Revert "OpcodeDispatcher: optimize logical flags" (9aa82ec)

  • Use FEX_HOSTFEATURES instead of FEX_ENABLEAVX (b17a2e9)

  • unittests

  • Adds MMX and x87 conflating unit test (d2437e6)

  • Fixes typo in vpcmpgtw test (d884eb9)

  • Split up vtestps unittest to accumulate flags in independent registers. (4d00a52)