protonscr

Performance in Elex is more than halved when using winelib dxvk

dxvkclosed
doitsujin/dxvk#805 · opened 2018-12-09 by shmerl · updated 2019-06-15 · 24 comments · github
1 matching comments, n / p to jump
Sshmerl 2018-12-09 github

I noticed a strange thing. Performance in Elex is more than halved when using winelib dxvk, in comparison with dll one. Is that expected?

I don't observe such degradation for example in The Witcher 3. Performance is practically the same there between winelib and dll builds.

dll:

elex_dxvk_dll

so (winelib):

elex_dxvk_so

Dxvk: latest master (post 0.93).
GPU: AMD Sapphire Pulse Vega 56.
radv: Mesa master, llvm 8.0.

Ddoitsujin maintainer 2018-12-09 github

Any particular reason you use winelib builds with Elex? Are you maybe getting some log spam from wine? Did you build it with compiler optimizations enabled?

Sshmerl 2018-12-09 github

No specific reason, just wanted to compare performance. I ran it with:

export WINEDEBUG=-all
export DXVK_LOG_LEVEL=none

So it shouldn't have log spammed it. Let me check how it was compiled.

Sshmerl 2018-12-09 github

I built it using this (setting some variables before):

  meson --cross-file build-wine64.txt --prefix ${dest_dir} "$dxvk_build"
  cd "$dxvk_build"
  meson configure -Dbuildtype=release
  ninja

Does release enable compiler optimizations?

Ppchome 2018-12-09 github

@shmerl

Does release enable compiler optimizations?

buildtype=release enable -O3 optimization level. The flags enabled at this level can vary between GCC versions, see e.g. enabled by default at -O3 ("General Improvements" section):

You can:

  • check compiler versions used for build (Meson usually prints both, during MinGW build)
  • modify your build-wine64.txt to use -O2, and try e.g. -Dbuildtype=plain
    or (for newer Meson versions) -Dbuildtype=custom -Doptimization=2

Such steps will help to find out is regression caused by -O3, by the specific flag, or by different GCC version.

Kkakra 2018-12-10 github

The other question is: Did you build the DLL version yourself or did you use the pre-compiled one? Because you didn't mention how you built the other version...

Otherwise, comparing both versions is meaningless: The compiler is probably different, and versions may differ.

Sshmerl 2018-12-11 github

I built both myself. I'll run some tests using suggestions to lower optimization level for winelib case.

Sshmerl 2018-12-12 github

Compilers used (according to Meson):

  • Winelib build:
Native C compiler: cc (gcc 8.2.0 "cc (Debian 8.2.0-9) 8.2.0")
Cross C compiler: winegcc (gcc 8.2.0)
Native C++ compiler: c++ (gcc 8.2.0 "c++ (Debian 8.2.0-9) 8.2.0")
Cross C++ compiler: wineg++ (gcc 8.2.0)
  • dll build:
Native C compiler: cc (gcc 8.2.0 "cc (Debian 8.2.0-9) 8.2.0")
Cross C compiler: x86_64-w64-mingw32-gcc (gcc 7.3.0)
Native C++ compiler: c++ (gcc 8.2.0 "c++ (Debian 8.2.0-9) 8.2.0")
Cross C++ compiler: x86_64-w64-mingw32-g++ (gcc 7.3.0)

So there is that difference already.

Sshmerl 2018-12-12 github

Strange, I can't reproduce the issue now (no performance regression with either -O2 or default (-O3) when using winelib. May be it's something with the kernel since I was switching between 4.19.x and 4.20.0. Let me compare that.

Sshmerl 2018-12-12 github

Nope, the kernel doesn't make a difference. Not sure what changed really. This can probably be closed, unless it comes up again.

Kkakra 2018-12-12 github

@shmerl Maybe you are experiencing the same pitfall I did and during tests something was eating your VRAM, e.g. an open browser with multiple tabs which wasn't open during on of your test cases (or memory usage was different)? The effect was about half the performance here...

Sshmerl 2018-12-12 github

Good point, I didn't monitor my VRAM usage. I'm actually not sure how to do that for amdgpu. Are there some good methods?

Sshmerl 2018-12-12 github

Ah, this produces something, but probably means pages:

sudo cat /sys/kernel/debug/dri/0/amdgpu_vram_mm | pcregrep 'total|usage'
total: c, used 152311 free 1940745
man size:2093056 pages, ram usage:594MB, vis usage:42MB

It makes sense, since I have 8 GB VRAM. So 8,573,157,376 B / 2,093,056 = 4,096 B. I.e. one page is 4 KB.

Ppchome 2018-12-12 github

Created a crude AMD GPU load / VRAM monitor

https://github.com/clbr/radeontop ?

Sshmerl 2018-12-12 github

I tried radeontop, it produces no data for my Vega.

Ddoitsujin maintainer 2018-12-12 github

I can't even get the game to start, so I won't be able to look into it for now.

Sshmerl 2018-12-12 github

Is it crashing?

Ddoitsujin maintainer 2018-12-12 github

It shows an unreadable crash dialogue and then proceeds to show an infinite loading screen. Not sure why but I've had this with all wine versions past 3.14, and now even my 3.14 build stopped working.

Sshmerl 2018-12-12 github

Hm, just for the record, I'm using 4.0~rc1, but never experienced such crash with earlier versions as well. The build is from WineHQ.

Kkakra 2018-12-14 github

@doitsujin Does "unreadable" mean "very tiny fonts"? Both keywords ("unreadable" and "infinite") ring a bell here that I was able to fix.

Eedmondo 2018-12-16 github

@shmerl I started the game about at the same place as you with a winelib and the standard dll and I don't have perfomance differences:

dll release 0.94 : 52.3 FPS
winelib 0.94 (-march=native -O2) : 52.5 FPS

my setup is very similar to yours, if I remember well (just smaller):
AMD Ryzen 2600
AMD RX 470 (POLARIS 10)

Sshmerl 2018-12-16 github

@edmondo: I don't see it now either, so I can't explain what happened before when it was halved.

Kkakra 2018-12-18 github

@shmerl Did you set CFLAGS or something similar? Or update meson lately? While debugging a build issue here, I noticed that the winelib build no longer respected my CFLAGS set through a makefile (or maybe it never did and I didn't notice). Upon inspection, I found that there was a fix to meson to ignore CFLAGS for cross-builds. Since winelib is implemented as a meson cross-build, that could explain something...

Sshmerl 2018-12-18 github

Meson was updated not so long ago in Debian testing to 0.49: https://tracker.debian.org/pkg/meson

But I encountered this before that update happened, so I was still using 0.48 then.

Launch options