|Summary:||1 second freezes during new effects UT4|
|Component:||Drivers/Gallium/radeonsi||Assignee:||Timothy Arceri <t_arceri>|
|Status:||RESOLVED FIXED||QA Contact:||Default DRI bug account <dri-devel>|
|i915 platform:||i915 features:|
Description bellamorte42 2015-11-04 03:58:31 UTC
I encountered this bug months ago but I wasn't sure if it was just UT4 or Mesa. Before I would see 3 to 5 second freezes when a new effect was being rendered for the first time. A new effect being a weapon firing, an impact occuring (explosions etc), or even the alternate fire on the enforcer would cause it as well even if I've use the normal fire previously. Needless to say, this made the first 2-3 minutes of any match unplayable as an enemy player would enter a room using a weapon I hadn't 'loaded' previously and I would be dead without being able to react or even fire a shot. It was a Mesa update a couple months ago that reduced the freeze time to about 1 second. It's still pretty horrible.
Comment 1 Ernst Sjöstrand 2015-11-04 08:02:23 UTC
I guess apitrace could find out what's going on... ?
Comment 2 Michel Dänzer 2015-11-04 09:26:51 UTC
Please set the environment variable GALLIUM_HUD=num-compilations,num-shaders-created,buffer-wait-time,num-bytes-moved,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage for running the game and let us know which of the graphs show spikes corresponding to the freezes.
Comment 3 bellamorte42 2015-11-04 21:00:50 UTC
Num compilations showed spikes corresponding to the feezes. Sometimes it was accompanied by a spike in shader compilation, but not the majority.
Comment 4 bellamorte42 2015-11-04 21:20:56 UTC
As an additional note, the num compilations spikes were only 2-6 during these freezes. Also apitrace didn't show any errors during this time.
Comment 5 Michel Dänzer 2015-11-05 07:31:03 UTC
So it looks like the freezes are due to delayed shader compilations in the radeonsi driver (and to a lesser extent in the Mesa state tracker). Marek Olšák has been working on improving this (which is probably the main reason why it's a little better now), but it'll probably take a while until delayed shader compilations are completely eliminated.
Comment 6 Michel Dänzer 2015-11-05 07:35:37 UTC
Meanwhile, make sure you're not using a debugging build of LLVM.
Comment 7 bellamorte42 2015-11-06 02:37:29 UTC
Are num compilations the same as shader compilations? Also iirc I had the same issue on my 6950 system so it might not be radeonsi specific.
Comment 8 Michel Dänzer 2015-11-06 09:32:46 UTC
A num-compilations spike without a num-shaders-created spike means the shader compile was triggered by the driver, either because UT4 used the GLSL shader for the first time or because UT4 changed some OpenGL state affecting the code generated for the shader. A num-compilations spike with a num-shaders-created spike means the shader compile was triggered by the state tracker or by UT4 itself.
Comment 9 bellamorte42 2015-11-07 14:53:43 UTC
Thaanks for the info. Should I close this or wait for the problem to be resolved?
Comment 10 Michel Dänzer 2015-11-09 03:05:28 UTC
Bug reports are normally only resolved when the problem is fixed.
Comment 11 bellamorte42 2016-02-24 15:23:12 UTC
Update Huge improvement with the shader cache (Great job Marek), but the issue is still present and detrimental. The first 10 seconds of the game is unplayable, and <1 second freezes (usually when in combat) still persist for the first couple of minutes after.
Comment 12 Marek Olšák 2016-02-24 15:40:01 UTC
(In reply to bellamorte42 from comment #11) > Update > Huge improvement with the shader cache (Great job Marek), but the issue is > still present and detrimental. The first 10 seconds of the game is > unplayable, and <1 second freezes (usually when in combat) still persist for > the first couple of minutes after. Yes, that's expected. The issue can only be fixed with an on-disk shader cache. It won't help with the first run (that's unfixable), but it should help with all subsequent runs. I guess Unreal Engine was designed with the assumption that the first run will always be unpleasant and all the rest should be fine as long as the driver isn't updated.
Comment 13 famo 2016-09-16 15:48:32 UTC
Can someon explain when (where) the updates land? Because I can't see any improvement here: Kernel: 4.5.7-1-CHAKRA x86_64 (64 bit) Graphics: Card: Advanced Micro Devices [AMD/ATI] Bonaire XTX [Radeon R7 260X] Display Server: X.Org 1.17.4 driver: radeon GLX Renderer: Gallium 0.4 on AMD BONAIRE (DRM 2.43.0 / 4.5.7-1-CHAKRA, LLVM 3.7.0) GLX Version: 3.0 Mesa 12.0.1 ty
Comment 14 Nicolai Hähnle 2016-09-16 16:08:03 UTC
You need at least LLVM 3.8 (and Mesa re-built to link against it) to benefit from the existing shader improvements. A full shader cache is still missing
Comment 15 Marek Olšák 2016-10-17 21:59:16 UTC
If you have OpenGL 4.3 (LLVM 3.9 needed), UE4 should no longer compile shaders on demand or not do that so often.
Comment 16 Samuel Pitoiset 2017-03-15 14:01:06 UTC
Closing. Presumably the on-disk shader cache should help a lot.