Game is slow...C# runtime issues?

Discussion about the game and its default mods.
Matt
Posts: 1144
Joined: Tue May 01, 2012 12:21 pm
Location: Germany

Post by Matt »

I have a new laptop now and updated to openSUSE 12.2 and suddenly I am also affected.

glxinfo | grep renderer:

Code: Select all

OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile x86/MMX/SSE2
I added the following settings but they had no effects.

Code: Select all

Graphics:
	Renderer: Cg
	Mode: Windowed
	WindowedSize: 1366,720
	CapFramerate: True
	MaxFramerate: 70
The green render line in the performance graph is above the scale (outside of the box) and spikes occasionally.

Updating Mono from 2.10.6 to 2.10.9 did not help.

I also disabled VSYNC for KDE and at ~/.drirc

Code: Select all

<device screen="0" driver="dri2">
    <application name="all">
    <option name="vblank_mode" value="0"/>
    </application>
</device> 
glxgears gives >1800 FPS so I guess it is off.

OpenRA seems to be the only game that is effected. I tried Urban Terror 4.2 (based on ioQuake3 Engine) and it runs smoothly.

ddd
Posts: 272
Joined: Sat Oct 23, 2010 5:04 pm

Post by ddd »

Did you try to measure framerate and CPU/GPU usage?

Matt
Posts: 1144
Joined: Tue May 01, 2012 12:21 pm
Location: Germany

Post by Matt »

It uses 25% of the CPU and ~180.000 K RAM. Setting it to a higher priority (nice) does not effect anything.

I had to modify your patch:

Code: Select all

@@ -327,6 +327,8 @@ namespace OpenRA
 
 		internal static void Run&#40;&#41;
 		&#123;
+			ushort i=0;
+			
 			while &#40;!quit&#41;
 			&#123;
 				var idealFrameTime = 1.0 / Settings.Graphics.MaxFramerate;
@@ -340,6 +342,16 @@ namespace OpenRA
 					if &#40;waitTime > 0&#41;
 						System.Threading.Thread.Sleep&#40; TimeSpan.FromSeconds&#40;waitTime&#41; &#41;;
 				&#125;
+				
+				if &#40;Settings.Graphics.DebugFrameRate&#41;
+				&#123;
+					i++;
+						if &#40;i == Settings.Graphics.MaxFramerate / 2&#41;
+						&#123;
+							Debug&#40;"Frame Rate&#58; &#123;0&#125;", sw.ElapsedTime&#40;&#41;&#41;;
+							i = 0;
+						&#125;
+				&#125;
 			&#125;
 
 			OnQuit&#40;&#41;;

Code: Select all

@@ -71,6 +71,7 @@ namespace OpenRA.GameRules
 		public bool PixelDouble = false;
 		public bool CapFramerate = false;
 		public int MaxFramerate = 60;
+		public bool DebugFrameRate = false;
 
 		public int BatchSize = 8192;
 		public int NumTempBuffers = 8;
The debug messages shows ~0,27 so the unit conversion is wrong. It feels like ~3 FPS. It is really unplayable.
Last edited by Matt on Mon Sep 17, 2012 1:16 pm, edited 1 time in total.

Matt
Posts: 1144
Joined: Tue May 01, 2012 12:21 pm
Location: Germany

Post by Matt »

I followed http://www.mono-project.com/Performance_Tips#Profiling

Code: Select all

mono --profile=default&#58;stat OpenRA.Game.exe
Platform is Linux
Using Cg renderer
Desktop resolution&#58; 1920x1848
Using resolution&#58; 1366x720
Available mods&#58;
        cnc&#58; C&C &#40;&#123;DEV_VERSION&#125;&#41;
        d2k&#58; Dune 2000 &#40;beta&#41; &#40;&#123;DEV_VERSION&#125;&#41;
        example&#58; Example Mod &#40;a0001&#41;
        ra&#58; Red Alert &#40;&#123;DEV_VERSION&#125;&#41;
        ra_perf&#58; RA Perf &#40;a0001&#41;
Loading mods&#58; ra

Native stacktrace&#58;

        mono&#40;&#41; &#91;0x80e903d&#93;
        mono&#40;&#41; &#91;0x8064ee0&#93;
        linux-gate.so.1&#40;__kernel_rt_sigreturn+0&#41; &#91;0xb77c340c&#93;
        /usr/lib/libmono-profiler-log.so&#40;+0x41e1&#41; &#91;0xb5be31e1&#93;
        /lib/libc.so.6&#40;dl_iterate_phdr+0x109&#41; &#91;0xb76cd109&#93;
        /usr/lib/libmono-profiler-log.so&#40;+0x539e&#41; &#91;0xb5be439e&#93;
        /usr/lib/libmono-profiler-log.so&#40;+0x575e&#41; &#91;0xb5be475e&#93;
        /lib/libpthread.so.0&#40;+0x6e32&#41; &#91;0xb7757e32&#93;
        /lib/libc.so.6&#40;clone+0x5e&#41; &#91;0xb76948ee&#93;

Debug info from gdb&#58;

&#91;Thread debugging using libthread_db enabled&#93;
Using host libthread_db library "/lib/libthread_db.so.1".
&#91;New Thread 0xad7ffb40 &#40;LWP 6426&#41;&#93;
&#91;New Thread 0xb2201b40 &#40;LWP 6425&#41;&#93;
&#91;New Thread 0xb4cd3b40 &#40;LWP 6420&#41;&#93;
&#91;New Thread 0xb581db40 &#40;LWP 6419&#41;&#93;
&#91;New Thread 0xb6426b40 &#40;LWP 6417&#41;&#93;
&#91;New Thread 0xb6c27b40 &#40;LWP 6416&#41;&#93;
&#91;New Thread 0xb7428b40 &#40;LWP 6415&#41;&#93;
0xb77c3424 in __kernel_vsyscall &#40;&#41;
  Id   Target Id         Frame 
  8    Thread 0xb7428b40 &#40;LWP 6415&#41; "mono" 0xb77c3424 in __kernel_vsyscall &#40;&#41;
  7    Thread 0xb6c27b40 &#40;LWP 6416&#41; "mono" 0xb77c3424 in __kernel_vsyscall &#40;&#41;
  6    Thread 0xb6426b40 &#40;LWP 6417&#41; "mono" 0xb77c3424 in __kernel_vsyscall &#40;&#41;
  5    Thread 0xb581db40 &#40;LWP 6419&#41; "mono" 0xb77c3424 in __kernel_vsyscall &#40;&#41;
  4    Thread 0xb4cd3b40 &#40;LWP 6420&#41; "mono" 0xb77c3424 in __kernel_vsyscall &#40;&#41;
  3    Thread 0xb2201b40 &#40;LWP 6425&#41; "threaded-ml" 0xb77c3424 in __kernel_vsyscall &#40;&#41;
  2    Thread 0xad7ffb40 &#40;LWP 6426&#41; "mono" 0xb77c3424 in __kernel_vsyscall &#40;&#41;
* 1    Thread 0xb75a9700 &#40;LWP 6414&#41; "mono" 0xb77c3424 in __kernel_vsyscall &#40;&#41;

Thread 8 &#40;Thread 0xb7428b40 &#40;LWP 6415&#41;&#41;&#58;
#0  0xb77c3424 in __kernel_vsyscall &#40;&#41;
#1  0xb775ba4c in pthread_cond_wait@@GLIBC_2.3.2 &#40;&#41; from /lib/libpthread.so.0
#2  0x0822f657 in ?? &#40;&#41;
#3  0x082298c9 in ?? &#40;&#41;
#4  0x0822ddb3 in ?? &#40;&#41;
#5  0xb7757e32 in start_thread &#40;&#41; from /lib/libpthread.so.0
#6  0xb76948ee in clone &#40;&#41; from /lib/libc.so.6

Thread 7 &#40;Thread 0xb6c27b40 &#40;LWP 6416&#41;&#41;&#58;
#0  0xb77c3424 in __kernel_vsyscall &#40;&#41;
#1  0xb775ba4c in pthread_cond_wait@@GLIBC_2.3.2 &#40;&#41; from /lib/libpthread.so.0
#2  0x0822f657 in ?? &#40;&#41;
#3  0x082298c9 in ?? &#40;&#41;
#4  0x0822ddb3 in ?? &#40;&#41;
#5  0xb7757e32 in start_thread &#40;&#41; from /lib/libpthread.so.0
#6  0xb76948ee in clone &#40;&#41; from /lib/libc.so.6

Thread 6 &#40;Thread 0xb6426b40 &#40;LWP 6417&#41;&#41;&#58;
#0  0xb77c3424 in __kernel_vsyscall &#40;&#41;
#1  0xb775ba4c in pthread_cond_wait@@GLIBC_2.3.2 &#40;&#41; from /lib/libpthread.so.0
#2  0x0822f657 in ?? &#40;&#41;
#3  0x082298c9 in ?? &#40;&#41;
#4  0x0822ddb3 in ?? &#40;&#41;
#5  0xb7757e32 in start_thread &#40;&#41; from /lib/libpthread.so.0
#6  0xb76948ee in clone &#40;&#41; from /lib/libc.so.6

Thread 5 &#40;Thread 0xb581db40 &#40;LWP 6419&#41;&#41;&#58;
#0  0xb77c3424 in __kernel_vsyscall &#40;&#41;
#1  0xb775fa2b in waitpid &#40;&#41; from /lib/libpthread.so.0
#2  0x080e91b3 in ?? &#40;&#41;
#3  0x08064ee0 in ?? &#40;&#41;
#4  <signal handler called>
#5  0xb5be31e1 in ?? &#40;&#41; from /usr/lib/libmono-profiler-log.so
#6  0xb76cd109 in dl_iterate_phdr &#40;&#41; from /lib/libc.so.6
#7  0xb5be439e in ?? &#40;&#41; from /usr/lib/libmono-profiler-log.so
#8  0xb5be475e in ?? &#40;&#41; from /usr/lib/libmono-profiler-log.so
#9  0xb7757e32 in start_thread &#40;&#41; from /lib/libpthread.so.0
#10 0xb76948ee in clone &#40;&#41; from /lib/libc.so.6

Thread 4 &#40;Thread 0xb4cd3b40 &#40;LWP 6420&#41;&#41;&#58;
#0  0xb77c3424 in __kernel_vsyscall &#40;&#41;
#1  0xb775dda5 in sem_wait@@GLIBC_2.1 &#40;&#41; from /lib/libpthread.so.0
#2  0x082134b8 in mono_sem_wait &#40;&#41;
#3  0x08159e7c in ?? &#40;&#41;
#4  0x081e2efd in ?? &#40;&#41;
#5  0x0820da03 in ?? &#40;&#41;
#6  0x0822f448 in ?? &#40;&#41;
#7  0xb7757e32 in start_thread &#40;&#41; from /lib/libpthread.so.0
#8  0xb76948ee in clone &#40;&#41; from /lib/libc.so.6

Thread 3 &#40;Thread 0xb2201b40 &#40;LWP 6425&#41;&#41;&#58;
#0  0xb77c3424 in __kernel_vsyscall &#40;&#41;
#1  0xb768990b in poll &#40;&#41; from /lib/libc.so.6
#2  0xb25b3ac6 in ?? &#40;&#41; from /usr/lib/libpulse.so.0
#3  0xb25a1d5a in pa_mainloop_poll &#40;&#41; from /usr/lib/libpulse.so.0
#4  0xb25a2599 in pa_mainloop_iterate &#40;&#41; from /usr/lib/libpulse.so.0
#5  0xb25a2674 in pa_mainloop_run &#40;&#41; from /usr/lib/libpulse.so.0
#6  0xb25b3a4e in ?? &#40;&#41; from /usr/lib/libpulse.so.0
#7  0xb25551ba in ?? &#40;&#41; from /usr/lib/libpulsecommon-1.1.so
#8  0xb7757e32 in start_thread &#40;&#41; from /lib/libpthread.so.0
#9  0xb76948ee in clone &#40;&#41; from /lib/libc.so.6

Thread 2 &#40;Thread 0xad7ffb40 &#40;LWP 6426&#41;&#41;&#58;
#0  0xb77c3424 in __kernel_vsyscall &#40;&#41;
#1  0xb775f2c6 in nanosleep &#40;&#41; from /lib/libpthread.so.0
#2  0xb25f0fd6 in ?? &#40;&#41; from /usr/lib/libopenal.so.1
#3  0xb25fd1e1 in ?? &#40;&#41; from /usr/lib/libopenal.so.1
#4  0xb25f08b0 in ?? &#40;&#41; from /usr/lib/libopenal.so.1
#5  0xb7757e32 in start_thread &#40;&#41; from /lib/libpthread.so.0
#6  0xb76948ee in clone &#40;&#41; from /lib/libc.so.6

Thread 1 &#40;Thread 0xb75a9700 &#40;LWP 6414&#41;&#41;&#58;
#0  0xb77c3424 in __kernel_vsyscall &#40;&#41;
#1  0xb768c079 in ioctl &#40;&#41; from /lib/libc.so.6
#2  0xb37d6054 in drmIoctl &#40;&#41; from /usr/lib/libdrm.so.2
#3  0xb3295ca9 in ?? &#40;&#41; from /usr/lib/libdrm_intel.so.1
#4  0xb32924f8 in drm_intel_bo_subdata &#40;&#41; from /usr/lib/libdrm_intel.so.1
#5  0xb36a49b6 in intel_upload_data &#40;&#41; from /usr/lib/dri/i965_dri.so
#6  0xb36a4c40 in intel_bufferobj_source &#40;&#41; from /usr/lib/dri/i965_dri.so
#7  0xb36c3288 in ?? &#40;&#41; from /usr/lib/dri/i965_dri.so
#8  0xb36d580f in brw_upload_state &#40;&#41; from /usr/lib/dri/i965_dri.so
#9  0xb36c1bdf in brw_draw_prims &#40;&#41; from /usr/lib/dri/i965_dri.so
#10 0xb3526aee in ?? &#40;&#41; from /usr/lib/dri/libdricore.so
#11 0xb3b889dc in ?? &#40;&#41;
#12 0xac75a6e4 in ?? &#40;&#41;
#13 0xac75a620 in ?? &#40;&#41;
#14 0xac75a5e0 in ?? &#40;&#41;
#15 0xac75a57e in ?? &#40;&#41;
#16 0xac75a32c in ?? &#40;&#41;
#17 0xac75a0fe in ?? &#40;&#41;
#18 0xac758b8f in ?? &#40;&#41;
#19 0xac7589c8 in ?? &#40;&#41;
#20 0xac758980 in ?? &#40;&#41;
#21 0xac7594d8 in ?? &#40;&#41;
#22 0xa776c3d4 in ?? &#40;&#41;
#23 0xa7769cf3 in ?? &#40;&#41;
#24 0xa7769d1e in ?? &#40;&#41;
#25 0xa7769d1e in ?? &#40;&#41;
#26 0xa7769c9d in ?? &#40;&#41;
#27 0xa88245dc in ?? &#40;&#41;
#28 0xa8823f7c in ?? &#40;&#41;
#29 0xa8823cc0 in ?? &#40;&#41;
#30 0xb5863180 in ?? &#40;&#41;
#31 0xb585ed74 in ?? &#40;&#41;
#32 0xb585ef27 in ?? &#40;&#41;
#33 0x0806915c in ?? &#40;&#41;
#34 0x081ad2ff in mono_runtime_invoke &#40;&#41;
#35 0x081b0195 in mono_runtime_exec_main &#40;&#41;
#36 0x080c3026 in mono_main &#40;&#41;
#37 0x0805de38 in ?? &#40;&#41;
#38 0xb75c33d5 in __libc_start_main &#40;&#41; from /lib/libc.so.6
#39 0x0805df35 in ?? &#40;&#41;

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================


Mono log profiler data
        Profiler version&#58; 0.4
        Data version&#58; 4
        Mean timer overhead&#58; 330 nanoseconds
        Program startup&#58; Mon Sep 17 15&#58;11&#58;15 2012
        Program ID&#58; 6414
        Server listening on&#58; 43145

JIT summary
        Compiled methods&#58; 6696
        Generated code size&#58; 1216586

GC summary
        GC resizes&#58; 23
        Max heap size&#58; 156430336
        Object moves&#58; 0
        Gen0 collections&#58; 46, max time&#58; 11517us, total time&#58; 201463us, average&#58; 4379us
        GC handles weak&#58; created&#58; 10, destroyed&#58; 0, max&#58; 10
        GC handles weaktrack&#58; created&#58; 33, destroyed&#58; 0, max&#58; 33

Metadata summary
        Loaded images&#58; 18

Exception summary
        Throws&#58; 13
        Executed catch clauses&#58; 13
        Executed finally clauses&#58; 9

Thread summary
        Thread&#58; 0xed4c8bc0, name&#58; "Finalizer"
        Thread&#58; 0xb75a9700, name&#58; "Main"
This seems to crash after 5 seconds.

User avatar
riderr3
Posts: 98
Joined: Sat Feb 26, 2011 11:26 pm
Location: Camo pillbox
Contact:

Post by riderr3 »

Yeah, same thing here on Ubuntu, with graphics of 1997 year - much usage of cpu, e.t.c.

Matt
Posts: 1144
Joined: Tue May 01, 2012 12:21 pm
Location: Germany

Post by Matt »

I tried http://manicdigger.sourceforge.net which is a C# MineCraft clone that uses OpenTK. It runs very fluently with 100 FPS so I guess this is an OpenRA bug.

ddd
Posts: 272
Joined: Sat Oct 23, 2010 5:04 pm

Post by ddd »

Cmd. Matt, I tried to use the above patch:
https://github.com/cerebrum/dr/blob/mas ... 0630.patch
and got the following screenshots. The first one is with CapFramerate: True and MaxFramerate: 70 options and the second one is with CapFramerate: False option.
I got 4-cores CPU and ancient nVidia GPU.
http://i.imgur.com/H1rBh.png
http://i.imgur.com/JNv3S.png

P.S. You can test what is it like with 3 FPS or even 1 FPS with
CapFramerate: True
MaxFramerate: 3
options. I tried that when was writing capFramerate patch and it was working there pretty nice. The included version is pretty the same except it gives slightly less precise results. But it's worth it as long as it gives less usage of CPU.

Matt
Posts: 1144
Joined: Tue May 01, 2012 12:21 pm
Location: Germany

Post by Matt »

This happens with Intel core i5 with HD 4000 integrated graphics. It seems to be somehow incompatible with OpenRA so I reported it at https://github.com/OpenRA/OpenRA/issues/2413

When applying your patch the yellow performance bar goes up, too. Synchronized with the renderer. When displaying the framerate it will become even more stuttering.

Capping the framerate to 3 FPS will result in the FPS Debug message be displayed more often, same stuttering.
Attachments
The shellmap brings it really down.
The shellmap brings it really down.
Screenshot-Shellmap.jpg (479.4 KiB) Viewed 7727 times
ingame with not much around
ingame with not much around
Screenshot-ingame.png (198.16 KiB) Viewed 7727 times

Matt
Posts: 1144
Joined: Tue May 01, 2012 12:21 pm
Location: Germany

Post by Matt »

Maybe it is related to the rendering of the Widgets.

I removed all the framerate displaying and capping code and it changed nothing.
Attachments
More GUI makes it worse.
More GUI makes it worse.
Map-Chooser.png (796.34 KiB) Viewed 7724 times

ddd
Posts: 272
Joined: Sat Oct 23, 2010 5:04 pm

Post by ddd »

Chrisf thinks it's a drivers issue. Try to update to the latest mesa and kernel. Also check your GPU clock.

Matt
Posts: 1144
Joined: Tue May 01, 2012 12:21 pm
Location: Germany

Post by Matt »

Latest Mesa 8.98 something did not boot, but switching to Linux kernel vanilla 3.6.rc6.52.gc46de22-1.1 solves this. I now have ~50 FPS for the shellmap and >100 FPS when starting a new game. Don't know if it is the upgrade from 3.4 to 3.6 or if SUSE patches dragged the performance.

Anyway I like your FPS counter. Maybe add it to the performance graph as the Debug Message is kinda spammy.

ddd
Posts: 272
Joined: Sat Oct 23, 2010 5:04 pm

Post by ddd »

Yeah, FPS graph in the corner of the screen would be cool. I just did the simplest thing to measure it.

Post Reply