Full CPU Usage core/core_basic_window

[dabba39]

The simplest example occupies one core fully, cpu load between 93 % and 99 %. Memory is around 10 MB, so ok.

How can I optimize this?

$ cat /etc/issue
Ubuntu 14.04.1 LTS \n \l

$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 10.1.3
OpenGL shading language version string: 1.20
OpenGL extensions:

and built raylib with
make PLATFORM=PLATFORM_DESKTOP SHARED_RAYLIB=YES GRAPHICS=GRAPHICS_API_OPENGL_11

gcc version:
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

[gen2brain]

@dabba39 try to set FLAG_VSYNC_HINT with SetConfigFlags() , or, you can comment this line in core.c:
#define SUPPORT_BUSY_WAIT_LOOP , line is at the beginning of the file, and compile library again.

[dabba39]

thanks, that fixed it, but the ./physac/physics_demo still has even 110 % CPU Usage

[gen2brain]

Yes, I noticed that too, physac uses another thread to do calculations and then try to synchronize or something like that. Go bindings (although physics module doesn't work properly, some bug etc.) don't have that problem, everything is in single thread and CPU usage is not much different from other examples.

[RDR8]

@gen2brain, will you please enlighten a noob? Where would one set FLAG_VSYNC_HINT? With a call to SetConfigFlags() in the game source or somewhere in the makefile?

[gen2brain]

You should call SetConfigFlags() with flags you want there before InitWindow(), in game source or example.

[raysan5]

Thanks for the answer @gen2brain!

Actually, I recommend commenting #define SUPPORT_BUSY_WAIT_LOOP on core.c to avoid high CPU usage but keep in mind that depending on OS, clock granularity could be up to 10 ms (despite raylib trying to enable a hi-res clock with granularity of 1ms), it means, some undesired timming issues...

Using SetConfigFlags(FLAG_VSYNC_HINT); before InitWindow() tries to enable monitor VSync for the game but it also depends on graphic card driver configuration... it could require setting it manually in Graphic Card control panel for 3D options (that happens usually with NVIDIA cards).

EDIT:

...but the ./physac/physics_demo still has even 110 % CPU Usage

physac module requires timming system review...

Related issues: #404, #412

[RDR8]

Excellent. Thank you both. These little details are very helpful.

[gen2brain]

@raysan5 I keep #define SUPPORT_BUSY_WAIT_LOOP commented for some time in raylib-go, maybe I should add tag to enable it if desired. I am always in Linux, and there with two different generation of Intel cards I needed that or else 100% CPU is there. Probably works totally different on Windows.

[raysan5]

Yes, that's right, same on Windows. if SUPPORT_BUSY_WAIT_LOOP, main game loop keeps checking time until it reaches targetFPS to continue, so the 100% CPU usage... but that's the simpler method to get accurate framerate.

[RDR8]

What happens to targetFPS if #define SUPPORT_BUSY_WAIT_LOOP? Is there any timing control at all? Or is the user left with an unbuffered spray or trickle of frames depending on the environment? I.E., does it open the possibility that the apparent performance will vary widely? Or is it just a developer control issue related to clock granularity as mentioned above?

Apologies for the fundamental nature of these questions. It's what you get for advertising to beginners. (^; I'm gonna go look at core.c now.

[raysan5]

Actually, everything works the same way for the user.

The only internal difference is that when using #define SUPPORT_BUSY_WAIT_LOOP waiting time to match targetFPS is a while loop asking repeatedly for time passed until targetTime is reached, obviously it keeps the CPU at 100% usage (not a big problem, really).

The other way, system process is halt for a specific time (CPU usage down to 0 for that process) and continues after required time receiving a system interruption managed by OS.

[RDR8]

I see. Thanks

[raysan5]

Just closing it.