Bug 101978

Summary: [bisected] war thunder performance reduced by ~28%
Product: Mesa Reporter: higuita
Component: Drivers/Gallium/radeonsiAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED INVALID QA Contact: Default DRI bug account <dri-devel>
Severity: normal    
Priority: medium CC: lakostis
Version: 17.2   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 77449    

Description higuita 2017-07-31 05:14:00 UTC
Since sometime i notice that war thunder is running slower on my machine using mesa-git, but as the game is always updating, i (wrongly) blamed some game update. 

Yet, some days ago, after a test with a steamOS, i could confirm that older mesa versions worked faster than mesa-git, with the same game version. I excluded the kernel version, so i have done a mesa bisect and found the (old) commit that made war thunder lost about 28% performance on my setup (RX480 on a A10-7850k):

commit ac6007460adaf4bb21028a3281ec622d1e43df49
Author: Marek Olšák <marek.olsak@amd.com>
Date:   Wed Feb 15 19:50:15 2017 +0100

    radeonsi: upload constants into VRAM instead of GTT
    
    This lowers lgkm wait cycles by 30% on VI and normal conditions.
    The might be a measurable improvement when CE is disabled (radeon)
    or under L2 thrashing.
    

I'm running slackware64 -current, with kernel 4.12.1, LLVM 4.0.1 and the game is free, so you can test it. For the bisect i started the game, run the CPU benchmark (as workaround some bug where most first benchmarks are slower) and then run the  "still scene" benchmark. as is the shorter one, but all others  had performance drop.
Comment 1 higuita 2017-08-01 01:11:03 UTC
Running some of the other benchmarks, i get this:

Benchmark       good    bad     %

patrick         4082    3173    -22
plane           2001    1793    -10
tank (cpu)      1320    1094    -17
tanks           1706    1431    -16

in other benchmarks, the commit did not make much difference, specially on planes, but on tanks it did a lot, "test drive" with the chi-nu tank (ie: as in real game play) i get this fps reduction:

chi nu test     25	14	-44%

I also notice that the GPU load also drop mostly in the same degree, but the sclk get a little higer with more spikes.for the "still scene", where i get -28% performance, the gpu load drops 32% and about 330-370MHz for before the commit, but 320-390MHz after the commit

GPU load        55	37	-32
sclk          330-370 320-380

Can a apitrace help in anyway to understand why this affects so much this game
Comment 2 Michel Dänzer 2017-08-01 01:20:13 UTC
(In reply to higuita from comment #1)
> Can a apitrace help in anyway to understand why this affects so much this
> game

Possibly.

Also, there are amdgpu kernel driver changes lined up for 4.14 that might help.
Comment 3 Marek Olšák 2017-08-14 19:43:57 UTC
(In reply to Michel Dänzer from comment #2)
> (In reply to higuita from comment #1)
> > Can a apitrace help in anyway to understand why this affects so much this
> > game
> 
> Possibly.
> 
> Also, there are amdgpu kernel driver changes lined up for 4.14 that might
> help.

Is it the work by John Brooks?
Comment 4 Michel Dänzer 2017-08-15 01:04:25 UTC
(In reply to Marek Olšák from comment #3)
> > Also, there are amdgpu kernel driver changes lined up for 4.14 that might
> > help.
> 
> Is it the work by John Brooks?

Him and yours truly, yes.
Comment 5 higuita 2017-09-29 00:30:50 UTC
I'm not very familiar with apitrace, so i generated a 2.6GB trace, locate here:
http://motaleite.net/~higuita/warthunder/aces.trace

The replay also look broken, do not know if its some bug or its normal

Anyway, 1 minute after starting you get a long benchmark run where you can notice in a RX480 (and probably other GPUs of the same family or even in all amdgpu ) that the GPU load is low (~30% here), sclk also low (~350-450Mhz)
Comment 6 Justin 2017-10-22 17:21:47 UTC
Setting, echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
Seems to help, even in the main menu, I will be getting 26 FPS at medium settings. setting that used to bring me up to about 45 seems to not be working any more.
Comment 7 higuita 2017-11-14 00:55:55 UTC
>Also, there are amdgpu kernel driver changes lined up for 4.14 that might help.

Updates to 4.14 and i fail to see any improvement, sclk is still low, performance is still very low for what this card is capable. Or is there any new setting that i have to enable/change to get a possible improvement
Comment 8 Konstantin A. Lepikhov 2018-01-28 23:16:31 UTC
I observe the same behavior with 17.3.3, maybe we should reassign to 17.3 version?

[lakostis@lks ~]$ glxinfo -B
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: X.Org (0x1002)
    Device: AMD Radeon (TM) R9 Fury Series (FIJI / DRM 3.23.0 / 4.14.0-lks-wks-alt8, LLVM 6.0.0) (0x7300)
    Version: 17.3.3
    Accelerated: yes
    Video memory: 4060MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 4059 MB, largest block: 4059 MB
    VBO free aux. memory - total: 4092 MB, largest block: 4092 MB
    Texture free memory - total: 4059 MB, largest block: 4059 MB
    Texture free aux. memory - total: 4092 MB, largest block: 4092 MB
    Renderbuffer free memory - total: 4059 MB, largest block: 4059 MB
    Renderbuffer free aux. memory - total: 4092 MB, largest block: 4092 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 4060 MB
    Total available memory: 8153 MB
    Currently available dedicated video memory: 4059 MB
OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon (TM) R9 Fury Series (FIJI / DRM 3.23.0 / 4.14.0-lks-wks-alt8, LLVM 6.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.3 (git-80f5f27)

The GPU runs fine other tasks and benchmarks only WarThunder is slow. BTW If GALLIUM_HUD is enabled with buffer_wait_time, those values are very high for this kind of workload (~100-120ms), normally they're in us, not ms.
Comment 9 Konstantin A. Lepikhov 2018-02-01 21:32:01 UTC
BTW running warthunder under brand new 4.15 kernel + latest amd-staging-4.15 gives 25-30+ FPS and the same during the gameplay with performance set to 'auto' and fps spikes up to 50+ with 'high' performance on my R9 Fury.

But it seems that 4.15 vanilla kernel doesn't have any patches from staging which improve performance so the results are nearly the same as it was with 4.14.
Comment 10 Timothy Arceri 2018-09-20 05:05:27 UTC
(In reply to Konstantin A. Lepikhov from comment #9)
> BTW running warthunder under brand new 4.15 kernel + latest amd-staging-4.15
> gives 25-30+ FPS and the same during the gameplay with performance set to
> 'auto' and fps spikes up to 50+ with 'high' performance on my R9 Fury.
> 
> But it seems that 4.15 vanilla kernel doesn't have any patches from staging
> which improve performance so the results are nearly the same as it was with
> 4.14.

Has the performance now been fixed for you with 4.{16,17,18}?
Comment 11 higuita 2018-09-21 03:16:18 UTC
As we can't control the installed game version (auto-update to startup), we can't now test the older opengl4 version anymore, where this problem was found. Before the upgrade that removed the opengl4, i got higher fps with power_dpm_force_performance_level setting set to high. That was with kernel 4.16 or 4.17

Warthunder dropped the opengl4 engine (only used in linux) and reverted to the opengl3 (also used in MacOS) for linux. They did this because they were making big changed in the engine and supporting the opengl4 only for linux was a waste of time when they are also adding vulkan support (not yet enabled by default, but one can enable it changing the config file). This vulkan support is still not complete (some drivers have rendering bugs, i can see some micro-freezes sometimes), but the future looks promising.

With opengl3 in the 4.18.9 kernel, at least for me (rx480 and latest mesa), performance increased about 20% over opengl4 (but again, comparing different engine versions)
With Vulkan, i get always 60fps (vsync is enabled) and the GPU is using the top sclk speed, so at least vulkan is working fine.


So i vote to close this "obsolete" or similar, as we can't test it anymore.
Also, probably next version (probably around the end of year) will release the vulkan support for all OS.
Comment 12 Konstantin A. Lepikhov 2018-12-08 21:38:37 UTC
(In reply to Timothy Arceri from comment #10)
> (In reply to Konstantin A. Lepikhov from comment #9)
> > BTW running warthunder under brand new 4.15 kernel + latest amd-staging-4.15
> > gives 25-30+ FPS and the same during the gameplay with performance set to
> > 'auto' and fps spikes up to 50+ with 'high' performance on my R9 Fury.
> > 
> > But it seems that 4.15 vanilla kernel doesn't have any patches from staging
> > which improve performance so the results are nearly the same as it was with
> > 4.14.
> 
> Has the performance now been fixed for you with 4.{16,17,18}?

Just tested w/ 4.19.8 + Mesa 18.3.0 on R9 Fury and latest WT client - everything became even worse, missing textures, white screen, so the game now is totally unplayable. But I know they have problems with nvidia as well, and their vulkan never worked on my box (black screen on focus).

So no progress so far.
Comment 13 Timothy Arceri 2018-12-10 02:18:48 UTC
(In reply to Konstantin A. Lepikhov from comment #12)
> Just tested w/ 4.19.8 + Mesa 18.3.0 on R9 Fury and latest WT client -
> everything became even worse, missing textures, white screen, so the game
> now is totally unplayable. But I know they have problems with nvidia as
> well, and their vulkan never worked on my box (black screen on focus).
> 
> So no progress so far.

These are all different issues from the original bug report and are probably game bugs if Nvidia is also having issues. As per comment 11 I'm closing this bug (using INVALID for lack of a better option).

Any new issues should have new bug reports opened for them.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.