So... I said AVX can be poison

The place to discuss Linux and Unix Operating Systems
Forum rules
Behave
Post Reply
User avatar
Grogan
Your Host
Posts: 470
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

So... I said AVX can be poison

Post by Grogan »

I'm going to mention a few ways that it has been for me, with the intent of advising caution when using -march= to compile things. This could apply to more than just AVX, but the use of -march= in general. I used to get away with -march=nehalem for bloody everything, but alderlake is not a safe bet for relying on compiler heuristics at this time.

First of all, it's a bad idea to compile toolchains with -march= anything that may allow the compiler to use hinky instructions, if you expect any of that code to run on other processors. I hadn't noticed the problem with gnu (uses shared libraries) but with LLVM, it doesn't have shared runtimes (well, other than plugging in to the back end like mesa and rust) and so anything you compile with it is going to have code from static libraries built in. This is the same for Rust. The point being, this is great for my computer, but now I can't run what I build here on the other computer, even though I have specifically compiled it for nehalem. It will be an instant illegal instruction op error.

I should have realized this, but hadn't considered the static libraries. I don't care though, I haven't done any -march=alderlake'ing anywhere yet on my LFS/Bollux system (and I need to fix my LLVM stuff anyway, I have 18.0.0 there) so I'll just keep that system with everything built for nehalem. That's actually good for any Intel CPUs (of nehalem or higher of course). Then I'll just reboot and spend half an hour compiling a Firefox for the other box and it will run. I'm tired of that taking hours on any computer.

Now, that's beside the point. AVX can also be poison on THIS system. So far, I haven't run into that much, and only with DXVK and vkd3d-proton (so far), but it can also be more subtle.

If the 32 bit DXVK (d3d9, 10, 11 dlls) is compiled with -march=alderlake, 32 bit games and game clients won't run. (game clients use embedded web browers -> dx11). Full stop.

I thought that vkd3d-proton was OK compiled like that, most games were working, but some would immediately crash. It seems that these games are ones that use AVX themselves :lol:

So I can build the Wine parts, both gcc and mingw parts of the build, both 64 and 32 bit with -march=alderlake and that's just dandy. However I have to be careful to unset and reset CFLAGS/CXXFLAGS (-march=nehalem -mtune=alderlake is good) in places in a scripted Proton build. I had to build my system dxvk and vkd3d-proton that get used with my system wine for lutris without alderlake too. Again, at first I thought my vkd3d-proton was fine until I tried my first game with AVX usage (Cyberpunk 2077 has CPU detection and enables it in code paths)

It's now unwise for me to do this, but I'll make my own mistakes and adjust builds as necessary. At least this stuff is funner for me than connecting screws and wires rong :evil:
User avatar
Grogan
Your Host
Posts: 470
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: So... I said AVX can be poison

Post by Grogan »

I did a clean build of LLVM 18.1.2 on my LFS (no -march at all) and then built it again with itself to make sure there were no "nehalem" instructions in my libraries. I then did the same with Rust 1.77.0 (I link my Rust statically too so it doesn't break when I upgrade LLVM)

I'll be able to build code for any target with that LLVM toolchain now. (and yes the firefox browser I built with it runs on the other computer). I have my wasi compiler working for firefox builds now too. I'm going to keep that clean on that one setup for this purpose but on Arch I'm going to -march :-)

(The fun part is that I had this all done before supper yesterday... no more messing up my game time waiting for builds to finish. The only good thing about procrastination is that it stops hurting when you finally stop lol)

This is one very good reason that static linking is bad, bad, bad. Maybe those Gnu folks (and Microsoft for that matter) have it right, by having shared compiler runtimes, though at least gcc's are backwards and mostly forwards compatible (libgcc_s.so.1 doesn't ever seem to be a problem, though libstdc++ will be, but that's more than just low level runtimes). Those Microsoft c++ compiler runtimes are ridiculous... they have to maintain umpteen versions of that in WinSxS.
Post Reply