Guest - Testers are needed for the reworked CDateTime core component. See... https://forum.kodi.tv/showthread.php?tid=378981 (September 29) x
  • 1
  • 155
  • 156
  • 157(current)
  • 158
  • 159
  • 170
RetroPlayer Test Builds (updated for Nexus)
@garbear After I have updated my main system from 20.0 to 20.1 (CoreELEC), I'm having issue with huge memory leak while trying to run PSX games (PCSX-reArmed). It is leaking like 100 MB every 2 seconds, so the whole system crashes on out-of-memory in about a minute from the game start. The game itself is running, it just dies on the OOM after a while. Reverting back to 20.0 solves the issue. I haven't noticed the same issue in other emulators, so far only in PCSX.

Any ideas?

EDIT: I've tried to check the problem on Windows just to find out, that I can't get the PCSX emulator to start at all under Windows. The log says:
Code:
info <general>: AddOnLog: game.libretro.pcsx-rearmed: Loaded CD Image: D:\Data\emulators\...
info <general>: AddOnLog: game.libretro.pcsx-rearmed: Track 01 (DATA) - Start 00:02:00, Length 61:43:13
info <general>: AddOnLog: game.libretro.pcsx-rearmed: unsupported/invalid CD image: D:\Data\emulators\...
The image is fine and the same emulator runs the same image perfectly fine in LibreELEC.
Reply
@garbear So far it seems, that I have tracked the problem down to this commit:
https://github.com/xbmc/xbmc/pull/22694/...65c0039212

It seems, that this commit breaks the PCSX emulator (causing crashes and out-of-memory problems). Currently building LibreELEC with this commit reverted to confirm that. I'll report back when I have tested it.

EDIT: So I've built a LE image with the "Add memory access and alignment" reverted and I can confirm it solves the PCSX issue:
https://github.com/KOPRajs/xbmc/commits/...ess-revert

I've had to revert more commits, but the one causing the issue seems to be the "Add memory access and alignment".

Here is what I've got in "dmesg" in LE when the issue occurs:
Code:
[   56.076937] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   56.092870] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   78.745625] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   78.759347] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   78.771813] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   78.783967] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   78.796897] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   78.810712] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   78.823998] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   78.836742] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   78.885065] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   78.897506] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   83.748884] cma_alloc: 188 callbacks suppressed
[   83.748892] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   83.769315] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   83.783639] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   83.798985] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   83.814861] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   83.830790] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   83.846920] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   83.862625] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   83.878312] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   83.894112] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   88.768383] cma_alloc: 302 callbacks suppressed
[   88.768392] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   88.784256] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   88.800669] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   88.817918] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   88.835052] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   88.851689] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   88.869180] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   88.886296] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   88.903446] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
[   88.920543] cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12

Shortly after this the Kodi crashes. In CoreELEC (with old vendor kernel) there are no such messages in dmesg, but Kodi is allocating a lot of memory and then the system dies on OOM instead. I'd say the difference in behavior is caused by different kernels used by CoreELEC and LibreELEC.
Reply
(2023-03-26, 16:56)KOPRajs Wrote: We only have tried it on Linux, no experiences with Android, sorry.

@garbear I'm really just guessing here, but let's have a look:
https://github.com/garbear/xbmc/pull/114...d731f834ea
There is a line added to cmake/treedata/linux/subdirs.txt regarding the GL shaders. Maybe the similar line is missing in cmake/treedata/android/subdirs.txt for the Android build?
Reply
@KOPRajs Depending on which SoC your running CoreElec, does Beetle PSX display similar behaviour? I normally use Beetle PSX on my N2+ running CoreElec, but haven't used it since the 20.1 update. I've used it with MegaDrive and SNES emulation and not noticed an issue though. Not that that invalidates the fact you have issues.
Reply
(2023-03-29, 12:49)OmniBlade Wrote: @KOPRajs Depending on which SoC your running CoreElec, does Beetle PSX display similar behaviour? I normally use Beetle PSX on my N2+ running CoreElec, but haven't used it since the 20.1 update. I've used it with MegaDrive and SNES emulation and not noticed an issue though. Not that that invalidates the fact you have issues.

I'll try the Beetle PSX when I get chance. I've used Mega Drive (genplus) and SNES (snes9x) without issues as well. So far only PCSX seems to be affected by the "Add memory access and alignment" commit. I was actually always using the PCSX because it is heavily optimized for ARM (especially the Neon GPU plugin). Also it was working well until now.

My HW is S922X as well (GT King Pro).
Reply
@garbear I have played with the shaders again.
I wanted to try to build LibreELEC for my ARM box with the GLES shader support and I wanted to test, whether it behaves the same, as it did when we were trying it on Wayland with Joe.

1. The build itself went fine, no errors there.
2. Then I built the game.shaders.preset addon.
3. I've found out that the path to the shaders is hardcoded as "special://xbmcbinaddons/game.shaders.preset/resources/...". It cannot be used with such path when the addon is installed from .zip (or repository). So I needed to change the hardcoded path to "special://home/addons/game.shaders.preset/resources/...". Then I got the presets to load from the XML. I've also added the actual shaders to the correct folder before.
4. But when selecting a shader preset in the Video Filter menu, I get only the nearest filter. No errors in log, everything looks good, except there is no shader being applied at all.
5. I've found out that my LibreELEC build for RK3399 is actually not using the OpenGL ES renderer directly. There is another renderer called DMA, which is a special case of the OpenGL ES render. It seems that for GBM windowing this renderer is used instead of the OpenGL ES one.
6. So I ended up adding the shader support code to the RPRendererDMA as well and (to my surprise) now I've got the shaders working on my LibreELEC box (with the same bugs and limitation as with OpenGL ES).

The code is here, if it can be of any use: https://github.com/KOPRajs/xbmc/commits/video-shaders
The 2 relevant commits are:
https://github.com/KOPRajs/xbmc/commit/0...443716301f
https://github.com/KOPRajs/xbmc/commit/3...7abb8e98c7

Again, be aware, I do not fully understand the code. I've only copied a chunk of code from the OpenGL renderer to the DMA render (the same as for the OpenGL ES).
Reply
Thanks @KOPRajs for finding the exact commit! This should be easy to fix. I was digging through the entire code diff between v20 and v20.1 in a desolate search.

The memory leak is related to "zero-copy", which the DMA renderer uses. After the problematic commit, we allocate both a DMA and GLES buffer. The DMA buffer is used and released, the but a new GLES buffer is allocated every frame and never released, sucking up memory. It's not technically a leak because the memory is tracked and freed when the game ends. I would call it a memory exhaustion bug. Fix incoming.

I'll keep playing with the GLES code you've provided. Kodi's devcon is this weekend but next week I'll have a GLES device to test with.
RetroPlayer releases: https://github.com/garbear/xbmc/releases

Donations: eigendude.eth
Reply
@garbear Have you tried the Android GLES build with the line added to cmake/treedata/android/subdirs.txt?
 
(2023-03-30, 07:27)garbear Wrote: I would call it a memory exhaustion bug. Fix incoming.

Any idea why only PCSX seems to be affected by this bug?
Reply
PCSX uses zero-copy, I'm guessing the other cores don't.
RetroPlayer releases: https://github.com/garbear/xbmc/releases

Donations: eigendude.eth
Reply
I'm 99% sure this is the feature we're implementing: RETRO_ENVIRONMENT_GET_CURRENT_SOFTWARE_FRAMEBUFFER: https://github.com/libretro/RetroArch/bl...tro.h#L967
RetroPlayer releases: https://github.com/garbear/xbmc/releases

Donations: eigendude.eth
Reply
@garbear Just to summarize what is known about the "memory" bug so far:
  1. PCSX is affected. For now I don't know about any other affected emulators.
  2. I've tested it on 2 systems. The first one is running LibreELEC and the GBM stack (it uses the RPRendererDMA). The second system is running CoreELEC and is using the direct rendering to Amlogic fbdev (this one is using the RPRendererOpenGLES).
  3. On the LibreELEC system with the RPRendererDMA I'm getting these errors in dmesg and the Kodi crashes after a few seconds:
    Code:
    cma: cma_alloc: reserved: alloc failed, req-size: 238 pages, ret: -12
  4. On the CoreELEC system with the RPRendererOpenGLES I'm seeing the memory consumption problem and there are no errors in the dmesg.
    Exactly as you've expected, when I exit the game before the system dies on OOM, the memory is released.
  5. Reverting of the "Add memory access and alignment" commit solves the issue on LibreELEC (but I haven't tested it on CoreELEC yet).
Reply
@garbear Here is what might help the GL shaders to build on the remaining platforms:
https://github.com/KOPRajs/xbmc/commit/7...da2f6c6dc6
Reply
I have a PR up to fix the memory exhaustion bug: https://github.com/xbmc/xbmc/pull/23098 . It's included in my upcoming round of test builds.

Over the weekend I got together with the GSoC students, @lrusak and @sarbes to get shaders working on OpenGL using a Macbook M1. We spent a while hunting down a bug in https://github.com/xbmc/xbmc/pull/22211 , which is in my retroplayer-shaders branch. We never got shaders to work on the M1 because no GL tracing tools supported the M1. @gusandrianos is going to try Linux when he gets home, which should still be working.
RetroPlayer releases: https://github.com/garbear/xbmc/releases

Donations: eigendude.eth
Reply
I've looked into it some more. It seems that we RP is binding the default VAO after it is done rendering, but it might fail under certain circumstances? I'm not sure.

But we should not unbind the VAO.
Reply
(2023-04-03, 20:19)garbear Wrote: I have a PR up to fix the memory exhaustion bug: 23098 (PR).

Great to hear that!

In the meantime, I've successfully built the GL shaders in LibreELEC and even in CoreELEC, because I was curious whether the ARM boxes are actually capable of using the shaders. I've tested the LibreELEC first, running on the Rockchip RK3399. With the shader support for the DMA renderer added, I've got some basic shaders working, but the performance is poor for most of the shaders. I thought that it might be caused partly by the reverse-engineered panfrost OpenGL ES 3.1 driver, so I went to try CoreELEC on Amlogic S922X with the vendor-supplied OpenGL ES 3.2 driver. However, the performance was about the same, and there are plenty of graphic bugs with the vendor OpenGL ES driver when compared to the panfrost driver in LibreELEC (even less shaders work and there is even more bugs).

So the conclusion is that the code is working (at least it can be built, and some shaders are working), but most of the ARM boxes probably are not powerful enough for most of the shaders.

The code is in this branch (https://github.com/KOPRajs/xbmc/commits/video-shaders). The commit from https://github.com/xbmc/xbmc/pull/22211 was also included in my testing builds.
Reply
  • 1
  • 155
  • 156
  • 157(current)
  • 158
  • 159
  • 170

Logout Mark Read Team Forum Stats Members Help
RetroPlayer Test Builds (updated for Nexus)16
This forum uses Lukasz Tkacz MyBB addons.