-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't Compile on Amlogic s905 after last commits #10626
Comments
What if you add here: ppsspp/SDL/SDLGLGraphicsContext.cpp Line 8 in 99386da
The following: #if defined(USING_EGL)
#include "EGL/egl.h"
#endif -[Unknown] |
Thanks for the reply but unfortunately I get the same error :( |
after trying one by one, last compiling Commit is c27d64f but it won't work on the device itself, it just shows a black screen. |
Any idea on how can I fix this? |
From that it sounds like the Vulkan changes brought this on. But this error:
Really should be solved by including EGL.h in that c file. If that's not helping, I'm a bit perplexed. -[Unknown] |
Thank you for the reply, Is there a way to pass an option to skip vulkan, for systems that don't support it? I am going to compile each commit and see exactly where the error started showing. |
Thanks @suzuke I will try that and report back :) |
Unfortunately it didn't work :( that commit compiles fine with or without the patch, but it does not work on the device itself (SDL_CreateWindow failed: Could not initialize OpenGL / GLES library I think using -DNO_VULKAN has the same effect, but the main problem is I am not sure why its not finding egl.h. This is the info I have gathered: The SDL create window error starts on this commit: e3eb6d3 It seems to me (but I could be very wrong) like the commits to fix Raspberry Pi GLES2 compilation broke other devices, since the egl.h problems seem to start around those commits, unfortunately this is something out of my league to even debug much less even for me to confirm :( Last good commit that I tried and worked on the S905 is this one 9a732fe Thanks for all the help. |
EGL_Init is a function defined in SDLMain.cpp |
Oh, oops, I assumed it was actual EGL without thinking. In that case, we should really just move Disabling Vulkan on all arm64 devices is not a good idea, since it works quite well on Android arm64 devices. Anyway, the SDL create window issue may be a problem with the driver when requesting a specific version - try replacing this line: for (size_t i = 0; i < ARRAY_SIZE(attemptVersions); ++i) { With: if (false) { Does it work again (this is just a hack), or does it still error? -[Unknown] |
There is not only EGL_Init() but also g_eglDisplay, g_eglSurface, eglSwapBuffers, EGL_Close() all has the same issue. |
@unknownbrackets unfortunately that didn't work, there is no error on EGL_Init() anymore but as @suzuke said, there is still errors on the others. Also the change for the SDL window didn't work :( |
I managed to move forward on this a bit by adding this:
but now I get this error:
|
Got it to compile with @suzuke 's no vulkan patch (we really don't need it in this device) but now just need to figure out the SDL window creation error. I think this might work, replacing from line ppsspp/SDL/SDLGLGraphicsContext.cpp Line 26 in 7ef749b
ppsspp/SDL/SDLGLGraphicsContext.cpp Line 62 in 7ef749b
But I really have no idea what I am doing! so if someone can tell me if this would work and not break anything else I would appreciate it :) I will post the full patch when I figure this out. EDIT: it kinda worked, now I don't get an error, but I only get sound and no video :( SDL_CreateWindow failed: mali-fbdev: Can't create EGL window surface |
@unknownbrackets sorry to be a bother on this, but have you had any time to check this at all? I've been trying so many ways, but the best I could do is get audio with no video, my experience on this is practically null so I am just doing trial and error. It would be great if you could give me more pointers as to how to move forward to fix this. Thank you! |
I googled around a bit - is your user in the "video" group? -[Unknown] |
User is always root, LE only has one user. |
@shantigilbert
Do you mean that built and ran okay? I've been trying #10534 to build PPSSPP since last year on an S905x and the best I managed was built, but with a black screen at runtime, and no error messages (sound and gamepad working in the background though). I just checked out that commit and unfortunately that too had the black screen. |
@hissingshark The last commit that works for me is this one 9a732fe Not sure what you are using as OS, I am using LibreElec, but to make it work I need to set the color depth to 16 so that it will run. I use (for 1080p) then you can run PPSSPP, if I run it without chaining depth all I get is sound. But after the changes to SDLGLGraphicsContext.cpp nothing I've tried seems to work anymore. |
@shantigilbert Well that's most enlightening, thank you! With that setting my I wish I'd know about this last year. Because now I can see how badly it's running on my box and I needn't have spent so many nights on it! I've tried downgrading as many setting as I can but can't quite get it playable. Tested GTA and the Burnout games so far. I'll try a bit more tweaking, but I think it's just beyond the SOC, which is understandable (don't know until you try). Having said that, you must have found it acceptable or you wouldn't be trying to build from master? My OS is OSMC on their Vero4k. It would run better I'm sure if I was running 64-bit as it's aarch64/armv8-a, but unfortunately our userland is 32. I see from the 1st post that you were tricking it into building for armv7 too. I can build most of it 64, but at the final linking stage I get:
I assume the video drivers are pre-compiled as 32bit and I can't work around that as the sources aren't available. |
Not sure about GTA, but the games I play on it run at 30+fps without a
problem, which make them very playable To test, try running Ultimate Ghosts 'n Goblins and if it's below 30 fps then it has to be something on the OS you are using (or probably the settings?)
These are the options I used to build and older version for 64bit
"-DUSING_FBDEV=1 \
-DUSING_GLES2=1 \
-DUSE_FFMPEG=1 \
-DARM64=1 \
-DSHARED_LIBZIP=1 \
-DARM_NEON=1"
but I didn't find any performance advantages so I never tried it again.
|
@hissingshark found some useful issues in #10534 which are probably related. There was a mistake in the way GL versions were being attempted. See #11144. I think there's more information in that other issue (which is older than this one) at this point, so I'm going to close this as a duplicate. If I'm wrong, feel free to comment and I'll reopen. -[Unknown] |
@unknownbrackets Thanks, although that fixed the SDL window error, when I run it there is still only a black screen with audio. (but you also mentioned that in the other issue) Also I still had to add this to make it compile
Otherwise I would get the same errors as the first post. |
What happens? Compile ends in error
Using these options PPSSPP used to compile with no problem
But now I get this error
Last commit I was using was 5eba689 so a lot has changed since then, do I need to change my compiler options?
What should happen? Finish Compiling
What hardware and operating system are you running PPSSPP on? GPU might matter if it's a graphical issue. Amlogic S905 using Libreelec
The text was updated successfully, but these errors were encountered: