Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • mesa mesa
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3,062
    • Issues 3,062
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 994
    • Merge requests 994
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • MesaMesa
  • mesamesa
  • Issues
  • #1416
Closed
Open
Issue created Sep 25, 2019 by Bugzilla Migration User@bugzilla-migration

link_shader and deserialize_glsl_program suddenly consume huge amount of RAM

Submitted by roland@rptd.ch

Assigned to Default DRI bug account

Link to original bug (#111077)

Description

Created attachment 144715 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.

Attachment 144715, "Valgrind massif log":
massif.out.32396

Version: 18.3

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking