Compiling openMSX for Armbian 5.59 xenial

Page 5/6
1 | 2 | 3 | 4 | | 6

By Manuel

Ascended (18256)

Manuel's picture

23-10-2021, 23:11

Which MSX machine are you emulating when testing the speed difference?

By Shinobi

Master (198)

Shinobi's picture

23-10-2021, 23:21

Quote:

mali_drm" is the GPU driver, so if that doesn't load, you probably don't have accelerated OpenGL. Or maybe no OpenGL at all: what does "set renderer" print after you try to switch to "SDLGL-PP"? It's possible the switch fails and it falls back to the "SDL" renderer.

What hardware are you running on? Do you have the "mali" driver packages installed?

When i run (sudo openmsx), the mali message wont appear.. any ideas how to check if i have mali drivrers as i am new to linux..
My hw is cheap android tv box with 1gb ram and allwinner h3 soc

By Shinobi

Master (198)

Shinobi's picture

23-10-2021, 23:22

Quote:

Which MSX machine are you emulating when testing the speed difference?

Msx1 machine...alamiah ax 170

By Shinobi

Master (198)

Shinobi's picture

23-10-2021, 23:48

Here i got some info about opengl rendering...look
https://ibb.co/xjNG85S

By mth

Champion (503)

mth's picture

23-10-2021, 23:50

The GPU in that SoC seems to be Mali-400 (Utgard). You could try whether "apt search mali" turns up anything.

It's also possible the Mali drivers are now integrated into Mesa and not all of Mesa is installed, so "apt search mesa" and looking for anything described as direct rendering (DRM/DRI) drivers might help too.

I don't have an Armbian installation and the info I can find on the web isn't very useful, so I'm sorry that I can't be more precise.

By mth

Champion (503)

mth's picture

23-10-2021, 23:53

"llvmpipe" is a software renderer, so that's not going to be very fast.

With SDL2 we moved from exclusive full-screen mode (which changes the monitor resolution) to non-exclusive full-screen mode (which scales up the graphics without changing the monitor resolution). The result is a quicker and smoother transition from/to full-screen, but it does rely on hardware scaling to perform well.

By ren

Paragon (1888)

ren's picture

24-10-2021, 01:55

@mth would it be possible (and doable/feasible) to (still) implement/offer (the 'original') exclusive fs mode as well? (I believe I inquired about that earlier already) Smile

By mth

Champion (503)

mth's picture

24-10-2021, 18:16

For systems using hardware scaling (SDLGL-PP renderer), exclusive full-screen doesn't make sense. The software scaling code is a pain to maintain and isn't going to be useful on modern systems, since hi-dpi screens are becoming the norm and it is super wasteful or downright impossible to output that many pixels in software.

We'll probably keep 1x and the simple 2x software scaler around to enable ports to low-powered devices. Most of those devices use the framebuffer directly though, in which case you'll automatically get exclusive full-screen output since there is no windowing system.

The use case of non-accelerated rendering in a windowing system is pretty uncommon and I'm not sure it's worth supporting. Even if we'd enable exclusive full-screen, we might run into other issues where SDL2 expects rendering acceleration. There is always the option to run openMSX 0.15 (the last SDL1 release) on such systems.

By Shinobi

Master (198)

Shinobi's picture

25-10-2021, 02:06

To solve this issue, I switch my android tv box to av output with 720 X 576 PAL, in 2X it is full-screen , the fps drops a bit in some games but it is full screen, i didnt try the new cheap tv boxes in the market, I will get one and test it..thank you all for the help..

By ren

Paragon (1888)

ren's picture

25-10-2021, 14:15

@mth Thanks for your explanation. You say hw scaling + exclusive fs doesn't make sense, although up till openMSX 15 that was the out-of-the-box configuration right?

The difference between 15 & 16/17 is definitely noticeable (on some (older/less capable) systems), where the latter took somewhat of a performance hit. It seems to me the main culprit is the switch to non-exclusive fs + perhaps the changed vsync handling/code?

Isn't it, implementation wise, simply a matter of calling SDL_WINDOW_FULLSCREEN instead of SDL_WINDOW_FULLSCREEN_DESKTOP?

I do know there are emu's that do offer the option. I understand the sw scaling part (reasoning), but I might be missing something here Smile

Page 5/6
1 | 2 | 3 | 4 | | 6