Author Topic: Performance Improvements (Updated 22/06/14)  (Read 10925 times)

0 Members and 1 Guest are viewing this topic.

Performance Improvements (Updated 22/06/14)
I was laying the groundwork for that EFF container stuff when I got a bit sidetracked. I think I ended up with a higher framerate instead... :D

Compiled with MSVC2008 Express. Based on Antipodes Revision 9533. Please compare with other builds, particularly clean Antipodes and clean Trunk.

Executable (Trunk Release Inferno SSE2):
http://www.mediafire.com/?xa93tn9ap7v7vws

Executable (Antipodes Release SSE2):
http://www.mediafire.com/?dw5jresv3sr5154

Executable (Antipodes Release SSE2 + BP Compatibility build):
http://www.mediafire.com/?llrtdqz1iy7gg7t

Patch:
http://www.mediafire.com/?je4uay9mifujo8j


The patch works on both Antipodes and Trunk since the files affected are identical between the two.

Testing was done with the massive battle mission provided with Blue Planet 2 (which explains the build with the BP Compatibility patch). That one happens to have lots of beams and explosions that kill my framerate, so improvements tend to be noticeable.

Feel free to review the code in the patch - I suspect the same sorts of changes could be made to the code that loads textures in the first place for a further performance boost.

UPDATE:

Built it in linux on underpowered machine, with BP compatibility and without my changes, got some profiling info while running artemis at 4fps. I think others might find this information useful.

http://www.mediafire.com/?1k1cw1auirfharr

UPDATE 2:

Renamed thread.

More improvements with the aid of the profiler data. Messed with bm_load() so missions should load a bit faster (needs quantifying). Seems to have improved framerate too.

Hit the following dead ends (no improvement or made things worse):

fvi_ray_boundingbox() - other supposedly efficient algorithm tried involved many more floating point operations and turned the game into a slideshow (trying to run ray tracing on CPU, go figure - may consider offloading to GPU somehow)
see http://tavianator.com/2011/05/fast-branchless-raybounding-box-intersections/
I was able to halve my framerate by adding extra useless lines of code, so this might be one of the bigger CPU bottlenecks

model_octant_find_faces_sub() - attempts to do changes similar to bm_lock() improvements resulted in performance decrease

Executable (Antipodes Release SSE2 + BP Compatibility build):
http://www.mediafire.com/?1n1056ab5z614mi

Patch:
http://www.mediafire.com/?8kq27ni3kli5u7n


UPDATE 3:

2nd patch degrades performance and should be ignored.


Update 4:

Reversed TGA specific changes, TGA no longer looks like crap. Patch attached.


Update 5:

New patch - previous patches should be disregarded. Needs testing.

http://www.mediafire.com/download/omd55wlt6o9jh0j/inline_trunk_9771.patch

Linux build:

http://www.mediafire.com/download/wp23mjm3vp5sa7e/fs2_open_3.7.1_inline.tar.gz

Compiled on LMDE x64

Windows builds: http://blueplanet.fsmods.net/E/stuff/Flaming_Sword_Speedup.7z


Update 6:

Added tweak to shader string comparison code - new patch attached:

Linux Build: fs2_open_3.7.1_inline_string_compare_trunk_9802.tar.gz

Mac Build: FS2_Open_FS_ISC_r9802.zip

[attachment deleted by ninja]

Update 7:

Updated patch for trunk 10338, posted below and attached.

Update 8:

Updated for trunk 10831 - Now with windows executables (unix goodies in separate patch)

http://www.mediafire.com/download/9u05k7edc8040y5/inline_string_compare_trunk_10831.patch
http://www.mediafire.com/download/zc2ytfo3z2c9rgb/inline_string_compare_trunk_10831.7z
http://www.mediafire.com/download/b9wp9uzc2wt49aw/unix_goodies_trunk_10831.patch - stacktrace printing and symbols for gdb
« Last Edit: June 21, 2014, 11:39:47 pm by Flaming_Sword »

 

Offline Kobrar44

  • On Suspended Sentence
  • 29
  • Let me tilerape it for you!
    • Steam
Re: bm_lock() Performance Improvements
tests on both artemis and massive battle, massive battle is very random so I considered Artemis more reliable.



I think I helped Artemis on bp comp build to slow down a tiny bit by taking few screenshots, shouldn't make huge difference.

No problems encountered on test build.
Oh guys, use that [ url ][ img ][ /img ][ /url ] :/

 

Offline Echelon9

  • Moderator
  • 210
Re: bm_lock() Performance Improvements
Perhaps it's the way I'm reading your charts, but it looks like this patch slowed down FPS for you but less % of GPU was used?

 

Offline Kobrar44

  • On Suspended Sentence
  • 29
  • Let me tilerape it for you!
    • Steam
Re: bm_lock() Performance Improvements
Massive Battle is CPU-intensive it appears. GPU didn't have a chance to sweat a tiny bit, and every massive battle is different. Artemis had a performance gain though.
Oh guys, use that [ url ][ img ][ /img ][ /url ] :/

 

Offline Echelon9

  • Moderator
  • 210
Re: bm_lock() Performance Improvements
Ah, so Artemis is the second chart?

 
Re: Performance Improvements (Updated 25/02/13)
Can you please rerun the tests on the new build and post the results?

 

Offline Kobrar44

  • On Suspended Sentence
  • 29
  • Let me tilerape it for you!
    • Steam
Re: Performance Improvements (Updated 25/02/13)
first of all:
correct
performance tweaks
secondly, charts

Oh guys, use that [ url ][ img ][ /img ][ /url ] :/

 

Offline Luis Dias

  • 211
Re: Performance Improvements (Updated 25/02/13)
Do you have access to the raw data? You could place it in a spreadsheet and give a new chart that outputs "bp comp" - "perf-tweaks". You can also output the average of that amount and so on. Eyeballing it, it seems that the improvement in FPS is next to zero, if not negative.

 
Re: Performance Improvements (Updated 25/02/13)
That's funny... I was testing by watching the FPS counter in the corner of the screen when the missions were running. How reliable/unreliable is that measure? How were you getting your data? Can I get a copy of the trailer mission for testing? :P

 

Offline Kobrar44

  • On Suspended Sentence
  • 29
  • Let me tilerape it for you!
    • Steam
Re: Performance Improvements (Updated 25/02/13)
mission should be here: http://199.91.152.85/6i5utbbyya9g/pjvoudwd9as5o2o/FSO+Trailer+Mission.7z [by default it links to "mediavps" instead of "mediavps_3612"]
I use MSI Afterburner, but I am going to check out HWiNFO.
Oh guys, use that [ url ][ img ][ /img ][ /url ] :/

 
Re: Performance Improvements (Updated 03/03/13)
I can confirm the results - the 2nd patch should be ignored.

 
Re: Performance Improvements (Updated 03/03/13)
Stupid question, but when you tested with the FSO trailer, did you have any rendering issues? Particularly with the text that shows at the beginning (tga textures).

 

Offline Kobrar44

  • On Suspended Sentence
  • 29
  • Let me tilerape it for you!
    • Steam
Re: Performance Improvements (Updated 03/03/13)
My post began with such issue.
first of all:
correct
performance tweaks
Lack of black background on performance tweaks and **** colours on bitmaps, if its not too apparent. The font and bitmaps were fukced up too in the beginning.
Oh guys, use that [ url ][ img ][ /img ][ /url ] :/

 
Re: Performance Improvements (Updated 03/03/13)
Not just me then. Something in there is messing with rendering of TGA. PNG/DDS work fine in my testing, which is strange because I did the same changes to them that I did to TGA. Continuing to investigate.

 
Re: Performance Improvements (Updated 16/03/13)
Removing the TGA specific changes seems to have fixed the issue.

 

Offline Echelon9

  • Moderator
  • 210
Re: Performance Improvements (Updated 16/03/13)
Is there any hard evidence that these changes are performance improvements?

To date, it seems users reporting nothing compelling beyond marginal improvement.

 
Re: Performance Improvements (Updated 16/03/13)
Is there any hard evidence that these changes are performance improvements?

To date, it seems users reporting nothing compelling beyond marginal improvement.

Uh, the charts? The patch itself that you can test?

I also assume that a marginal improvement is better than no improvement at all. Feel free to investigate further methods for improving performance. We can only benefit from such work.

 

Offline jg18

  • A very happy zod
  • 210
  • can do more than spellcheck
Re: Performance Improvements (Updated 16/03/13)
Is there any hard evidence that these changes are performance improvements?

To date, it seems users reporting nothing compelling beyond marginal improvement.

As in we should collect mean frame rates with and without the changes from a bunch of people on randomly assigned mission segments and run a paired t-test? It'd be doable.

* jg18 had to pull out his college stats book for that.

 
Re: Performance Improvements (Updated 16/03/13)
We should probably collect framerate data for the whole run so we can do more analysis after the fact. Variance in framerate is also a consideration.

 

Offline jg18

  • A very happy zod
  • 210
  • can do more than spellcheck
Re: Performance Improvements (Updated 16/03/13)
Over the whole run = over an entire mission? What sort of analysis? And a consideration how? Although admittedly we're approaching the limits of my stats knowledge...

The idea I was going with was hypothesis testing with the null hypothesis being "the difference in average frame rate comparing mission segments played with your changes to the same segments played without them is zero (or otherwise insignificant)" and then running a paired t-test to see whether it's possible to reject H0 with p < 0.05. I don't have my stats book nearby, so the wording may be a bit off.

EDIT: I figure that since E9 asked for hard evidence, this could qualify as that, if done right.
« Last Edit: March 16, 2013, 08:30:56 pm by jg18 »