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.
I guess apitrace could find out what's going on... ?
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.
Num compilations showed spikes corresponding to the feezes. Sometimes it was accompanied by a spike in shader compilation, but not the majority.
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.
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.
Meanwhile, make sure you're not using a debugging build of LLVM.
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.
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.
Thaanks for the info. Should I close this or wait for the problem to be resolved?
Bug reports are normally only resolved when the problem is fixed.
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.
(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.
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
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
If you have OpenGL 4.3 (LLVM 3.9 needed), UE4 should no longer compile shaders on demand or not do that so often.
Closing. Presumably the on-disk shader cache should help a lot.
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.