[Bug 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM - bugzilla-daemon

From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
Date: Sat, 06 Jul 2019 17:46:22 +0000	[thread overview]
Message-ID: <bug-111077-502@http.bugs.freedesktop.org/> (raw)

[-- Attachment #1.1: Type: text/plain, Size: 2036 bytes --]

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

            Bug ID: 111077
           Summary: link_shader and deserialize_glsl_program suddenly
                    consume huge amount of RAM
           Product: Mesa
           Version: 18.3
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: blocker
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: roland@rptd.ch
        QA Contact: dri-devel@lists.freedesktop.org

Created attachment 144715
  --> https://bugs.freedesktop.org/attachment.cgi?id=144715&action=edit
Valgrind massif log

Since a recent update a few days ago an application which barely consumes 2G
RAM at full load is very slow to load and compiling shaders causes over 16G RAM
to be consumed when the app eventually crashes.

I don't know what exactly in the update caused problems but certainly Mesa, the
amdgpu driver and LLVM did get updates.

I also tried using Mesa 19.x but the problem is the same.

Driver is xf86-video-amdgpu-19.0.1 . LLVM is 7.0.x .

I've already deleted the mesa shader cache and all caches the application
creates. I've totally recompiled the system (GenToo) to make sure no strange
problems can be around. I've also tried with a completely fresh user to run the
app.

Using valgrind --tool=massif the culprit seems to be ralloc_size which is
called by the two above mentioned methods. I've attached a massif log of a
couple of seconds running of the application and shutting it down before memory
skyrockets even more. The app in question shows at that point of time only an
empty scene with a simple shader doing a sky-box. The rest is Non OpenGL UI
stuff.

Classified this as blocker since as soon as you try loading more shaders not
even 32G seems to be enough to cope with the rampaging glsl compiler.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 3546 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel