+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: Game support (https://forum.kodi.tv/forumdisplay.php?fid=292)
+--- Thread: RetroPlayer Test Builds (updated for Nexus) (/showthread.php?tid=173361)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-03-26
@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\...RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-03-27
@garbear So far it seems, that I have tracked the problem down to this commit:
https://github.com/xbmc/xbmc/pull/22694/commits/388c0287545a2af6e4462c0dcf6f4665c0039212
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/memory-access-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: -12Shortly 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.
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-03-28
(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/commits/f26aa570bee15956f7b651ed095889d731f834ea
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?
RE: RetroPlayer Test Builds (updated for Nexus) - OmniBlade - 2023-03-29
@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.
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-03-29
(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).
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-03-29
@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/0de9e78bd83e4efc196f08db1c53a6443716301f
https://github.com/KOPRajs/xbmc/commit/3f233163de2990bc5c186e42daf6b87abb8e98c7
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).
RE: RetroPlayer Test Builds (updated for Nexus) - garbear - 2023-03-30
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.
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-03-30
@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?
RE: RetroPlayer Test Builds (updated for Nexus) - garbear - 2023-03-30
PCSX uses zero-copy, I'm guessing the other cores don't.
RE: RetroPlayer Test Builds (updated for Nexus) - garbear - 2023-03-30
I'm 99% sure this is the feature we're implementing: RETRO_ENVIRONMENT_GET_CURRENT_SOFTWARE_FRAMEBUFFER: https://github.com/libretro/RetroArch/blob/master/libretro-common/include/libretro.h#L967
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-03-30
@garbear Just to summarize what is known about the "memory" bug so far:
- PCSX is affected. For now I don't know about any other affected emulators.
- 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).
- 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 - 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.
- Reverting of the "Add memory access and alignment" commit solves the issue on LibreELEC (but I haven't tested it on CoreELEC yet).
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-03-30
@garbear Here is what might help the GL shaders to build on the remaining platforms:
https://github.com/KOPRajs/xbmc/commit/75131280a7cc0f94da1c362f2b7f6eda2f6c6dc6
RE: RetroPlayer Test Builds (updated for Nexus) - garbear - 2023-04-03
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.
RE: RetroPlayer Test Builds (updated for Nexus) - sarbes - 2023-04-03
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.
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-04-03
(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.