Vsync.Wait rises while the game runs

Questions
#1

Hi there,

I have a question about Vsync.Wait in the profiler. The display settings in game .project are: Frame Cap = 0, Vsync = true.

I am testing a debug build on a Huawei P10 Lite. I start my project and I see the engine takes about 16ms per frame and the Vsync.Wait is about 1.8 ms. As the game runs (always staying in the same loop, no input, no changing in the “scenario”) the Vsync.Wait rises slowly but in a constant rate. I see it reaching more than 10ms with a frame taking 25ms. The other items in the profiler stay almost constant.

It seems that Vsync.Wait is increasing forcing the frame length to increase in a compatible way.

Any hint?

Thanks!

EDIT: checked with Vsync = false in game.project but nothing changed.

#2

The combinations of vsync and framecap and their implications can be seen in this matrix:

Can you please test with a completely empty collection as bootstrap collection and see if it behaves the same way?

#3

Thanks for the matrix about Vsync and FrameCap. I think the one I need is the default: Vsync = true and Frame Cap = 0.

I am sorry, but I don’t know how to launch the profiler with a completely empty collection as bootstrap collection… could you suggest how should I do?

Thanks!

#4

I checked with an “almost” empty collection as bootstrap, a collection with only one go having only one script with the following lines:

function init(self)
msg.post("@system:", “toggle_profile”)
end

The display project settings are:
High Dpi = false
Samples = 0
Fullscreen = false
Display Properties = /builtin/render/default.display_profiles
Dynamic Orientation = false
Frame Cap = 0
Vsync = true

This is what I see:

  1. For (about) 10 seconds: The frame length stays at 16ms and Vsync.Wait = 4ms (and a very long Graphics.Clear of 10ms).

  2. Then, after 10 seconds: Vsync.Wait jumped to 24ms and the total frame length jumped (accordingly) to 34ms (with now Graphics.clear = 1ms).

So, essentially the same behavior. This looks very strange to me!

#5

And this is on the Huawei P10 Lite? Do you have access to any other Android device?

@johan_beck-noren might have some input?

#6

Could it be some device CPU throttling?

#7

Thanks for the hints!

I am not an expert, but it could be some throttling. I read that Huawei P10 Lite is very sensitive to thermal throttling… Moreover I was not able to reproduce again the behavior with the empty collection. Probably the two times I saw that behavior with the empty collection were false positive: still for thermal throttling due to the previous running of the complete build. I will soon test on some other Android devices as suggested.

I attach a profiler screenshot (sorry for the masking of the game frame behind… I am shy to show a work in progress…). Could you please suggest in which direction to reduce the load on the CPU / GPU? Also, I have raised the sprite max to 256 and the particlefx max to 256 but in the test both items stay always way behind this limits.

Thanks so much!

Screenshot_20190318-194244_masked
Screenshot_20190318-194244_masked.jpg1920×1080 838 KB

#8

Rendering takes a lot of time and you have 94 drawcalls! Judging from the profiler you have plenty of particle effects, quite a few sprites and some models. The engine will batch draw operations as much as possible, but you have to help it as well by thinking about how you assign z-values and so on. We currently don’t have a manual that describes how we do batching of draw operations, but I will make sure to add this later this week or the next. In the meantime you can read about it here in this forum post: Draw calls and Defold

1 Like
#9

Thank you!

I will read the post you suggested and try to lower the draw calls. I have so many draw calls since:

  1. I extensively use the tint uniforms (and I may guess that this prevents the batching),
  2. I use some custom shaders, mostly of them processing (2d) model vertices for animation / curve drawing.

Probably I may try to bake some tint variations. This will cost some texture memory, but perhaps this is not that important as I was assuming.

Thanks again!

2 Likes
#10

Hi there,

I have read the post about draw calls. And clearly I must pay a lot of more attention about the z-values in order to batch more elements as it is possible.

On the other hand, I see that you have planned the option to move tint from uniform to vertex color (in this way tint will not break anymore the batching), via some kind of custom vertex format.

So, before I start optimizing the whole game reducing the tint usage, could you please give me some indication when this new engine feature will be available?

Thanks very much!

#11

It is unlikely that you’ll see this being released within the next 4-6 months.

#12

Thank you for the useful information.

#13

I am attempting to lower the drawCall number. For the moment I succeeded to lower it from ~95 to ~50 by a simple rule: do not use tint! :slight_smile:

Then I moved to a closer look to openGL via Apple openGL Profiler. I am learning a lot of interesting things about my own project :slight_smile: And I am seeing a lot of possible improvements. But there is also something I don’t understand.

The engine is drawing identical ParticleFx with different tint in different DrawCalls. I understand that tint is a uniform for the particlefx.material so different DrawCalls are needed. However the same particlefx.material has a vertex color attribute that is multiplied by tint in the fragment shader. Since the engine is already computing these vertex colors each frame for each particle it could also multiply them by the tint and batch all them together.

Probably this is prevented by some other engine consideration I am not aware. But in my case a different particlefx for each tint will result in too many different collections… not a practical or elegant solution…

There could be the possibility to change the “animation” property of the emitter in code to pretinted particle; but there is no method to do that

Are there any other solution?

Thanks very much!

Ciao!

#14

Hi there,

I continue to update my personal efforts in minimizing the number of drawCalls; hope this may be useful to someone else.

Till now I have lowered this number way down by avoiding tint and rearranging Z values aiming at material-wise homogeneous Z-intervals.

However I have a question about tint and batching. I have a sprite with animated tint. At the end of the animation the tint is full white [vmath.vector4(1.0,1.0,1.0,1.0)]. But it seems to me that the engine is not batching the sprite with the other sprites whose tint has always been full white. As if the sprite tint is marked as animated and is no more batched.

Is there something I am missing?

Thanks for any hint and thanks, as usual, to the Defold team for the incredible work with the engine!

Ciao!

1 Like
#15

Hi! When you setup a constant, batching will not work for this node
Instead of returning to full white, you should reset contant, if you want return batching

3 Likes
#16

Thank you! Now it makes sense!

#17

Hi there,

a new update about drawcalls and vsync. It took some time, but I succeeded in lowering the number of drawCalls from ~90 to ~15. Now it seems to me that I have no more space to optimize it…

BUT, the vsync wait interval has the same problem as before. The engine takes ~10ms for frame. The vsyncWait starts very low (1ms) but rises till ~11ms resulting in more than 20ms of frame period.

I am still using the Huawey P10 lite and I still have to test on other devices. But I really don’t know what to do to solve this problem.

Probably the problem is not on the GPU side but on the CPU side. Are 10ms (overall period including drawing and simulation) too much and the engine is consuming too much energy/battery warming the device? And this causes a thermal throttling?

Any hint is greatly appreciated! I have to admit I am a bit worried about this issue…

Ciao!

#18

Could you either share the project with me (bjorn.ritzl@king.com) or a debug build that I can try? I’d like to test on a device or two and take a look at the profiler.

#19

Yes, sure! I added you to the project on bitbucket.

1 Like
#20

Probably I solved the issue about vsync.

The game had a fog effect made with many large particles (with an almost trasparent bitmap). I think this resulted in a huge amount of overdraw. And this was too much for the GPU. I have removed the fog and now on my Huwaei P10 lite the game runs perfectly smooth.

Learned a lesson about the importance of fill-rate on mobile.

Ciao!