GLshim not in all images?

[makama80]

First of all ('Boring' alert!): outstanding job with the new updates. It must be lonely at the top. Kudos!

 

Then (just curious!): is there any particular reason known that the amount of memory is an issue for GLshim?

 

Then secondly: I do have an orange pi + (H3, 1 GB memory, Mali400)... according to the changelog GLShim is not in... For me it does not make sense... 

 

 

Regards,

 

Makama80

[tkaiser]

You encountered 2 bugs 1 bug and 1 good decision 

• Known problems: Mali OpenGL ES does not work on H3 boards with 2GB RAM (Orange Pi Plus 2, Orange Pi Plus 2e)
• Detection for 2GB boards catches also OPi Plus that is unaffected

Zador is already doing some investigation why this 2 GB problem happens. As soon as this is resolved an 'apt-get upgrade' should fix everything.

[makama80]

Thanks! I was already afraid of what you replied. Well... let's pray that Zador can fix the issue or that a manual workaround for the 1GB boards is possible.

 

If help is needed for documenting that, I am willing to help / participate where possible,

[tkaiser]

I would assume doing an 'apt-cache show libglshim1' points already in the right direction? 

[zador.blood.stained]

@makama80

 

If you have 1GB RAM board, you can just install it manually from repository (sudo apt-get install libglshim1) and log out or reboot after that.

Since we share the same image for 1GB and 2GB boards I decided that "better safe than sorry", because GLShim on 2GB boards = black screen (or black window) in all applications that use GLX rendering).

[zador.blood.stained]

Zador is already doing some investigation why this 2 GB problem happens. As soon as this is resolved an 'apt-get upgrade' should fix everything.

 

Thanks! I was already afraid of what you replied. Well... let's pray that Zador can fix the issue or that a manual workaround for the 1GB boards is possible.

 

Let's hope that @ssvb picks up this issue, my understanding of Mali internals is not enough to interpret the results of my tests.

[RagnerBG]

GLShim on 2GB boards = black screen (or black window) in all applications that use GLX rendering).

I don't know if it's related, but i had common behavior with OpiPC (1Gb RAM) yesterday. I use the description in the link you show me in the other topic and relink /etc/ld.so.conf.d/arm-linux-gnueabihf_GL.conf to point to directory in /usr/lib/arm-linux-gnueabihf with GLShim library and also consist a file ld.so.conf, with the path to this directory. I had the same message in Xorg0.log :

[    26.058] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/swrast_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
[    26.058] (EE) GLX: could not load software renderer
[    26.058] (II) GLX: no usable GL providers found for screen 0

but maybe it's normal since desktop can't use anything from EGL for acceleration. I had the same message - "unable to load mali_drm", when i execute glxgeard, but it loads glshim stuff and framerate is higher, as when i replace mesa library, but application screen is black. I suspect libegl1-mesa-dev and libgles2-mesa-dev i installed because mpv require it for compilation and notice they conflict with some of mali driver files. I don't know if this have something common with the problem.

 

And one question - can libglshim1 from repository be installed on Armbian Xenial Desktop, or it's for Jessie only?

[zador.blood.stained]

I don't know if it's related, but i had common behavior with OpiPC (1Gb RAM) yesterday. I use the description in the link you show me in the other topic and relink /etc/ld.so.conf.d/arm-linux-gnueabihf_GL.conf to point to directory in /usr/lib/arm-linux-gnueabihf with GLShim library and also consist a file ld.so.conf, with the path to this directory. I had the same message in Xorg0.log :

[    26.058] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/swrast_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
[    26.058] (EE) GLX: could not load software renderer
[    26.058] (II) GLX: no usable GL providers found for screen 0

Yes, I noticed these messages too. Since I don't see any actual errors like crashing apps or black screens (yet), I think it can be ignored for now.

 

I had the same message - "unable to load mali_drm", when i execute glxgeard, but it loads glshim stuff and framerate is higher, as when i replace mesa library, but application screen is black. I suspect libegl1-mesa-dev and libgles2-mesa-dev i installed because mpv require it for compilation and notice they conflict with some of mali driver files. I don't know if this have something common with the problem.

So do you have any errors/black sceens with prebuilt desktop images or not (apart from Xorg messages)?

*-mesa-dev packages install additional symlinks that may conflict with ones from Mali and GLshim, but this should be properly handled with packaged libraries.

By the way, why do you want to recompile mpv? One in Armbian repository is a latest version with OSD (tested) and subtitles (not tested but should work since OSD is working) support.

 

And one question - can libglshim1 from repository be installed on Armbian Xenial Desktop, or it's for Jessie only?

Yes, it can be installed on Xenial too, but Jessie and Xenial have different repository components for desktop packages.

[RagnerBG]

So do you have any errors/black sceens with prebuilt desktop images or not (apart from Xorg messages)?

I am downloading and burning to sd Jessie image for ONE right now and will be able to answer to this question later. For OpiPC, since you are not upload new images yet, i am building myself right now, so that's why i am asking for Xenial, because i want to switch to it for no particular reason (newer and fancy maybe ). I try to upgrade from 5.17 but this breaks my installation, which is not surprising because i made some changes, like install ralink firmware and others and decides to start in fresh.

About mpv, i remember i had some problems with earlier build-in version, maybe it's ok now, but i used to do things my way from CLI, because... i don't know - educational reasons maybe.