New Hypseus and lr-Daphne to add on Retropie-Setup

[DirtBagXon]

@darksavior said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon
Log file: https://pastebin.com/zwMLkrxi
I believe it's listing both times I ran it. Once with the preinstalled sdl2 (2.0.16 maybe?) and the 2nd time with 2.0.20.
And yes, the game runs fine at that resolution before the update.

There are no errors there, but this isn't an issue with Hypseus functionality, it's an SDL interaction with the display.

Did you try the -novsync or -opengl arguments?
Ok, sorry missed that bit - so no difference....

I am no expert on the display environment RetroPie provides in these weekly builds and how it may have changed. This is a change in the SDL interaction with the display between SDL versions. I may be able to offer a flag to overcome an issue, but I need to understand the issue first.

As this SDL release has fixed a standing issue with ActionMax, which now allows Hypseus to read pixel data from the SDL Texture on the GPU. SDL has obviously undergone more changes than the Changelog states for the Pi.

I am hoping someone may be able to offer some insight as to how the display environment and SDL 2.0.20 could have changed in RetroPie between these versions on a weekly build?

I cannot replicate the issue on a standard Rasbian Desktop release with SDL 2.0.20, and in fact I see the SDL improvements, listed above, with it in that environment....

Of course as it's a weekly build it may also be a bug in the current RetroPie build...

Thoughts...

 

[Darksavior]

@dirtbagxon Retropie doesn't support bullseye right now but I also tried their custom sdl 2.0.20 a week or so ago on it.

On 32bit bullseye lite I get the same slowdowns/desyncs as their weekly 32bit buster build with 2.0.20.
On 64bit bullseye lite the problem doesn't exist...

sdl 2.0.20 installer: https://raw.githubusercontent.com/RetroPie/RetroPie-Setup/039407c5ed012286924ea0d8b3b782974aa4fab5/scriptmodules/supplementary/sdl2.sh
The sdl2 installer included with the weekly buster build: https://pastebin.com/rMT3eDvn

[mitu]

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

I am no expert on the display environment RetroPie provides in these weekly builds and how it may have changed. This is a change in the SDL interaction with the display between SDL versions. I may be able to offer a flag to overcome an issue, but I need to understand the issue first.

The major change in the KMSDRM display driver in 2.0.20 is the ability to change resolutions, but there have been also other changes added to the driver which may have an effect. If you're running on the desktop, you are not using the KMSDRM display driver though, but the X11 one, so if there's something caused by it, you may not notice it.

[DirtBagXon]

@darksavior said in [New Hypseus and lr-Daphne to add on Retropie-Setup]

On 32bit bullseye lite I get the same slowdowns/desyncs as their weekly 32bit buster build with 2.0.20.
On 64bit bullseye lite the problem doesn't exist...

Ok, so this is smelling more like a bug in 32bit

I'll try and get the 2.0.20 libraries running on my 4.7.1 install to see if I can see what this might be.....

[DirtBagXon]

@mitu said in New Hypseus and lr-Daphne to add on Retropie-Setup:

The major change in the KMSDRM display driver in 2.0.20 is the ability to change resolutions, but there have been also other changes added to the driver which may have an effect. If you're running on the desktop, you are not using the KMSDRM display driver though, but the X11 one, so if there's something caused by it, you may not notice it.

Thanks @mitu

I am pretty certain that KMSDRM has not been an issue thus far, I have a couple of guys who run hypseus on the bleeding edge "rasbian" stuff without any X11 libraries whatsoever, and they feedback to me. They do however all run in full aarch64. Last bug report I had was in 2.0.16 which was fixed (nothing display related ), I'll try and ping them to check 2.0.20.

SDL 'should' be behaving the same in 32/64 land, the SDL calls are identical......

[DirtBagXon]

Ok, so on vanilla v4.7.1 on a Pi3 running (full 32bit) I compiled SDL 2.0.20 as above. Installed in /usr/local/lib

I patched hypseus to show the loaded SDL library version when run.

I can switch between SDL versions simply by adding /usr/local/lib to the first line of /etc/ld.so.conf.d/arm-linux-gnueabihf.conf and running sudo ldconfig

Executing: /opt/retropie/emulators/hypseus/hypseus.sh "/home/pi/RetroPie/roms/daphne/dle21.daphne"
[version] Hypseus Singe: v2.8.1-RPi - SDL(LD): 2.0.10
[console] Setting alternate home dir: /opt/retropie/emulators/hypseus

Parameters:
Executing: /opt/retropie/emulators/hypseus/hypseus.sh "/home/pi/RetroPie/roms/daphne/dle21.daphne"
[version] Hypseus Singe: v2.8.1-RPi - SDL(LD): 2.0.20
[console] Setting alternate home dir: /opt/retropie/emulators/hypseus

Using v4.7.1 default package 2.0.10 libraries, all is good.

Switching to 2.0.20, using default compile options, I see the slowdown, but ActionMax games work...

Dropping back to 2.0.10 source, with default compile options, all is good once again.

Built 2.0.10 again with compile arguments from the setup script provided, no change.

Moved to 2.0.12 source - working

Build with, and without, from this point: --enable-video-rpi --enable-video-kmsdrm --disable-video-x11 --disable-video-vulkan

Moved to 2.0.14 source - working

Couldn't get 2.0.14 to compile with these flags..

/home/pi/SDL/src/video/kmsdrm/SDL_kmsdrmvideo.c: In function 'KMSDRM_CreateWindow':
/home/pi/SDL/src/video/kmsdrm/SDL_kmsdrmvideo.c:1765:71: error: 'EGL_PLATFORM_GBM_MESA' undeclared (first use in this function)
              if ((ret = SDL_EGL_LoadLibrary(_this, NULL, egl_display, EGL_PLATFORM_GBM_MESA))) {
                                                                       ^~~~~~~~~~~~~~~~~~~~~
/home/pi/SDL/src/video/kmsdrm/SDL_kmsdrmvideo.c:1765:71: note: each undeclared identifier is reported only once for each function it appears in
make: *** [Makefile:635: build/SDL_kmsdrmvideo.lo] Error 1

From SDL 2.0.16 this issue arises - with or without compile flags

This is only occurring on 32bit, aarch64 builds and works fine on all the testbeds I could put together. I know guys running full KMSDRM on 2.0.16 in aarch64 without issue.

Between SDL 2.0.14 and 2.0.16 the most obvious culprit is:

• Added Vulkan support to the KMSDRM video driver

I tried disabling/adding various Window/Renderer SDL flags to hypseus in order to work around this. Nothing seems to work. CPU is pegged up at 80%+ so it does in fact appear like HWACCEL is failing.....

 

[mitu]

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

Ok, so on vanilla v4.7.1 on a Pi3 running (full 32bit) I compiled SDL 2.0.20 as above [...]

RetroPie doesn't use KMSDRM on a Pi3, only on the Pi4. If you used the 'installer' posted by @Darksavior previously, then this is your issue: the RPI video driver - which gives acceleration on the Pi3) - is not enabled with that.

2.0.20 has been added (yesterday) in RetroPie - just update your setup and re-test, you don't need to compile SDL manually.

[DirtBagXon]

@mitu said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

Ok, so on vanilla v4.7.1 on a Pi3 running (full 32bit) I compiled SDL 2.0.20 as above [...]

RetroPie doesn't use KMSDRM on a Pi3, only on the Pi4. If you used the 'installer' posted by @Darksavior previously, then this is your issue: the RPI video driver - which gives acceleration on the Pi3) - is not enabled with that.

I didn't run the 'installer' - I compiled manually from SDL github source.

With and without arguments in that installer script, so configure will have picked up most things.

I gave the following arguments when I compiled with them: --enable-video-rpi --enable-video-kmsdrm --disable-video-x11 --disable-video-vulkan

So what should I add for acceleration on the Pi3 ? I should note that up to 2.0.14 works fine from source.

2.0.20 has been added (yesterday) in RetroPie - just update your setup and re-test, you don't need to compile SDL manually.

If I do this, I can't test incremental changes in SDL. Up to 2.0.14 works fine. I assume that RetroPie does nothing special to SDL rather than compile time arguments ?

[mitu]

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

I assume that RetroPie does nothing special to SDL rather than compile time arguments ?

We have a few patches added so it's more than just the compile flags.

EDIT: are you sure your setup is using the KMSDRM driver ? You would need to modify the config.txt boot configuration file to enable it, it won't work out-of-the-box on a Pi3 with the RetroPie image.

[DirtBagXon]

@mitu said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

I assume that RetroPie does nothing special to SDL rather than compile time arguments ?

We have a few patches added so it's more than just the compile flags.

EDIT: are you sure your setup is using the KMSDRM driver ? You would need to modify the config.txt boot configuration file to enable it, it won't work out-of-the-box on a Pi3 with the RetroPie image.

Ok, I think I have pretty much seen that it is not necessarily related to KMSDRM, but is related to SDL version and 32bit land.

I'm not clear how to proceed on this in RetroPie.

I want to be able to configure various SDL commits from github to trace the issue, so kinda need a means to be able to do this in a controlled manner. In the method I describe above, I can just switch SDL libraries to whatever version I need to test, and back. How can I do this with RetroPie specific changes and have your local patches, and compile flags, available in those libraries easily?

I am certainly not qualified to tease through all the SDL commits to locate specific changes here.

Whether I do this on a Pi3 or Pi4 distributions seems mute at this point as they both exhibit the issue in later versions of SDL after the previous 2.0.10 package.

Edit: I have just tested SDL 2.0.20 libraries against both 32bit and 64bit Windows builds of Hypseues. And the issue isn't there. This is looking implementation specific....

 

[mitu]

@dirtbagxon If the issue appears in vanilla SDL, as you tested from 2.0.16 on, then you wouldn't necessarily need the RetroPie patches.
Regardless, the SDL tree used by RetroPIe is a clone of the main one from github.com/libsdl-org/SDL and you can find it at https://github.com/retropie/sdl. There are separate branches for each version, with the RetroPie patches applied, you can use the 2.0.20 branch and you'll get the tree used in the SDL packages we distribute with RetroPie-Setup.

[DirtBagXon]

@mitu said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon If the issue appears in vanilla SDL, as you tested from 2.0.16 on, then you wouldn't necessarily need the RetroPie patches.

Sure, I just wanted to get specific, and in-line with your previous comments, on available features that are enabled outside of those auto-detected.

Regardless, the SDL tree used by RetroPIe is a clone of the main one from github.com/libsdl-org/SDL and you can find it at https://github.com/retropie/sdl. There are separate branches for each version, with the RetroPie patches applied, you can use the 2.0.20 branch and you'll get the tree used in the SDL packages we distribute with RetroPie-Setup.

Thanks for this, I will take a look.

I am struggling to get any difference whatsoever by enabled/disabling SDL features in the Window/Renderer/Surface/Texture functions in SDL on this version. CPU utilisation just goes through the roof on 2.0.16.

Are there any other SDL2 emulators in RetroPie that stream video at this resolution and bitrate in SDL you are aware of?

I am asking around the Batocera and Recalbox devs to see if they are experiencing any issue after 2.0.16 - it is almost like hardware acceleration has just been halved in RetroPie.

Weird....

[mitu]

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

Are there any other SDL2 emulators in RetroPie that stream video at this resolution and bitrate in SDL you are aware of?

PPSSPP maybe, but also EmulationStation itself when displaying video in the gamelist - video frames are rendered via VLC and rendered to a GL texture.

[DirtBagXon]

@mitu said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

Are there any other SDL2 emulators in RetroPie that stream video at this resolution and bitrate in SDL you are aware of?

PPSSPP maybe, but also EmulationStation itself when displaying video in the gamelist - video frames are rendered via VLC and rendered to a GL texture.

But these will H.264 and using mmal or v4l/v4l2 I assume?

[mitu]

@dirtbagxon For ES, it's MMAL through libvlc or omxplayer, for PPSSPP I don't know for sure.

EDIT: Maybe give it a try also with the current SDL dev branch, just in case of a regression that might have been fixed recently, after the 2.0.20 release.

[DirtBagXon]

@mitu

Ok, so I have located the commit that causes the issue, it was from 2.0.15:

https://github.com/libsdl-org/SDL/commit/e87c7940f59db12670089a4ed79c91dfbca92b33

If I revert out this "fix" on SDL 2.0.21, i.e. HEAD of libsdl-org/SDL, it all stills works as expected.

Executing: /opt/retropie/emulators/hypseus/hypseus.sh "/home/pi/RetroPie/roms/daphne/dle21.daphne"
[version] Hypseus Singe: v2.8.1-RPi - SDL(LD): 2.0.21
[console] Setting alternate home dir: /opt/retropie/emulators/hypseus
[console] Forcing 4:3 aspect ratio.
2022-02-13 18:12:06.278 INFO  [27986] [reset_logfile@324] Version v2.8.1-RPi
2022-02-13 18:12:06.279 INFO  [27986] [reset_logfile@328] Command line: /opt/retropie/emulators/hypseus/hypseus.bin dle21 vldp -framefile /home/pi/RetroPie/roms/daphne/dle21.daphne/dle21.txt -homedir /opt/retropie/emulators/hypseus -fullscreen -volume_nonvldp 5 -min_seek_delay 600 -blank_searches -blank_skips -force_aspect_ratio 

So this detection is obviously not optimal in the the 32bit RetroPie environment. Are you guys able to offer a correction ?

I am no dev of SDL, but I see you guys have some experience on the local patches of SDL.

Wondering how to proceed on this ?

 

[mitu]

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

So this detection is obviously not optimal in the the 32bit RetroPie environment. Are you guys able to offer a correction ?

Not sure what correction could we add - the RetroPie environment is just a plain Raspbian Lite (Buster), using the default GL libraries/drivers provided by the OS. Is there any test - from one of the ones provided by SDL - that would help reproduce the bug ?

For now we rolled back the 2.0.20 upgrade (due also to https://retropie.org.uk/forum/topic/32209/), so this issue will not affect any more user for now.

[DirtBagXon]

@mitu said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

So this detection is obviously not optimal in the the 32bit RetroPie environment. Are you guys able to offer a correction ?

Not sure what correction could we add - the RetroPie environment is just a plain Raspbian Lite (Buster), using the default GL libraries/drivers provided by the OS.

Yeah, I was hoping you wouldn't say that :)

I'm not sure where to go from here. The aarch64 version works obviously with this "fix" and doesn't see the CPU utilisation or video stuttering. So maybe this is a 32bit SDL bug. I am nowhere near the pay-grade to talk to the SDL guys on this topic,

Is there any test - from one of the ones provided by SDL - that would help reproduce the bug ?

Nothing that looks relevant to me unfortunately...

For now we rolled back the 2.0.20 upgrade (due also to https://retropie.org.uk/forum/topic/32209/), so this issue will not affect any more user for now.

Ok, but I'm sure this will come up again. I guess we may just need to pull back the package at that time until RetroPie makes the jump to aarch64.

The "alternatives", one of which is full 64bit, aren't seeing the issue. The other is 32bit, but using a different drivers I believe, is stating they are not seeing the issue, but I am continuing to investigate on that side too.

Edit: From an old SDL dev - "SDL people won't do a fix for 32bit" - guess I'm screwed...... lol

 

[mitu]

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

I'm not sure where to go from here. The aarch64 version works obviously with this "fix" and doesn't see the CPU utilisation or video stuttering.

The difference between 32/64 is that there are no legacy BRCM drivers for 64bit, regardless of platform (Pi3/Pi4). I don't think it's a 32bit vs 64bit thing, more likely a legacy GLES vs Mesa (mainline) GLES driver thing.

The other is 32bit, but using a different drivers I believe, is stating they are not seeing the issue, but I am continuing to investigate on that side too.

Yes, it's the legacy Broadcom drivers vs the Mesa driver (enabled with the kms overlay). The Mesa drivers are the default in Bullseye, so that may explain why some users may not see the issue, even on 32bit.

EDIT: since the bisected commit points to changes in SDL_CreateTexture, is there a specific code path in Hypseus where this gets used and causes the issue ? I haven't checked the code, so I don't know wether there's multiple uses of SDL_CreateTexture.

[DirtBagXon]

Yes, it's the legacy Broadcom drivers vs the Mesa driver (enabled with the kms overlay). The Mesa drivers are the default in Bullseye, so that may explain why some users may not see the issue, even on 32bit.

Ok, that makes sense. See you do know more about SDL than I.

So RetroPie uses the Legacy drivers ?

Are there any public intentions on a move from this ?

EDIT: since the bisected commit points to changes in SDL_CreateTexture, is there a specific code path in Hypseus where this gets used and causes the issue ? I haven't checked the code, so I don't know wether there's multiple uses of SDL_CreateTexture.

I can explore that, but there are two pixel formats that are tied into the Daphne VLDP codebase and overlays, YUV and 8-bit.

SDL_PIXELFORMAT_YV12
SDL_PIXELFORMAT_RGBA8888

I have looked at these in the past and they appear fairly ingrained to the legacy codebase.

Fairly basic as far as pixel formats go...