0

There is x264. It use a lot of x86 asm files. For example pixel-32.asm. This files can use different SIMD instruction set: mmx, 3DNow!, sse family, others

I need the simple way to automatically analyze every file. I want get which SIMD family in which file are used. How?

I think every asm file must contain information about which SIMD family it use (or information that no SIMD). Without this information it is very bad idea try to use this files...
I am angry, my x86 CPU support mmx and 3DNow! only, but x264 try call sse, so I get "Illegal instruction" sometimes. I plan to make patch for x264.

P.S. If you can make issues in official repo let me know.

P.P.S. This thread on Doom9 (mirror).

Андрей Тернити
  • 192
  • 11
  • 1
    SSE1 and SSE2 are included in the AMD64 instruction set. Since you have 3DNow, you probably using AMD K6 or K7 CPU. These CPUs were made between 1998 and 2004. I will be surprised if maintainers of x264 will accept patches addressing compatibility issues with 20+ years old processors. They can’t even test these patches because they don’t have a compatible hardware. – Soonts Jul 28 '23 at 23:46
  • 2
    @Soonts 1) anyway program should say "need sse, sse2 instructions; your CPU not supported" instead of "Illegal instruction" and restart user session, isn't it? 2) AMD discontinued all Geode processors in 2019. What about support of 4 years old CPUs? – Андрей Тернити Jul 30 '23 at 08:25
  • In that doom9 thread, you say you only have a 586-compatible CPU. Most 32-bit binaries you'll find these days are compiled for i686, using Pentium-Pro new instructions like `cmov`, so will fault on a CPU that doesn't support them. That includes truly ancient CPUs like K6-2. (https://bbs.archlinux32.org/viewtopic.php?id=2701). If you're doing serious retro-computing below the baseline that most modern distros configure `gcc -m32` to build for, you should expect to need special build options for most modern programs. – Peter Cordes Aug 01 '23 at 10:50
  • BTW, one program faulting with SIGILL doesn't "restart [the] user session". It doesn't log you out or anything, it just exits with an error message. x264 is a command line program that just does one encode, so one run of it isn't what I'd call a "user session". If the fault is in hand-written asm, then yeah it would be nice if it told you which ISA feature level was missing from the CPU. Hopefully it even does that, exiting if SSE2 is required but missing. But if it's faulting before it even gets to its CPU-detection function, that's a problem with how it was compiled (not) for your CPU. – Peter Cordes Aug 01 '23 at 10:56
  • Anyway, you can use a debugger to check where it faults, and on what instruction. (In GDB, `disas`) Then look it up in the manual; any actual SSE instruction will normally have an "extension" listed, showing what CPU feature added it, like `psadbw` in SSE2 for the version using XMM registers, SSE1 for the MMX version (https://www.felixcloutier.com/x86/psadbw). AMD may have added some or all MMX-extended instructions in some CPUs without SSE, though. – Peter Cordes Aug 01 '23 at 10:59
  • @PeterCordes If any program doesn't support for example i586 it should says "Error, i586 CPU not supported", isn't it? x264 don't try to check. – Андрей Тернити Aug 01 '23 at 11:53
  • @PeterCordes "faulting with SIGILL doesn't "restart [the] user session" when I get "Illegal instruction", htop also crash.. "If the fault is in hand-written asm" - see my first post, pixel-32.asm use "pshufw" from "64–Bit SIMD Integer Instructions", but I can't find any officially (from maintainer) information about minimum requirements to use hand-written asm of x264 for x86. I agree with MasterNobody looks like it is SSE2 for x86, but it can be not a true. – Андрей Тернити Aug 01 '23 at 12:03
  • If other processes also crash when one dies from SIGILL, your system is broken. Perhaps you installed a distro where some packages are compiled with `-march=i686`, and some code-paths use an instruction like `cmov`. But I'd have expected that to lead to an unusable system. Maybe the OOM-killer, if SIGILL triggers dumping a core-dump filtered through something that allocates a lot of RAM when that happens? – Peter Cordes Aug 01 '23 at 17:37
  • `pshufw mm, mm, immediate` is an MMXext instruction, not supported by Pentium-MMX. It was new for Intel in Pentium-3 (Katmai: https://nasm.us/doc/nasmdocf.html#section-F.1.7), as part of the SSE1 feature bit in CPUID. If x264 intended to support MMX-only CPUs, maybe they got their CPU feature levels wrong and used an extended-MMX instruction on a CPU that doesn't support them. (Or maybe your CPU has some but not all of those new MMXext instructions, making detection harder. I think x264's hand-written asm has some asm feature-level checking built-in with macros.) – Peter Cordes Aug 01 '23 at 17:42
  • 1
    x264's handwritten asm wouldn't be used on his CPU because minimum supported instruction set for it is MMXExt and x264 checks its support in runtime. There is no MMX only (not MMXExt) version of handwritten asm in x264. So SIGILL is most probably is in C code and not in asm. – nobody555 Aug 01 '23 at 21:14
  • Did you actually check with GDB which instruction faulted? x264 uses CPU detection and dynamic dispatching (via function pointers). Seeing an instruction in an asm source file doesn't mean it will try to run it; that's why it can have AVX2 and AVX-512 functions but still run on CPUs without AVX. Run `gdb x264`, and inside GDB do `run --help` or with args for a video input file. Or run GDB on `ffmpeg`. Anyway, then use `disas` or `layout asm` when it faults. – Peter Cordes Aug 03 '23 at 06:34

0 Answers0