Bug 92806

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.