Gaming Terrain performance testing request

[Artlav]

all sliders moved to the right

Nice.

It's a really bad idea to set texture resolution higher than 256 - any computer will hang there.
128 is about the highest meaningful setting.
512 is an epic overkill - you got all the resolution 21 textures in, the other 200 would just eat up memory till depletion.

Try http://spaceway.1gb.ru/files/sway-terrain-test-130803-3.zip tomorrow - it checks for texture resolution changes and no longer needs cache clearing. Also, it allows Uniformness to go up to 3.1, which on your rig might look great.

 

[dgatsoulis]

Sorry about the Sharp clouds.

Does it work as well without the capture software?
Specifically, the jerkiness.
30 FPS in space also seems too low.

The capture software has about a 25% to 30% impact on the framerate, which is consistent to what I get with other recordings.
I usually get ~90-100 fps in Orbiter (D3D9), but when I am recording it drops in the sixties.

Without recording, running the same scenarios I get about 42 fps. I saw the "jerkiness" in the vid, but it did not feel bad at all during the test. Also in some of the "jumps", it was just me pressing Home to recenter the view.

Does it fell playable?

Definitely. The spacecraft movement was pretty smooth and the terrain generation looked good when I used Uniformness 1.8

Also, about texture resolution 128 - please try deleting all in cache/dynpl, then trying it again.

I will get the -3 version and try it again a little bit later, once with recording and once without.

 

[jangofett287]

Using the latest download posted just above, Uniformity and Quality at max. Tex res at 128
CPU: 4 Core 2.4GHz
GPU: GeForce GTX 650
RAM: 4 GB
OS: Win 7 32 Bit Pro

1st Scenario:
Total = 4 sec
Tex = 25 sec
Paused FPS = 20
Unpaused FPS = 15
Comment: While looking around unpaused, Spaceway closed with no error message, Log says: 04/08/2013-14:30:33:[SWAY ]:Error in sw_drint Access violation at address 004B0A0A in module 'terrain_test.exe'. Read of address 0000004C

 

[Artlav]

Uniformity and Quality at max. Tex res at 128
...
Paused FPS = 20
Unpaused FPS = 15

Nice!
Is it playable at these settings?
Is it jerky or uniformly slow?

What kind of settings do you find most comfortable (performance and niceness balanced)?

Comment: While looking around unpaused, Spaceway closed with no error message, Log says: 04/08/2013-14:30:33:[SWAY ]:Error in sw_drint Access violation at address 004B0A0A in module 'terrain_test.exe'. Read of address 0000004C

Does it happen every time?

Please try to reproduce the problem with this version:
http://spaceway.1gb.ru/files/sway-terrain-test-130804-4.zip

 

[jedidia]

Windows 7 32-bit
AMD Athlon 64 X2 Dual Core, 2.91 Ghz
2 GB RAM
ASUS EAH5770 CU graphics card with 1 GB video memory

pt_big_air:
total stoped increasing in less than two seconds. not long enough for any precision, really...
paused FPS 30
unpaused FPS 55 - 60
Terrain keeps up ok, but very visible buildup in the textures

pt_big_orbit
total maxed out after ~2.5 seconds
FPS 57 - 60, no matter whether paused or unpaused
Rather weird texture behavior: Patches the camera focuses on get updated and increased in detail immediately on the cost of others, leading to kind of a quantum expierience while looking around. If you don't focus on it, it ain't really there. Somewhat irritating.

pt_small_air:
total maxed out after about 2 seconds.
paused FPS: 40-45
unpaused FPS: 50 - 60
Terrain has less trouble keeping up than pt_big_air (none, really)
Atmosphere transitions are extremely rough (as in, this frame it looks like this, the next frame it looks like that).

General observations:
maxing out uniformity helps texture buildup to keep up with vessel, but drops FPS by 30-50%
maxing out quality has no visible effect on FPS.
Also, don't ask me why I have less FPS when I pause the game. It's been a consistent phenomenon, and I think you can make a much more educated guess on why that is than I.

Something entirely different: You mentioned on the sway page that you are looking for ideas what to actually do with an infinite universe, and that is indeed a pretty tough one. Maybe it would help to see the "infinite" part of the universe not in terms of setting, but in terms of replayability.

---------- Post added at 03:23 PM ---------- Previous post was at 03:14 PM ----------

Sorry, forgott to post the times for texture buildup:

pt_big_air: ~7seconds
pt_big_orbit: ~3 seconds
pt_small_air: ~10 seconds

All measurmenets with maxed out settings.

 

[donatelo200]

Hey Think the fourth scenario has caught an error that may be causing my graphics card to timeout on the terra planet. Tested in sway-terrain-test-130804-4.

 

[Artlav]

Hey Think the fourth scenario has caught an error that may be causing my graphics card to timeout on the terra planet. Tested in sway-terrain-test-130804-4.

Is the issue with that log message reproducible?
Are there any 0-sized files in cache\ogla\planets?
Does the problem continue to happen if you turn off caching (Esc in scenario select, options, uncheck cache_stuff)?

Last, please try http://spaceway.1gb.ru/files/sway-terrain-test-130804-5.zip

Also, AFAIK the timeout problem is 90% likely to be a driver issue rather than my code issue.
A quick check - get an older version of Spaceway, that you said worked before, and run it again now, looking for the problem. (i.e. http://spaceway.1gb.ru/files/dw.php?id=6 ).
Scenarios should be compatible.

Rather weird texture behavior: Patches the camera focuses on get updated and increased in detail immediately on the cost of others, leading to kind of a quantum expierience while looking around. If you don't focus on it, it ain't really there. Somewhat irritating.

Nice.

Does this effect go away if you bump up uniformness to 2-3?
It is somewhat intentional, since i want to test dynamic performance for worst case, i.e. flying in orbit at high time accel when nothing ever repeats.

There would be some persistence added later to smooth out the tunnel vision effect.

Maybe it would help to see the "infinite" part of the universe not in terms of setting, but in terms of replayability.

Infinite replayability is exactly my point - how to make a game that would stay fun for a while?
i.e. Minecraft technically have an infinite world, and only a tiny bit of it is ever used, yet it's fun to play for pretty much ever.
How can you get the same effect in a space game? (I'm not going the Orbiter way, obviously.)

 

[donatelo200]

Hmm no effect and error is not reproduced in sw-120420-raw however the error does show up in it's log for scenario 4. There are no 0 sized files in the cache.

Also the timeout crash has been happening faster and faster with each progression of new version.

 

[Artlav]

Hmm no effect and error is not reproduced in sw-120420-raw however the error does show up in it's log for scenario 4. There are no 0 sized files in the cache.

Ok, so the proc_lv1to8 error is not the problem, just one of these silent errors that are logged.

There are no indication of any errors in run.log of -5, and i can't think of any error in my code that won't show up in the log - worst case, the global exception handler would catch it.
So, it's either a very platform-specific issue that is not easily solvable without hands-on debugging, or a driver issue.

Let's try to compartmentalize.

Go to the big options menu, and set the lowest preset (Software).
That would minimize the use of the GPU.
Does the error still happen?
If not, go up through the presets until it does.

Also the timeout crash has been happening faster and faster with each progression of new version.

Another confusing point.
The changes from -1 to -5 are only various checks, logging and cosmetics, nothing related to rendering per se.

 

[donatelo200]

The crash happens at High (gaming rig) which is where i had the settings on the previous versions. I'll just leave the settings at medium as there is no crash and my FPS is stable.

EDIT: Arg crash just happened at Medium settings now.

 

[orb]

I've done some dynamic testing now with the 5th version (still in WINE), and it's still locking the X screen after flying for a while, even with texture set to 128 (uni: 3.1; q: 256000), after some 1772 lines of this error logged to the file:

[DefFreeHTex]:Texture release error

By the way, the above settings (3.1, 256000, 128) seem to be the best for my setup on Linux/WINE, with 43 FPS (every other screen refresh) when no large amount of textures is generated, and 28 FPS (every 3rd screen refresh) when many textures are generated at the same time. Textures set to 256 caused FPS drop to 20-23 during texture generation period and 28 FPS when no or only small amount of textures was generated, but they also caused the screen lock much sooner.


There is also sometimes an error logged when I don't clean cache when rerunning pt_small_air scenario (but there is no error window, like it was in the 1st version from this thread). I haven't noticed it when rerunning other scenarios:

[ORBGL     ]:Error: Error in gentex: Access violation at address 0047B363 in module 'terrain_test.exe'. Write of address 0000xxxx

 

[Artlav]

I've done some dynamic testing now with the 5th version (still in WINE), and it's still locking the X screen after flying for a while

Interesting.
Let's try to get Wine out of the equation.

Here is a 32bit Linux build, binary only:
http://spaceway.1gb.ru/files/sway-terrain-test-130804-lin-1.gz
Any version's data would do, cache might need cleaning.

It's a blind build - i have no Linux machine right now - so there is a 50% chance of it simply failing to run at all.

If the problem remains:
-Does it happen with texture resolution 64?
-Does it start happening above certain settings?
-Is it a high settings or high duration issue (i.e. if you run for a while on low settings would it happen anyway - if something is leaking, then high settings might just leak it faster)?

[DefFreeHTex]:Texture release error
...
Error in gentex: Access violation at address 0047B363 in module 'terrain_test.exe'. Write of address 0000xxxx

This suggests that Windows drivers might swallow some errors silently, while Linux ones are more rigorous, or it might be some WINE issue.

By the way, the above settings (3.1, 256000, 128) seem to be the best for my setup on Linux/WINE, with 43 FPS (every other screen refresh) when no large amount of textures is generated, and 28 FPS (every 3rd screen refresh) when many textures are generated at the same time. Textures set to 256 caused FPS drop to 20-23 during texture generation period and 28 FPS when no or only small amount of textures was generated, but they also caused the screen lock much sooner.

Nice.

Is there any meaningful improvement in appearance with 256 and top settings over something lesser and faster?

How does it feel on the responsiveness - jerking or uniformly slow?
Playability? Distractiveness of terrain changes?

---------- Post added at 22:36 ---------- Previous post was at 22:27 ----------

1772 lines of this error logged to the file:

[DefFreeHTex]:Texture release error

Wait a sec.
You mean there are 1772 lines of "Texture release" errors?
If so, here is our leak.

Please try this (win32) build: http://spaceway.1gb.ru/files/sway-terrain-test-130804-6.zip
It should log the error details, with nothing else changed.
What is in the log now?

 

[RacerX]

info of my system was in PM i sent you

 

[Artlav]

@orb:
Also, in Linux build you might want to put
http://spaceway.1gb.ru/files/linux_default.cfg
into options/control and change to it in options -> keys -> control sets, otherwise there will be no meaningful controls.

 

[RacerX]

i am getting this in shader.log

microtex:
Vessel program 0:
Vessel program 1:
Vessel program 2:
Vessel program 3:
Vessel program 4:
Planet program 0:
0(36) : warning C7532: global function textureOffset requires "#version 130" or later

Fragment info
-------------
0(36) : warning C7532: global function textureOffset requires "#version 130" or later

Planet program 1:
0(42) : warning C7532: global function textureOffset requires "#version 130" or later

Fragment info
-------------
0(42) : warning C7532: global function textureOffset requires "#version 130" or later

Planet program 2:
0(42) : warning C7532: global function textureOffset requires "#version 130" or later

Fragment info
-------------
0(42) : warning C7532: global function textureOffset requires "#version 130" or later

Planet program 3:
0(42) : warning C7532: global function textureOffset requires "#version 130" or later

Fragment info
-------------
0(42) : warning C7532: global function textureOffset requires "#version 130" or later

Planet program 4:
0(42) : warning C7532: global function textureOffset requires "#version 130" or later

Fragment info
-------------
0(42) : warning C7532: global function textureOffset requires "#version 130" or later

Planet program 5:
0(43) : warning C7532: global function textureOffset requires "#version 130" or later

Fragment info
-------------
0(43) : warning C7532: global function textureOffset requires "#version 130" or later

Planet program 6:
0(49) : warning C7532: global function textureOffset requires "#version 130" or later

Fragment info
-------------
0(49) : warning C7532: global function textureOffset requires "#version 130" or later

Planet program 7:
0(49) : warning C7532: global function textureOffset requires "#version 130" or later

Fragment info
-------------
0(49) : warning C7532: global function textureOffset requires "#version 130" or later

Planet program 8:
0(49) : warning C7532: global function textureOffset requires "#version 130" or later

Fragment info
-------------
0(49) : warning C7532: global function textureOffset requires "#version 130" or later

Planet program 9:
0(49) : warning C7532: global function textureOffset requires "#version 130" or later

Fragment info
-------------
0(49) : warning C7532: global function textureOffset requires "#version 130" or later

Haze program:
Ring program:
Post program:
Nebular program:
prog[0]:
prog[1]:
prog[0]:
prog[1]:

 

[Artlav]

info of my system was in PM i sent you

Nothing is happening in that link you PMed me.

What is the context of this error, under what conditions did it happen?

i am getting this in shader.log

Expected warnings from overdiligent shader compiler, not related to any errors.
Anything in the run.log?

 

[RacerX]

Nothing is happening in that link you PMed me.

What is the context of this error, under what conditions did it happen?

Expected warnings from overdiligent shader compiler, not related to any errors.
Anything in the run.log?

Well when I sent you the pm everything WAS working and appeared stable. Then display driver started freaking out and recovering. It now happens without streaming. Crashes on startup now. going to do a reboot. The run.log shows no errors

 

[orb]

The 6th Windows version now only locks the X screen for me in the orbit scenario (big_orbit), yet during the initial texture generation. Other scenarios work just fine and for as long as I was flying, but they still log this into the log file (last time it logged 18828 such lines, before I was bored flying):

[DefFreeHTex]:Texture release error, k=3, gl_dbg_var=2

The Linux native version isn't v-sync locked, like the Windows version under WINE, but I don't see much FPS improvement either. In average it gets 2-10 FPS more when flying above planet (and 20-30 FPS more when pointing camera at space), and the FPS changes are smooth instead of jumping between one and another v-synced frame rate.

So far only the simple planet worked without problems with the Linux version (small_air). The in orbit scenario locked the window for a while, but I could still close it when it unlocked itself for a moment. The flying scenario above the big planet locked the screen during texture generation until X server crashed and didn't want to restart automatically. Even stopping XDM and removing nvidia module didn't help starting X again, but only clean reboot (and I didn't try the landed scenario after the reboot to see if it's the same).

There are no errors in the Linux run log file (the shader log shows the usual warnings: "#version 130" and "implicit cast from int to float").


I haven't tested if it's the same with the 64 texture resolution yet after the reboot, but I'll rather do it tomorrow, after testing it in native Windows environment.


The change in appearance between 128 and 256 resolution textures is only noticeable just above the ground (for example in the landed scenario, or when I fly low).

There is noticeable jerkiness during turning around when FPS skips from 43 to 28 to generate new textures in the v-sync locked simulation (something like a half of second the terrain movement in view is smooth, and for another half of second there is visible terrain skipping). It obviously isn't noticeable when turning around in the Linux version, due to smoother FPS transition without the v-sync, and I haven't seen any tearing there either.

 

[Artlav]

and the FPS changes are smooth instead of jumping between one and another v-synced frame rate.
...
There is noticeable jerkiness during turning around when FPS skips from 43 to 28 to generate new textures in the v-sync locked simulation

Interesting.
You can disable vsync in Windows version with F11-~ combination.
Is there a point to having it on by default? I kind of thought it keeps the CPU load down.

Anyway, try for jerkiness on Windows with vsync off.

The 6th Windows version now only locks the X screen for me in the orbit scenario (big_orbit), yet during the initial texture generation. Other scenarios work just fine and for as long as I was flying, but they still log this into the log file (last time it logged 18828 such lines, before I was bored flying)

Nice, i think i got the problem - The textures can be released from either the main thread or the generation thread, but only the main thread have OpenGL context created.
On Windows the threads seem to inherit the OpenGL context, or some silent error correction is doing the job, so textures are released as intended, while on Linux this is a full error, and Wine does not help.

Fixing that might take a bit more than an evening, so expect a new version tomorrow.

Not sure if it's what causes the crash, however.

and I haven't seen any tearing there either.

What do you mean by tearing?

---------- Post added at 02:42 ---------- Previous post was at 02:14 ----------

Actually, fixing it only took a dozen minutes.
Here are the new versions:
http://spaceway.1gb.ru/files/sway-terrain-test-130804-7.zip
and
http://spaceway.1gb.ru/files/sway-terrain-test-130804-lin-2.gz
I also disabled vsync by default (cfg files might override that).

This should remove the errors in the log.
Does the server still crash?
Anything else got broken?

 

[orb]

What do you mean by tearing?

[ame="http://en.wikipedia.org/wiki/Screen_tearing"]Screen tearing - Wikipedia, the free encyclopedia[/ame]

Tearing is the main argument people use to convince others to turn on v-sync.


I can check the 7th version tomorrow, as now I'm going to bed.