Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full CPU Usage core/core_basic_window #415

Closed
dabba39 opened this issue Dec 7, 2017 · 13 comments

Comments

Projects
None yet
4 participants
@dabba39
Copy link

commented Dec 7, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2017

@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

This comment has been minimized.

Copy link
Author

commented Dec 7, 2017

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

@gen2brain

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Dec 8, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Dec 8, 2017

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

@raysan5

This comment has been minimized.

Copy link
Owner

commented Dec 8, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Dec 8, 2017

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

@gen2brain

This comment has been minimized.

Copy link
Contributor

commented Dec 8, 2017

@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

This comment has been minimized.

Copy link
Owner

commented Dec 9, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Dec 10, 2017

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

This comment has been minimized.

Copy link
Owner

commented Dec 11, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Dec 11, 2017

I see. Thanks

@raysan5

This comment has been minimized.

Copy link
Owner

commented Dec 14, 2017

Just closing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.