Raspberry pi. Brainstorming about potential problems

Prophet (2066)

22-08-2022, 21:37

Vsync has some effect. Setting the scaler to simple has effect too. Removing scanline effects makes it even better. This is all strange because the frame counter really stays put at 60hz

Par Manuel

Ascended (19468)

22-08-2022, 22:29

Which memory usage did you check? RSS is the proper one... It's the actual memory in use.

Par Daemos

Prophet (2066)

23-08-2022, 09:30

Checked them all. Memory looks fine. On track of something more. It looks video related. Disabling vsync has some effect on the pi in a positive way and lowering the output resolution makes the pi full screen

But that doesn't do much, however. Once the "problem" starts kicking in all I have to do is call the OSD menu and exit and the problem goes away but the problem can be seen on the framecounter. When the problem starts the 59,9 fps start slight dropping in brief moments to 59,8 fps. When the problem intensifies the framecounter increases to 61 fps and then wobbles between 59,8 and 61 fps until I call the OSD menu. It doesn't matter how long I call the menu just calling it and exiting it is enough and the framecounter stabilises and the problem goes away. I timed the problem to start occuring after 5 minutes.

Par gaula82

Resident (45)

23-08-2022, 13:31

@Daemos

You have been reading guesses, now let's got for the facts.

-If you are running an Xorg(X11) graphics server, you can't reliably emulate anything: the X11 video system is plagued with problems, from the system's design to the poor X11 support that the drivers have.

-You are forced to have 3 buffers if you use OpenMSX on X11 (triple buffering scheme). That gives a better CPU usage (emulation thread is not blobcked by vsync event wait) but you get a very noticeable input lag. Not, you are not imagining anything: there are technical facts behind your poor MSX emulation experience on the enviroment you are using.

-SDL2 has support for KMS/DRM: that means that SDL2 programs (like OpenMSX, I hope it's not using SDL1.x these days) can run without an X11 server, using the kernel graphics infraestructure directly.
Using that SDL2 backend, you can export this: export SDL_VIDEO_DOUBLE_BUFFER=1
...and the program will be forced into two buffers mode, which will guarantee a low input lag.
NOTE you can't do this under X11: you have to be on a system without the X11 system running.

-Since setting up a system without the stinky X11 and building SDL2 with KMS/DRM isn't something you may be willing to do, you can simply download latest Lakka for Pi4 here:

https://le-builds.lakka.tv/RPi4.aarch64/Lakka-RPi4.aarch64-4...

Lakka is a GNU/Linux distro without X11 and without SDL2. Emulators run directly on KMS/DRM using low-level APis like Vulkan.

Once in Lakka, go to the graphics settings and:
-set the video driver to Vulkan.
-disable "threaded video"
-set the max buffers to 2.

Now, use the FBNeo core to load MSX1 games, like Zannac.
You will see how good MSX emuation can be when done right.
Don't use other cores: use FBNeo.

NOTE: Since OpenMSX doesn't have any mechanism for video/audio synchronization, you will ALWAYS have small hiccups with it (yes, even with vsync ON).
Libretro cores, on the other hand, run in sync with the video and have their audio resampled to cope with the video frequency, so everything is smooth as in a real MSX on a real CRT.
In other words: you want realistic MSX emulation, forget OpenMSX unless someone ports it to libretro, which I don't think will ever happen by now.

NOTE2: I am not making all this up. I did a big chunk of SDL2 programming these past years so I know my way around those problems and their causes-

Par Daemos

Prophet (2066)

23-08-2022, 16:12

ditched the x server a long time ago and gfx is output directly via sdl so we are on good track. I will try the double buffer and see what happens. thnx for the input.

Par gaula82

Resident (45)

23-08-2022, 16:37

Indeed, if you ditched the X server you are on good track!

Are you using SDL1.x or SDL2?
Double buffering only works on SDL2. SDL1.x is utterly broken: I added native Dispmanx support for SDL1.x (Dispmanx is the Pi's GPU native 2D interface, but thanks God it's now dead and standard KMS/DRM took it's place) but it doesn't work anymore.

In simple words, use SDL2 for the double-buffering.

Anyway, with fine-scrolling games you will have small hiccups if you use OpenMSX on SDL2, no matter what.

Par Daemos

Prophet (2066)

23-08-2022, 17:38

SDL2 it is compiled on that library so I assume SDL2. Double buffering it is.

EDIT: The double buffering did the trick but only after calling the OSD menu for a second. The game runs smooth after that and the problem doesn't come back after a very long time.

Par gaula82

Resident (45)

24-08-2022, 11:51

That part of calling the OSD makes no sense: if you exported SDL_VIDEO_DOUBLE_BUFFER=1, every and each pageflip on the KMS/DRM backend is sinchronous. What you do inside the emulator has nothing to do.

But really, go and test Lakka with the settings I mentioned an a shader: you will see how incredibly well an emulated MSX can look.

Par Daemos

Prophet (2066)

25-08-2022, 09:14

Question is. Will lakka also do the same with openmsx. I need openmsx as right now it simply emulates what is required to be emulated. In the meanwhile, forcing vsync on via sdl instead of in openmsx cleans up the emulation even more. Can now finish hero fully.