| Summary: | Unusually long time in SDL_AllocateRenderVertices | ||
|---|---|---|---|
| Product: | SDL | Reporter: | edwinguy |
| Component: | render | Assignee: | Alex Szpakowski <amaranth72> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | Keywords: | target-2.0.12 |
| Version: | HG 2.1 | ||
| Hardware: | x86 | ||
| OS: | macOS 10.14 | ||
| Attachments: |
Flame graph of the call stack
Image of what the screen is rendering Embarassingly messy code Flame graph when using master branch |
||
Created attachment 4053 [details]
Image of what the screen is rendering
Created attachment 4054 [details]
Embarassingly messy code
For what it's worth, disabling every call to set_draw_color() (which I presume maps to SDL_SetRenderDrawColor() under the hood) made very little difference. I also hadn't realized that I wouldn't be able to edit my initial post so pardon the grammar there. It seems that I'm using sdl2 2.0.10 and the code (which maybe is getting called too many times?) is here: https://github.com/spurious/SDL-mirror/blob/release-2.0.10/src/render/metal/SDL_render_metal.m#L958 Are you able to test with the latest SDL source code? I put in a change in August which drastically improved the performance of SetRenderDrawColor on macOS for me. Sorry, I meant to say the performance of SDL_AllocateRenderVertices (especially via METAL_QueueSetDrawColor) was improved. Oh yeah, that made a huge difference. It seems to be about a 5x speedup. I'm now seeing CPU usage of ~12%. Other than shipping a new build, I'd say this is fixed. I'll upload a new flame graph for the curious. Created attachment 4056 [details]
Flame graph when using master branch
|
Created attachment 4052 [details] Flame graph of the call stack I've been playing around with SDL2 bindings for Rust and I decided to look into why my single-core CPU usage is at 54%. It seems from the flame-graph generated by dtrace is showing the vaste majority of the time is taken up by SDL_AllocateRenderVertices. I looked at the implementation for macOS's Metal and it doesn't seem terribly obvious as I don't expect the time is taken during memory allocation (or that would be a the top). It seems the problem is when changing draw colours. I've attached the flame graph here (open it in your browser) and I'll see if I can attach a screenshot of what's being drawn along with my sloppy code noodling.