1.8 vs 1.7.1 performance?

#1 Yes 1.8 does suffer a performance loss compared to 1.7.1. It partly lies in the fact that the whole GFX subsystem was re-written. Performance loss was probably less of a concern than finally delivering MacOS compatibility to TGEa. In time I'm sure, I hope anyway, that GFX2 will be optimized to the extent that the old GFX system was.

#2 That was using the shipped exe. I just tried recompiling the exe with no changes and now the perf is seemingly cpu locked, I'm getting 50 fps at 640x480 (!!!!) and around 40 at 1900x1200 with 8x AA

And I'm sure I'm running the release build.. this is a pretty serious issue unless it's something wrong with my computer, but I doubt that as I run l4d at 1900x1200 4x AA with 50 zombies at 90 fps avg, anyone else noticing this?

#3 Having just ported my working level into 1.8, I think that performance is fairly similar to 1.7.1.

Can't say anything about a freshly compiled exe at the moment, as I can't get 1.8 to recompile right now.

Quote:1900x1200 4x AA. My system specs are 2.4 duo core, windows xp, 8800gts 640mb, 3 gigs ram

wow, wish I had your system

#4 It's definately a huge hit on my system. To give some real world examples, AtlasDemo saw a drop from about 550 fps to about 200 fps. That's a big hit. Other demos were all the similar. If your doing a PC version I'd use 1.7.1 for it.

#5 If your original performance was less than 50fps then it's probably not valid data...

#6 With windows just stick with the 1.7.1! The 1.8 does not deliver nothing that good (only for mac users).

#7
Hmmm, before I did some actual profiling on 1.8 I, too, assumed GFX2 was to blame for the FPS losses one sees in certain configuration with 1.8. However, I realized once again that it's nothing but assumptions until you've actually proven it.

GFX2 does not imply any significant loss in performance (it may even have sped up things; don't know, haven't tested).

The FPS losses come with legacy terrain and are actually caused by the new resource system. The old legacy terrain rendering code (which now has been replaced in Torque 3D) does *lots* of heightfield sampling and performs each access by indirecting through the TerrainBlock's resource pointer. With the additional indirection introduced by the resource system, this was reduced to less than half its former speed.

I will go and create a patch for 1.8 that fixes this.

#8 Also, fences are enabled by default in TGEA 1.8, but disabled by default in TGEA 1.7.1, so there's that too.

#9 If that's the case, why is the main menu FPS also much lower than in 1.7.1 (not that you need 700 fps on the main menu, but when i'm experiencing 170 instead of 800 you begin to wonder)

#10 That would be the fences.

#11 I have no idea what these 'fences' are could you elaborate or link me? I've never heard the this term before or I'm confused :) Thanks

#12 Fences are a method of synchronizing the CPU and GPU. Essentially, when you set a fence you mark a point in the GPU command stream that you would like to synchronize with. When you block on that fence, CPU execution is halted until the GPU has processed all commands issued before the fence was set. TGEA uses fences to ensure that the CPU doesn't get too far ahead of the GPU. In 1.8 by default the fences are set up such that the CPU will only be at most one frame ahead of the GPU.

#13 Well, I changed the fence variables to 0, that didn't work, tried restarting torque when they were 0 and that didn't work either, Opened up GuiCanvas.cpp and changed the if( mNumFences > 0 ) to if (false) as well as hardcoding mNumFences to 0... And I've noticed no change what so ever... Even running the mission in just a skybox with no geometry of any kind produces roughly 150 fps max... This is definitely bizzare...

#14 Any other suggestions Alex? This is kind of a major major issue...

#15 Alex did not say fences were the problem.

I have posted a thread with 1.7.1 and 1.8 comparisons using exact same testing variables environments. In hope to rally some community interest, but it seems to lack motivated interest.

I know for face the bug is not fences. Nothing wrong with 'RenderMeshMgr_render', and am now tentatively seeking issues with 'TerrainRenderRecurse'. Oh it is also not the GFX system, one can test this themselves with systematic profiling of different render object types in controlled experiment environments.

#16 Rene already posted above that there is issues with legacy terrain and 1.8 and some of it comes from the new resource system. He is looking into it and seeing what can be done.

#17 Yes Thomas i read that, and agree profiling test have proven even on my hardware that there is a slight difference between the TGEA versions; but it is not so simple as only being with "legacy terrain" and "new resource system" functions do not profile large discrepancy. I at first, also thought that was the issue (something in the terrain functions), as Rene Damm had concluded. But other test seem to point elsewhere.

So i truly think deeper testing and better comparisons are needed.

(As proof that it is NOT "legacy terrain" try testing without any terrain at all... hmm? I also ran test with nothing but DIF and tests with nothing but DTS, among other odd test environment.)

#18 I've did tests with nothing but dif's and no terrain and seen no difference between 1.7.1 and 1.8.

#19 Just curious Thomas, did you test under an AMD cpu? As seen in my other thread, i also see very very slight difference between 1.7.1 and 1.8, all my computers use AMD cpu's.

#20 Yes that was with a (AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2 CPUs), ~2.8GHz) Running Windows 7.

So that might have been why I was seeing not much difference if any at all between the two.