https://bugs.freedesktop.org/show_bug.cgi?id=93301

--- Comment #1 from Nicolai Hähnle nhaehnle@gmail.com --- Hi Thomas! The VM faults are in backend writes. Can you try running with R600_DEBUG=nohyperz and/or nodcc?

https://bugs.freedesktop.org/show_bug.cgi?id=93301

--- Comment #3 from Thomas DEBESSE dev@illwieckz.net --- (In reply to Michel Dänzer from comment #2)

Note that the game crash probably isn't directly related to the GPUVM faults.

Perhaps, but they were spamed right before the crash and stopped with it.

We'd need to see backtrace of the crash (preferably from gdb) to say if the crash is due to a bug in the game or Mesa.

I will try that.

(In reply to Nicolai Hähnle from comment #1)

Hi Thomas! The VM faults are in backend writes. Can you try running with R600_DEBUG=nohyperz and/or nodcc?

Right now I started it with R600_DEBUG=nohyperz and I get the output I’ll join.

On stdout side I got a 'radeon: mmap failed, errno: 12' error and on the syslog side I got a standard segfault message. There was no other message in syslog.

https://bugs.freedesktop.org/show_bug.cgi?id=93301

--- Comment #5 from Thomas DEBESSE dev@illwieckz.net --- Good to know, using R600_DEBUG=nodcc the game loaded fine. There was many 'radeon: mmap failed, errno: 1' lines printed but the games does not crashed on graphical rendering (it crashed while playing a weapon sound). I was able to load a map and move in it, so that nodcc option workarounds the graphical rendering issue.

https://bugs.freedesktop.org/show_bug.cgi?id=93301

--- Comment #7 from Thomas DEBESSE dev@illwieckz.net --- Created attachment 120431 --> https://bugs.freedesktop.org/attachment.cgi?id=120431&action=edit ns2 stdout (default)

https://bugs.freedesktop.org/show_bug.cgi?id=93301

Thomas DEBESSE dev@illwieckz.net changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #120432|0 |1 is obsolete| |

--- Comment #9 from Thomas DEBESSE dev@illwieckz.net --- Created attachment 120433 --> https://bugs.freedesktop.org/attachment.cgi?id=120433&action=edit ns2 stdout + gdb full backtrace + libdrm-radeon1-dbg symbols

https://bugs.freedesktop.org/show_bug.cgi?id=93301

Nicolai Hähnle nhaehnle@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Summary|ns2_linux32: radeon VM |ns2_linux32: radeon VM |fault / |fault on Hawaii w/ DCC |VM_CONTEXT1_PROTECTION_FAUL |enabled (+mmap errors) |T_ADDR |

https://bugs.freedesktop.org/show_bug.cgi?id=93301

--- Comment #12 from Nicolai Hähnle nhaehnle@gmail.com --- Thank you for the followup.

Concerning your last backtrace: The crash is in a different thread than the one you mentioned, but the symbols in the backtrace suggest that it happens while updating a buffer, so the crash is likely a consequence of the failed mmap and the game not checking whether the map succeeded.

I'm noticing a lot of other error messages in stdout, though, such as the "Failed to launch child process" and something about allocation failures that is unrelated to Mesa. Perhaps the game's virtual address space is simply getting full? It does call itself a 32 bit program.

I'm a bit surprised in hindsight that nodcc had an effect. Now that I think about it, Hawaii doesn't actually have DCC, does it?

https://bugs.freedesktop.org/show_bug.cgi?id=93301

--- Comment #14 from Marek Olšák maraeo@gmail.com --- No, Hawaii doesn't have DCC.

The issue can indeed be that there is not enough address space. Mesa doesn't unmap most buffers, because mmap is a very costly operation. Such buffers are only unmapped when destroyed. This is obviously a problem on 32-bit. Possible solutions:

1) Always unmap buffers at appropriate places. This can have a significant performance cost in CPU-bound apps.

2) Clear pb_cache on mmap failure and try mmap again.

(pb_cache typically contains staging buffers, which are always mapped. Therefore, pb_cache completely hides allocation, GPU mmap, and CPU mmap overhead, but it also contributes to address space usage.)

https://bugs.freedesktop.org/show_bug.cgi?id=93301

--- Comment #16 from Thomas DEBESSE dev@illwieckz.net --- OK. Thanks, I will try all these things. I just have one question, since this software is running in 32 bit mode, does it mean I have to recompile mesa in 32bit too ?

https://bugs.freedesktop.org/show_bug.cgi?id=93301

--- Comment #18 from Thomas DEBESSE dev@illwieckz.net --- OK, I patched and recompiled mesa, but it changes nothing (see incoming log).

Setting R600_DEBUG=info I get:

---8<------------- radeon_drm_winsys_create: create cache of 4194304 bytes pci_id = 0x67b0 family = 57 chip_class = 9 gart_size = 2043 MB vram_size = 8192 MB max_sclk = 1080 max_compute_units = 44 max_se = 4 max_sh_per_se = 1 drm = 2.43.0 has_uvd = 1 vce_fw_version = 671220224 r600_num_backends = 16 r600_clock_crystal_freq = 27000 r600_tiling_config = 0x1023 r600_num_tile_pipes = 16 r600_max_pipes = 11 r600_virtual_address = 1 r600_has_dma = 1 r600_backend_map = 0 r600_backend_map_valid = 1 si_tile_mode_array_valid = 1 cik_macrotile_mode_array_valid = 1 Num displays: 1 ------------->8---

https://bugs.freedesktop.org/show_bug.cgi?id=93301

Thomas DEBESSE dev@illwieckz.net changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #120443|ns2 stdout + gdb full |ns2 stdout + gdb full description|backtrace + |backtrace + |libdrm-radeon1-dbg symbols |libdrm-radeon1-dbg symbols |/ patched mesa |/ patched mesa + | |R600_DEBUG=info

https://bugs.freedesktop.org/show_bug.cgi?id=93301

--- Comment #21 from Nicolai Hähnle nhaehnle@gmail.com --- Indeed. You'll also find that thread 1 commits suicide because TCMalloc cannot find more memory. So it's definitely still an out of memory condition, but without more evidence to the contrary I'm inclined to say it's probably not the OpenGL driver's fault.

https://bugs.freedesktop.org/show_bug.cgi?id=93301

famo richard.llom@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |richard.llom@gmail.com

--- Comment #23 from famo richard.llom@gmail.com --- Created attachment 128951 --> https://bugs.freedesktop.org/attachment.cgi?id=128951&action=edit GTT and VRAM usage after 30 min play

Here is a screenshot of GTT and VRAM usage after 30min of play.

From these graphs alone I couldn't make out any memory leaks.

However the game crashed soon afterwards on an new map.

System Info: Card: Advanced Micro Devices [AMD/ATI] Bonaire XTX [Radeon R7 260X]

glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD BONAIRE (DRM 2.46.0 / 4.8.6-1-CHAKRA, LLVM 3.9.1) OpenGL core profile version string: 4.3 (Core Profile) Mesa 13.0.2 OpenGL core profile shading language version string: 4.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 13.0.2 OpenGL shading language version string: 1.30 OpenGL context flags: (none)

https://bugs.freedesktop.org/show_bug.cgi?id=93301

--- Comment #25 from Kamil Páral kamil.paral@gmail.com --- Please note that more people report crashing on radeonsi after some time of playing: http://forums.unknownworlds.com/discussion/comment/2330666/#Comment_2330666 This is with "Failed to allocate" errors.

For me personally, NS2 didn't even start on older Mesa (mmap failed), now it starts, but as people report, seems to crash after some time. I personally never played that long (because loading the shaders takes an eternity).

I'd guess this is simply the game running out of 32bit space, and Mesa drivers being more memory hungry than proprietary drivers. The devs had OOM problems even with nvidia drivers in the past and had to cut down on memory usage. They said they can't even add more skins because they're that close to the RAM limit. They are working on a 64bit version of the game, which should hopefully fix all this.

https://bugs.freedesktop.org/show_bug.cgi?id=93301

--- Comment #27 from Thomas DEBESSE dev@illwieckz.net --- On my end I re-tried to play ns2_linux32 with my R9 390X two days ago running Linux 4.9 (amdgpu), Mesa 17~git and LLVM 4~svn and I was able to play a complete alien tutorial without crashes and the rendering looked OK to me. By the way I haven't seen the game running on another platform so I can miss something, but everything looked acceptable, I don't know if it's the expected rendering, but it's a nice, acceptable and honest rendering. I've never played too much this game to be able to hit the 32bit memory limit.

https://bugs.freedesktop.org/show_bug.cgi?id=93301

--- Comment #29 from Kamil Páral kamil.paral@gmail.com --- Yes, I can confirm NS2 works well now. One thing to note is that when compiling the shaders, the memory usage of the game is much higher than when running from the cache (even *after* the compilation has ended), I'm not sure whether it's a game problem or driver problem of not freeing all the memory. In that case, it's still possible to hit the 32b memory limit. But when running from cache, I've seen no memory issue and rendering is fine.