Update to OpenGL 2.1

[RudderDuck]

I'm a very happy PinebookPro user. I'm more used to the Raspberry Pi family but trying to get familiar with this Pine product.

When starting an application that I installed using the package manager it says that it requires OpenGL 2.1 to run and tells me 'try updating your drivers'.

Code:

glxinfo | grep "OpenGL version"

Gives me:

OpenGL version string: 2.0 gl4es wrapper 1.1.1

Is there a possibility to upgrade to 2.1?

[ab1jx]

Looking through the specs now that I've had one on order a few weeks the situation looks grim for OpenGL ES at present.  Which will make the 3rd Mali computer I've got in that situation.  I'm not into games but I was hoping for fast screen updates run by the GPU for an SDR program, doing the waterfall as a rotating texture that scrolls down without CPU involvement is what I'm looking for.  Maybe I can do it in OpenCL since it's very SIMDish, I've done it with memcpys but it's a significant CPU load.

Midgard family Mali, it's probably worth looking at Panfrost: https://panfrost.freedesktop.org/

The problem, at least with my Rock64 and Odroid N2 is a lack of driver software and technical information, mostly from ARM I gather, partly because they don't want to divulge trade secrets and because the drivers are expensive to write.  Or maybe you can blame it on Rockchip, but these chips with wonderful capabilities are hitting the streets without drivers except maybe Java-ish ones in cell phones because they sell millions of those.  I'm now building a recent llvm from sources so I can build Panfrost from sources because my Rock64 only does software OpenGL ES so far.  And Panfrost wants a 5.2 kernel with probably some custom stuff in it.  (Enable CONFIG_DRM_PANFROST which has to exist before it can be enabled.).  But it could be worse, the latest Malis are more of a dead-end right now for open source.  Panfrost is all(?) written by reverse engineering, which is a slow process, but Midgard Malis have been around a few years.

And look at Vulkan, that's implemented https://en.wikipedia.org/wiki/Vulkan_(API)

[pjsf]

I'm a very happy PinebookPro user. I'm more used to the Raspberry Pi family but trying to get familiar with this Pine product.

When starting an application that I installed using the package manager it says that it requires OpenGL 2.1 to run and tells me 'try updating your drivers'.

Code:

glxinfo | grep "OpenGL version"

Gives me:

OpenGL version string: 2.0 gl4es wrapper 1.1.1

Is there a possibility to upgrade to 2.1?

If you go to a mainline kernel with panfrost it shows OpenGL 2.1 with Mesa 19.2.6, but that's a big change to make for one program.

[ab1jx]

And I hear Panfrost isn't that great.  I'm just exploring the same issues on an Odroid N2 and a Rock64.  You might look into meson  (not meson the build system).  The Mali people pulled a fast one on the rest of the world, it's rare to get one to work right, except in Android.  Wayland may come out better than X11 since they've stopped writing drivers for X11, everything has to be reverse engineered.  https://forum.odroid.com/viewtopic.php?f...5&start=50

Waiting for word on my Pinebook Pro, due in December.  The Mali T860 in it has been approved (Conformant) for Vulkan https://vulkan.lunarg.com/ and https://www.khronos.org/vulkan/ drivers linked from https://developer.arm.com/solutions/grap...pis/vulkan  Vulkan is billed as a replacement for OpenGL ES, or an underlying lower-level language which maybe an OpenGL frontend could run on.  OpenGL is decades old  and not very interesting so the Khronos people are working on replacing it.

[ab1jx]

My Odroid N2 is in about the same situation, there's a lack of drivers coming from ARM because they're pushing Android and Wayland.  BUT, if you're in a position to build a kernel, and I've done it a few times: take the kernel-level Mali package https://developer.arm.com/tools-and-soft...ard-kernel and build it in, then add the user-space drivers from https://developer.arm.com/tools-and-soft...user-space

The user-space driver is actually a libmali.so file with a few symlinks pointing at it, looks something like this:

Code:

lrwxrwxrwx 1 root root        11 Dec  2 13:43 libEGL.so -> libEGL.so.1
lrwxrwxrwx 1 root root        10 Dec  2 13:43 libEGL.so.1 -> libmali.so
lrwxrwxrwx 1 root root        17 Dec  2 13:43 libGLESv1_CM.so -> libGLESv1_CM.so.1
lrwxrwxrwx 1 root root        10 Dec  2 13:43 libGLESv1_CM.so.1 -> libmali.so
lrwxrwxrwx 1 root root        14 Dec  2 13:43 libGLESv2.so -> libGLESv2.so.2
lrwxrwxrwx 1 root root        10 Dec  2 13:43 libGLESv2.so.2 -> libmali.so
-rwxr-x--- 1 root root 149838991 Dec 18  2017 libmali.so
-rwxr-x--- 1 root root  19467864 Dec 18  2017 liboffline_compiler_api_gles.so
lrwxrwxrwx 1 root root        14 Dec  2 13:43 libOpenCL.so -> libOpenCL.so.1
lrwxrwxrwx 1 root root        10 Dec  2 13:43 libOpenCL.so.1 -> libmali.so

The library is a big binary blob but if you use nm to look into it you see functions and objects defined that belong to several Khronos languages.  If it's complete with the kernel-level stuff added it could be used to do OpenGL ES or OpenCL at least.  Looks like this wouldn't get OpenGL ES 2.1 but somewhere I saw 3.0 I think.

There are limitations on how it can be distributed but the workaround is to have everybody fetch their own package after agreeing to the distribution restrictions then use it with a package that somebody else made, you used to have to install Java that way.  If you try to use the user-space stuff by itself you get "undefined reference" errors because you've only got part of it.

I have a hunch that OpenGL shaders are about the same as OpenCL kernels, they're little subroutines which get compiled before use.  And that certainly didn't come from any OpenGL tutorial I've read.

[sebt3]

ptitSeb will need a pinebook pro to add gl 2.1 features

[aaspectre]

mali t820. which is also midgard, recently reached feature parity with other gpus in upstream mesa late last month

it is not so grim considering this, there are other blog posts from the same team about rk3399 and adjacent, though it doesn't seem to be the subject of singular focus.  i perceive there is a surge in popularity of rk3399 devices, so we might see some movement soon, hopefully

it does feel like pbp may be on the cusp of being less of a nerdy toy and more of a serious contender for good laptop

[aaspectre]

another lead for the impatient like me may be compiling and installing alyssa rosenzweig's personal fork of mesa (something I tried yesterday, but failed as i was rushing and not really reading the docs(clearly replacing the git url in the mesa-git aur pkgbuild isn't enough!). second of all, her fork will undoubtedly be merged upstream anyway, so this is for the very impatient), as she seems to be the main person responsible for progressing panfrost

[icecream95]

second of all, her fork will undoubtedly be merged upstream anyway, so this is for the very impatient), as she seems to be the main person responsible for progressing panfrost

AFAICT almost everything is already upstream, so there isn't any reason to not just use latest mesa-git.

Besides, if you use a fork you'll miss out on many of the recent features and fixes, such as my just-pushed LZDoom crash fix.

[RudderDuck]

Thanks for all the info people, as I'm not a very experienced user, I went for a simpler approach and managed to get in installed by changing from the default Debian system to Ubuntu as described here:

https://forum.pine64.org/showthread.php?tid=8119