So... I said AVX can be poison
Posted: Tue Mar 26, 2024 7:22 pm
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
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
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
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