virt-manager sketchup enable hardware acceleration

[rik70]

E' più simile a questo il problema: https://github.com/libvirt/libvirt/issues/93

Che versioni hai di libvirtd e qemu?

[rik70]

Ma proviamo a farla 'semplice'.

Scarica la iso di debian live gnome e prova a farla partire da riga di comando:

Codice: Seleziona tutto

qemu-system-x86_64 -M q35,accel=kvm,vmport=off,dump-guest-core=off,hpet=off,acpi=on \
 -m 4096 -cpu host,migratable=on -smp 2 -display gtk,gl=on -device driver=virtio-vga-gl \
 -cdrom iso/debian-live-12.5.0-amd64-gnome.iso -usb -usbdevice tablet

[joe]

Codice: Seleziona tutto

$ findpkg virt
libvirt-python-9.1.0-x86_64-1_SBo
virt-manager-4.1.0-x86_64-1_SBo
libvirt-9.1.0-x86_64-1_SBo
virt-viewer-10.0-x86_64-1_SBo
libvirt-glib-4.0.0-x86_64-1_SBo

$ findpkg qemu
qemu-8.2.2-x86_64-2_SBo

[joe]

Proviamo Debian... la versione ora è la 12.8.0:

https://cdimage.debian.org/debian-cd/cu ... bt-hybrid/

Codice: Seleziona tutto

$ qemu-system-x86_64 -M q35,accel=kvm,vmport=off,dump-guest-core=off,hpet=off,acpi=on \
 -m 4096 -cpu host,migratable=on -smp 2 -display gtk,gl=on -device driver=virtio-vga-gl \
 -cdrom Downloads/debian-live-12.8.0-amd64-gnome.iso -usb -usbdevice tablet
qemu-system-x86_64: egl: eglBindAPI failed (core mode): EGL_BAD_PARAMETER
qemu-system-x86_64: OpenGL is not supported by the display

[rik70]

Uhm... che dice

Codice: Seleziona tutto

glxinfo | grep  'renderer string'

?

[joe]

Codice: Seleziona tutto

$ glxinfo | grep  'renderer string'
OpenGL renderer string: GeForce 210/PCIe/SSE2

[joe]

Spetta un po', ho fatto una prova senza alcun razionale... m'è venuto solo in mente che prima avevi accennato di utilizzare di SDL anziché GTK nella tua configurazione.

Il comando qemu che mi avevi suggerito sopra contiene "-display gtk".
E siccome l'errore dice anche che il Display non supporta OpenGL... mi sono detto perché non provare a cambiare il display?
Così ho sostituito "-display gtk" con "-display sdl".

E, grande botta di deretano, è partita la schermata di qemu col suo bravo grub e il menu di boot Debian!

[joe]

Ho fatto partire dal menu la versione "filesafe".

Però glxinfo non contine nulla relativo a virgl, come invece appare nel tuo caso.
Io ho 4 GB di ram su questo catorcio, per cui ho dovuto limitare a 2GB quella dedicata alla VM.
Ora provo ancora la versione di debian standard non filesafe ma prima s'è bloccato tutto... riprovo.

[rik70]

Ma non è che devi ricompilare qemu dopo aver installato virglrenderer?
O hai già fatto?

https://docs.mesa3d.org/drivers/virgl.html

https://gitlab.archlinux.org/archlinux/ ... type=heads

[joe]

Niente, Debian avviato col comando suggerito, anche abbassando la memoria dedicata a 2GB non arriva a consegnarmi il desktop Gnome.
Ho provato a scaricare la versione Xfce, ma anche lì ieri sera alla fine non sono riuscito: parte, mostra lo splash screen, poi la finestra di qemu diventa nera, e invece di riapparire vari messaggi log di avvio ecc, resta nera per molto tempo, troppo per non interrompere la prova manualmente. Del tipo che ho lasciato andare e sono tornato dopo un'ora... era ancora in schermata nera.
Scegliendo invece la modalità failsafe al boot, allora si avvia, però come dicevo glxinfo, dice solo render yes, ma nulla in merito a virgl.

Virglrenderer è installato, bisogna vedere se è stato installato prima o dopo rispetto a qemu...

Da /var/log/packages vedo che qemu è stato ricompilato molto più di recente rispetto all'installazione di virglrenderer.
Ora al volo non so se qemu se lo integra automaticamente se lo trova sul sistema o se si debba specificare in fare di "configure". Dovrei leggermi il README di qemu. Non so neanche se si possa vedere con quali opzioni e dipendenze sia stato compilato qemu... devo fare una ricerca.

[rik70]

Niente, Debian avviato col comando suggerito, anche abbassando la memoria dedicata a 2GB non arriva a consegnarmi il desktop Gnome.

Forse ha bisogno di una rete. Hai provato premendo il tasto tab a modificare la voce di avvio eliminando quiet e splash?
Per la rete, visto che usi libvirt,potrebbe essere:

Codice: Seleziona tutto

-netdev bridge,br=virbr0,id=n1 -device virtio-net,netdev=n1

Bisognerebbe che qualcuno provasse qui con una nvidia recente o comunque con i driver della serie 5xxx.

Perché qui funziona:

[joe]

Sulla "rete" non ti seguo, possibile che mi sia perso eh...
Ma io mi riferivo al comando qemu lanciato da prompt, quello che hai suggerito sopra. In quel caso libvirt c'entra qualcosa?

Invece davo un'occhiata allo slackbuild SBo:

https://slackbuilds.org/slackbuilds/15. ... SlackBuild

Il mio pacchetto dovrebbe essere stato creato creato con quella "ricetta", a meno di modifiche che non ricordo più, l'ho installato secoli fa:

Codice: Seleziona tutto

$ ls -lt /var/log/packages/|cat -n|grep "qemu\|virgl"
    47  -rw-r--r-- 1 root root   22108 mag 25  2024 qemu-8.2.2-x86_64-2_SBo
   350  -rw-r--r-- 1 root root     895 apr 19  2023 virglrenderer-0.10.4-x86_64-1_SBo

Qemu attuale l'ho compilato e installato a maggio, mentre virglrenderer più di un anno prima.

Ad ogni modo confrontando il PKGBUILD di Arch, con le opzioni di build dello SlackBuild SBo, in quest'ultimo virglrenderer non è nominato.
Non sono tanto pratico di PKGBUILD, non capisco se virglrenderer in quel caso è una dipendenza, oppure se significa che viene attivata la funzionalità in fase di build.

Ho trovato anche questa discussione in cui in effetti potrebbe essere necessario compilare qemu con l'opzione "--enable-virglrenderer" in fase di configure:

https://github.com/lima-vm/lima/issues/ ... 1860593887

Anzi spetta... rileggendo meglio il README di qemu dice:

Codice: Seleziona tutto

libiscsi (to access iSCSI targets directly), libslirp (user mode
networking), libcacard, spice, usbredir, virglrenderer, libnfs, snappy,
glusterfs, and vde2, numactl. sphinx-rtd-theme and Sphinx (to build
documentation) are optional dependencies that will be automatically
detected during compilation, if present (all avialable on SBo).

Quindi anche "virglrenderer" siccome era preinstallato sempre via SBo, al build di Qemu dovrebbe essere stato regolarmente attivato e incluso.

[rik70]

Sulla "rete" non ti seguo, possibile che mi sia perso eh...

Nel comando qemu per avviare la live Debian, mancava la rete. Il boot va all'inizio in stallo per un po' a causa di NetworkManager che 'aspetta' a configurarsi.
Aggiungendo la rete a qemu, come detto sopra o preferisci, velocizza l'avvio.

Comunque, se togli gli argomenti splash e quiet dalla voce di avvio 'normale della live, capisci almeno che succede.

Ad ogni modo, penso che con i driver 340 non c'è speranza.

Poi: win si avvia con i driver virtiogpu di redhat, però è un altro paio di maniche capire se le app che necessitano accelerazione 3d funzionino.
Ho provato furmark, ma dice che opengl non è installato.

Il desktop funziona però molto bene, quasi a livello nativo.


Comunque sia... a me win sta sulle palle, scusate la finezza, e non ho voglia di sbattermi.

[rik70]

Codice: Seleziona tutto

libiscsi (to access iSCSI targets directly), libslirp (user mode
networking), libcacard, spice, usbredir, virglrenderer, libnfs, snappy,
glusterfs, and vde2, numactl. sphinx-rtd-theme and Sphinx (to build
documentation) are optional dependencies that will be automatically
detected during compilation, if present (all avialable on SBo).

Quindi anche "virglrenderer" siccome era preinstallato sempre via SBo, al build di Qemu dovrebbe essere stato regolarmente attivato e incluso.

Se non vuoi issare ancora bandiera bianca, potresti provare ad aggiornare all'ultima versione sia virglrenderer che qemu.
I driver nouveau funzionano con la tua VGA?

Per quanto riguarda i driver virtiogpu 3d per Windows, sono questi: https://github.com/virtio-win/kvm-guest ... s/pull/943

Pare che la versione di sviluppo di virglrender abbia già la parte di codice per 'ospitarli'.
Per il guest, andrebbero compilati(il link che permetteva di scaricare binari è stato rimosso): chi si offre volontario ?

Comunque se qualcuno è interessato, provi a virtualizzare Win 11 con la configurazione che bypassa spice menzionata sopra e i virtiogpu guest precompilati(2d o 3d ).
Le prestazioni sono impressionanti, niente a che vedere con spice+qxl.

[joe]

Grazie anzitutto delle tante informazioni.
Al volo, ieri avevo provato ad avviare l'immagine di win7 col comando qemu che avevi suggerito tu, apena modificato per far partire da hd virtuale e non da cdrom come nella prova con Debian. Spetta che se è rimasto in history della shell lo ripesco. Ho dovuto lanciare da root perché l'immagine di win7 è nella dir in cui la piazza automaticamente virt-manager:

Codice: Seleziona tutto

$ su -c "qemu-system-x86_64 -M q35,accel=kvm,vmport=off,dump-guest-core=off,hpet=off,acpi=on  -m 1448 -cpu host,migratable=on -smp 2 -display sdl,gl=on -device driver=virtio-vga-gl  -drive id=disk,file=/var/lib/libvirt/images/win7.qcow2 -usb -usbdevice tablet"

Così si avvia, avevo provato anche con "drive id=virtio" o simile che avevo trovato cercando, ma così non parte, probabilmente a win, manca qualche driver virtio per gestire l'avvio in quel modo, invece con "id=disk" gira.

Il problema è che non si risolve. A parte il mouse che sbarella, cioè da di matto, non si riesce a spostarlo con precisione... a parte quello, avviando Sketchup torna ad uscirsene con lo stesso errore, ovvero necessità di accelerazione hardware.

Potrebbe anche essere che sia normale così dal momento che non ho installato nulla sul guest.
E perdona la beata ignoranza ma in quanto dicevi sopra non ho capito cosa si dovrebbe fare lato guest, quali driver installare di preciso insomma.