"Vertex Shader Compilation Failed" - Odroid Go Advance/RK3326, Void Linux/Arch Linux aarch64

[SeongGino]

Description The sm64 program compiles fine (all done on the device via SSH), however any attempts at running it fail. With default optimization and using -GL, running the binary pauses and then drops a Segmentation Fault, which perhaps is expected since the Mali-G31 is made for GL ES applications. With a custom profile in the Makefile to use -lGLESv2 and all of its related flags, repurposed from the RaspPi 0/1 profiles, running the generated program instead drops a vertex shader compilation failed (see terminal). I acknowledge that the -lGLESv2 flags are made primarily for the aforementioned RaspPi systems and not this device, but GL ES has shown to work in other unrelated projects that run on the device. Perhaps there could be a more generic profile for Linux platforms using GL ES?

These are the flags being used (replacing the 'default PC' flags): VERSION_CFLAGS := $(VERSION_CFLAGS) -DNON_MATCHING -DAVOID_UB -DUSE_GLES BACKEND_LDFLAGS := -lGLESv2 OPT_FLAGS := -march=armv8-a+crc+simd -mtune=cortex-a35 -mcpu=cortex-a35 ... LDFLAGS := $(BITS) -march=$(TARGET_ARCH) $(OPT_FLAGS) -lm $(BACKEND_LDFLAGS) -no-pie -lpthread

Desktop (please complete the following information):

• OS: Void Linux aarch64 (also tried/reproduced on Arch Linux ARM [aarch64])
• Version: Nightly (07/09/2020)

Additional context Logs (Terminal output):

fs: writepath set to '/home/odroid/.local/share/sm64ex' fs: gamedir set to 'res' fs: mounting '/home/odroid/.local/share/sm64ex' Loading configuration from 'sm64config.txt' option: 'fullscreen', value: 'true' option: 'window_x', value: '4294967295' option: 'window_y', value: '4294967295' option: 'window_w', value: '480' option: 'window_h', value: '320' option: 'vsync', value: '1' option: 'texture_filtering', value: '1' option: 'master_volume', value: '127' option: 'music_volume', value: '127' option: 'sfx_volume', value: '127' option: 'env_volume', value: '127' option: 'key_a', value: '0026' '1000' '1103' option: 'key_b', value: '0033' '1002' '1101' option: 'key_start', value: '0039' '1006' 'ffff' option: 'key_l', value: '002a' '1009' '1104' option: 'key_r', value: '0036' '100a' '101b' option: 'key_z', value: '0025' '1007' '101a' option: 'key_cup', value: '0148' 'ffff' 'ffff' option: 'key_cdown', value: '0150' 'ffff' 'ffff' option: 'key_cleft', value: '014b' 'ffff' 'ffff' option: 'key_cright', value: '014d' 'ffff' 'ffff' option: 'key_stickup', value: '0011' 'ffff' 'ffff' option: 'key_stickdown', value: '001f' 'ffff' 'ffff' option: 'key_stickleft', value: '001e' 'ffff' 'ffff' option: 'key_stickright', value: '0020' 'ffff' 'ffff' option: 'stick_deadzone', value: '16' option: 'rumble_strength', value: '50' option: 'skip_intro', value: 'false' rk-debug mali-ver=rsx-p0-1.0 Vertex shader compilation failed

FATAL ERROR: vertex shader compilation failed (see terminal)

[fgsfdsfgs]

Interesting that it doesn't spew any compilation errors into the terminal like it should, meaning the GL implementation returns nothing in that regard, or something fails before the compilation stage. I don't own any aarch64 devices that I can test on, other than a Switch (and on that it works alright), so I can't really figure out why this happens. In the meantime, you could try using the GL_LEGACY renderer, though the chances that you have legacy GL support on that thing are pretty slim.

[SeongGino]

In the meantime, you could try using the GL_LEGACY renderer, though the chances that you have legacy GL support on that thing are pretty slim.

Tried this as well, Seg Faults when running the binary like using normal -GL without GL ES flags. But like you said, that's probably to be expected.

Of course I wasn't, and shouldn't be, expecting any immediate solutions to this since smaller/niche devices support doesn't seem to be brought up often. I'll be waiting until someone who either already has the device in question, or something similar, can provide a fix.

[SeongGino]

Small update:

After a bit of digging, I was able to discover someone who had a fork based off an older state of the repo - May 18th (c18e70f) on Master, May 20th (4e7ce3f) on Nightly. With a single modification that changes the global/default LDFLAGS's -lGL flag to -lGLESv2, the project compiles and runs perfectly fine on the target hardware. This version of the Makefile does not contain the switches that the current project uses to switch between renderer APIs.

So, that works, but uses older code. The alternative for using sm64ex directly is to build for GL and run in conjunction with gl4es - this works, but decals like the decorations on Peach's Castle, or the doors in the main hall, flicker like mad almost like a bad emulation, so it still isn't preferable. For the moment, I'll be using the old release build to play, but I'm hoping this'll help others with the hardware listed in the issue title as a workaround, or provide any sort of clues for those working on the current project here.

Sidenote: now that I'm seeing this run on the hardware, I'm kinda wishing there was an option for text/HUD element filtering. Sharp text doesn't downscale perfectly to 320p.

QUICK EDIT: Built the nightly branch in the alt. repo in question, where some of the additions were support for GL Legacy rendering using a switch to enable the option or not. Builds fine with defaults, runs fine as in previously detailed master branch. So the 'breaking' change is sometime after GL-legacy support, but not directly caused by it.

[SeongGino]

And this is the part where I congratulate myself for being dumb, and apologize for effectively wasting everyone's time.

So, when I made this issue, I thought for sure I was using only the needed flags for GL ES support. Clearly, I was wrong and overcomplicated things at that time, because when I decided to try again tonight with a different set of Makefile modifications, it built and ran just fine. No gl4es, no segfaults, nothing - it just worked.

Just to make sure, I'll be pasting the relevant global variables that are changed, without any specific target hardware being specified when calling make:

60) RENDER_API ?= GL
...
187) # Default build is for PC now
188) VERSION_CFLAGS := $(VERSION_CFLAGS) -DNON_MATCHING -DAVOID_UB -DUSE_GLES
...
349) OPT_FLAGS := -march=armv8-a+crc+simd -mtune=cortex-a35 -mcpu=cortex-a35 -O3
...
504)  else
505)    BACKEND_LDFLAGS += -lGLESv2
506)  endif
...
629) LDFLAGS := $(BITS) -march=$(TARGET_ARCH) $(OPT_FLAGS) -lm $(BACKEND_LDFLAGS) -no-pie -lpthread

Anyways, leaving this up for those who plan to build for OGA; ignore everything else I said in this thread. Closing...