FWGS / xash3d

DEPRECATED in favor of https://github.com/FWGS/xash3d-fwgs. Only bugfixes are accepted.
https://xash.su
GNU General Public License v3.0
551 stars 109 forks source link

GLES / nanogl issues #349

Open kpek opened 6 years ago

kpek commented 6 years ago

Hello,

I am trying to run the xash3d engine on 2 different devices :

  1. Chinese box X96mini using s905w chip - for our scenario its the same as s905x ( Mali 450 GPU )
  2. Asus Tinkerboard using rk3288 chip ( Mali T760 MP4 GPU )

In both cases i made sure that the GLES acceleration works - es2gears giving results as expected.

When i compile without the XASH_GLES flag and XASH_NANOGL flag, the engine runs fine, but only in software rendering mode - I get about 4 FPS on S905w and about 5-6 FPS on RK3288

If i compile with XASH_GLES - i get error popup during startup of the engine "undefined symbol nanoGL_GetProcAdress" and engine never starts. If ill add XASH_NANOGL to compile flags, it makes no difference. I do have the latest nanogl repo cloned inside xash3d/engine folder. i also tried the "hardfloat" branch, makes no difference.

I also tried running with gl4es library from https://github.com/ptitSeb/gl4es :

  1. if the xash3d is compiled without XASH_GLES, i get output from the gl4es that it has been loaded and looks promising, but itthrows Segmentation fault right after that, before initializing the engine or showing any window. I expect this to be problem on gl4es side anyway, so this is just an info for anyone trying to run with gl4es.
  2. if xash3d is compiled with XASH_GLES and / or with XASH_NANOGL, i get the same error as mentioned above : "undefined symbol nanoGL_GetProcAdress", and theres no output in console from gl4es whatsoever before i see this error.

Also tried to compile / install latest SDL2 library from scratch, and enabled opengl during build, this made no difference.

Iam running armhf debian on both boxes ( armbian on s905w, tinkeros on tinkerboard which is based on debian).

Iam currently at work, so i cannot provide more details at the moment. If anything else is needed i can provide more info in evening.

a1batross commented 6 years ago

I have not tested this configuration for a while. @mittorn maybe knows more about it.

I have added XASH_NANOGL flag support for CMake in latest commit, it should work now, if you have rebuilt SDL2 with GLES support. (Ubuntu on x86 don't have it)

mittorn commented 6 years ago

SDL2 must be built without opengl support, otherwise it trying to initialize glx extensions and failing.

mittorn commented 6 years ago

https://github.com/FWGS/xash3d/blob/master/ports/RENDERERS.md

kpek commented 6 years ago

Good news, it works ! ;)

There are still problems caused by SDL2 though. I recompiled SDL2 multiple times with --disable-video-opengl and --enable-video-opengles but the opengl was still enabled and SDL always used it instead of GLES. Also i tried many combinations of config options, basically disabling all other video modes and leaving only opengles, but opengl was still being built and used as primary renderer.

So the way it worked at the end was to run the engine with following command, forcing to use the gles library (libGLES is just a link to libmali.so in my case) : SDL_VIDEO_GL_DRIVER=/path/to/libGLES.so ./xash3d

I didnt have much time to test it more in depth, but on TinkerBoard (Mali T760MP4) I get 20-40 FPS in 1920x1080 resolution which is pretty impressive, and thats running in windowed mode on top of X11. I believe if ill manage to run it directly from console using just SDL in fullscreen, it would be even faster.

Ill do some more tests tomorrow with the second chinese box using Mali 450 and maybe also test even RPi3 , i have it laying around somewhere.

Thanks !

mittorn commented 6 years ago

most drivers requires to use EGL_DEFAULT_DISPLAY to run in console. Mali400 have separate driver builds for x11 and console, and second always use EGL_DEFAULT_DISPLAY and does not work with x11 applications. I think, sdl should be built without x11 to do this, but not sure if it will work out-of-box.

a1batross commented 6 years ago

I have encountered a bug on Ubuntu 17.10.

There was a package named for Mesa, which had create an important file "libGLESv1_CM.so". They have removed it and said that libglapi-mesa will provide it. And... no, it don't have create it.

So on Ubuntu x86_64 17.10 there is a workaround: SDL_VIDEO_GL_DRIVER=/usr/lib/i386-linux-gnu/libGL.so xash3d

Link to bug:https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1749766

HelloOO7 commented 6 years ago

Hey, I'm trying to get Xash to run on a RPi 3 and I'm having issues similar to OP's. I've compiled SDL2 with:

./configure --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-opengl --enable-video-opengles

and Xash3D with

cmake -DXASH_NANOGL=yes -DXASH_GLES=yes -DXASH_VGUI=no ..

and used

SDL_VIDEO_GL_DRIVER=/usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 xash3d

with no luck of getting more than 7spf ingame. There is no performance difference when using nanogl and when not (compiling vanilla). Using GLshim had no impact on the performance either.

Any idea of what's going on?

nekonomicon commented 6 years ago

@HelloOO7, May be bad drivers? Try 64-bit build.

Mr0maks commented 6 years ago

@nekonomicon, 64 бита ему долго придётся собирать

a1batross commented 6 years ago

@HelloOO7

At first, your RPi3 should support full OpenGL natively.

At second, check GL_RENDERER string by entering r_info in console. It may be possible, that you somehow using the software rendering in Mesa.

HelloOO7 commented 6 years ago

@a1batross

I am aware that RPi supports GL, which is also most possibly the reason why it worked without nanogl. As I stated before, the performance was identical. The gl_renderer is "Gallium 0.4 on llvmpipe" btw, which various sources say is software renderer (bad). Also, I used hl.so and client.so from ptitSeb's versions of hlsdk and XashXT, for there were none after I compiled this Xash and I'm too dumb to compile XashXT without a Makefile. I hope that can't do any harm..?

a1batross commented 6 years ago

No. HLSDK isn't a problem here.

May be there is a problem with your SDL2 build. Try to use SDL2 from your Linux distibution and don't compile it by yourself.

mittorn commented 6 years ago

a1batross, it supports opengl only on experimental mesa driver with mainline kernel

HelloOO7 commented 6 years ago

@a1batross

So I got it to work with VideoCore 4 HW renderer shown in r_info using the Retropie libSDL 2.0.8. However, I can't get past the menu as the game turns into an ugly mess of corrupted segments of something (even the console) and gets back to normal only when paused. Also, the game only works without Xserver with the GL driver disabled. When used with X on, it "falls back to dedicated mode" and with the GL driver it never starts.

mittorn commented 6 years ago

It is not engine issue. RPI does not have x11 egl support. Try something like https://github.com/kika123/x11eglrpi to workaround it. But it seems only work in fullscreen. Use only nanogl wrapper, do not add glshim, it may break rendering. try set r_vbo to 0, if renderer still not work correctly. Also there is open-source mesa driver, it supports full opengl with x11. Even indirect renderer: https://github.com/anholt/mesa/wiki

HelloOO7 commented 6 years ago

@mittorn

It works... kinda. Even though I installed x11eglrpi, it still fallbacks to dedicated mode in X. That doesn't really bother me though, because I'm using CLI and/or EmulationStation for launching everything most of the time. Turns out that the corrupted graphics were probably fixed with x11eglrpi and the config edits required for it OR by the fact that I temporarily used a shady 1998 pirated version of HL before I got home and copied over my Steam one. Anyway, the only issues rn are:

  1. Turning on flashlight drops the FPS to ~10FPS. This is probably the RPi's problem.
  2. There's no ammo/shots/weapon particles/bullet holes rendered. Might be a problem of either the Pi or the ptitSeb client.so and hl.so, although I don't know if those libs handle these.
  3. Explosions drop some frames. RPi again, most possibly.

P.S.: What does r_vbo 0 do? I don't seem to be able to find more than a few mentions in a russian discussion about Xash iOS beta.

P.P.S.: How can I compile up-to-date client.so and hl.so?

nekonomicon commented 6 years ago

Turning on flashlight drops the FPS to ~10FPS. This is probably the RPi's problem.

Explosions drop some frames. RPi again, most possibly.

Set r_vbo_dlightmode 1

There's no ammo/shots/weapon particles/bullet holes rendered. Might be a problem of either the Pi or the ptitSeb client.so and hl.so, although I don't know if those libs handle these.

XashXT does not have weapon prediction support. Set cl_lw 0. But I recommend to use client and server from hlsdk-xash3d repo. Source code from ptitSeb's repos already deprecated.

P.S.: What does r_vbo 0 do? I don't seem to be able to find more than a few mentions in a russian discussion about Xash iOS beta.

VBO provides good optimization on some graphic cards.

P.P.S.: How can I compile up-to-date client.so and hl.so?

https://github.com/FWGS/xash3d/wiki/Building-and-running#microndk

HelloOO7 commented 6 years ago

Thanks, everything is up and running now!

HelloOO7 commented 6 years ago

Hey, I'm back again, tried compiling using the same steps on a clean install and not everything's working as before. The menu runs fine, but when I open the console, the text turns into a perpetually repeating mess. When I go in-game, it consistently keeps repeating the loading screen texture and everything is garbled (no 3D rendered). Pausing gets me a working menu. Strangely, when I change the resolution to something lower than my monitor's highest res, the console returns back to normal (game still does not work). I remember having the same problem a few comments ago here and I fixed it by using different HL and x11eglrpi. I have the exact same config as before, including those, but it didn't fix anything this time. Can make pics if needed. Thoughts?