energy usage

페이지 1/4
| 2 | 3 | 4

By rolandve

Master (218)

rolandve의 아바타

25-04-2020, 12:15

This is a hard one: the energy usage of openMSX is really high. It burns laptop batteries dry in an hour, which is no fun if you're like me, using MSX while sitting in a lazy chair enjoying the fact that MSX can do games without the need for a mouse.
It easily peaks at 30% (of an i9 at 2.4 ghz) while just waiting for user input in a OpenMSX boosted TurboR with IDE. This scales nicely with the machine, because my previous MBP had an i7 and that also burned at 30%.

I understand this is not a bug, nor that its really high on a priority list ( I guess), but perhaps you could put some breaks in the code that burns the energy. I understand I have no clue about the architecture of openMSX so it might even not be possible. I only have some tips from my job. In VB.Net I sometimes write code that loops in some kind of wait-state (because not everything is an event) and the code become a CPU-hog, burning energy. Some sleeps x ms/doevents, etc at that point performs miracles. Perhaps, this is a possibility?

Thanks

Login or 등록 to post comments

By Manuel

Ascended (16692)

Manuel의 아바타

25-04-2020, 12:39

We're not wasting CPU cycles if we don't have to, be sure about that. There are no busy loops whatsoever.

Which rendering settings are you using?
Which renderer? Which scale factor? Which scaling algorithm? Which openMSX version?

By PingPong

Prophet (3526)

PingPong의 아바타

25-04-2020, 12:41

Have you an idea of much is hard to emulate a hw through a sw high level language.?
Did you notice that openmsx must do in sw what a vdp does in hw? Like regenerating the image stretching it emulate scanlines and blur. The simple operation of scale by 2 the msx screen by 2 to see a decent size picture multiply x 4 the number of bytes you need to throw in the screen. Plus the pc screen is somewhat a little heavier in terms of memory than the most msx screen mode. Make your calculations : 640x480x24 bits per pixels. Plus they probably render gfx using sdl. Based on driver maybe the work could not be done in accelerated way but need to be done by cpu itself.

This kind of sw emulation is somewhat very different from a graphical gui application where the most of the time is spent I the main idle cycle and you can low cpu usage by yielding cpu time to other tasks.

By rolandve

Master (218)

rolandve의 아바타

25-04-2020, 13:04

PingPong wrote:

Have you an idea of much is hard to emulate a hw through a sw high level language.?
Did you notice that openmsx must do in sw what a vdp does in hw? Like regenerating the image stretching it emulate scanlines and blur. The simple operation of scale by 2 the msx screen by 2 to see a decent size picture multiply x 4 the number of bytes you need to throw in the screen. Plus the pc screen is somewhat a little heavier in terms of memory than the most msx screen mode. Make your calculations : 640x480x24 bits per pixels. Plus they probably render gfx using sdl. Based on driver maybe the work could not be done in accelerated way but need to be done by cpu itself.

This kind of sw emulation is somewhat very different from a graphical gui application where the most of the time is spent I the main idle cycle and you can low cpu usage by yielding cpu time to other tasks.

Yeah, and that's why I was very careful, like not calling it a bug etc.

By Emphy

Resident (41)

Emphy의 아바타

25-04-2020, 13:12

You may want to check which renderer is being used (in the video options). On my laptop (i5), cpu usage lowers from 30% to around 15% when I select sdlgl instead of sdl.

By rolandve

Master (218)

rolandve의 아바타

25-04-2020, 13:27

Thanks for the swift reply.
Latest build
I scaled down every video setting to use 16% by these settings:
Videosource : MSX
Scaler : simple
scale factor: 2x -> difference in energy impact : 14% scale factor 1x, 16% factor 2x, 18% factor 3x
Min Frameskip: 5 / Missed 6 -> frameskip 0 minimal skip 0 and energy usage is around 35%
Enforce VDP sprites per line limit add's 0.5% energy usage.

Again: this is not an issue that should be classified as anything even nearly a bug, it just makes you wonder: where does the energy go Smile Looks like the screen.

By rolandve

Master (218)

rolandve의 아바타

25-04-2020, 13:29

Emphy wrote:

You may want to check which renderer is being used (in the video options). On my laptop (i5), cpu usage lowers from 30% to around 15% when I select sdlgl instead of sdl.

This Mac build does not have the option for SDLgl or SDL.

By gdx

Prophet (3561)

gdx의 아바타

25-04-2020, 13:33

The more precisely an emulator imitates the hardware, the more it consumes resources. OpenMSX worked well on a core 2 duo a few years ago, now there is some heaviness in frame rate and the sound that is no longer as clear.

By Manuel

Ascended (16692)

Manuel의 아바타

25-04-2020, 13:36

rolandve wrote:
Emphy wrote:

You may want to check which renderer is being used (in the video options). On my laptop (i5), cpu usage lowers from 30% to around 15% when I select sdlgl instead of sdl.

This Mac build does not have the option for SDLgl or SDL.

Did you see my post? You can check these settings in the OSD menu or using the console (e.g. set renderer)

By sd_snatcher

Prophet (3296)

sd_snatcher의 아바타

25-04-2020, 14:05

But there's some interesting fact: openMSX uses around 1% of CPU in my Mac just by being paused. Yes: no emulation running whatsoever.

Steps to reproduce:

1) Boot an MSX on openMSX
2) Press CMD+P to pause the emulation
3) Check the how much CPU openMSX is using on Activity Monitor

openMSX settings:
- renderer: SDLGL-PP
- scale_factor: 2
- scale_algorithm: simple
- scanline: 20

host machine specs:
- iMac Retina 21.5"
- Intel Core i5 3.4GHz
- 8GB RAM
- macOS 10.14.6

By gdx

Prophet (3561)

gdx의 아바타

25-04-2020, 14:40

It is also faster with SDLGL-PP renderer here (about 10% on average on a mac core2duo) but There is still heaviness with missing frames at times especially in window mode even if I set frame skipping on zero or low.

페이지 1/4
| 2 | 3 | 4