[Bug 56713] New: etqw perf regresses over time followed by oom since r600g: don't snoop context state while building shaders

[bugzilla-daemon at freedesktop.org]

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

          Priority: medium
            Bug ID: 56713
          Assignee: dri-devel at lists.freedesktop.org
           Summary: etqw perf regresses over time followed by oom since
                    r600g: don't snoop context state while building
                    shaders
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: lists at andyfurniss.entadsl.com
          Hardware: x86 (IA32)
            Status: NEW
           Version: git
         Component: Drivers/Gallium/r600
           Product: Mesa

Created attachment 69483
  --> https://bugs.freedesktop.org/attachment.cgi?id=69483&action=edit
dmesg showing oom gpu lock and drm errors

HD4890 on (old) 32 bit LFS with 4(3.3) gig mem.

This one takes about 20 minutes to show and longer to oom (if it does).

ETQW 1920x1080 with all settings on/turned up sitting on commit -

commit b6521801070d52bdd5908824e82c1ce2dde16e8e
Author: Marek Olšák <maraeo at gmail.com>
Date:   Mon Sep 17 23:22:00 2012 +0200

    r600g: don't snoop context state while building shaders

    Let's use the shader key describing the state.

The game initially runs OK, but after some time (15-20 mins) when
spectating/following a bot switching between bots to force a new part of the
map to load provokes short stalls for a couple of seconds which are not present
when the game first runs.

Spectating a bot that is flying so seeing a large part of the map also starts
stalling - 1/4 to 1/2 second stalls.

This happens with or without --enable-r600-llvm-compiler, though the oom was
produced without.

Eventually when switching bots to force different parts of map to load some
temporary rendering errors like black ground appear then after more time and
switching oom-killer + gpu lock as in dmesg provided.

After oom I lost X screen, though vts/fbcon was OK restarting X didn't recover
- vt7 still showing mangled game scene.

The WARNING and seamonkey errors in the attached dmesg are "normal for me" and
were way before the problem (and also before a 60 minute issue free etqw run
while sitting on the commit before this one).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121103/99bebbb3/attachment.html>