draw_line performance has worsened since 3.2.3

[kaetjaatyy-dev]

Godot version

3.4.stable

System information

Windows 10, GLES3, GeForce GTX 980M

Issue description

draw_line (and others such as draw_arc) performance has dropped significantly from 3.2.3 to 3.3 and is still at a low level in 3.4. A simple test of drawing 700 horizontal lines on screen gives about 275 FPS on my machine in 3.2.3-stable. In 3.3 (earliest version where the performance issue occurs is 3.2.4-beta1) and 3.4-stable I get 55-65 FPS on the same machine, running the same scene. This is without antialiasing. _draw is called only once (in scene _ready) and _update is not called at all. This strange behavior occurs only when drawing lines with width > 1 (tested with width=2). With width=1, 3.4. performance is extremely good.

Expected behavior: Versions after 3.2.3 would have similar performance for draw_line and other custom drawing as 3.2.3 instead of a 80% FPS loss.

3.

Steps to reproduce

• Create a new scene
• Add a few hundred draw_line calls in _draw
• Run the code in Godot 3.2.3 and any 3.3 or 3.4 version
• Observe the FPS drop from the older Godot version to the newer one

Minimal reproduction project

gd34-perftest.zip

[clayjohn]

How does performance compare when you disable batching?

[lawnjelly]

On an integrated Intel HD Graphics 630 on Linux I get:

3.2.3 stable - 123fps
3.4 - without batching 145fps, with batching 870fps

This suggests there's something your GPU doesn't like. First I would try it with batching switched off for comparison in 3.4. Some GPUs don't deal very well with dynamic buffer usage, this is very ill defined in OpenGL, and we have attempted to use the most compatible method.

If you have a look in rendering/2d/opengl, there are some options for buffer usage which may help on your system, however I would encourage you to export with the defaults, as for an export you should try and have it running well on the majority of machines (yours may be an outlier).

You can also try updating your graphics drivers, sometimes this will be a driver issue.

[kaetjaatyy-dev]

How does performance compare when you disable batching?

No meaningful change. I got about 55 FPS with a quick test with batching disabled (i.e. a few percent drop).

This suggests there's something your GPU doesn't like. First I would try it with batching switched off for comparison in 3.4. Some GPUs don't deal very well with dynamic buffer usage, this is very ill defined in OpenGL, and we have attempted to use the most compatible method.

There is definitely something strange going on with how custom drawing is implemented between versions. When I set the line width to 1 (instead of 2 in the above benchmark) the 3.4 FPS skyrockets to about 2000, whereas 3.2.3 FPS stays constant.

If you have a look in rendering/2d/opengl, there are some options for buffer usage which may help on your system, however I would encourage you to export with the defaults, as for an export you should try and have it running well on the majority of machines (yours may be an outlier).

These do not seem to change the results. I flipped each of the four options separately and together, and did not see any changes in the FPS.

You can also try updating your graphics drivers, sometimes this will be a driver issue.

Thanks, I will try that.

[lawnjelly]

Ah this changes things. If you get no increase with batching off, and it is related to line width, then it sounds like the different methods with different sized lines, rather than the dynamic buffers. I will take a look. I can't remember if we made any changes to this since 3.2.3...

[kaetjaatyy-dev]

Awesome! I should have mentioned the line width aspect in the main post but I just noticed it right now when doing further testing.

[lawnjelly]

Ah slight confusion on my part, I've realized the release I was using was with this PR #54377 (which hasn't been merged yet) which will have increased the performance a boatload.

In fact with a small window (200x100) I get a frame rate increase from 147fps to 4000fps with the PR, showing it is now fill rate limited, and this would be more common on more powerful GPUs.

In regular 3.4 stable I get:

without batching 255fps with batching 255fps

With the regular 3.4 it draws them as default lines with or without batching. So the performance is pretty similar the batching won't affect it.

Still investigating! 😁

Ok looks like there may be a number of changes since 3.2.3, but most likely are dynamic buffer changes, so I may have been correct to suggest trying the opengl buffering options.

On the flip side, this is probably moot in this particular case because #54377 will change the mechanism for drawing these thick lines so that they will be batched, and I suspect will be a lot faster on your system too. You may be able to test the artifact builds in that PR (if you click the green tick builds you can download and test out). We may end up cherry picking this to 3.4, or else if you use the 3.5 betas it should be fine.

Related:
Interestingly the performance (on mine at least) for the regular thick line drawing has increased since 3.2.3, going up from 123fps to 255fps. So any changes to the old line drawing (probably buffering) have made things faster for some systems, but not for you. But either way, the batched line drawing should be miles faster, except in the case of single thick lines on their own, or when batching is off, which seems is around 3.2.3 speeds. I'll put a note to this effect on the PR.

[lawnjelly]

Should be fixed by #54377.