virt-manager sketchup enable hardware acceleration

[rik70]

quali driver installare di preciso insomma.

I driver sono questi: https://github.com/virtio-win/virtio-wi ... /README.md
La iso stabile o l'ultima.

Lanciare qemu da root non va bene per lo scopo che ci stiamo prefiggendo.

Devi ottenere una finestra della vm con l'accelerazione gl del desktop.

La debian live è il test più semplice da fare: se con sdl, anche in modalità failsafe, ottieni llvmpipe anziché virgl, allora non sta funzionando ed è inutile perdere tempo con win.

Riassumendo:
premesso che il sistema che hai non è adattissimo, al momento non esiste la possibilità di utilizzare l'accelerazione 3d con i driver virtiogpu 'ufficiali'.
Si riesce al massimo a far partire un'applicazione 3D con le Mesa per Windows, ma con accelerazione solo software, come puoi vedere qui sotto:


La stessa possibilità si ottiene con vga qxl, quindi non ha senso continuare a sbattere la testa con i virtio.

Rimarrebbe da compilare e testare questi, ma...

Insomma, si torna a bomba al pci passthrough.

Alla fine della fiera, per provare ad attivare virgl almeno su guest Linux, io farei così:
- aggiornerei qemu e virglrender alle ultime versioni e riproverei con la Debian;
- se non andasse nemmeno così, toglierei gli nvidia e proverei coi nouveau.

[joe]

Ora mi è un po' più chiaro almeno a livello operativo, perdona l'ignoranza ma la gestione di tutte ste librerie grafiche mi è oscura, e in generale ci sto capendo sempre meno.
Lo "schemino" immagino sia semplice alla fine (per capire giusto la configurazione che serve allo scopo), ma per "disegnarlo" occorre come sempre un po' di approfondimento, che personalmente non ho sondato. In pratica sto andando molto a tentoni. E questo direi che era lampante!

Posso sicuramente fare quanto dicevi, tranne l'ultimo punto. Sì, coi driver nouveau, forse, ma forse, potrebbe essere una via più digeribile per le librerie coinvolte, ma i nouveau con la mia scheda video portano ad una situazione piuttosto poco prestante e instabile, li avevo provati per esempio per valutarne l'accelerazione hardware nella decodifica video, e tempo due secondi, il sistema crasha alla grande.
Sarebbe stata una buona alternativa ai vetusti nvidia-l3gacy-340.108, che ormai sono fuori supporto da anni.. E si torna all'esclamazione di Torvalds.
Neanche SBo li supporta più di fatto, sono marcati UNMAINTAINED. Ne avevamo parlato in un vecchio topic all'uscita della slack-15...
Quindi insomma i driver proprietari funzionicchiano, la gpu in question fa pena, e si farebbe prima a sostituirla che a rivedere il pacchetto, anche perché poi non è che si risolva problemi tipo questo... che esula probabilmente dal pacchetto del driver, e invece dipende proprio dal driver in sé o da limitazioni forse anche hardware della gpu in questione, non saprei. di preciso.
Comuque sì, qemu posso ricompilarlo aggiornato e anche virglrenderer.
Chissà se dopo vada ricompilato anche libvirt e virt-manager... forse me la cavo senza doverli ritoccare...

Farò sapere com va a finire. Grazie ancora per il momento.

[joe]

Anticipo che ho fatto una prova senza tanti approfondimenti, come al solito... premesso che come da firma sono su Slackware64-15.0

Partendo da SBo e modificando la versione nello slackbuild:

- virglrenderer 1.1.0

compila e fila liscio

- qemu 9.2.0

Non fila... lamenta versioni troppo vecchie in particolare di Meson, sulla mia slack, ma vedo anche dal repo ufficiale via slackpkg che meson è alla 0.59.4.
Anche il pacchetto Sphinx se lo aspetta alla 5.3.0, mentre qui sono alla 2.2.11.

Codice: Seleziona tutto

qemu-9.2.0/subprojects/proc-macro-error-1.0.4/README.md
qemu-9.2.0/subprojects/proc-macro-error-1.0.4/build.rs
qemu-9.2.0/subprojects/keycodemapdb.wrap
qemu-9.2.0/qemu.nsi
chmod: impossibile operare sul collegamento simbolico con obiettivo non esistente './roms/edk2/EmulatorPkg/Unix/Host/X11IncludeHack'
Using './build' as the directory for build output
python determined to be '/usr/bin/python3'
python version: Python 3.9.19
mkvenv: Creating non-isolated virtual environment at 'pyvenv'
mkvenv: checking for meson>=1.5.0
mkvenv: checking for pycotap>=1.1.0
mkvenv: installing meson==1.5.0, pycotap==1.3.1
mkvenv: checking for sphinx>=3.4.3
mkvenv: checking for sphinx_rtd_theme>=0.5

'sphinx==5.3.0' not found:
 • Python package 'sphinx' was not found nor installed.
 • mkvenv was configured to operate offline and did not check PyPI.


Sphinx not found/usable, disabling docs.
The Meson build system
Version: 1.4.0
Source dir: /tmp/SBo/qemu-9.2.0
Build dir: /tmp/SBo/qemu-9.2.0/build
Build type: native build

../meson.build:1:38: ERROR: Meson version is 1.4.0 but project requires >=1.5.0

A full log can be found at /tmp/SBo/qemu-9.2.0/build/meson-logs/meson-log.txt

ERROR: meson setup failed

Insomma mi sa che slackware 15.0 non sia il massimo per questa roba troppo recente.
D'altra parte in SBo, ci potrebbero essere buoni motivi per essere rimasti a versioni così arretrate di qemu ecc...

Provo ad accontentarmi della versione 9.0.2 che si trova su SBo.
Siccome virglrenderer l'ho aggiornato alla 1.1.0 dovrebbe rilevarlo automagicamente ed attivarne il supporto. Vediamo...

[rik70]

Il problema è anche lato driver proprietari.
Dato che virglrender dipende da Mesa, con quale paleozolica versione avranno realizzato i 340xxx legacy per la tua scheda?

Perché su slackware 15 c'è sicuramente una versione abbastanza recente, ma il tuo hardware poi utilizzerà quella dei driver proprietari.

Non mi gioco neanche ½ centesimo, ma certo non scommetto che funzioni.

Piuttosto a che ti serve sketchup?
Perché se lo vuoi solo lanciare per studiarlo, allora rimani su spice+qxl: ti scarichi e scompatti le Mesa per Windows e copi la dll opengl dove c'è l'eseguibile di skethup.
Può darsi che parta.

[joe]

Volevo provarlo ed eventualmente studiarlo un po' sì.
Con wine funzionicchia.
Ma non in modo accettabile, per cui visto che avevo lì pronta una VM con win7 mi ero detto, perché non provare?
Solo che poi la situazione è troppo ingarbugliata (nel frattempo qemu sta compilando sul bravo macinino) come abbiamo visto.

Alla fine avevo "ripiegato" approcciando un po' Blender che è sullo stesso genere e anzi probabilmente anche più vasto.

Ho tentato di seguire i tuoi consigli giusto per provare la soddisfazione di veder partire in VM un programma che necessita di accelerazione grafica, a quel punto poi magari potevo anche approfondire... ma se non funziona continuo a smanettare con Blender. Che tra l'altro è anche Open per cui preferisco sicuramente.

I driver nvidia, certamente conterranno una parte precompilata contro chissà quale versione obsoleta di varie librerie. Soprattutto la versione dei driver fuori supporto necessari alla mia povera scheda video.

Mettere in piedi accrocchi con Mesa per sperare di far partire l'eseguibile di sketchup (per windws) su linux, non mi entusiasma, nel senso che non voglio farlo partire ma utilizzarlo con una stabilità accettabile. Se parte ma poi si pianta ogni 3 per 2, non mi serve.

[joe]

Niente, compilato qemu 9.0.2, ho copiato anche l'immagine di win7 e modificato il proprietario in modo da provare lanciando tutto da semplice utente.
Ma niente, stesso errore di prima.

Codice: Seleziona tutto

$ qemu-system-x86_64 --version
QEMU emulator version 9.0.2
Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers

$ 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=/mnt/libvirt/images/win7.qcow2 -usb -usbdevice tablet