Open ms178 opened 10 months ago
Does it work if you add
#include <algorithm>
to d3d9_mem.cpp
?
Yes, that fixes that particular build error.
By the way, I still see the following build issue with LTO later on (which was also present in 13.2.1 on an earlier dxvk build):
FAILED: src/d3d11/d3d11.dll
i686-w64-mingw32-g++ -o src/d3d11/d3d11.dll src/d3d11/d3d11.dll.p/version.o src/d3d11/d3d11.dll.p/.._dxgi_dxgi_format.cpp.obj src/d3d11/d3d11.dll.p/d3d11_annotation.cpp.obj src/d3d11/d3d11.dll.p/d3d11_blend.cpp.obj src/d3d11/d3d11.dll.p/d3d11_buffer.cpp.obj src/d3d11/d3d11.dll.p/d3d11_class_linkage.cpp.obj src/d3d11/d3d11.dll.p/d3d11_cmdlist.cpp.obj src/d3d11/d3d11.dll.p/d3d11_context.cpp.obj src/d3d11/d3d11.dll.p/d3d11_context_def.cpp.obj src/d3d11/d3d11.dll.p/d3d11_context_ext.cpp.obj src/d3d11/d3d11.dll.p/d3d11_context_imm.cpp.obj src/d3d11/d3d11.dll.p/d3d11_cuda.cpp.obj src/d3d11/d3d11.dll.p/d3d11_depth_stencil.cpp.obj src/d3d11/d3d11.dll.p/d3d11_device.cpp.obj src/d3d11/d3d11.dll.p/d3d11_enums.cpp.obj src/d3d11/d3d11.dll.p/d3d11_features.cpp.obj src/d3d11/d3d11.dll.p/d3d11_fence.cpp.obj src/d3d11/d3d11.dll.p/d3d11_gdi.cpp.obj src/d3d11/d3d11.dll.p/d3d11_initializer.cpp.obj src/d3d11/d3d11.dll.p/d3d11_input_layout.cpp.obj src/d3d11/d3d11.dll.p/d3d11_interop.cpp.obj src/d3d11/d3d11.dll.p/d3d11_main.cpp.obj src/d3d11/d3d11.dll.p/d3d11_on_12.cpp.obj src/d3d11/d3d11.dll.p/d3d11_options.cpp.obj src/d3d11/d3d11.dll.p/d3d11_query.cpp.obj src/d3d11/d3d11.dll.p/d3d11_rasterizer.cpp.obj src/d3d11/d3d11.dll.p/d3d11_resource.cpp.obj src/d3d11/d3d11.dll.p/d3d11_sampler.cpp.obj src/d3d11/d3d11.dll.p/d3d11_shader.cpp.obj src/d3d11/d3d11.dll.p/d3d11_state.cpp.obj src/d3d11/d3d11.dll.p/d3d11_state_object.cpp.obj src/d3d11/d3d11.dll.p/d3d11_swapchain.cpp.obj src/d3d11/d3d11.dll.p/d3d11_texture.cpp.obj src/d3d11/d3d11.dll.p/d3d11_util.cpp.obj src/d3d11/d3d11.dll.p/d3d11_video.cpp.obj src/d3d11/d3d11.dll.p/d3d11_view_dsv.cpp.obj src/d3d11/d3d11.dll.p/d3d11_view_rtv.cpp.obj src/d3d11/d3d11.dll.p/d3d11_view_srv.cpp.obj src/d3d11/d3d11.dll.p/d3d11_view_uav.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_blend.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_buffer.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_depth_stencil.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_device.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_input_layout.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_multithread.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_query.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_rasterizer.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_sampler.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_texture.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_util.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_view_dsv.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_view_rtv.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_view_srv.cpp.obj -Wl,--allow-shlib-undefined -Wl,-O1 -shared ../../dxvk/src/d3d11/d3d11.def -Wl,--start-group -Wl,--out-implib=src/d3d11/d3d11.dll.a -static -static-libgcc -static-libstdc++ -Wl,--file-alignment=4096 -Wl,--enable-stdcall-fixup -Wl,--kill-at -Wl,-O3,--as-needed,-Bsymbolic-functions,--sort-common,-flto=auto -Wl,--gc-sections -march=native -mtune=native -maes -mbmi2 -mpclmul src/dxbc/libdxbc.a src/dxvk/libdxvk.a src/util/libutil.a src/spirv/libspirv.a src/wsi/libwsi.a subprojects/libdisplay-info/libdisplay-info.a src/vulkan/libvkcommon.a -ldxgi -pthread -lm -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -Wl,--end-group
../../dxvk/src/d3d11/d3d11_buffer.cpp: In function 'bool dxvk::CheckViewCompatibility(const DxvkBufferViewCreateInfo&, const DxvkBufferViewCreateInfo&)':
../../dxvk/src/d3d11/d3d11_buffer.cpp:206:3: error: no register to spill
206 | }
| ^
../../dxvk/src/d3d11/d3d11_buffer.cpp:206:3: error: this is the insn:
(insn 203 219 220 17 (parallel [
(set (reg:DI 153 [142])
(and:DI (not:DI (reg:DI 152))
(reg/v:DI 151 [orig:96 features ] [96])))
(clobber (reg:CC 17 flags))
]) "../../dxvk/src/d3d11/d3d11_buffer.cpp":294:40 481 {*andndi3_doubleword_bmi}
(expr_list:REG_DEAD (reg:DI 152)
(expr_list:REG_DEAD (reg/v:DI 151 [orig:96 features ] [96])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))))
../../dxvk/src/d3d11/d3d11_buffer.cpp:206: confused by earlier errors, bailing out
That is an Internal Compiler Error. It's a bug in GCC and should be reported to them.
Thanks, I should add a bit more context: Your fix unblocked me getting proton-cachyos to compile with mingw-gcc14-git; however the final dxvk binary still doesn't seem to work with several tested DX11 titles that crash at startup (e.g. Battlefield 1). This was also the case with minw-gcc-13.2.1; I also use quite aggressive compiler flags.
I can get it working again by exchanging the dxvk files under /usr/share/steam/proton with dxvk binaries compiled with mingw-gcc12.3.1 which I produce with a specific dxvk-mingw PKGBUILD. This way I get the best of the old and the new toolchain and get the DX11 titles working again.
As mingw-gcc is still at 12 on Arch Linux, most people compiling from source won't see this issue until Arch upgrades its mingw toolchain.
@ms178 Are you still having issues with this?
@ms178 Are you still having issues with this?
I haven't used mingw-gcc-14-git for a while. I also saw other issues with the stable GCC-14 release and the current MinGW version that made me abandon that GCC revision alltogether as it probably needs some more work from the MinGW side. However, using a recent mingw-gcc-13 snapshot some weeks ago, I still saw problems with DXVK in general using my aggressive flags that used to work with 12.3.1 which lead to non-starting or exciting DX games. But that is a different issue from the one originally reported here and probably not worth investigating at the moment.
Due to a recent switch in hardware, I am also not on Linux at the moment to investigate further.
I was about to fill a new bug report when I saw this one.
On my system, after a recent update of mingw-gcc to 14.1.1 dxvk also fails to compile while with mingw-gcc 13.2.1 worked without issues.
mingw-gcc versions:
x86_64-w64-mingw32-gcc (gcc 14.1.1 "x86_64-w64-mingw32-gcc (GCC) 14.1.1 20240607 (Mageia MinGW 14.1.1-1.mga10)
x86_64-w64-mingw32-gcc (gcc 13.2.1 "x86_64-w64-mingw32-gcc (GCC) 13.2.1 20230728 (Mageia MinGW 13.2.1-1.mga10)
Including \<algorithm> into any of d3d9_mem.(h,cpp) files fixed it for me.
It looks like \<algorithm> is also included into src/dxvk/dxvk_memory.cpp, src/dxvk/dxvk_presenter.cpp which use remove_if
too, so, at least for consistency sake, d3d9_mem
should include algorithm imo.
Besides this minor issue building/running dxvk with mingw-gcc-14.1.1 looks fine in my case. Regards.
Due to another issue with dxvk and mingw-gcc-13.2.1 (no DX apps work), I've decided to be brave, trying out a fresh mingw-gcc-git build from September 28th 2023. I saw the following build error in the 32-bit build with modest flags on my Haswell system. Maybe that's a pre-existing dxvk problem only revealed by the new compiler?! I've verified with mingw-gcc-12.3.1 that everything compiles fine with the old stable toolchain with the same dxvk version and compiler flags.