LÖVE is a CPU/power hog: why?

[Hexenhammer]

At first I thought my game code was less efficient than I thought when I looked at the Windows task manager: my little (vsync'ed) demo maxed out one my CPU cores! But then I got suspicious, thinking "there is no way in hell that this code can max out a core", so I started LÖVE 0.9.0 (x64) without a game.. that Baby Inspector screen also maxes out one core!

I assume there is a reason why LÖVE hogs the CPU (one of its cores to be exact) all the time even if there is nothing to do. I would like to know that reason.

[slime]

What GPU and OS are you using? 0.9.0's no-game screen uses 4-5% CPU for me.

This is probably related to your problem:
http://gamedev.stackexchange.com/questi ... alext-is-e
http://www.retrocopy.com/blog/5/the-bat ... s-ati.aspx

(it's a driver issue.)

[Hexenhammer]

What GPU and OS are you using?

Win 7 Professional SP1, Geforce GT 640, official Nvidia driver .

0.9.0's no-game screen uses 4-5% CPU for me.

This is probably related to your problem:
http://gamedev.stackexchange.com/questi ... alext-is-e
http://www.retrocopy.com/blog/5/the-bat ... s-ati.aspx

(it's a driver issue.)

I only speed read it but if I got the gist it is that the problem is the combination OpenGL + Nvidia driver + Windows. Would explain why my old C + SDL games do not have that problem (they do not use OpenGL).

Thanks for the explanation.

P.S: Yet another excuse for me to write my own SDL based back-end! (I love re-inventing the wheel). My combination is very common and I do not want my game to be a CPU/power hog on all those systems.

[slime]

nvidia's OpenGL driver in windows seems to wait for the screen's vblank by basically doing a busy-loop until it happens, which will always use 100% CPU on that thread if it can. Other drivers do it differently.

One of the links I gave provides a possible workaround for the issue.

By "SDL based backend" I assume you mean software rendering? SDL 2's render API (which replaces its old software rendering API) is hardware-accelerated with OpenGL as one possible backend, but it's still much more primitive than LÖVE's API.

Software rendering won't help, since you'd lose all reasonable performance plus the use of the GPU, and gain massive CPU usage.

[Hexenhammer]

nvidia's OpenGL driver in windows seems to wait for the screen's vblank by basically doing a busy-loop until it happens, which will always use 100% CPU on that thread if it can. Other drivers do it differently.

One of the links I gave provides a possible workaround for the issue.

I already have workarounds for other issues and at some point it makes sense to switch to a solution which does not require any workarounds. Especially given that I can implement the functionality of LÖVE I actually use (a small subset) in a day using C+SDL. LÖVE has been great for prototyping though.

By "SDL based backend" I assume you mean software rendering?

I meant using SDL2 with hardware accelerated rendering.

SDL 2's render API (which replaces its old software rendering API) is hardware-accelerated with OpenGL as one possible backend

One possible back-end. By default it uses Direct3D on Windows i.e. problem solved.

, but it's still much more primitive than LÖVE's API.

My Lua code will look almost the same. I will do it like LÖVE, implement the low-level logic in C (okay LÖVE does it in ugly C++ ) and expose a high-level interface to the Lua code i.e. the Lua code will not contain any direct SDL API calls.

Software rendering won't help, since you'd lose all reasonable performance plus the use of the GPU, and gain massive CPU usage.

Not in my experience. My software rendered SDL 1.2 game which does way more than my little demo and at a higher resolution only needs 2-3% of a core to do it. "It" being simply drawing a lot of tiles .. which is really all I need.

[Suppercut]

I'm having the same problem, but I have a Radeon, and I've never saw it up until 0.9.

Then again, I guess I never really looked at the percentages until 0.9 completely broke NppExec, making it a [random stream of curses] to test my game on the fly.