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

Priority: medium Bug ID: 56713 Assignee: dri-devel@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@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@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).