Ancora su GPU e DSP

d_phatt 18-07-21 10.40
Buongiorno,
Riprendo questo argomento già più volte toccato da Orange1978, buttando come scusa un link a caso: link.
Sospetto che ormai si troveranno altre soluzioni di questo genere.

Ne approfitto anche per chiedere se qualcuno sa a che punto siamo con la "accelerazione DSP" tramite le schede video.
maxpiano69 19-07-21 12.02
Ciao, tecnicamente usare la tecnologia delle GPU per fargli fare altro è una cosa nota e già utilizzata (basti pensare alle batterie di GPU utilizzate per fare mining di criptovalute), il problema è che qualcuno si metta a scrivere il software per farglielo fare ovvero nel caso specifico implementi dei "VST" (o più in generale "applicazioni audio") scritte e compilate per girare su delle determinate GPU (specifiche, perché non sono tutte uguali). La ditta che hai linkato sembra voglia lanciarsi su quel territorio ma secondo me sono ancora in pochi (forse perché la domanda/mercato non è così ampia?).
d_phatt 19-07-21 12.46
@ maxpiano69
Ciao, tecnicamente usare la tecnologia delle GPU per fargli fare altro è una cosa nota e già utilizzata (basti pensare alle batterie di GPU utilizzate per fare mining di criptovalute), il problema è che qualcuno si metta a scrivere il software per farglielo fare ovvero nel caso specifico implementi dei "VST" (o più in generale "applicazioni audio") scritte e compilate per girare su delle determinate GPU (specifiche, perché non sono tutte uguali). La ditta che hai linkato sembra voglia lanciarsi su quel territorio ma secondo me sono ancora in pochi (forse perché la domanda/mercato non è così ampia?).
Ciao maxpiano, grazie, sotto sotto mi aspettavo un tuo intervento emo

Suppongo tu riferisca al GPGPU. Sotto questo aspetto, e quello della portabilità, io sapevo che c'era OpenCL come soluzione, ma non so effettivamente quanto sia praticabile come strada.

Il fatto è che a livello di architettura del software si introduce una dipendenza enorme. Alla fine se ci si limita a del normale codice C/C++, è relativamente semplice scrivere software audio che girino o possano essere portati più o meno ovunque (l'unico vero requisito è che l'applicazione sia realtime, di solito)...e la piattaforma è ormai più o meno la stessa da decenni.
Invece il mondo delle GPU, boh, almeno dall'esterno mi sembra una cosa in continuo cambiamento, non molto "stabile" in un certo senso. Magari sbaglio, nella mia piccola esperienza con motori grafici 3D, ho visto che chi si occupava del rendering stava sempre a impazzire con le varie API, varie versioni della stessa API, driver...un casino, almeno questo è quello che ho percepito, non avendo mai lavorato direttamente sul rendering...e questa mia sensazione non mi fa venire tanta voglia di iniziare a farlo emo

Sul discorso della domanda, mah, mi sembra che i potenziali clienti possano essere principalmente studi di registrazione, cose del genere, quindi quel tipo di clienti...però mi sembrava interessante mandare quel link, qualcosa in effetti si sta muovendo.
maxpiano69 19-07-21 14.04
d_phatt ha scritto:
Il fatto è che a livello di architettura del software si introduce una dipendenza enorme. Alla fine se ci si limita a del normale codice C/C++, è relativamente semplice scrivere software audio che girino o possano essere portati più o meno ovunque (l'unico vero requisito è che l'applicazione sia realtime, di solito)...e la piattaforma è ormai più o meno la stessa da decenni.
Invece il mondo delle GPU, boh, almeno dall'esterno mi sembra una cosa in continuo cambiamento, non molto "stabile" in un certo senso. Magari sbaglio, nella mia piccola esperienza con motori grafici 3D, ho visto che chi si occupava del rendering stava sempre a impazzire con le varie API, varie versioni della stessa API, driver...un casino, almeno questo è quello che ho percepito, non avendo mai lavorato direttamente sul rendering...e questa mia sensazione non mi fa venire tanta voglia di iniziare a farlo

Oltre alla dipendenza dalla specifica piattaforma GPU (ma prendiamo pure a riferimento quella più sfruttata in ambiti non audio ovvero NVIDIA e le sue librerie CUDA), anche dal punto di vista software si dovrebbe secondo me ripensare ogni applicazione perché sfrutti le peculiarità, soprattutto a livello di parallelismo, che può offrire una GPU (non basta per capirci prendere un codice per CPU e ricompilarlo, imo).

Precisazione: neanche io ho mai frequentato il mondo delle GPU, in nessuna salsa e men che mai dei software di grafica/rendering, ma ogni tanto mi è capitato di leggere qualcosa, per pura curiosità. Se vuoi approfondire puoi partire da https://developer.nvidia.com/cuda-zone che già solo nella home page dice molte cose interessanti, ad esempio (riporto testualmente):

In GPU-accelerated applications, the sequential part of the workload runs on the CPU – which is optimized for single-threaded performance – while the compute intensive portion of the application runs on thousands of GPU cores in parallel. When using CUDA, developers program in popular languages such as C, C++, Fortran, Python and MATLAB and express parallelism through extensions in the form of a few basic keywords. emo
d_phatt 19-07-21 21.09
maxpiano69 ha scritto:
dal punto di vista software si dovrebbe secondo me ripensare ogni applicazione perché sfrutti le peculiarità, soprattutto a livello di parallelismo, che può offrire una GPU (non basta per capirci prendere un codice per CPU e ricompilarlo, imo).

Anche imho, è proprio un modo diverso di scrivere i programmi...cambia tutto, non credo che si possa adattare facilmente a meno di non portare avanti porzioni di codice doppie, la versione normale per CPU e quella accelerata per GPU...un po' come si fa appunto nei motori grafici che supportano renderer multipli con relative API, e tutti i renderer si attaccano a turno allo stesso "core", il client. Ovviamente ne consegue la relativa moltiplicazione del codice, dei problemi, della fatica...anche a livello di architettura aumentano le complessità, ma si fa, in quell'ambito si fa regolarmente. Però posso dire per (modesta, appunto) esperienza diretta che i motori 3D sono programmi tremendi, sono grossi e complicati, il rendering è solo una delle tante parti; e infatti gestirli è complicato, però il motore è UN programma...
Invece uno sviluppatore di plugin dovrebbe mantenere una doppia path del codice per ogni singolo plugin/programma...sarebbe folle. E non di una parte di codice qualsiasi, ma proprio quello del motore DSP.

maxpiano69 ha scritto:
In GPU-accelerated applications, the sequential part of the workload runs on the CPU – which is optimized for single-threaded performance – while the compute intensive portion of the application runs on thousands of GPU cores in parallel. When using CUDA, developers program in popular languages such as C, C++, Fortran, Python and MATLAB and express parallelism through extensions in the form of a few basic keywords

Interessante, grazie mille, quindi in pratica usare CUDA e similari non è troppo diverso, a livello concettuale e di architettura del software, da usare OpenGL, Vulkan e compagnia.
maxpiano69 20-07-21 14.42
Di sicuro andrebbero scritti avendo già in partenza chiaro come distribuire il carico tra CPU (sequenziale e tendenzialmente single threaded) e GPU (multi threaded), ma se ci pensi alla fine nel caso ad esempio di un Virtual Analog è un'architettura che si presta benissimo ad emulare la struttura di un synth reale, ogni voce sarebbe un thread che impegna un certo numero di core della GPU mentre la parte di "controllo" che gira su CPU si limiterebbe alla gestione delle parti comuni (parametri del preset, MIDI...).

Altra idea interessante sarebbe quella di sviluppare strumenti a modelli fisici con algoritmi di "wavetracing" (volendo dare un nome ad un equivalente audio del raytracing) implementati su GPU, qualche esperimento in tal senso è stato fatto in passato ma che io sappia non hai poi preso piede, probabilmente perché al momento la modellazione fisica audio di strumenti acustici è più un problema di bontà del modello (che spesso è ancora insufficiente a garantire il realismo atteso, rispetto all'uso del più semplice ed economico sampling) che non di prestazioni, ovvero per far girare un buon modello fisico con un numero più che sufficiente di voci basta una normale CPU, Pianoteq come esempio fra tutti.
d_phatt 20-07-21 19.59
Molto interessante quello che dici sul wavetracing, non ci avevo mai pensato.

Sì, diciamo che per come sono impostati ora i programmi audio, una CPU abbastanza potente può gestire tanta di quella roba che (a patto di avere sufficiente memoria) bisogna fare mix con parecchie tracce e plugin pesanti per iniziare a metterla in difficoltà (usando anche il rendering audio di alcune tracce ovviamente). Quindi ci vuole un certo sforzo anche solo per iniziare a sentire l'esigenza di qualcosa di diverso. Come sicuramente saprai meglio di me.
Per fare un esempio, io con un i5 vPro piuttosto vecchiotto e 8 GB di memoria ram gestisco tranquillamente i miei piccoli progetti da massimo 10/15 tracce, con vari plugin di effetti...il tutto mentre sono aperti altri programmi, nulla di quello che ho fatto finora con la DAW è bastato per metterlo in crisi...quindi anche se sotto il cofano c'è anche una GT 1030, non serve.
Per chi fa mix più impegnativi invece il discorso cambia ovviamente. Ma solo mettendo in gioco tante tracce, tanti plugin, il singolo programma gli fa un baffo a questi processori.

Però certo, questo vale perché le tecniche di elaborazione sono quelle "normali"...certo se iniziamo a parlare di tracing "punto per punto" dell'onda con i vari rimbalzi nello spazio...beh cambia tutto. Che sia una tecnologia del genere su GPU la chiave per avere un pianoforte modellato realistico? Con Pianoteq 7 si sono migliorati veramente e avvicinati (grazie a seri miglioramenti del modello), la differenza con il 6 è piuttosto netta, ma il finto ancora si sente troppo imho.