Does A24 Lag Less?

[Stan`]

That would be #3997

[hyperion]

On 27/01/2021 at 8:55 PM, Stan` said:

On 27/01/2021 at 8:14 PM, hyperion said:

Option to disable rendering of corpses and projectiles on the ground. Not rendering possibly thousands of objects likely helps quite a lot.

Was done. But apparently it costs too much performance doing that see https://code.wildfiregames.com/D2936

An option to removing projectiles immediately and removing corpses as soon as the falling to ground animation is played is sufficient. Some people are even willing to disable shadows which is far worse from my point of view. This is fine as a brute force method, perfectly fine to ignore the I want to see exactly 362 corpses and no more crowd. Though removing the thousands of pebbles no one sees in large scale slinger battles might make sense for everyone.

 

On 27/01/2021 at 8:55 PM, Stan` said:

On 27/01/2021 at 8:14 PM, hyperion said:

Use of vulkan instead of opengl.

Too many users would not be able to play the game anymore...

It might or might not be early for requiring vulkan. However it would anyway take a year or two before 0ad would have migrated even if you started right now. If someone was willing to take up this task I'd suggest you welcome it whether ifdefed, runtime switchable or straight transition. This is a game about ancient warfare and not ancient hardware.

Also there is quite a bit of work that can be done towards vulkan while still using opengl.

 

On 27/01/2021 at 9:55 PM, wraitii said:

Quote

• One I don't like to see personally. Let units have no obstruction so the pathfinder has it easy.

Unit pushing (D1440) does something like that in a saner manner, but it needs a lot more work to be mergeable.

Nice idea, though the units gathering in the video look hilarious.

[Stan`]

8 minutes ago, hyperion said:

It might or might not be early for requiring vulkan. However it would anyway take a year or two before 0ad would have migrated even if you started right now. If someone was willing to take up this task I'd suggest you welcome it whether ifdefed, runtime switchable or straight transition. This is a game about ancient warfare and not ancient hardware.

Also there is quite a bit of work that can be done towards vulkan while still using opengl.

We're not closed to the idea far from it. What we're against is dropping all the users and devs (yes) that do not support it

I have yet to see someone come here and make a vulkan patch, but it's one of the GSOC ideas. Maybe if @vladislavbelov has time to mentor it.

9 minutes ago, hyperion said:

An option to removing projectiles immediately and removing corpses as soon as the falling to ground animation is played is sufficient. Some people are even willing to disable shadows which is far worse from my point of view. This is fine as a brute force method, perfectly fine to ignore the I want to see exactly 362 corpses and no more crowd. Though removing the thousands of pebbles no one sees in large scale slinger battles might make sense for everyone.

I suppose one could play with the decay time to that effect.

[gator303]

Short answer. Nope! It's even worse than before.

[Bellaz89]

@wraitii Just out of curiosity: did you see an improvement in JS execution performance after the SM update? I remember that I didn't get very impressive results with tests done by myself.

[Stan`]

57 minutes ago, Bellaz89 said:

@wraitii Just out of curiosity: did you see an improvement in JS execution performance after the SM update? I remember that I didn't get very impressive results with tests done by myself.

We didn't in fact it was slightly worse from what I recall. We did include a 15% perf improvement due to incorrect polling though. https://code.wildfiregames.com/D2919

According to wraitii though spidermonkey 91 will have a bigger boost.

[borg-]

1 minute ago, Stan` said:

According to wraitii though spidermonkey 91 will have a bigger boost.

Is it scheduled for a25?

[Bellaz89]

16 minutes ago, Stan` said:

We didn't in fact it was slightly worse from what I recall. We did include a 15% perf improvement due to incorrect polling though. https://code.wildfiregames.com/D2919

According to wraitii though spidermonkey 91 will have a bigger boost.

Interesting.  So probably some VM knobs have really to be optimized.. What kind of feature does SM 91 include that makes the code run faster? I am not able to find the changelog (it seems that FF 91 is not even released).

[wraitii]

I did some profiling and I found it inconclusive. Jumping from SM45->78 meant we paid the price of the Spectre fault which means that equivalent speed is good IMO.

The improvement in SM91 is theoretical at this point, but in principle Warp should make things faster.

At this point in JS I have identified a bunch of slow code:

- Gathering can take a lot of time (mostly because ai AIProxy messages)
- Finding new targets is slow / combat in general
- Researching something is generally slow (modification messages are sent)
- Changing ownership / Renaming / Diplomacy updates are all quite slow.

[nwtour]

On 27/01/2021 at 10:14 PM, hyperion said:

Some ideas:

• Option to disable rendering of corpses and projectiles on the ground. Not rendering possibly thousands of objects likely helps quite a lot.

I commented out in my local copy:
//this.CreateDeathSpawnedEntity () in binaries/data/mods/public/simulation/components/Health.js
and replaced <DeathType>corse</DeathType> with <DeathType>vanish</DeathType>
in binaries/data/mods/public/simulation/templates/template_unit.xml

It became faster and more convenient to play without a heap of corpses, blood and ruins

I think it would be a good idea to make it a config option.

On 27/01/2021 at 10:14 PM, hyperion said:

• Use of vulkan instead of opengl.

IMHO Vulkan only benefits engine developers. Allowing to optimize autogenerated code. In 0 A.D. is hardcoded GL calls - nothing to optimize.
We'll just get compatibility problems without any performance gain

[smiley]

48 minutes ago, nwtour said:

We'll just get compatibility problems without any performance gain

You misunderstood what Vulkan is. Vulkan is a new framework that is an alternative to OpenGL (* important to note it's not meant to be a replacement). Rather than the monolithic state machine OpenGL is, Vulkan implements a completely different pattern where you can squeeze out even more performance since Vulkan doesn't suffer from most of the overheads OpenGL does. I noticed that drawcalls in Vulkan are pretty much negligible overhead whereas in OGL, it's a nightmare. Since 0AD does not have instanced drawing, switching to Vulkan will actually help a lot.

Then again, who's got the time to write a new rendering backend.

[Stan`]

5 hours ago, nwtour said:

I commented out in my local copy:
//this.CreateDeathSpawnedEntity () in binaries/data/mods/public/simulation/components/Health.js
and replaced <DeathType>corse</DeathType> with <DeathType>vanish</DeathType>
in binaries/data/mods/public/simulation/templates/template_unit.xml

It became faster and more convenient to play without a heap of corpses, blood and ruins

I have a patch for it D2936. But I need profiling data to show it's an improvement

[nwtour]

>I have a patch for it D2936. But I need profiling data to show it's an improvement

But how to do it? On my low-spec system, fps is completely correlated with the number of units in the screen scope. An excellent patch may show worse results depending on the player's camera movements (Replay does not remember the position of the camera).

[Stan`]

3 hours ago, nwtour said:

>I have a patch for it D2936. But I need profiling data to show it's an improvement

But how to do it? On my low-spec system, fps is completely correlated with the number of units in the screen scope. An excellent patch may show worse results depending on the player's camera movements (Replay does not remember the position of the camera).

@OptimusShepard might explain it better. but basically the idea is to use a replay, with follow player OR to use the cinematic function in the game.

[OptimusShepard]

On 27/02/2021 at 1:58 PM, nwtour said:

>I have a patch for it D2936. But I need profiling data to show it's an improvement

But how to do it? On my low-spec system, fps is completely correlated with the number of units in the screen scope. An excellent patch may show worse results depending on the player's camera movements (Replay does not remember the position of the camera).

Yeah I'm currently working on benchmark maps and the possibility to start, save and end the game automatically by triggers. I have currently two benchmark maps. One for heavy graphics load, and one for a big battle scenario. For both maps I created a cinematic flight, so the user is not be able to move the camera. A replay wont be necessary as no AI is used.

At the end the tester (you) should only start the benchmark map, and let it run until the cinematic flight has ended. Than you only need to apply and compile the new patch and run the map again. That's it.

https://code.wildfiregames.com/D3554

[OptimusShepard]

On 27/02/2021 at 5:07 PM, Stan` said:

@OptimusShepard might explain it better.

The profiling starts (buffering data) always when the map starts loading. To be able to use/interact with this data, you need to start the profil-server. This is done by pressing ctrl+F11. Another thing you need is the html gui. You find this gui at source->tools->profiler2->profiler2.html. When pressing the button "Save live report to file", the buffered data are saved to the file profile2.jsonp. You find the file in the log folder of 0 A.D. You can also analyze the saved data with this gui.

You need to profile the data one time with, and one time without patch to compare the both results.

Four things to remember. The map loading effects your profile data. Second, the manual pressing of the button saves the buffered data, there is no possibility to "start" the profiling. Third, don't move your camera while you are profiling, or do it in a reproducible way (e.g. following a player in the replay). Four, use a replay for reproduce.

Edited March 4, 2021 by OptimusShepard