VirtualGL is using LLVMPipe and not the GPU

January 27, 2024, 12:12

semp1337

What I currently have - Raspberry Pi 5 with 3a/5v charger and fan What's my purpose here I want to use RPi's GPU to its full core I'm currently using Xpra and hosted it online so that my friends can view and do stuff along with me However glxinfo reports LLVMPipe is used so I believe it's cpu's complete work? I've compiled VirtualGL and ran but then found that it also uses LLVMPipe [note the attachment pic] What have I tried for alternatives I've used TightVNC with noVNC for achieving similar to Xpra but then sound wasn't there [the forks with sound seems impossible for me to config] I noted that RealVNC uses Broadcom's GPU in Service Mode which gave me some hope but then it wasn't working with noVNC, the authorization protocol resulted in some error [ https://github.com/novnc/noVNC/issues/1826 ] i'm newbie so idk much, just read the docs and tried stuff then failed miserably :C

semp1337

oh and this screenshot refs to vglrun command on glxinfo

oops.se

Please don't post pictures of text. There are several reasons for that!

semp1337

uhm, i just can't copy the text

semp1337

nvm, i'll do OCR

oops.se

What environment are you in ?

semp1337

uhh, environment?

oops.se

Terminal, ssh window ?

semp1337

oh, i'm on xpra currently

semp1337

it's being displayed on browser

semp1337

for some reasons copy-paste isn't working

oops.se

Strange ? SSH ?

semp1337

let's say I broke my windows ssh :C

oops.se

Download ex. "putty portable app" and use SSH.

oops.se

That will make easier for you.

semp1337

putty, i feel like i heard of it

semp1337

well uh, here's text version
css
ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'libvglfaker.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
OpenGL vendor string: Mesa
OpenGL renderer string: llvmpipe (LLVM 15.0.6, 128 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 23.2.1-1~bpo12+rpt3
OpenGL core profile shading language version string: 4.50
OpenGL version string: 4.5 (Compatibility Profile) Mesa 23.2.1-1~bpo12+rpt3
OpenGL shading language version string: 4.50
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 23.2.1-1~bpo12+rpt3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

oops.se

Curiosity, why compile it when they has released a package?

semp1337

ah, I've tried the package as well, results same output

semp1337

I thought I should compile and try

oops.se

My advice, open a ticket on VirtualGL github

semp1337

acknowledged

oops.se

Please post a feedback as it could help someone else and increase my knowledge.

semp1337

I have realized that I've made the things more complicated as I compiled and installed Mesa 24 from dev branch git; 24 version Mesa doesn't seeming to support Zink driver on RPi and outputs DRI3 unavailable as glxinfo runs I have reinstalled every possible mesa related packages in apt but then I found no luck as it's not reverting the version back Therefore I decided to reinstall RPi OS once again and will update this thread if I found any way to make VirtualGL functional

semp1337

And please do note that, VirutalGL doesn't intend to support RPi in any way. However, there seems to be one person who got it working at the very least ref : https://github.com/VirtualGL/virtualgl/issues/59#issuecomment-732993131

semp1337

I believe making VirtualGL functional for RPi will be helpful as it allows GPU to be functional within Virtual servers [VNC]

semp1337

If a person got VirtualGL running in RPi 4 could possibly make it functional for RPi5 as well I assume??

oops.se

Possible, but what is the difference between X.11 and Wayland, as Raspberry Pi foundation has switch the GUI stack between Bullseye (Debian 11) and Bookworm (Debian 12) ? And could that have any influence ?

semp1337

Oh, I forgot to mention; I've used X11 throughout the process and I believe you can switch the GUI Stack anytime? [Openbox as X11 and Wayfire for Wayland] I believe it doesn't have any influence as X11 is followed in both github mentioned issue as well as in the current thread and I'm totally unsure about wayland