doitsujin / dxvk

Vulkan-based implementation of D3D8, 9, 10 and 11 for Linux / Wine
zlib License
13.1k stars 841 forks source link

Hey would you mind building a release build for Newest-Windows-10 Pro? #1817

Closed lowspecchaos closed 3 years ago

lowspecchaos commented 3 years ago

I did try compiling it myself but Visual Studio was having none of it. meson errors -.- Like the performance is currently really close to Window's native performance in DX11.1, Also Fullscreen-Exclusive can also break window on minimise,

(My PC doesn't like Windowed-FullScreenMode due to being Exclusive Fullscreen OS, i'm using __COMPAT_LAYER=DisableDXMaximizedWindowedMode across most the OS)

I would so love to do some more testing if you wouldn't mind & i understand my configuration 100% isn't supported xD But it would be nice to get a single build with no support on release. Huge fan of your work, BF4 looks epic, You all deserve a pat on the back lol, Great Job 🥇 :) image

K0bin commented 3 years ago

Just use release 1.7.2.

And FWIW, there's usually no point in using DXVK on Windows with an Nvidia GPU. Almost all games end up being slower than without DXVK.

ghost commented 3 years ago

The build is patched with https://github.com/Sporif/dxvk-async dxvk---no-package.tar.gz

ghost commented 3 years ago

The build is patched with https://github.com/Sporif/dxvk-async dxvk---no-package.tar.gz

Does this patch affect / allow asynchronous shader compilation in Dx9 games such as Guild Wars 2?

ghost commented 3 years ago

Actually, it's very interesting it does work on Windows it self, even tho there's no mention in it and releases come in the non-Windows way of a .tar.gz file.

While I'm not an expert debugger and profiling troubleshooter, so I'm not sure if this is at all helpful in depth, but on the surface DXVK actually has a benefit on Windows that it enables GPU profilers/debuggers which normally don't support a game's GFX API to be able to work on those games. At least the versions which run on Windows.

I think I used a version a year ago and the host was the 1607 or 14393 build of Win10 from 2016, the anniversary update, and the game I tried with was DX11 only. The game in DXVK mode nor the profiler ever crashed, but there were some effects (smoke) in game that looked totally different (broken/unintended) from the native DX11 mode. The benefit may be the modern interface, more tools (filtering, searching), and perhaps some benefit in terms of visualizing the GPU work and timeline, but since it gives false (slower) results because of being another layer ontop then ofcourse everything wouldn't correspond to how it would be without DXVK, however in my case, it surprisingly was kinda even, it did not see a dramatic slowdown, it was pretty much the same, tho not any faster.

I mostly had no idea nor experience with most of the profiler and GFX API/Programming in general so I had no way of knowing how accurate or sensible those profiling results were that would actually be of any use and whether a real developer could do some actual work with it's help.

Perhap's I'll try this again on that same game and poke around a bit what other's think. Certainly for that game it's not worthwhile, that game is getting a native Vulkan renderer anyway so the devs are rather focused on that, than on jerry-rigging a newer GPU profiler and trying to fix the old renderer.

So while I'm adding my own experience in a cheering way to find an excuse of possible double-use of this, I have to admit I can't say I did, rather staying safe, but that's the only thing I tried DXVK for, perhaps there is another niche usecase, perhaps there is a bigger justified usecase?

Oh, BTW, I never built DXVK on Windows, I just used the linux bins. @lowspecchaos should have just tried the existing ones ;)

EDIT: Oh I recalled now, I tried another game where I attempted to daisy-chain a bunch of these API converters together.

Silly me, it's been a busy busy year so much I forgot that I documented the whole process right here, lol: https://github.com/doitsujin/dxvk/issues/1498

So turned out it did actually help very much indeed in that case. I was able to figure out exactly which component was being spammed by the game that caused slowdowns. A particular image/texture is being manipulated by the engine in such a way that it produces calculations which are very hard on the hardware, in general, hence the implementation is poorly optimized, or the newer drivers/hardware simply don't have optimizations/support for the legacy operations/calculations. So I guess that's one example ( proof ) of a usecase right there, and the catch may have been I couldn't get the older profiler to work on the newer Windows and newer GPU architecture, I forgot tho. Whether this alone is enough of a justification I can't say since I don't really have a full scope around these things, I have yet to actually try "linux gaming", but it is kinda coolish if the default bins keep working on Windows.

Squall-Leonhart commented 3 years ago

Actually, it's very interesting it does work on Windows it self, even tho there's no mention in it and releases come in the non-Windows way of a .tar.gz file. Oh, BTW, I never built DXVK on Windows, I just used the linux bins. @lowspecchaos should have just tried the existing ones ;)

@altimumdelta The binaries are your typical dll's and work on windows no matter how you build them.

DXVK is basically the only way to play some games with AMD's drivers on Windows, since it circumvents the drivers overhead, You get a fair performance improvement in Witcher 3 and Sekiro for example, not to mention some games have been broken on RDNA since last year and DXVK fixes those, it even improves GTA4's fps drops somewhat.

Does this patch affect / allow asynchronous shader compilation in Dx9 games such as Guild Wars 2?

@seanmacky Yes

DXVK dlls goes into bin or bin64 dxvk.conf does into the root folder

lowspecchaos commented 3 years ago

Hi again i've been using the default libraries in release for DXVK but i saw them bottom of the DXVK github page says

"For non debian based distros, make sure that your mingw-w64-gcc cross compiler does have --enable-threads=posix enabled during configure. If your distro does ship its mingw-w64-gcc binary with --enable-threads=win32 you might have to recompile locally or open a bug at your distro's bugtracker to ask for it."

& i thought maybe targeting windows rather than linux might fix the issues i'm having with the window crashing on minimize Currently testing the DXVK-ASync build on Windows, Thank you for all the help :)