Help with GPU

VisionFive 2 （English Forum)
1

Hi,

Usually when I get a new SBC one of the things I like to try out is to test the GPU. Usually I start with running glxinfo, but I’m get the error:

$ glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig

Is there anything that I can use to test the GPU? I can see the driver option when I reconfigured the kernel, but somehow after reconfiguring I can’t seem to find anything that suggests the GPU exists.

3 Likes
2

Maybe this will help:

not sure was a random google search from the error

3

The GPU in the VF2 doesn’t support OpenGL, it does support EGL and GLES2 though. You can use the es2gears_x11 (or es2gears_wayland) demos to test the GPU.

You can also prepend the commandline with vblank_mode=0 to run unconstrained by vsync, eg vblank_mode=0 es2gears_x11 within an X session

2 Likes
4

for some scenarios maybe gl4es: GitHub - ptitSeb/gl4es: GL4ES is a OpenGL 2.1/1.5 to GL ES 2.0/1.1 translation library, with support for Pandora, ODroid, OrangePI, CHIP, Raspberry PI, Android, Emscripten and AmigaOS4. works - it wrapps opengl around gles in the form of a shared library which you simply ld-preload via LD_LIBRARY_PATH … it worked for me quite well for several arm systems with mali gles blobs … this is how i built it for those arm systems, so similar options might maybe work on the vf2 (not yet tested it myself yet): mesa-etc-build/gl4es-build.txt at master · hexdump0815/mesa-etc-build · GitHub

good luck and best wishes - hexdump

3 Likes
5

it looks like gl4es seems to work to make opengl somehow work - i did not successfully try it myself, but the gl4es author has it working, so i guess it should just work - see starfive visionfive2 support? · Issue #420 · ptitSeb/gl4es · GitHub

6

Imaginationtech sad IMG BXE-4-32 MC1 is supported vulkan.
This means zink is a batter choice for opengl.

1 Like
7
3 Likes
8

did anyone here get the gpu in xorg and/or wayland working well besides the starfive debian image and has documented/scripted all the steps required?

i tried to get it working for my experimental debian sid image but so far failed … kernel side i seem to have gotten to work, i.e. pvr firmware gets loaded and starts properly and all required drm devices register properly and in the same order as in the starfive debian image.

i then took the debian gpu related binaries from Debian/gpu/DDK1.17-binary-xorg at 20221225T084846Z · starfive-tech/Debian · GitHub and unpacked them to the right place into my running image and then i changed /usr/bin/Xorg to a symlink to /usr/local/bin/Xorg … all seems to startup ok, but then xorg does not start properly: it starts up initially, initializes properly even the hacked up glamor in the xorg but a bit later dies and gets restarted by lightdm.

can it maybe be because i have that patch to enable the framebuffer console in my kernel? i think i saw some fb related errors in my xorg log …

a lot of thanks in advance and best wishes - hexdump

ps: this is the xorg.log i’m getting - https://pastebin.com/raw/sjSQn7QV … the dri2 error is also present in the working starfive debian image … no idea why the xserver always restarts

pps: i think i’m getting an idea …
/var/log/lightdm# cat seat0-greeter.log
/usr/sbin/slick-greeter: symbol lookup error: /lib/riscv64-linux-gnu/libharfbuzz.so.0: undefined symbol: FT_Get_Transform

ppps: the gpu etc. binaries brought a libfreetype with it which does not seem to be compatible with the installed libharfbuzz - moving that libfreetype aside at least lets me start the xorg server now, but everything is extremely slow in it now :slight_smile:

5 Likes
9

i have created a seperate thread to collect all the internal gpu related information in one place - so maybe lets followup there in case it is not related to the starfive debian images: Getting the builtin img gpu working from scratch

1 Like