Open LauPhi opened 1 year ago
Indeed ...
d3d11 (nor d3d12) isn't really batching: https://github.com/libsdl-org/SDL/blob/14a4ce8b59c3fd24ba91fcfa772af03e12e069f3/src/render/direct3d11/SDL_render_d3d11.c#L2100-L2115 gles2 (and gl) does: https://github.com/libsdl-org/SDL/blob/14a4ce8b59c3fd24ba91fcfa772af03e12e069f3/src/render/opengles2/SDL_render_gles2.c#L1299-L1339
There are 3 levels of batching in sdl:
Though you can submit a PR to improve d3d11 ..
Running through SDL_Render issues tagged for 3.0 ABI, sorry if you get multiple e-mails for this...
This could possibly get obsoleted by implementing a backend that uses the GPU API (like the one at #9312), but since SDL_Render targets a super low feature level it would actually be reasonable to keep SDL_render_d3d11, so it may not apply to <D3D11-class hardware...
It doesn't look like the Metal or D3D9 renderers try to merge individual draws either.
This is probably worth fixing in all the backends, but it doesn't need to be in the 3.0 ABI milestone. I'm bumping it to 3.2.0, and possibly to 3.x later.
OS: Windows 10 SDL: 2.26.4 GCC: 12.2.0 (x86_64-posix-seh-rev2, Built by MinGW-W64 project)
I was using RenderDoc to confirm that the batch rendering was working but it is actually not.
I am specifying a direct3d11 renderer because RenderDoc can not capture OpenGL 2 frames.
I am setting the hints like this:
Then creating the renderer with:
The texture is rendered using 8 times:
So no flush should happen until
SDL_RenderPresent(renderer);
at the end of the frame.Here is the frame capture from RenderDoc:
As you can see, there is 8 separate draw calls for essentially the same texture.
I tried spacing the drawn rectangles and it did not enable batching either.
Here is the minimal reproduction project: SDLBatchingNotWorking.zip