Add batching to RendererCanvasRenderRD

[stuartcarnie]

This PR adds batching support for RendererCanvasRenderRD. It borrows much of the implementation from the OpenGL compatibility renderer, with additional optimisations to reduce branching and extra work in the hot loops.

Issue #85871 was a particularly interesting case, as zoomed to about 9% on my MacBook Pro M1:

area	before	after
draw calls (for tile map)	> 573440	36
FPS	~10	> 130

• Production edit: This closes Vulkan: Editor constantly uses 1-2% CPU while doing nothing on empty project due to Vulkan lacking 2D batching #71084.

[akien-mga]

GCC warning to fix:

servers/rendering/renderer_rd/renderer_canvas_render_rd.cpp: In member function 'void RendererCanvasRenderRD::_allocate_instance_buffer()':
Error: servers/rendering/renderer_rd/renderer_canvas_render_rd.cpp:3903:47: error: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Werror=sign-compare]
 3903 |  if (int(state.current_instance_buffer_index) < state.canvas_instance_data_buffers[state.current_data_buffer_index].instance_buffers.size()) {
      |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Calinou]

Tested locally, it works as expected.

Testing project: test_2d_batching_1x1_sprite.zip
This project renders 10,000 Sprite2D nodes that are 1x1 each at a fixed position. This creates a stress point for the CPU while not using the GPU much (as each sprite is tiny).

Benchmark

Using a Linux optimized editor build (optimize=speed lto=full).

PC specifications

• CPU: Intel Core i9-13900K
• GPU: NVIDIA GeForce RTX 4090
• RAM: 64 GB (2×32 GB DDR5-5800 C30)
• SSD: Solidigm P44 Pro 2 TB
• OS: Linux (Fedora 40)

Results are in 3840x2160 fullscreen, but results in 1152x648 are pretty much identical since this is a CPU-bottlenecked scenario.

Before	After (this PR, old implementation)	After (this PR, new implementation)	Compatibility1
935 FPS (1.07 mspf)	2145 FPS (0.47 mspf)	1632 FPS (0.62 mspf)	1563 FPS (0.64 mspf)

Software rendering with llvmpipe (1152x648):

Before	After (this PR, old implementation)	After (this PR, new implementation)	Compatibility1
27 FPS (37.04 mspf)	183 FPS (5.46 mspf)	185 FPS (5.41 mspf)	N/A

Footnotes

1. Not affected by this PR, but this is present for reference. ↩ ↩²

[stuartcarnie]

GCC warning to fix:

servers/rendering/renderer_rd/renderer_canvas_render_rd.cpp: In member function 'void RendererCanvasRenderRD::_allocate_instance_buffer()':
Error: servers/rendering/renderer_rd/renderer_canvas_render_rd.cpp:3903:47: error: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Werror=sign-compare]
 3903 |  if (int(state.current_instance_buffer_index) < state.canvas_instance_data_buffers[state.current_data_buffer_index].instance_buffers.size()) {
      |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fixed!

Strange, as that code is a duplicate of the gles3, so they must have that warning disabled?:

godot/drivers/gles3/rasterizer_canvas_gles3.cpp

Line 2589 in 96a386f

if (int(state.current_instance_buffer_index) < state.canvas_instance_data_buffers[state.current_data_buffer_index].instance_buffers.size()) {

[AThousandShips]

Strange, as that code is a duplicate of the gles3

It isn't fully, the forward code uses a LocalVector but gles uses Vector

[clayjohn]

The equivalent for this in the compatibility renderer is rendering/gl_compatibility/item_buffer_size. I wish I had had the foresight to make the setting something backend-agnostic like the name you use here.

After we merge this PR, we should deprecate rendering/gl_compatibility/item_buffer_size and use this setting for both the RD backend and the compatibility backend. I think it should be possible to stop writing rendering/gl_compatibility/item_buffer_size and to just read it if present, then delete it.

[stuartcarnie]

Important

I've pushed an alternative version to this branch that is more efficient and reduces branching in the CPU side.

Further, it uses bitfieldExtract to reduce branching on the GPU side.

The previous version is still available via sgc/canvas_batching_prev

[stuartcarnie]

Rebased so the build can run; I'll remove the fallback code and squash the commits next.

[clayjohn]

Tested after the rebase and it looks and runs great!

[akien-mga]

Tested briefly on Linux (AMD Radeon RX 7600M XT), with unoptimized dev_build.

Simple 2D scene, editor FPS with Update Continuously and VSync off:

• FPS master: 460-500
• FPS with this PR: 600-650

MRP from #85871, zoomed out to around 7%, with grid enabled, and using forward_plus:

• FPS master: 3-4
• FPS with this PR: 12-13
  Same project with 32% zoom:
• FPS master: ~40
• FPS with this PR: ~70

[akien-mga]

Amazing work once again 👏 🎉

[mihe]

I'm seeing a regression in font subpixel antialiasing that seems to have originated from this pull request, where I get these weird black artifacts around a lot of the text in the editor.

I opened an issue for it here: #97195

[darksylinc]

I'm afraid this PR broke mobile support because it uses slots beyond the minimum guaranteed maxBoundDescriptorSets = 4 by Vulkan spec.

I create a ticket for that issue here: #97341

[kyle-wannacott]

@stuartcarnie @clayjohn Awesome work!, any chance this batching could be extended to the other drawing functions ? ; draw_texture(), draw_rect(), draw_line() are batched!, however drawing functions like draw_arc() draw_circle(), draw_polygon(), etc... seem to make a separate draw call each time they are drawn (tested on 4.4 dev6). I think having them batched might attract people that look to game frameworks (like raylib, sdl2) for more performance with basic shapes..

[clayjohn]

@stuartcarnie @clayjohn Awesome work!, any chance this batching could be extended to the other drawing functions ? ; draw_texture(), draw_rect(), draw_line() are batched!, however drawing functions like draw_arc() draw_circle(), draw_polygon(), etc... seem to make a separate draw call each time they are drawn (tested on 4.4 dev6). I think having them batched might attract people that look to game frameworks (like raylib, sdl2) for more performance with basic shapes..

It's possible. We've discussed an approach to batching other primitives and I even wrote up some notes on how it could work, but no one has been interested in implementing it. So feel free to take a stab at it if you want!