There’s another recent similar topic but I’m in a slightly different situation, so I think I should open a new thread. Hope you don’t mind.
I’m writing a small demo program using SDL2 and cairo, just to get acquaintance with SDL2. Open a window, load a BMP, draw a line, all good so far.
My event loop is this:
while (1) {
rc = SDL_WaitEventTimeout(&event, 3000);
if (rc == 0) {
printf("timeout? %s\n", SDL_GetError());
continue;
}
printf("event type: %d\n", event.type);
if (event.type == SDL_QUIT) {
break;
}
}
On my Ubuntu 18.04 laptop, SDL2 version 2.0.8, the CPU usage of my process is, as expected, almost 0.
But on Raspberry PI 2, running Raspbian with its system-provided SDL2 version 2.0.5, plain X11 with no desktop environment, I get a 20% CPU usage. There’s clearly something wrong. But… what?
Thanks for any suggestion.
P.S.: There’s a place in this forum dedicated to SDL on Raspberry PI?
20% CPU usage from your program or 20% overall? 20% of one core or 20% of all cores?
Does it get lower if you remove the printf()? (ok, with 3sec timeout that’s probably not significant)
One thing to keep in mind is that a Desktop CPU is a lot faster than RPi’s CPU, so the same amount of work causes a higher percentage of CPU load…
(20% still seems a bit high)
20% for my process alone (on one core, this is a single threaded program). It is VERY high, even on the low power RPi processor. A single printf every 3 seconds is negligible as CPU usage. I’d probably be suspicious even for a 2% of usage.
Hmm so SDL_WaitEventTimeout() calls SDL_Delay(10) between checking for new events, and SDL_Delay() calls the system’s nanosleep() function.
I don’t know how exactly nanosleep() is implemented, but it seems likely that it uses CPU-specific instructions (if available). So maybe x86(_64) has instructions that allow sleeping for a few milliseconds without causing load, and ARM doesn’t (or at least none that are as good)?
You could try a simple C program to see how “costly” nanosleep() for 10ms is, like
I ran your code on my RPi and its cpu usage is barely visible in top. So nanosleep() is fine.
But you have an interesting point. What else does SDL_WaitEventTimeout() in its loop?
Now I’m having troubles recompiling a working SDL for RPi, in order to do the profiling of that loop. I can’t find, right now, how the system-provided library was compiled. But this isn’t matter for this thread.
I didn’t thought about it… that’s a clever idea I focused on recompiling SDL because I also want to update it, but in the meantime I can do as you say to work on this problem.
SDL_PumpEvents() takes, on the Raspberry Pi, 6.5 milliseconds to return; compared to the 10ms delay inside the loop, it is pretty big. Given the purpose of this function, there’s a change the problem lives outside SDL.
yeah, that would’ve been my next guess - if nanosleep() indeed sleeps and keeps CPU usage low, it must be SDL_PumpEvents() and whatever it calls - I guess to debug/profile that further you’ll have to build SDL yourself after all - and if you’re very lucky the problem might have been fixed at some point between 2.0.5 and 2.0.9 (or current HG)
Generally not, I think - but you should be able to get the package source from your Linux distro and figure out what they’re using. apt-get source libsdl2-2.0-0 should download the source (if you have apt repos for sources configured) and extract it and set up the debian (or Raspbian) specific patches etc.
There will be a debian/ directory in that extracted source directory then, look around there for information; especially debian/rules is interesting (it’s the makefile to build the .deb), but debian/control is as well, it lists the build dependencies. Speaking of build dependencies, apt-get build-dep libsdl2-2.0-0 should install all of those, I guess that’d help as well?
I can’t tell if the bug has been solved moving from SDL 2.0.5 to 2.0.9 or has been excluded by the disabled features.
Now I have another problem, still only on the Raspberry PI, when this function returns due to the timeout expiration. But I think this is matter for another thread.