TGEA 1.7.1 VRS TGEA1.8 performance comparison results:
by Caylo Gypsyblood · in Torque Game Engine Advanced · 01/19/2009 (4:28 am) · 43 replies
I have read several times about a performance difference between TGEA1.7.1 and TGEA1.8 so decided to run some TGEA 1.7.1 vrs TGEA 1.8 METRICS(FPS); tests and took screen shots to compare the results.
Testing system is an AMDx2 2.8, 2 gig ram, 2 GF8500 with 256meg each(NOT SLI), 1 GF8200 with 128meg running Video driver 175.19 on XP PRO 32bit SP2.
Test are right from SDK GameExamples Stronghold with no settings changed.
This is TGEA 1.7.1
Here is TGEA 1.8
Now i added to mission file;
Here is TGEA 1.8
Not truly a real game scenario, but simple enough test to give an idea.
One can notice right away that TGEA1.7.1 is a bit FPS faster, but once both builds have some stress on them (latter two pic's) the FPS is near the same.
My observations that are not noticeable from screen shot is 1.7.1 pause multiple times for about 100MS each once the fxShapeReplicator mass came into the viewstrum. And the 1.8 3D positional sound FX were very realistic, much better then TGE versions and even TGEA1.7.1. Both could be results of hardware configuration and not examples of build version differences.
It would be interesting if other TGEA SDK holders would also run GameExamples Stronghold metrics test and post results, just to see how much differences hardware configurations actually make.
Testing system is an AMDx2 2.8, 2 gig ram, 2 GF8500 with 256meg each(NOT SLI), 1 GF8200 with 128meg running Video driver 175.19 on XP PRO 32bit SP2.
Test are right from SDK GameExamples Stronghold with no settings changed.
This is TGEA 1.7.1
Here is TGEA 1.8
Now i added to mission file;
new fxShapeReplicator(lottatest) {
canSaveDynamicFields = "1";
Enabled = "1";
position = "441.157 201.387 209.828";
rotation = "1 0 0 0";
scale = "1 1 1";
HideReplications = "0";
ShowPlacementArea = "1";
PlacementAreaHeight = "25";
PlacementColour = "0.4 0 0.8 1";
shapeFile = "scriptsAndAssets/data/shapes/trees/shrub.dts";
seed = "1376312589";
ShapeCount = "500";
ShapeRetries = "100";
InnerRadiusX = "0";
InnerRadiusY = "0";
OuterRadiusX = "100";
OuterRadiusY = "100";
AllowOnTerrain = "1";
AllowOnInteriors = "1";
AllowOnStatics = "1";
AllowOnWater = "0";
AllowWaterSurface = "0";
AlignToTerrain = "0";
Interactions = "1";
AllowedTerrainSlope = "90";
TerrainAlignment = "1 1 1";
ShapeScaleMin = "1 1 1";
ShapeScaleMax = "4 4 4";
ShapeRotateMin = "0 0 0";
ShapeRotateMax = "0 0 0";
OffsetZ = "0";
};This is TGEA 1.7.1Here is TGEA 1.8
Not truly a real game scenario, but simple enough test to give an idea.
One can notice right away that TGEA1.7.1 is a bit FPS faster, but once both builds have some stress on them (latter two pic's) the FPS is near the same.
My observations that are not noticeable from screen shot is 1.7.1 pause multiple times for about 100MS each once the fxShapeReplicator mass came into the viewstrum. And the 1.8 3D positional sound FX were very realistic, much better then TGE versions and even TGEA1.7.1. Both could be results of hardware configuration and not examples of build version differences.
It would be interesting if other TGEA SDK holders would also run GameExamples Stronghold metrics test and post results, just to see how much differences hardware configurations actually make.
#2
But then ageain I could be wrong about it, since I haven't done any major testing yet. Though with Paper Soldier so far we haven't noticed much different between 1.7.1 and 1.8. 1.8 seems to run alot smoother and under some circumstances even runs faster then 1.7.1. But most of the time they are the same give or take a fps or two.
01/19/2009 (8:01 am)
With the fences inplace and working now. Things are going to be more insink between the cpu and gpu. This may result in a lower high end fps under low load conditions. But I do imagine that preformance across the board under heavy loads and such will be more equalized and steady.But then ageain I could be wrong about it, since I haven't done any major testing yet. Though with Paper Soldier so far we haven't noticed much different between 1.7.1 and 1.8. 1.8 seems to run alot smoother and under some circumstances even runs faster then 1.7.1. But most of the time they are the same give or take a fps or two.
#3
Would it be an excess expenditure of your time to try and emulate my above benchmarking, taken from same location same view area? It should take about 20 minutes if you already have both SDK installed. And the information could be helpful to many TGEA users. Screen shots are not necessary, just the metrics reading.
01/19/2009 (8:30 am)
That is something im wondering about, as i dont have any INTEL systems to test with, or MAC. Its going to be difficult to calculate an acceptable target detail level for multiple system configurations. My work computers have weak video cards for this very reason, so as not to 'paint myself into a corner' with to much details, but i usually work for engines that have predictable performance curves. Would it be an excess expenditure of your time to try and emulate my above benchmarking, taken from same location same view area? It should take about 20 minutes if you already have both SDK installed. And the information could be helpful to many TGEA users. Screen shots are not necessary, just the metrics reading.
#4
So I can't give much as far as results on high end machines.
01/19/2009 (11:14 am)
I will take a look and see what I come up with. Though it is worth noting that my development machine uses a built in geforce 6150SE nForce 430.So I can't give much as far as results on high end machines.
#5
As Thomas noted correctly, the fences are cutting into high FPS scenarios and matter less at <100 FPS. Disabling them altogether is a simple variable setting ($pref::Video::defaultFenceCount = 0;). Once I've done that, what I noticed was slight FPS increases with 1.8 except where legacy terrain was involved--which has steep performance losses.
I'm still working on getting legacy terrain performance back en par with 1.7.1, but currently am stumbling along a bit. I've yanked all the resource stuff out of the terrain's inner rendering loop but that recuperated only half the loss. Have to investigate further.
01/19/2009 (2:03 pm)
As Thomas noted correctly, the fences are cutting into high FPS scenarios and matter less at <100 FPS. Disabling them altogether is a simple variable setting ($pref::Video::defaultFenceCount = 0;). Once I've done that, what I noticed was slight FPS increases with 1.8 except where legacy terrain was involved--which has steep performance losses.
I'm still working on getting legacy terrain performance back en par with 1.7.1, but currently am stumbling along a bit. I've yanked all the resource stuff out of the terrain's inner rendering loop but that recuperated only half the loss. Have to investigate further.
#6
01/19/2009 (2:46 pm)
Dont you think trying to chart the actual FPS performance differences first would be the best starting point here? From everything i can tell there actually is not any problem with 1.8. This is what im after- hard evidence that 1.8 is considerable slower then 1.7.1. I agree on the surface it SEEMS like 1.7.1 is running much faster- but under scene load testing they equal out for me, if this is an abnormality then it should be looked into. Such as perhaps for some reason 1.8 perform well on AMD CPU's but not Intel, or even as silly and far fetched as memory bus speed.
#7
Yep, out of the box, 1.8 will *seem* a lot slower than 1.7.1 since the fencing will cap all the high FPSs. That's not affecting real usage scenarios much and can be disabled altogether if desired.
The terrain rendering stuff is odd, though. I noticed that 1.7.1 is issuing *WAY MORE* terrain chunk render calls than 1.8 yet still gets done with them *WAY* quicker. The reason for that eludes me at the moment, but I'm digging.
01/19/2009 (2:54 pm)
Yep, out of the box, 1.8 will *seem* a lot slower than 1.7.1 since the fencing will cap all the high FPSs. That's not affecting real usage scenarios much and can be disabled altogether if desired.
The terrain rendering stuff is odd, though. I noticed that 1.7.1 is issuing *WAY MORE* terrain chunk render calls than 1.8 yet still gets done with them *WAY* quicker. The reason for that eludes me at the moment, but I'm digging.
#8
01/21/2009 (1:09 pm)
I dunno... 30-40 fps on stronghold out of the box compared to 90-120 seems like it's affecting real usage scenarios.. especially because stronghold isn't very art heavy... (Compared to a 'real' mission with 'real' art) (8800GTS 640 mb, 2.4. duo core, 3 gigs ram, winxp.. 1.7.1 vs 1.8 both out of the box)
#9
EDIT: ok, i think i see what your saying. Once more from your sys specs your using Dual Core, nvidia 8800 gts could this be a common factor?
{I hope i dont end up needing to buy an Intel Dual Core system just to profile the different hardware myself.}
01/21/2009 (1:32 pm)
Helk, please review the actual TEXT from first forum post; your missing allot of the details. EDIT: ok, i think i see what your saying. Once more from your sys specs your using Dual Core, nvidia 8800 gts could this be a common factor?
{I hope i dont end up needing to buy an Intel Dual Core system just to profile the different hardware myself.}
#10
01/21/2009 (6:52 pm)
I am kinda leaning with you Caylo in that this might be a Intel Issue as we don't seem to be seeing much on the AMD side alone.
#11
Im wondering if it is not something deeper, like the branch prediction problem, Intel have very expensive branch prediction miss penaltys.
01/21/2009 (7:12 pm)
Perhaps an Intel user could turn off hyper threading, and report back? (do the core2's have toggle able hyper threading option?)Im wondering if it is not something deeper, like the branch prediction problem, Intel have very expensive branch prediction miss penaltys.
#12
01/21/2009 (9:26 pm)
Core 2's don't have hyper threading. The only modern Intel processor that has that are the newest Core i7-style processors.
#13
01/21/2009 (9:56 pm)
Just an idea. I haven't payed any mind to Intel after the MMX. Not that im some AMD FANBOY, i pick my hardware on its technical merits, not benchmarking ability. (and sometimes the ability to get 2 AMD systems for the same price of one Intel system have helped me decide...)
#15
TGEA 1.8 @ 1900x1200
TGEA 1.7.1 @ 640x480
TGEA 1.7.1 @ 1900x1200
For the record:
Intel 2.4. duo core
8800GTS 640 mb
3 gigs ram
Windows XP
01/21/2009 (11:56 pm)
TGEA 1.8 @ 640x480TGEA 1.8 @ 1900x1200
TGEA 1.7.1 @ 640x480
TGEA 1.7.1 @ 1900x1200
For the record:
Intel 2.4. duo core
8800GTS 640 mb
3 gigs ram
Windows XP
#16
Im going to (sometime next 3 hours) run metrics off my next step down system who have an 6600 and try to figure out a performance curve. Im truly now theorizing that TGEA is slower on Intel.
01/22/2009 (12:18 am)
I place my view at same location in world, and comparing to your 1.7.1 FPS, im getting around120FPS. It seems very unlogical your 8800GTS could only be 40FPS faster at 640x480, then my supper cheepass 8500.Im going to (sometime next 3 hours) run metrics off my next step down system who have an 6600 and try to figure out a performance curve. Im truly now theorizing that TGEA is slower on Intel.
#17
01/22/2009 (12:24 am)
Well at least we're making some kind of progress. We should make a post on the ubiqvisuals forum. Alot of people want the DoF pack to be supported for 1.7.1 becuase they won't upgrade to 1.8 due to perf reasons. Maybe we can get their stats to help with this analysis.
#18
Edit: also in light of this evidence im not going back to the GF6600 system to run testing, its a hassle to move my screens around and i dont see reason to collect that data from it, just going to go by Thomas Oliver's reports above.
01/22/2009 (12:32 am)
Ah. Also notice how the change from your 1900x1200 TGEA 1.8 FPS (42FPS) and your 640x480 TGEA 1.8 FPS (49FPS) is a much closer ratio then same resolutions in 1.7.1?! That proves that 1.8 is actually more efficient then 1.7.1, and being from all AMD systems (I got 4PC that run and 2 laptop all who have AMD cpu), that do not show much speed variation between 1.7.1 and 1.8 at all- nothing like the reporting from Intel users; I think its very safe now to conclude that TGEA dont run well on PC's with Intel CPU. I truly wish i had an Intel PC here to experiment with.... Edit: also in light of this evidence im not going back to the GF6600 system to run testing, its a hassle to move my screens around and i dont see reason to collect that data from it, just going to go by Thomas Oliver's reports above.
#19
Tell me what to change in the code/hit, to show the FPS, and I'll post screen shots.
01/22/2009 (3:48 am)
I'm relatively new to the internals of the engine. But, I've got an Intel (dual core E8400, GeForce 8800GT).Tell me what to change in the code/hit, to show the FPS, and I'll post screen shots.
#20
Thanks for your participation.
01/22/2009 (3:55 am)
press the ~ key for console and type METRICS(FPS); press ~ to close console.Thanks for your participation.
Torque 3D Owner J.C. Smith