Bug 97003 - [d3dadapter+radeonsi] Dragon's Dogma: video memory leak with precompiled shaders
Summary: [d3dadapter+radeonsi] Dragon's Dogma: video memory leak with precompiled shaders
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Gallium/StateTracker/galliumnine (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-20 08:33 UTC by kudahkukarek
Modified: 2019-09-18 17:52 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
valgrind --leak-check=full --trace-children=yes --vex-iropt-register-updates=allregs-at-mem-access --workaround-gcc296-bugs=yes --smc-check=all wine DDDA.exe (967.44 KB, text/plain)
2016-07-20 23:35 UTC, kudahkukarek
Details
valgrind_output_i686 (871.99 KB, text/plain)
2016-07-22 09:08 UTC, kudahkukarek
Details

Description kudahkukarek 2016-07-20 08:33:08 UTC
Steps to reproduce:
1. Launch the game
2. Find a new location entrance (e.g. Cassardis gate)
3. Go back and forth between locations a few times, the game will eventually crash with "ERR08 : Memory overrun." (http://i.imgur.com/oPfFvq9.png)

Workaround: R600_DEBUG=mono fixes this

glxinfo:
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: X.Org (0x1002)
    Device: AMD PITCAIRN (DRM 2.43.0 / 4.4.0-28-lowlatency, LLVM 3.9.0) (0x6818)
    Version: 12.1.0
    Accelerated: yes
    Video memory: 2048MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.2
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
Comment 1 Michel Dänzer 2016-07-20 08:38:10 UTC
Can you run the game with

 valgrind --leak-check=full [game command line]

and attach the corresponding valgrind output?

Please make sure at least radeonsi_dri.so has debugging symbols available for this.
Comment 2 kudahkukarek 2016-07-20 23:35:31 UTC
Created attachment 125187 [details]
valgrind --leak-check=full --trace-children=yes --vex-iropt-register-updates=allregs-at-mem-access --workaround-gcc296-bugs=yes --smc-check=all wine DDDA.exe

(In reply to Michel Dänzer from comment #1)
> Can you run the game with
> 
>  valgrind --leak-check=full [game command line]
> 
> and attach the corresponding valgrind output?
> 
> Please make sure at least radeonsi_dri.so has debugging symbols available
> for this.

It does not launch under valgrind for me, it dies from unknown instruction in ntdll (log attached)

vex x86->IR: unhandled instruction bytes: 0x36 0x89 0x50 0xC


Also to clarify, "ERR08 : Memory overrun." refers to GPU's video memory running out, the game does not cause system OOM.
Comment 3 Michel Dänzer 2016-07-21 02:07:51 UTC
(In reply to kudahkukarek from comment #2)
> It does not launch under valgrind for me, it dies from unknown instruction
> in ntdll (log attached)
> 
> vex x86->IR: unhandled instruction bytes: 0x36 0x89 0x50 0xC

valgrind doesn't understand some (not very) recent AMD specific instructions yet. I build everything with -march=amdfam10 -mtune=native to avoid this.


> Also to clarify, "ERR08 : Memory overrun." refers to GPU's video memory
> running out, the game does not cause system OOM.

Right, but video memory leaks are usually accompanied by corresponding system memory leaks, which can be caught by valgrind.
Comment 4 kudahkukarek 2016-07-21 04:10:50 UTC
(In reply to Michel Dänzer from comment #3)
> valgrind doesn't understand some (not very) recent AMD specific instructions
> yet. I build everything with -march=amdfam10 -mtune=native to avoid this.

Ok, I'll recompile wine and try again.

> Right, but video memory leaks are usually accompanied by corresponding
> system memory leaks, which can be caught by valgrind.

True, the game does noticeably leak system memory (1.5+ GiB footprint with precompiled shaders vs 500 MB with mono)
Comment 5 kudahkukarek 2016-07-22 09:08:56 UTC
Created attachment 125253 [details]
valgrind_output_i686

I rebuilt wine with -march=amdfam10 and still get the same error (log attached), I also tried building with -march=i686 -mtune=generic and running valgrind on wine-1.7.44-gallium-nine binary from playonlinux with the same outcome. I tried both valgrind-3.11 from xenial repo and valgrind-3.12-svn from some random ppa. All other 3d wine games crash as well even if they use OpenGL, though tracing explorer.exe works.

(In reply to Michel Dänzer from comment #3)
> valgrind doesn't understand some (not very) recent AMD specific instructions
> yet. I build everything with -march=amdfam10 -mtune=native to avoid this.

AMD-specific or AMD64-specific? Either way, I use an Intel CPU and 32-bit wine.

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 60
Model name:            Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz
Stepping:              3
CPU MHz:               3900.039
CPU max MHz:           3900,0000
CPU min MHz:           800,0000
BogoMIPS:              6999.79
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt dtherm ida arat pln pts
Comment 6 Michel Dänzer 2016-07-22 09:16:34 UTC
(In reply to kudahkukarek from comment #5)
> I rebuilt wine with -march=amdfam10 and still get the same error [...]

The instruction valgrind doesn't know could be in Mesa or any other library used by Wine.


> [...] I use an Intel CPU and 32-bit wine.

It's probably an instruction from a recent Intel extension then.
Comment 7 Roland Scheidegger 2016-07-23 01:07:43 UTC
0x36 looks like a segment override (ss segment) prefix (0x89 would be a mov), so nothing new.
This looks like a valgrind bug to me:
https://bugs.kde.org/show_bug.cgi?id=344139 which seems old, in particular no updates since over a year (and specifically mentions wine is using such segment override prefixes).
Comment 8 Timothy Arceri 2017-02-14 02:53:10 UTC
(In reply to Roland Scheidegger from comment #7)
> 0x36 looks like a segment override (ss segment) prefix (0x89 would be a
> mov), so nothing new.
> This looks like a valgrind bug to me:
> https://bugs.kde.org/show_bug.cgi?id=344139 which seems old, in particular
> no updates since over a year (and specifically mentions wine is using such
> segment override prefixes).

Looks like a fix has been merged into valgringd git.
Comment 9 GitLab Migration User 2019-09-18 17:52:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/123.


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.