Generic GCC not working on Sandy Bridge

[tormento]

I am doing some real scenario benchmarks to choose what flavor of your builds to use on my good old Sandy Bridge.

I have the following results:

3,62 fps — x265-msvc1938 3,65 fps — x265-avx-msvc1938 3,69 fps — x265-sandybridge-gcc13.2.0

Unfortunately x265-gcc13.2.0 gives me the following error, such as if you forced some instruction set. Shouldn't be the most generic build, such as the x265-msvc1938 one?

Video encoding returned exit code: -1073741795 (0xC000001D)

It's unclear what this exit code means, in case it's
a Windows system error then it possibly means:

# for decimal -1073741795 / hex 0xc000001d
  STATUS_ILLEGAL_INSTRUCTION                                     ntstatus.h   
# {EXCEPTION}
# Illegal Instruction
# An attempt was made to execute an illegal instruction.
# as an HRESULT: Severity: FAILURE (1), FACILITY_NULL (0x0), Code 0x1d
# for decimal 29 / hex 0x1d
  ERROR_WRITE_FAULT                                              winerror.h   
# The system cannot write to the specified device.

P.S: As a curiosity, would be possible to have a msvc sandybridge build to benchmark against gcc sandybridge one?

[Patman86]

Hi, GCC 13.2.0 corresponds to the normal MSVC version. Unfortunately I cannot reproduce the error. What are your settings?

[tormento]

As I wrote, I have a Sandy Bridge (i7-2600k) on Windows 11 x64.

I am attaching here the full log from StaxRip.

Usually when I see that kind of error, it's about unsupported instruction set, such as AVX2 or AVX512 (in my case).

24 x265-gcc13.2.0_staxrip.log

So, reading your words, x265-msvc1938 and x265-gcc13.2.0 are "identical"? Why the first version is working and not the second one?

[DJATOM]

Generic one uses optimizations for the host CPU, so probably contains avx2/fma instructions somewhere in the optimized code and that leads to illegal instruction error.

[Patman86]

I just remembered that I adapted the build process for gcc. Previously x86-64 was stored there and now I use x86-64-v3. That could be the cause. Does rav1e work for you? This is also compiled with x86-64-v3.

[Patman86]

Please use this version for further testing ;)

https://github.com/Patman86/x265-Mod-by-Patman/releases/download/3.5%2B153%2B14/x265-3.5+153+15-fc339385e-.Mod-by-Patman.-x64-x86-64-gcc13.2.0.7z

[tormento]

@Patman86 it works and you made some miracle too, as it is the fastest build with 3.94 fps.

Unfortunately there is really strange size issue with encoded file as:

x265-avx-msvc1938 10.438.644 bytes x265-msvc1938 10.431.496 bytes x265-sandybridge-gcc13.2.0 10.445.853 bytes x265-gcc13.2.0 8.064.546 bytes.

[tormento]

I have found a tiny but useful utility to find the instruction set that a exe requires and applied to previous gcc release:

InstructionSets64-0.1.0.exe x265.exe

ret mode64 branch_relative jump call avx bmi2 cmov novlx avx2 bmi sse1 sse2 ssse3 sse41 sse3 mmx dqi avx512 vlx bwi xop fpu int

The very strange part is that the patched one that you gave me uses the very same instructions set but it works.

[Patman86]

I read something on the internet that files compiled with the x86-64-v3 switch in GCC should not work with SandyBridge. I have now recompiled all files again, please test them. I can't really explain the file size issue. Should be almost identical.

[tormento]

Thanks for your efforts!

Tested and working, with the following fps:

4,26 avx-msvc1937 4,18 gcc13.2.0 4,08 msvc1937 4,07 sandybridge-gcc13.2.0

Seems that MSVC is doing a great job. I would be really curious to test a build with intel compiler.