Problem compiling for GLES for Amlogic devices / missing textures

[shantigilbert]

Please Note: This form is the minimum required information for submitting bugs.
Removing this form may lead to your issue being closed until it is completed.

Platform / OS / Hardware: EmuELEC on Amlogic s905(x), Odroid N2, VIM3, etc

Github hash: 34575d577cb1284ef4b56be87ba660a0c53159f8

Hardware: Amlogic using MALI G52, G31, 450

Description of the Issue Trying to cross-compile for my device, I tried using armv7h-neon, odroidc1(or ordroidc2 adding my own platform) as my platform and I get this error:

/mnt/build.EmuELEC-Amlogic-ng.arm-3.5/flycastsa-34575d577cb1284ef4b56be87ba660a0c53159f8/shell/linux/../../core/wsi/egl.cpp:153:4: error: 'load_gles_symbols' was not declared in this scope
    load_gles_symbols();
    ^~~~~~~~~~~~~~~~~
/mnt/build.EmuELEC-Amlogic-ng.arm-3.5/flycastsa-34575d577cb1284ef4b56be87ba660a0c53159f8/shell/linux/../../core/wsi/egl.cpp:165:3: error: 'load_gles_symbols' was not declared in this scope
   load_gles_symbols();
   ^~~~~~~~~~~~~~~~~

when I use platform odroidxu3 it compiles and it runs but its missing a bunch of textures. I assume there is something missing when not using the -DGLES3 that xu3 is using because if I remove it then the compilation error appears.

EDIT: there is a typo (I think?) on sdl.h line 29 says #ifndef GLES2 change it to #ifndef GLES3 and now it compiles with platform=odroidc1 USE_SDL=1 but the program does not run

:00:642 linux/common.cpp:103 E[COMMON]: SIGSEGV @ 0 -> (nil) was not in vram, dynacode:0
00:00:643 rend/gui.cpp:1867 E[COMMON]: Fatal error : segfault
 in fault_handler -> /mnt/build.EmuELEC-Amlogic-ng.arm-3.5/flycastsa-34575d577cb1284ef4b56be87ba660a0c53159f8/shell/linux/../../core/linux/common.cpp : 104

However if I instead just add #include "gl32funcs.h" to sdl.cpp directly the program runs but the missing textures are the same as if I use platform=odroidxu3, should I open a new issue?

Here is a small video that shows the missing textures (sorry for the quality) https://youtu.be/RtTXnCTqWl4

[flyinghead]

This should help with the build error: https://github.com/flyinghead/flycast/commit/b907aa2d981a6fe558ba4a83d02585fe048899a8 The #ifndef in sdl.h is correct. When GLES2 is defined, there's no dynamic loading of GL/GLES functions, which is done in gl32funcs.h/c.

Not sure why most textures are missing however.

[shantigilbert]

Thanks, that fixed the compilation! :)

Unfortunately textures are still missing, is there anything else I can do to help figure that one out?

[flyinghead]

Looking at the video it seems the actual geometry is missing, not only the texture. But then, I have no idea what causes this.

Have you tried playing with the video settings to see if they change anything? Any hint would be helpful.

[shantigilbert]

Sure I can test that, any suggestions on what to change? also, is there a menu I can do these changes from, or do I have to edit the emu.cfg directly ?

[flyinghead]

pressing tab or select should open the menu then choose Settings. Try disabling shadows, fog, clipping. Also rendering at 0.5 downscale.

[shantigilbert]

sorry for the delay

it seems I am out f luck, nothing I do seems to even do any difference, I disabled shadows, fog and clipping, still the same missing textures/geometry.

Anything other than rendering at 1 (native) does not load the game.

Maybe this is something on the Mali-G31/Mali G52 drivers?

[shantigilbert]

I actually just tried it on an older device with Mali 450, and it displays correctly, so it has to be something with the newer drivers.

[flyinghead]

Fwiw I have a test device with a Mali-G51 running Android and no issue with GLES.

But I had issues with Vulkan which were fixed by upgrading the drivers.

[shantigilbert]

I am starting to think this might be the same issue that is causing PPSSPP to not display some geometry, just like this, on the exact same GPUs, it seems that maybe the 32bit version of the mali drivers for these GPUS are broken.

Anyways thanks for all the help, and I guess this is not Flycast at fault, so do you want me to close this issue?

[flyinghead]

No problem. This issue can stay open until there is a fix for it

[shantigilbert]

I am trying to do some more testing now on aarch64 see if the problem is the same but for some reason I cannot compile it for aarch64, what are the correct parameters to do this?

this is what I am using USE_SDL=1 USE_GLES=1 platform=arm64

but I always get

In file included from /mnt/SSD/flycastsa-125c1ff37d005809a18086cf60f5418e23caa9d4/shell/linux/../../core/khronos/EGL/egl.h:36,
                 from /mnt/SSD/flycastsa-125c1ff37d005809a18086cf60f5418e23caa9d4/shell/linux/../../core/wsi/gl32funcs.c:21:
/mnt/SSD/flycastsa-125c1ff37d005809a18086cf60f5418e23caa9d4/shell/linux/../../core/khronos/EGL/eglplatform.h:99:10: fatal error: X11/Xlib.h: No such file or directory
 #include <X11/Xlib.h>
          ^~~~~~~~~~~~

followed by a few other errors:

/shell/linux/../../core/hw/sh4/dyna/../sh4_if.h:355:29: error: can't convert value to a vector
 #define Sh4cntx (sh4rcb.cntx)

I am cross compiling and I do not have x11 but I can seem to compile fine for ARM but not for ARM64, am I missing something?

[flyinghead]

Sorry for the delay. Did you get this sorted out?

It looks like the included core/khronos/eglplatform.honly supports X11 on linux. Can you tweak the include path to use the system egl.h instead?

[shantigilbert]

No problem, and thanks! it seems including eglplatform.h from my toolchain worked with the x11 file as I no longer get the error.

But the others are still present

/shell/linux/../../core/hw/sh4/dyna/../sh4_if.h:355:29: error: can't convert value to a vector
 #define Sh4cntx (sh4rcb.cntx)

In file included from /mnt//build.EmuELEC-Amlogic-ng.aarch64-3.8/flycastsa-125c1ff37d005809a18086cf60f5418e23caa9d4/shell/linux/../../core/deps/xxHash/xxh3.h:81,
                 from /mnt//build.EmuELEC-Amlogic-ng.aarch64-3.8/flycastsa-125c1ff37d005809a18086cf60f5418e23caa9d4/shell/linux/../../core/deps/xxHash/xxhash.h:1930,
                 from /mnt//build.EmuELEC-Amlogic-ng.aarch64-3.8/flycastsa-125c1ff37d005809a18086cf60f5418e23caa9d4/shell/linux/../../core/hw/sh4/dyna/driver.cpp:24:
/mnt//build.EmuELEC-Amlogic-ng.aarch64-3.8/toolchain/lib/gcc/aarch64-libreelec-linux-gnueabi/8.3.0/include/arm_neon.h:24882:40: error: expected primary-expression before 'tab'
 vqtbx4q_p8 (poly8x16_t r, poly8x16x4_t tab, uint8x16_t idx)
                                        ^~~
/mnt//build.EmuELEC-Amlogic-ng.aarch64-3.8/toolchain/lib/gcc/aarch64-libreelec-linux-gnueabi/8.3.0/include/arm_neon.h:24882:56: error: expected primary-expression before 'idx'
 vqtbx4q_p8 (poly8x16_t r, poly8x16x4_t tab, uint8x16_t idx)
                                                        ^~~
/mnt//build.EmuELEC-Amlogic-ng.aarch64-3.8/toolchain/lib/gcc/aarch64-libreelec-linux-gnueabi/8.3.0/include/arm_neon.h:24882:59: error: expression list treated as compound expression in initializer [-fpermissive]
 vqtbx4q_p8 (poly8x16_t r, poly8x16x4_t tab, uint8x16_t idx)

Shouldn't neon be disabled for aarch64?

[shantigilbert]

Also since I forgot to mention it, I am using the Makefile in shell/linux directly since I cannot find a way to use GLES with cmake...

[flyinghead]

neon shouldn't be needed for aarch64.

And use shell/linux/Makefile for now as cmake support is still being worked on.

[shantigilbert]

neon shouldn't be needed for aarch64.

And use shell/linux/Makefile for now as cmake support is still being worked on.

Problem is, I can't seem to find where or why neon is being enabled?

These are my changes

# Generic 64 bit ARM (armv8) Linux
else ifneq (,$(findstring arm64,$(platform)))
    NOT_ARM := 1
ifndef USE_SDL
    USE_X11 := 1
endif
    USE_SDL := 1
    USE_GLES := 1
    ARM64_REC := 1
    ISARM64 := 1
    CFLAGS += -DGLES3
    CFLAGS += -D TARGET_LINUX_ARMv8 -fno-builtin-sqrtf
    CXXFLAGS += -fexceptions
    INCS += -I$SYSROOT_PREFIX/usr/include/
    LIBS += -L$SYSROOT_PREFIX/usr/lib -lEGL -lGLESv3

[flyinghead]

xxhash uses:

#  elif defined(__ARM_NEON__) || defined(__ARM_NEON)
#    define inline __inline__  /* clang bug */
#    include <arm_neon.h>

[shantigilbert]

adding

#undef __ARM_NEON__
#undef __ARM_NEON

at the top of the xxh3.h did the trick :)

Unfortunately even on aarch64 its the same issue with geometry :( on an Odroid N2+

Anyways, thanks for the help!

Edit: If its of any help, in Crazy Taxi when I pause the game, the image renders fully, as soon as I unpause it the geometry gets lost again...

[flyinghead]

When pausing, Crazy Taxi does a rendering of the scene to a texture, then uses this texture as background and draws the pause menu on top of it. It looks like an issue related to texture not being updated or being messed up.

You might want to change the DEBUG_LOG in BaseTextureCacheData::PrintTextureName() to NOTICE_LOG to check if and when textures are updated, and you can compare with a run on a desktop. But I don't know why this wouldn't work on odroid n2+.

[shantigilbert]

Thanks, I did the change and I can see the information, unfortunately I don't have a desktop version to compare to, but I'll see what I can do.

Thanks again!

[shantigilbert]

Just to add more information about this, it seems it only happens when using FBDEV, using DRM/kms/gbm it works fine.

[shantigilbert]

@flyinghead So I took a few hours trying to bisect this.

After commit: c3b958c5218ba651dc23d6fdd131270d3e6cdeed I can no longer run Flycast (it compiles fine), as I get all sorts or errors mostly

evdev: Opened device 'HORI CO.,LTD. HORIPAD S' using default mapping 'Generic Controller'
Info: EGL version 1.4
EGL config: 0x3610f40, 0x35b15b8, 0x35a51e0 1920x1080
SIGSEGV @ 0 -> (nil) was not in vram, dynacode:0
Fatal error : segfault
 in fault_handler -> /mnt/SSD/build.EmuELEC-Amlogic-ng.arm-3.8/flycastsa-b1bb89909e82d8a65e9a2054835162662f7621fa/shell/linux/../../core/linux/common.cpp : 107 

Trace/breakpoint trap

and

00:00:985 rend/gui.cpp:1787 E[COMMON]: Verify Failed  : glIsProgram(program)
 in gl_CompileAndLink -> /mnt/SSD/build.EmuELEC-Amlogic-ng.arm-3.8/flycastsa-8ada1d5320da772c1e0aefa6dc3ed28053a1b0c6/shell/linux/../../core/rend/gles/gles.cpp : 597 

but those errors do not matter, because when I get to this commit: 5b1d09377809744fe56130e824f5f73b958b7bd6 I can run it again but the missing geometry/texttures issue is now present, so the issue is between those 2 commits, I know it might not be of any help, as they are many changes between those 2, but maybe since you know what to look for it might help .

https://github.com/flyinghead/flycast/compare/c3b958c5218ba651dc23d6fdd131270d3e6cdeed...flyinghead:5b1d09377809744fe56130e824f5f73b958b7bd6

Note that commit c3b958c5218ba651dc23d6fdd131270d3e6cdeed (and before) Flycast works perfectly fine on the same hardware, so at least it might help to illustrate that this used to work before.

Edit: I just realized you gave me a fix a few comments back for the first error, so I might get back a second time with the fix you provided to see if I can pinpoint the exact moment the geometry gets lost.

edit2: nvm I can't find another working commit :(

[shantigilbert]

opps hit the wrong button :P

[flyinghead]

Thanks for these details. Unfortunately there's quite a few changes between those two points.

Something to try: disable mipmaps by adding this to emu.cfg.

[config]
rend.UseMipmaps = no

Another big change during that time is the Vulkan renderer, which necessitated some changes in GL as well. But it's much harder to find out which of these changes could be the culprit.

[shantigilbert]

Thanks, I've tried all the settings changes so I am sure it's not related to that, unfortunately.

Oh well I guess the libretro core is the only option for us stuck with fbdev.

On Tue, Aug 25, 2020, 5:42 AM flyinghead notifications@github.com wrote:

Thanks for these details. Unfortunately there's quite a few changes between those two points.

Something to try: disable mipmaps by adding this to emu.cfg.

[config] rend.UseMipmaps = no

Another big change during that time is the Vulkan renderer, which necessitated some changes in GL as well. But it's much harder to find out which of these changes could be the culprit.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/flyinghead/flycast/issues/91#issuecomment-679948276, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOFQEQGUEPIHD7TL2SUQ3TSCOISBANCNFSM4M4PSGMA .

[shantigilbert]

thanks for the help @flyinghead I will close this issue now :)