Can you please, in one or two concise sentences, explain what exactly your problem is? I read through the entire wall of text but I have no idea what it is you're trying to tell us.
but it seems it is not enabled for x86_64-w64-mingw32-gcc-10.2 either now.
SSE2 is supported by all x86_64 CPUs so there's no need to explicitly enable it. The 64-bit binaries do not contain x87 instructions even with GCC 10.2.
Aah.. right, so when the compiler hits stuff like
https://github.com/doitsujin/dxvk/blob/master/src/util/util_bit.h#L140
it automagically knows to use SSE (-msse) when compiling for x86_64, where as when compiling for i686/i386 it fails, as it has to be explicitly enabled to allow this.
Then i learned something new, cos i kinda thought since the default compiler-set options determined this - ie. when the compiler sais -msse [disabled] it is not the same as specifying -mno-sse in the build-options. Yeah.. i see that now.
Why ubuntu was not able to produce working binaries with meson-0.53 when using gcc-mingw-w64-10.2 is somewhat of a puzzle tho, and thought maybe some "detected flags" kind of thing was the reason, but probably not then.
Sorry for wasting your time with this then :) Closing. (Can always be searched if someone else struggles in the future with self-compiles and ubuntu... but docker w/arch for that)
Nothing extracted yet.
This is meant as a observation and some comments when building with recent mingw-w64.
As of cbba1472dbe6f2e206a570a69fd94c6b308503a5 DXVK requires mingw-w64-headers >= 8.0. This usually means it comes packaged with newer mingw-w64 aswell, although i had no huge issues compiling and using DXVK with gcc-mingw-w64-9.3 by just backporting the mingw-w64-headers-8.0 as a standalone upgrade.
However, Hirsute is now pulling gcc-mingw-w64-10.2 from upstream debian (including mingw-w64-headers-8.0). This is what arch uses currently aswell. All is good.
I backported this to Ubuntu, and had some strange issues when testing Unigine benchmarks (Valley, Heaven and Superposition), where DXVK would instantly crash upon loading. (Nothing interesting gathered from dxvk logs, as it crashed before that, and wine logs quickly spews 2+GB of trace/relay logs that is kinda beyond me to figure out).
I fired up the compile on arch using docker, and that (ofc...) worked like a charm. Upon further digging, i found that Arch was using meson 0.56, vs. Focal using meson 0.53. I backported this too from Hirsute, and whamola - progress.
So it seems as something changes when using newer meson (0.56) for this issue too for some odd reason?
Right, futher digging, and i find that both debian/ubuntu and arch gcc-mingw-w64 has quite a few compile flags changed between 9.3 -> 10.2. Not so easy to downgrade packages for Arch (finding the correct url for pacman and whatnot), but the most obvious change is that x86_64-w64-mingw32-gcc no longer enables SSE and SSE2 flags for 64-bit like it used to with 9.3(and older)! This was not enabled for i686 (32-bit) version for 9.3 or older either, hence 6fb09cb9fceaf9890ec83ded507ddae22c3b6a40 , but it seems it is not enabled for x86_64-w64-mingw32-gcc-10.2 either now.
9.3
10.2 (Arch... same for Ubuntu)
So, this kinda begs the question: Should it be enabled for 64-bit in the 64-bit buildfile now? I guess it would not do any huge harm when using <=9.3 mingw, since it is default enabled for that anyway?
Further it seems ubuntu has some additional patches to gcc-mingw-w64 that Arch is not using. This means that for me when building on Ubuntu i can enable
-mavx(and thus also enabling all the -msseX options too). This seem to work fine, but if i do this on Arch build, it will crash DXVK like i had experienced with meson-0.53 on ubuntu. (Go figure).Worth some tests perhaps? Sorry for getting horribly long-winded here, but there are quite a few build-bots that utilizes arch for most up-to-date packages (Forget debian/ubuntu as you either need to use sid, or hirsute to be able to compile this without PPA's).