Link alla notizia: https://www.hwupgrade.it/news/sistemi/un-ingegnere-di-nvidia-ha-creato-un-driver-vulkan-per-i-raspberry-pi-che-fa-girare-quake-3-a-oltre-100-fps_90259.html

Nei ritagli di tempo libero l'ingegnere di Nvidia Martin ha sviluppato un driver Vulkan per i Raspberry Pi dotati di GPU Broadcom VideoCore IV. Il driver, per quanto sperimentale e raffazzonato, permette di far girare Quake 3 a oltre 100 FPS in 720p.

Click sul link per visualizzare la notizia.

Vacca boia.
A volte si fa fatica a capire quanto possano essere effettivamente potenti questi aggeggini.

...Posso dirlo? POSSO?? ...Ora lo dico, pronti??

CI GIRA CRYSIS??

...L'HO DETTO! Sono un genio, nessuno avrebbe mai pensato a questa battuta.

Tutto bello, ma Quake 3 è un gioco del 1999.
21 anni fà.
Ad oggi, dovrebbe girare anche nella mia lavatrice xiaomi.

Tutto bello, ma Quake 3 è un gioco del 1999.
21 anni fà.
Ad oggi, dovrebbe girare anche nella mia lavatrice xiaomi.

La xiaomi fa pure le lavatrici?

Comunque si, è tanto impressionante che ci sia riuscito quanto inutile, poi oovviamente si tratta solo di un puro esercizio di ingegneria, come quelli che fanno i porting per le calcolatrici scientifiche.

Tutto bello, ma Quake 3 è un gioco del 1999.
21 anni fà.
Ad oggi, dovrebbe girare anche nella mia lavatrice xiaomi.

Non hai tutti i torti, fra l'altro sebbene con alcuni compromessi fu anche convertito in modo convincente sulla prima xbox, che come hardwarmente credo sia molto più limitata del più scarso dei raspberry, comunque interessante. :)

comunque sempre sull'argomento segnalo questo video: Playing Full PC Games on a Raspberry Pi 4 (https://www.youtube.com/watch?v=MkTbvknZQKU)

edit mi sono sconfonduto con Doom3, Quake3 non era stato convertito per xbox... ma per Dreamcast :D

... e cosi capisce ancora una volta dove possono arrivare le ottimizzazioni software e dei driver. Ottimizzazioni su particolari HW. E' uno dei punti di forza delle Apple con hw proprietario e pochi modelli, era il perche i telefoni di fascia Lumia con Ms WinPhone erano fluidi alla pari dei top di gamma android. Sappiamo la pesantezza e la virtualizzazione di Android, ed i compromessi per far girare su tanti dispositivi; solo ora che è aumentata la potenza delle CPU e l'aumento di memoria anche gli android non di fascia alta sono fluidi. Ecco ancora il perché da sempre i giochi sulle consolle molto spesso vanno meglio di computer con costose schede grafiche discrete.

La xiaomi fa pure le lavatrici?

Comunque si, è tanto impressionante che ci sia riuscito quanto inutile, poi oovviamente si tratta solo di un puro esercizio di ingegneria, come quelli che fanno i porting per le calcolatrici scientifiche.

Xiaomi Mijia Internet Washing e Drying

Vacca boia.
A volte si fa fatica a capire quanto possano essere effettivamente potenti questi aggeggini.
Il mio primissimo PC era un P3 733Mhz, 128MB di RAM SDR e con integrata Intel con 8MB di RAM condivisa ...
E Quake 3 lo facevo girare a 1024x768 a 85fps fisso in openGL dell'epoca.

Questo non mi pare che dopo 20 anni e passa vada molto di più, piccolo sì ma se i risultati sono questi è scarso.

effettivamente non mi pare questo miracolo di ottimizzazione, tutto sommato quel modello dovrebbe avere un quad core con Cortex-A53 a 1.4ghz, naturalmente sono architetture diverse ma dovrebbe essere decisamente più potente rispetto ai Pentium 3 cloccati sotto al ghz dell'epoca

effettivamente non mi pare questo miracolo di ottimizzazione, tutto sommato quel modello dovrebbe avere un quad core con Cortex-A53 a 1.4ghz, naturalmente sono architetture diverse ma dovrebbe essere decisamente più potente rispetto ai Pentium 3 cloccati sotto al ghz dell'epoca180nm all'epoca ed era pure all'avanguardia. :asd:

Tutto bello, ma Quake 3 è un gioco del 1999.
21 anni fà.
Ad oggi, dovrebbe girare anche nella mia lavatrice xiaomi.

La xiaomi fa pure le lavatrici?

Comunque si, è tanto impressionante che ci sia riuscito quanto inutile, poi oovviamente si tratta solo di un puro esercizio di ingegneria, come quelli che fanno i porting per le calcolatrici scientifiche.

Quake 3 è un gioco del 1999 che girava su un PC che consumava, a pieno carico, diciamo sui 100/120 Watt monitor escluso a 1024x768, talvolta con il compromesso dei 16 bit di profondità colore.

La GPU VideoCore IV anche è una GPU di circa una decina di anni anziana. Un raspberry diciamo che grossomodo si attesta sui 6-7 Watt di consumo sotto un carico di questo tipo, con performance paragonabili se non migliori (oltre 100 fps, 720p, 32 bit di colore) la differenza a me pare abissale sotto tutti i punti di vista, soprattutto considerando i circa 12 anni fra l'uscita del gioco e la commercializzazione del primo rpi

Il mio primissimo PC era un P3 733Mhz, 128MB di RAM SDR e con integrata Intel.
E Quake 3 lo facevo girare a 1024x768 a 85fps fisso in openGL dell'epoca.

Questo non mi pare che dopo 20 anni e passa vada molto di più, piccolo sì ma se i risultati sono questi è scarso.

ne dubuto fortemente

http://images.anandtech.com/old/video/nvidia/geforce2gts/image026.gif

Quake 3 è un gioco del 1999 che girava su un PC che consumava, a pieno carico, diciamo sui 100/120 Watt monitor escluso a 1024x768, talvolta con il compromesso dei 16 bit di profondità colore.Che centra scusa ?
Quello è merito della miniaturizzazione, non dell'ottimizzazione.

ne dubuto fortemente

http://images.anandtech.com/old/video/nvidia/geforce2gts/image026.gif
Continua a dubitare allora

Continua a dubitare allora

Senza offesa ma anche secondo me, forse, ti ricordi male. Considera il mio pc dell'epoca:

AMD Duron 800 mhz, Geforce 2 GTS, 256 mb di RAM - mi sembra già DDR ma non vorrei sbagliarmi - HDD Maxtor 7200 rmp.

E il frame rate era più o meno quello della tabella postata da voodooFX, soprattutto a 32 bit mi ricordo bene che Quake3 "ammazzava di brutto" le performances delle macchine dell'epoca. Ergo con la grafica integrata, quello che sostieni è "quantomeno improbabile", salvo che non avessi tutta la grafica del gioco impostata su "low", con qualità texture a 16 bit...e anche così sarebbe stata dura raggiungere tali livelli di fps...

ps. mi sta venendo voglia di riaccendere il mio fidato AMD K6-3 con Voodoo5 5500 e postare i risultati del timedemo...quasi quasi...:D

Continua a dubitare allora

Sulla CPU ok.
Ma la grafica integrata impossibile.

Anche io come tutti qui denttro mi sono sfondato di Unreal tournament e Quake 3 Aarena.
Ai tempi avevo un athlon 1 Ghz cos 256mb ram (che erano abbondanti) ma una Geforce 2 gts come GPU.
E per giocare bene a quei titoli una GPU discreta tipo quella era obbligatoria.

Confermo, da ex possessore di Riva TNT 1 prima e Geforce 1 DDR poi, su Mendocino 366@550 prima e Thunderbird 1000@1333 poi.
Sul monitor CRT da 19" potevo settare comodo i 1280x1024, ma toccava abbassare parecchio i dettagli, quindi spesso usavo i 1024

Su Raspberry il dettaglio non sembra al massimo, ma su Twitter l'autore ha scritto che ha provato anche i 1080p e le prestazioni erano abbastanza buone.
Saranno passati più di 20 anni, ma fa' colpo vedere quelle prestazioni su un hw da 25$

... e cosi capisce ancora una volta dove possono arrivare le ottimizzazioni software e dei driver. Ottimizzazioni su particolari HW. E' uno dei punti di forza delle Apple con hw proprietario e pochi modelli, era il perche i telefoni di fascia Lumia con Ms WinPhone erano fluidi alla pari dei top di gamma android. Sappiamo la pesantezza e la virtualizzazione di Android, ed i compromessi per far girare su tanti dispositivi; solo ora che è aumentata la potenza delle CPU e l'aumento di memoria anche gli android non di fascia alta sono fluidi. Ecco ancora il perché da sempre i giochi sulle consolle molto spesso vanno meglio di computer con costose schede grafiche discrete.

Oppure mostra semplicemente quali sono i reali limiti dell'hardware.

Io non griderei al miracolo francamente. Proprio perché parliamo di un gioco di 20 anni fa su hardware, il Raspberry 3B+ che è abbastanza recente.

Cioè in sostanza ci sta dicendo che CPU+GPU di quel Raspberry sono paragonabili a sistemi con una GeForce2 di molti molti molti anni fa.

...Posso dirlo? POSSO?? ...Ora lo dico, pronti??

CI GIRA CRYSIS??

...L'HO DETTO! Sono un genio, nessuno avrebbe mai pensato a questa battuta.

...
https://uploads.tapatalk-cdn.com/20200622/db6a5ad0054b8d027878b86b0fa5dd73.jpg

CUT.

Oh nooo che delusione!

Non vi impressiona che un gioco di vent'anni fa giri bene? Un PC gaming dell'epoca consumava 150/200 W e costava (ad oggi) 2/3k €. Una Raspberry va a pile e costa 40 €, e su molte altre cose lo asfalta (e aggiungerei che gioco e driver non sono ottimizzati). Se volete spendere e consumare un pelino di più, ci sono anche SBC più potenti.
Io sono più impressionato da questo che non dai PC gaming odierni, nonché dai giochi, che spesso oltre alla grafica non offrono granché come evoluzione.

Oppure mostra semplicemente quali sono i reali limiti dell'hardware.

Io non griderei al miracolo francamente. Proprio perché parliamo di un gioco di 20 anni fa su hardware, il Raspberry 3B+ che è abbastanza recente.

Cioè in sostanza ci sta dicendo che CPU+GPU di quel Raspberry sono paragonabili a sistemi con una GeForce2 di molti molti molti anni fa.

Miracolo magari no, ma notevole di sicuro. Almeno per me.
Il gioco è di venti anni suonati, ma parliamo di un titolo che per girare all'epoca necessitava di un signor PC con tanto di GPU gaming.
Oggi tutta quella potenza è restituita da un single board computer super economico raffreddato passivamente che consuma pochi watt.

Non vi impressiona che un gioco di vent'anni fa giri bene? L'impressionabilità cada appena finisci di dire che parliamo di un gioco di vent'anni fa fatto girare ad una risoluzione analoga a quella dell'epoca.
Se è per questo gira meglio sui telefonini.

L'impressionabilità cada appena finisci di dire che parliamo di un gioco di vent'anni fa fatto girare ad una risoluzione analoga a quella dell'epoca.
Se è per questo gira meglio sui telefonini.

A me sembra tutto come da programma. Il tasso di evoluzione è grossomodo sempre stato questo: desktop -> 10 anni dopo notebook -> 10 anni dopo tascabile. Negli ultimi anni c'è stata un'accelerazione nei tascabili, ma che costano più di un Raspberry :D

Non vi impressiona che un gioco di vent'anni fa giri bene? Un PC gaming dell'epoca consumava 150/200 W e costava (ad oggi) 2/3k €. Una Raspberry va a pile e costa 40 €, e su molte altre cose lo asfalta (e aggiungerei che gioco e driver non sono ottimizzati). Se volete spendere e consumare un pelino di più, ci sono anche SBC più potenti.
Io sono più impressionato da questo che non dai PC gaming odierni, nonché dai giochi, che spesso oltre alla grafica non offrono granché come evoluzione.

Questo!

L'impressionabilità cada appena finisci di dire che parliamo di un gioco di vent'anni fa fatto girare ad una risoluzione analoga a quella dell'epoca.
Se è per questo gira meglio sui telefonini.

Un gioco di venti anni fa che gira alla grande su hardware di dieci anni fa' con una manciata di watt non è notevole?
L'hardware di un raspberry è paragonabile ma di gran lunga più datato di un qualsiasi moderno telefono cellulare da 100€.
Se prendi un raspberry pi zero (https://cdn.shopify.com/s/files/1/2187/3161/products/cba5e4e317b457b3ddf81ab1dc6b8c5e_1024x.png?v=1520446002) (su cui appunto Quake3 ci gira analogamente) stiamo parlando di un hardware dal costo al pubblico di 5 euro !!

Peraltro ricordo perfettamente che all'epoca avevo un k6-2 450 Mhz e una Matrox G400. Quake3 girava talmente male da essere ingiocabile a 1024x768. Dubito che con una integrata intel, che all'epoca forse manco aveva i driver opengl, facessi i numeri di cui parli. Qua si parla di 70 FPS in full-hd con 30€ di hardware...

Questo!



Un gioco di venti anni fa che gira alla grande su hardware di dieci anni fa' con una manciata di watt non è notevole?
L'hardware di un raspberry è paragonabile ma di gran lunga più datato di un qualsiasi moderno telefono cellulare da 100€.
Se prendi un raspberry pi zero (https://cdn.shopify.com/s/files/1/2187/3161/products/cba5e4e317b457b3ddf81ab1dc6b8c5e_1024x.png?v=1520446002) (su cui appunto Quake3 ci gira analogamente) stiamo parlando di un hardware dal costo al pubblico di 5 euro !!

Peraltro ricordo perfettamente che all'epoca avevo un k6-2 450 Mhz e una Matrox G400. Quake3 girava talmente male da essere ingiocabile a 1024x768. Dubito che con una integrata intel, che all'epoca forse manco aveva i driver opengl, facessi i numeri di cui parli. Qua si parla di 70 FPS in full-hd con 30€ di hardware...
Hardware di 10 anni fa ?
E con questo ? La tecnologia ha fatto passi avanti da gigante dagli anni 90 al 2010.

70fps in FullHD ? Quindi da 720p a 1080p cala solo del 30% ? Magari.
Io a Quake 3 ci giocavo alla perfezione.

L'hardware di un raspberry è paragonabile ma di gran lunga più datato di un qualsiasi moderno telefono cellulare da 100€.Chi dice il contrario ?

Io a Quake 3 ci giocavo alla perfezione.

Ormai sono troppo curioso. Se ti ricordi dimmi il modello della scheda madre o il nome preciso della gpu intel integrata. Mi confermi a 1024x768@32 bit con dettagli alti, 85 fps ?

Perchè voglio vedere cosa mi sono perso all'epoca...ripeto ci voleva almeno una Geforce 2 GTS o simile della concorrenza pari potenza per domare per domare per bene i 32 bit in Q3A....

@Saturn Ma infatti in video integrata manco a calcion Q3 andava. Per giocare al massimo ricordo un GF3 con Athlon a 1Ghz e 100/120 FPS.

É vero che c'erano delle eccezioni. Mappe pesantemente ottimizzate di Q3A riuscivano a far funzionare una scheda video come la Kyro2, che aveva un hardware molto obsoleto per l'epoca rispetto alla concorrenza, ad un frame-rate simile o in certi casi superiore a quello di una ben più dotata Geforce 2 GTS/Ultra...ma parliamo comunque di schede video dedicate.

Integrate nella motherboard dell'epoca che potessero anche solo lontanamente pensare di allacciare le scarpe a schede video ati, nvidia, 3dfx o matrox e perchè no, anche s3 con la sua Savage4, che io sappia non sono mai esistite.

Ormai sono troppo curioso. Se ti ricordi dimmi il modello della scheda madre o il nome preciso della gpu intel integrata. Mi confermi a 1024x768@32 bit con dettagli alti, 85 fps ?

Perchè voglio vedere cosa mi sono perso all'epoca...ripeto ci voleva almeno una Geforce 2 GTS o simile della concorrenza pari potenza per domare per domare per bene i 32 bit in Q3A....Non ricordo la scheda madre.
La profondità del colore era a 16bit.

Hardware di 10 anni fa ?
E con questo ? La tecnologia ha fatto passi avanti da gigante dagli anni 90 al 2010.

70fps in FullHD ? Quindi da 720p a 1080p cala solo del 30% ? Magari.
Io a Quake 3 ci giocavo alla perfezione.

Chi dice il contrario ?

I primi raspberry sono usciti sul mercato mi pare nel 2012, la GPU è ancora più vecchia.
I numeri sono tutti dell'autore del driver, lo scrive lui su twitter, non vedo il motivo di dubitare.

Sul fatto che ci giocassi alla perfezione (85 fps, 1024x768 32 bit colore) con una integrata intel rimango decisamente scettico. All'epoca si parla del vetustissimo chipset i810...

Io a Quake 3 ci giocavo alla perfezione.


Ormai sono troppo curioso. Se ti ricordi dimmi il modello della scheda madre o il nome preciso della gpu intel integrata. Mi confermi a 1024x768@32 bit con dettagli alti, 85 fps ?

Perchè voglio vedere cosa mi sono perso all'epoca...ripeto ci voleva almeno una Geforce 2 GTS o simile della concorrenza pari potenza per domare per domare per bene i 32 bit in Q3A....


Visto che insiste vediamo di procedere con logica.

Parlando di Pentium3 733 il chipset poteva essere o il glorioso 440BX oppure il piu recente i810/i815.
Dato che il design del 440BX non prevedeva una scheda video integrata (vedi fonte1) doveva trattarsi di una soluzione con i81x, come ad esempio l'815EG.

Questo significa per forza di cose che sta parlando di un i752/i754 (vedi fonte2), versione leggermente migliorata (ma sempre a singola pipeline) dell'intel 740, una delle schede con accelerazione 3D piu lente della storia, che non faceva quei numeri nemmeno in GLQuake o Quake II.


fonte1: https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units
fonte2: https://en.wikipedia.org/wiki/Intel740#Successor

Ma quindi se oggi si progettasse da zero, un videogame per raspberry4 (con 8gb di ram) che livello di grafica ci dovremmo attendere?
Sarebbe interessante capirlo.
Non sto parlando di emulazione ovviamente.
Qualcuno ironicamente prima ha citato il solito Crysis... Volendo si potrebbe arrivare a quel dettaglio su un cosino da 80€?
Perché non esistono vg nativi per questo hardware?

Non ricordo la scheda madre.
La profondità del colore era a 16bit.

Ok. Allora forse ci sta come framerate.

16 bit, dettagli sicuramente abbassati su low/medium...

Certo 85 fps @ 1024x768 sono comunque veramente tanta roba per un P3 dell'epoca e un'integrata...
Rimane comunque un risultato molto alto, salvo che avessi disabilitato il lightmap...ho indovinato si ?

Cioè boh.
questo si è fatto il :ciapet: per due anni creando da _zero_ un supporto vulkan al raspberry pi4, abilitandolo potenzialmente a nuovi ed interessanti progetti potendo contare sulla gpu integrata tramite le nuove api vulkan....ed in questo thread vedo la maggior parte delle persone denigrare l'operato, tutti ingegneri e mister ovvio qua dentro.

Bisogna essere un minimo competenti per capire l'utilità delle cose.

É vero che c'erano delle eccezioni. Mappe pesantemente ottimizzate di Q3A riuscivano a far funzionare una scheda video come la Kyro2, che aveva un hardware molto obsoleto per l'epoca rispetto alla concorrenza, ad un frame-rate simile o in certi casi superiore a quello di una ben più dotata Geforce 2 GTS/Ultra...ma parliamo comunque di schede video dedicate.

Integrate nella motherboard dell'epoca che potessero anche solo lontanamente pensare di allacciare le scarpe a schede video ati, nvidia, 3dfx o matrox e perchè no, anche s3 con la sua Savage4, che io sappia non sono mai esistite.

La kyro2 in realtà non era poi così obsoleta, anzi! Teneva parecchio testa alle Geforce di prima generazione, e andava pure meglio con colore a 32 bit perché renderizzava internamente sempre a 32 bit, consumando meno ed essendo meno "carrozzata" in termini di frequenze e memorie grazie al tile-based rendering, tecnica che oggi ci ritroviamo nelle moderne GPU per sistemi embedded.

Concordo in pieno sul fatto che le neonate schede video integrate all'epoca (anni 2000) erano praticamente inesistenti dal punto di vista prestazionale. Erano buone solo per uso base 2D e nient'altro.

Comunque si, è tanto impressionante che ci sia riuscito quanto inutile, ...
Sicuro sia così inutile?
All'ultimo GioComix hanno fatto il torneo di Quake 3 Arena sui Raspberry, con costi hardware di creazione delle postazioni irrisori. ;)

Sul fatto che ci giocassi alla perfezione (85 fps, 1024x768 32 bit colore) con una integrata intel rimango decisamente scettico. All'epoca si parla del vetustissimo chipset i810...
C'è poco da rimanere scettici, chi ci ha giocato sa bene che è impossibile, anche con config pesantemente tweakata.
Diciamo che tanto per cambiare, ha detto una ca, ehm, ricorda male. ;)

@Saturn
La Kyro2 non andava affatto male su Q3A, per quel che costava ai tempi era un ottimo acquisto.

La kyro2 in realtà non era poi così obsoleta, anzi! Teneva parecchio testa alle Geforce di prima generazione, e andava pure meglio con colore a 32 bit perché renderizzava internamente sempre a 32 bit, consumando meno ed essendo meno "carrozzata" in termini di frequenze e memorie grazie al tile-based rendering, tecnica che oggi ci ritroviamo nelle moderne GPU per sistemi embedded.

Concordo in pieno sul fatto che le neonate schede video integrate all'epoca (anni 2000) erano praticamente inesistenti dal punto di vista prestazionale. Erano buone solo per uso base 2D e nient'altro.

Obsoleta dal punto di vista delle ottimizzazioni e delle novità software che introduceva assolutamente no. Parlavo solo dell'hardware. Poi perdonami se perdo qualche pezzo, ma son passati parecchi anni ormai. Ad ogni modo ne ho posseduta una, mi ricordo ancora la mappa di Q3A ambientata all'interno della piramide che andava fluida appunto solo con la Kyro2 e metteva in crisi la concorrenza. Detto questo, rimasi su nVidia. Ci volle la Ati con la sua Radeon 8500 per convincermi a passare per qualche anno alla concorrenza. Anche posseduto Matrox, S3, 3Dfx insomma mie o non mie le ho testate un po' tutte...è dai tempi in cui si spogliava Lara Croft in Tomb Raider su Dos che smadonno e butto via quattrini con questi pezzi di silicio...non oso fare il conto del totale speso...che altrimenti ci rimango male...maledette (ex) passioni... :asd:

ps. qualcuno qui si ricorda di RadeonItalia ?!? :)


@Saturn
La Kyro2 non andava affatto male su Q3A, per quel che costava ai tempi era un ottimo acquisto.

Rapporto prezzo/prestazioni non era affatto male, Q3A sia sulle mappe ottimizzate che su quelle normali era godibilissimo con la suddetta scheda, come già infatti ho scritto. :)

Ma quindi se oggi si progettasse da zero, un videogame per raspberry4 (con 8gb di ram) che livello di grafica ci dovremmo attendere?
Sarebbe interessante capirlo.
Non sto parlando di emulazione ovviamente.
Qualcuno ironicamente prima ha citato il solito Crysis... Volendo si potrebbe arrivare a quel dettaglio su un cosino da 80€?
Perché non esistono vg nativi per questo hardware?

Un raspberry pi 4, che non è oggetto del driver Vulkan di cui si parla nell'articolo, perché la sua GPU è una VideoCore VI, a quanto ne so ha supporto pieno a OpenGL ES 3.2, quindi Crysis può essere renderizzato completamente dall'hardware della GPU, ammesso che si palesasse una versione tale.

Ora non vorrei dire fregnacce, ma i raspberry Pi 3 e inferiori, che hanno invece una VideoCore IV, hanno supporto a OpenGL ES 2.0, quindi supportano lo Shader Model 2.0 e qualcosa del 3.0, per cui in teoria Crysis potrebbe girare in hardware anche sui vecchi rpi.

La parola "nativo" poi ha poco senso nell'accezione con cui la intendi: nessuna software house sana di mente farebbe qualcosa senza utilizzare diversi livelli di astrazione (leggi driver e librerie).

Un raspberry pi 4, che non è oggetto del driver Vulkan di cui si parla nell'articolo, perché la sua GPU è una VideoCore VI, a quanto ne so ha supporto pieno a OpenGL ES 3.2, quindi Crysis può essere renderizzato completamente dall'hardware della GPU, ammesso che si palesasse una versione tale.

Ora non vorrei dire fregnacce, ma i raspberry Pi 3 e inferiori, che hanno invece una VideoCore IV, hanno supporto a OpenGL ES 2.0, quindi supportano lo Shader Model 2.0 e qualcosa del 3.0, per cui in teoria Crysis potrebbe girare in hardware anche sui vecchi rpi.

La parola "nativo" poi ha poco senso nell'accezione con cui la intendi: nessuna software house sana di mente farebbe qualcosa senza utilizzare diversi livelli di astrazione (leggi driver e librerie).
Grazie della spiegazione!
Volevo farmi semplicemente un'idea di cosa si potrebbe ottenere da questo tipo di hardware.
Probabilmente si arriverebbe ad un livello grafico pari, grossomodo, a quello di un nintendo switch o smartphone di fascia media/alta (livello più che dignitoso per le cifre in ballo).
Mi rimane il dubbio del perché questi minipc (io ho il rb3 semi inutilizzato) non vengano presi in considerazione dalla software house ma siano sfruttati solo per emulazione e retrogaming.

Sai che risate che si fa la vetusta Voodoo3? :p

Considerando le specifiche e la potenza che "in teoria" ci si dovrebbe aspettare, altro che Quake3.
Ad ogni modo interessante ma 720p immagino tipo 1280x768, non certo una risoluzione galattica considerando quelle dell'epoca molto simili.
Non si sta' parlando del primo RPi con un ARM11 da 700Mhz e la solita gpu condivisa fino alla terza versione, immagino si stia parlando dell'ultima giusto?
[EDIT: errore mio pensavo si parlasse dell'ultima RPi non le precedenti]

Sicuro sia così inutile?
All'ultimo GioComix hanno fatto il torneo di Quake 3 Arena sui Raspberry, con costi hardware di creazione delle postazioni irrisori. ;)

Oh Dio al "GioComix" hanno giocato a quake 3 con i rasperry?? Lanciate la campagna di crowdfunding PRESTO! :D

Ovviamente scherzo, sicuramente una maniera di sfruttare la cosa qulcuno la potrebbe anche trovare, ma si tratta più di qualcosa di pittoresco che di realmente pratico e le alternative già pronte non mancano... Insomma vuoi organizzare un lan party di retrogaming? Quanti vecchi mini pc da ufficio ci sono in rete a dieci euro che potrebbero far girare quella roba molto meglio di quegli affarini? O davvero dici che nei costi dell'evento dovrebbe avere una qualche rilvanza il consumo di qualche pc da ufficio per un giorno? (o più giorni? non so come funziona sto giocomix).

Ripeto, figo. Ma mi pare abbastanza irrilevante.

@kamon
Scherzi vero? :D
Se devo fare una cosina retrogaming con amici possono anche andare bene i vecchi PC, ma in un ambito più serio contano tanti fattori tra cui tempi, costi, logistica, magazzino. La soluzione Raspberry era praticabile, altre soluzioni no.
Comunque era solo un esempio, una cosa per essere utile non deve essere ne la miglior soluzione possibile ne essere utilizzata da tutti. Semplicemente non darei dell' "inutile" con troppa fretta. :)

E poi non chiamarmi Q3A retrogaming! :p

Non si sta' parlando del primo RPi con un ARM11 da 700Mhz e la solita gpu condivisa fino alla terza versione, immagino si stia parlando dell'ultima giusto?

Si sta parlando delle prime 3 versioni anche se il test è stato fatto sulla penultima.

Ma quindi se oggi si progettasse da zero, un videogame per raspberry4 (con 8gb di ram) che livello di grafica ci dovremmo attendere?
Sarebbe interessante capirlo.
Non sto parlando di emulazione ovviamente.
Qualcuno ironicamente prima ha citato il solito Crysis... Volendo si potrebbe arrivare a quel dettaglio su un cosino da 80€?
Perché non esistono vg nativi per questo hardware?
Imho per come si e' evoluta soprattutto nell'ultima versione, le aspettative potranno essere migliori e gia' in parte lo erano a livello di CPU rispetto ad un computer low-end retro' x64.
Tempo fa ho visto i risultati di un Atom D2x00 x64 su linux a confronto con quelli di un Rpi 3/4 e gia' il sorpasso c'era stato in termini sintetici sui numeri dei benchmark su linux per quanto riguarda la CPU/FPU. Ma se si comincia a paragonare un soc mobile nato per consumare nell'insieme meno di 10 watt con processori anche vecchi desktop che magari invece ne consumano n volte tanto + n volte tanto di gpu, e' ovvio che e' tutto piu' mischiato tra l'aspettativa e il risultato.
Alla fine quello che i videogiocatori vedono sui loro smartphone, che hanno gia' risoluzioni elevate se li confrontiamo con un monitor dell'epoca, e' quello che ci si dovrebbe aspettare, dubito magari sbagliando che drivers low-level facciano differenze esagerate ma nel caso ben vengano.
Il punto di fondo imho e' che non sono architetture nate per macinare potenza ad ogni costo e considerando il numero di watt a livello di CPU fanno gia' miracoli, sebbene a livello di GPU non avrei preso Quake3 come esempio ma magari qualcosa che mostrasse le compatibilita' OpenGL della GPU a prescindere dal frame rate. ;)

Non si sta' parlando del primo RPi con un ARM11 da 700Mhz e la solita gpu condivisa fino alla terza versione, immagino si stia parlando dell'ultima giusto?

Invece si sta parlando proprio di quello: "Il driver è compatibile con la GPU Broadcom VideoCore IV a bordo dei Raspberry Pi 1, 2, 3 e Zero"

Si sta parlando delle prime 3 versioni anche se il test è stato fatto sulla penultima.

Invece si sta parlando proprio di quello: "Il driver è compatibile con la GPU Broadcom VideoCore IV a bordo dei Raspberry Pi 1, 2, 3 e Zero"

Ho risposto veloce e immaginavo dando per scontato fosse stato sviluppato per l'ultima, ad ogni modo e' impossibile comparare a parita' di gpu le prime tre versioni avendo architetture della CPU praticamente a distanza siderale in termini prestazionali e di ram in particolar modo. La prima cpu era in qualche modo paragonabile ad un Pentium II/III in termini prestazionali.
Se si parla della penultima la cosa ha certo piu' senso ma allora imho il limite e' proprio quello della GPU che appunto e' la stessa per tutte le versioni iniziali e forse anche della ram utilizzando una frazione di quel solo giga di DDR2 su sistemi operativi e kernel aggiornati e quindi non proprio leggeri oggigiorno. Comunque la parte piu' interessante e' appunto che finalmente ci si dedica in maggior modo alla parte di questi soc che lato linux solo negli ultimi anni ha visto un driver ufficiale a sfruttare la parte 3D.
Ricorda l' Atom che di suo praticamente aveva una gpu nel Cedarview non molto usata forse per i risultati reali di fronte a specifiche sulla carta di rispetto ma imho spiegabili sul target di queste soluzioni di provenienza mobile, una SGX545 e che messa sotto stress con 3DMark2005 (non certo leggero) aumentava rispetto alla situazione idle in desktop tipo meno di 3 watt il consumo totale del pc (per un consumo ipotetico della sola gpu boh forse di 5 watt?) e imho spiega perche' possano essere paragonabili con le aspettative gaming di desktop di anni 2003 in su, le cui schede video magari ne consumavano 30 watt a salire.
Imho i risultati reali in aspettative sono gia' visibili nei giochi per smartphone droid che non conosco ma dicono essere graficamente interessanti sebbene immagino girano oggigiorno su GPU piu' avanzate di quella delle prime tre rpi.

Un lavoro immane di tutto rispetto, complimenti!

Scommetto che tutti gli sviluppatori che qui dissertano sulla scelta di Quake3, sull'accadì o sul fullaccadì, sui 16/32 bit e sui FPS sono pronti a contribuire con delle congrue pull request verso il repository dell'ingegner Thomas, vero?

Il lavoro e' interessantissimo, i numeri magari lo sono anche, ma per come la vedo le SBC nelle prime versioni non erano semplicemente nate per il gaming (ne per il retrogaming se non possono prima ancora delle capacita' stesse far ovviamente girare codice x86). Ma sono sempre stato un appassionato di single board computer, le rpi le ho avute tutte tranne l'ultima. :)

Questi erano miracoli: https://m.youtube.com/watch?v=2NF5sU_n0uk

Su architetture x86 di miracoli se ne sono visti parecchi ad esempio se consideriamo su che hardware girava Quake, su che hardware girava GLQuake, su che hardware girava Doom3, su che hardware girava la tech demo musicale della Radeon 9700 o andando indietro esistevano emulatori di console 8bit che giravano su cpu 80486 etc, etc,..
Ma anche su console laddove tutto e' piu' dedicato, vedere Quake2 girare a piu' di 30fps su una PSP (cpu MIPS 333Mhz) accelerato o giochi 3D come Kawasaki Superbike Challenge girare fluidi sul Motorola 68000 del Mega Drive.
Pero' si parla di situazioni diverse con tutto l'ecosistema software e hardware nato per essere low-level, ben venga se il futuro si ritornera' per quanto parzialmente possibile a codice piu' a basso livello.
:)

...a proposito di miracoli...

S3 Virge con wrapper OpenGL (https://www.youtube.com/watch?v=gPyIwJHs4Vo) che "accelera" Gl Quake e Quake2 - anche se parte del merito va al Pentium III @ 1ghz utilizzato...

Comunque WOW...:eek:

...a proposito di miracoli...

S3 Virge con wrapper OpenGL che "accelera" Gl Quake e Quake2 - anche se parte del merito va al Pentium III @ 1ghz utilizzato...

Comunque WOW...:eek:

Peccato fosse appunto un wrapper Opengl-Directx5 e non un uso nativo come quei giochi pochi che la sfruttavano direttamente tipo Tomb Raider (magari 1fps in piu' ne sarebbe uscito.. :p).
Impressionante si comunque. Personalmente ho rivalutato negli anni anche l' ATi Rage IIc con cui ho visto girare giochi come Half Life sebbene a simili frame rates ma inaspettatamente comunque.
Ma se proprio ci si vuole impressionare basta lanciare l' originale Quake su un processore 80386DX e coprocessore separato 80387 possibilmente entrambi a 40Mhz, la migliore scheda video per questa config e vedere girare il gioco. Se davvero si vuole spremere l'hardware. :p

incredibile, un gioco del 1999 che gira su un hardware del 2018

Peccato fosse appunto un wrapper Opengl-Directx5 e non un uso nativo come quei giochi pochi che la sfruttavano direttamente tipo Tomb Raider (magari 1fps in piu' ne sarebbe uscito.. :p).
Impressionante si comunque. Personalmente ho rivalutato negli anni anche l' ATi Rage IIc con cui ho visto girare giochi come Half Life sebbene a simili frame rates ma inaspettatamente comunque.
Ma se proprio ci si vuole impressionare basta lanciare l' originale Quake su un processore 80386DX e coprocessore separato 80387 possibilmente entrambi a 40Mhz, la migliore scheda video per questa config e vedere girare il gioco. Se davvero si vuole spremere l'hardware. :p

Mancava il link...aggiunto se vuoi dare un'occhiata ! ;)

Mancava il link...aggiunto se vuoi dare un'occhiata ! ;)

Avevo costruito una config apposita anni fa per provarlo e di recente ho provato il Rage IIC su un Pentium3 500. :) Tra l'altro c'erano tweak possibili per migliorarne le prestazioni. L' S3 Virge nelle sue varie versioni era tecnicamente di tutto rispetto ed ebbe un gran successo forse non per le prestazioni ma aveva features molto complete per l'epoca e montata da una marea di terze parti e prestazioni a parte era un acceleratore a/con tutti gli effetti, sebbene per S3 si dovette attendere il Savage3D come chip prestante ma credo avesse i suoi problemi iniziali fino ad un migliore Savage4.
A suo tempo avevo il Trio3D, evoluzione 128bit del Virge.

Avevo costruito una config apposita anni fa per provarlo e di recente ho provato il Rage IIC su un Pentium3 500. :) Tra l'altro c'erano tweak possibili per migliorarne le prestazioni. L' S3 Virge nelle sue varie versioni era tecnicamente di tutto rispetto ed ebbe un gran successo forse non per le prestazioni ma aveva features molto complete per l'epoca e montata da una marea di terze parti e prestazioni a parte era un acceleratore a/con tutti gli effetti, sebbene per S3 si dovette attendere il Savage3D come chip prestante ma credo avesse i suoi problemi iniziali fino ad un migliore Savage4.
A suo tempo avevo il Trio3D, evoluzione 128bit del Virge.

A dire il vero io la S3 Virge me la ricordo come una vera patacca. Faceva parte della prima generazione di acceleratori 3D, ma era veramente lenta, tant'è che è rimasta nel mio immaginario come l'unico "deceleratore 3D". La montavano un po' dappertutto sui PC assemblati di fascia bassa.

Il Savage 4 invece mi ricordo che era di tutto rispetto, aveva anche il filtro trilineare gratis, ma aveva anche dei driver pessimi che la facevano bloccare ogni 3x2.

A dire il vero io la S3 Virge me la ricordo come una vera patacca. Faceva parte della prima generazione di acceleratori 3D, ma era veramente lenta, tant'è che è rimasta nel mio immaginario come l'unico "deceleratore 3D". La montavano un po' dappertutto sui PC assemblati di fascia bassa.

Il Savage 4 invece mi ricordo che era di tutto rispetto, aveva anche il filtro trilineare gratis, ma aveva anche dei driver pessimi che la facevano bloccare ogni 3x2.

La S3 Virge ha visto diverse varianti e spesso la si giudica mettendola a paragone di schede come la Voodoo Graphics che usci' nel tardo 1996 quando la prima S3 Virge l'anno precedente e a tutti gli effetti era un acceleratore 2D/3D che ovviamente aveva come focus non necessariamente l'accelerazione 3D (che comunque per l'epoca era interessante da un punto di vista tecnico, considerando anche S3 promuoveva le sue API S3d con essa) ma principalmente continuare su un filone di accelerazione 2D da cui provenivano le precedenti versioni e che piu' o meno era quello che facevano tutti ad esempio Matrox con l' Impression Plus o il Millennium. A quei tempi il 3D cominciava ad essere fondamentale ma lontano dall'essere "comune" e utilizzabile. S3 negli anni precedenti aveva sviluppato ottime soluzioni 2D che erano considerate al top della gamma come l'S3 Vision968 ad esempio.
Poi purtroppo il mondo console cominciava a spingere molto sul 3D e quindi le aspettative create dalla Playstation in termini di giochi 3D avevano spiazzato un po' tutti ovunque, senza considerare pero' il target differente delle soluzioni e hardware completamente diversi e imparagonabili gia' al lancio a favore teoricamente delle configurazioni PC ma nei fatti la PS1 appariva ed era certamente piu' impressionante nel 1994/5.
Se guardiamo alla concorrenza su PC non mi sembra di vedere molti acceleratori del 1995 poter rivaleggiare sul piano di accelerazione poligonale in termini di features e nemmeno velocita', erano tutti piu' o meno poco utilizzabili a seconda del numero di giochi le cui API proprietarie erano supportate e ce n'erano diversi giochi che giravano per la suddetta (per le aspettative dell'epoca) che giravano benino sfruttando le features del chip.
Spesso il problema di questi chip (cosi' come provai io sul Trio3D) era il supporto drivers oltre al fatto che a parte tot giochi non bisognava certo aspettarsi la compatibilita' di vederla sfruttata per tutte le features con "tutti" i giochi che invece rimanevano ancora software rendered, vedi Quake uscito nel 1996. Aspettativa che e' nata con l'arrivo di schede successive ben piu' potenti ma con la comodita' del tempo che passa tipo il Riva128 o il Savage3D o il Matrox G100/G200.
Di schede con chip Virge nelle sue varianti originale,DX,VX,GX,GX2 ne hanno stampate tantissime e se ne trovavano ovunque. Forse e' stato questo un problema che spesso molte configurazioni su cui erano montati quei chip lasciavano a desiderare come qualita' costruttiva, filtri, componenti usati etc...
Ma va tutto contestualizzato storicamente. La Voodoo Graphics fu una gran scheda ma un po' comoda, solo acceleratrice e quindi non avendo l'onere di tutta la parte 2D e di fatto se non era per un gran supporto sulle API Glide e per i miniGL per GLQuake avrebbe avuto molta meno notorieta' imho. Notorieta' che sembrava aver fatto dimenticare tutta l'evoluzione che S3, Cirrus Logic, ATi, Matrox e molti altri avevano fatto nel 2D come se da allora quello non serviva piu'. E infatti si e' visto le prime soluzioni 2D/3D di 3DFx come furono "ben costruite" e le difficolta' di arrivare ad una soluzione all-in-one che fosse buona in entrambi gli ambiti.

La S3 Virge ha visto diverse varianti e spesso la si giudica mettendola a paragone di schede come la Voodoo Graphics che usci' nel tardo 1996 quando la prima S3 Virge
...cut...
E infatti si e' visto le prime soluzioni 2D/3D di 3DFx come furono ben costruite e le difficolta' di arrivare ad una soluzione all-in-one che fosse buona in entrambi gli ambiti.

Grazie per la disamina, però ricordo che la S3 Virge fu contemporanea a prodotti come la Matrox Mystique (che avevo), la prima 3dfx voodoo, e nella mia memoria tornano in mente nomi come Rendition Veritè e Ati Rage. E in mezzo a tutte c'era anche, appunto, la S3 Virge. Però come giustamente fai notare c'erano tante versioni, e forse quelle che mi capitavano spesso fra le mani erano (vado sempre a memoria, quindi potrei sbagliarmi) le DX, particolarmente poco performanti.

Comunque per tornate un pochino in topic, questo è un mio run del timedemo demo1.dm2 di Quake 2 su Rockchip 3288 con Mali T760MP4 :D

https://www.youtube.com/watch?v=IjfbuY48AgM

Grazie per la disamina, però ricordo che la S3 Virge fu contemporanea a prodotti come la Matrox Mystique (che avevo), la prima 3dfx voodoo, e nella mia memoria tornano in mente nomi come Rendition Veritè e Ati Rage. E in mezzo a tutte c'era anche, appunto, la S3 Virge. Però come giustamente fai notare c'erano tante versioni, e forse quelle che mi capitavano spesso fra le mani erano (vado sempre a memoria, quindi potrei sbagliarmi) le DX, particolarmente poco performanti.

Comunque per tornate un pochino in topic, questo è un mio run del timedemo demo1.dm2 di Quake 2 su Rockchip 3288 con Mali T760MP4 :D

https://www.youtube.com/watch?v=IjfbuY48AgM

Se non ricordo male imho la Mystique originale usci' nel 96, la Mystique 220 nel 97. Ottime schede sul piano 2D e qualita' analogica all' output (ancora oggigiorno su un LCD tra l'altro) ma sul piano 3D la situazione beneficiava del progresso tecnologico (era piu' veloce), aveva un buon supporto drivers negli anni successivi ancora oggi si trovano i driver sulle pagine ufficiali di quelle soluzioni, ma all'atto pratico (senza poi l'accelerazione del filtro bilineare) era anch'essa legata alla vecchia concezione di schede principalmente 2D e con "supporto" 3D imho. La Rage usci' nel meta' 96. Il Vérité V1000 (interessante chip ma sembra di ricordare con diversi problemi soprattutto sul supporto in Dos) nel 96. Certo c'erano le versioni nuove del Virge come il DX "piu' veloci" ma certo non abbastanza appunto ma tutti allegramente dovettero vedersela con la novita' 3dfx ma senza l'onere di portare avanti i costi legati a costruire una soluzione che fosse 2D e 3D, allo stesso tempo competitiva e non troppo costosa.
Non voglio mitizzare certo quel chip, certamente "successo" (= numero di PC che la usavano) lo ebbe probabilmente perche' anche conveniente presumo come soluzione, ma se prendiamo il 1995 come anno di esempio, non c'era molto che facesse "tutto e bene", ogni soluzione aveva i suoi pro e contro e forse il Virge e' stato uno dei primi a lanciarsi nella battaglia 2D/3D. Di bello c'era che S3 aveva una gran esperienza nel 2D e una gran compatibilita' oltre ad un nome storico nel settore.

Sul video: certo interessante vedere girare a certe risoluzioni ma considerando la potenza "teorica" di molte soluzioni ARM ci si aspetterebbe talvolta o almeno avrei la sensazione, di veder giochi di quell' epoca letteralmente "volare". Ho come l'impressione che all'atto pratico molte soluzioni mobile moderne siano molto avanzate in termini di features ma sui giochi vecchi soprattutto non riescano a mostrare i loro muscoli forse per un discorso di non perfetta retrocompatibilita', forse perche' non ottimizzati. E non c'e' possibilita' di poterne (a parte mi sembra di capire recenti compatibilita' x64 "virtualizzate" mi sembra d'aver letto qualcosa sui processori Snapdragon) testare le capacita' con giochi veri su cui ci sia un know-how storico dei dati delle vecchie configurazioni su cui giravano nativamente.

Io sapevo che la GPU VideoCore IV che è presente nei SoC BCM2835-2836-2837 e 2837B0 (dal Pi 0/1 al Pi 3B+) non è compatibile con Vulkan ed è compatibile fino ad OpenGL ES 2.0 :confused:
Come ha fatto questo a farci girare Vulkan?
La GPU VideoCore VI cioè del Pi4 è 100% compatibile ed un driver è già in sviluppo da tempo.
Mi sono perso qualcosa?

Comunque si, è tanto impressionante che ci sia riuscito quanto inutile, poi oovviamente si tratta solo di un puro esercizio di ingegneria, come quelli che fanno i porting per le calcolatrici scientifiche.
In realtà no, se continua lo sviluppo e continuano ad ottimizzarlo, le potenzialità per i vecchi Pi 0/1 fino al 3B+ possono essere enormi, e non parlo di giochi, ma di accelerazione hw su chromium ad esempio, che può utilizzare Vulkan.

incredibile, un gioco del 1999 che gira su un hardware del 2018
Hardware del 2009/2010 veramente... la GPU VideoCore IV ha i suoi bei anni.

Come ha fatto questo a farci girare Vulkan?
Mi sono perso qualcosa?

Sì, semplicemente non l'ha fatto:

"Quanto sviluppato da Thomas non è di per sé un driver Vulkan "al 100%", in quanto non è conforme agli standard ufficiali stabiliti dal consorzio Khronos Group, sebbene aderisca quanto più possibile ai parametri di Vulkan, anche in base a quanto consentito dall'hardware. "

Da analfabeta quindi mi pare di capire abbia scritto dei driver di basso livello che riprendono implementazioni di Vulkan ma che proprio per limiti dell'hardware di fatto non posano esserlo al 100%

Sempre da ignorante mi viene da pensare che si potrebbe fare la stessa cosa per molte vecchie gpu per pc, come quelle già menzionate nell'articolo, semplicemente il gioco "non vale la candela" anche perché poi immagino che ogni software andrebbe appositamente compilato per sfruttare al meglio questi driver...




In realtà no, se continua lo sviluppo e continuano ad ottimizzarlo, le potenzialità per i vecchi Pi 0/1 fino al 3B+ possono essere enormi, e non parlo di giochi, ma di accelerazione hw su chromium ad esempio, che può utilizzare Vulkan.
già, peccato che non si possa sfruttare sul raspy 4, sarebbe bello anche che qualcuno ne tiri fuori una versione per VideoCore VI

In realtà no, se continua lo sviluppo e continuano ad ottimizzarlo, le potenzialità per i vecchi Pi 0/1 fino al 3B+ possono essere enormi, e non parlo di giochi, ma di accelerazione hw su chromium ad esempio, che può utilizzare Vulkan.


Hardware del 2009/2010 veramente... la GPU VideoCore IV ha i suoi bei anni.

Imho il limite delle prime soluzioni non era tanto la potenza bruta (che imho c'era con le dovute considerazioni) nè la mancanza poi colmata di un drivers OpenGL. L'errore e' che talvolta ci si dimentica lo scopo forse "originario" per cui si puo' immaginare una SBC simile sia nata cioe' IMHO automazione, insegnamento alla programmazione, progetti hardware elettronici, etc.. non necessariamente pensionare un pc desktop.
Alla fine "ben venga" la potenza bruta a suo modo ma il collo di bottiglia IMHO era la velocita' di banda tra soc e microsd e tutta la condivisione della banda con le porte USB e Ethernet se non ricordo male almeno fino alla quarta versione ove hanno risolto del tutto la questione distanzandosi dalla precedente in maniera decisa.
Con la memoria ram del primo rpi (256/512MB DDR) e del secondo/terzo (1GB DDR2) su cui una parte era condivisa con la GPU e la limitata velocita' di accesso alla microsd praticamente usarlo come pc desktop mostrava i suoi limiti soprattutto sul web browser ove nel momento in cui finiva la disponibilita' della ram e cominciava a utilizzare lo swap su microsd si finiva in lunghe attese e spesso si faceva prima a riavviare. Non era un problema di renderizzazione OpenGL della pagina web ammesso che sia mai servita.
Bastavano anche le precedenti versioni del soc Cortex A7 o A53 se con molta piu' ram e con la questione microsd/usb/ethernet risolta prima se proprio si deve usarlo come desktop, non ho mai trovato nella potenza della CPU (a parte la prima ovvio) un limite.
E' da tenere presente poi che (fortunatamente) ci gira una customizzazione di debian linux aggiornata che non e' proprio leggera nemmeno per un vecchio computer x64 da 100 watt.
Poi chiaro, ben venga tutto quello che possa "spremere" un po' di potenza in piu'. :) Se consideriamo che sul primo soc, un ARM11 700Mhz la GPU poteva gia' facilmente decodificare video offline in FullHD quando la cpu in se e' appunto paragonabile ad un Pentium II o i primi Pentium III, era impressionante gia' di suo.

Secondo me si sta perdendo la vera filosofia del Raspberry. Una mini sched a basso costo accessibile a tutti dove poter realizzare progetti, anche didattici. Quello di far girare software multimediale la vedo come "un qualcosa in più".

già, peccato che non si possa sfruttare sul raspy 4, sarebbe bello anche che qualcuno ne tiri fuori una versione per VideoCore VI
Il driver per il Pi 4 è già in sviluppo da tempo.

Secondo me si sta perdendo la vera filosofia del Raspberry. Una mini sched a basso costo accessibile a tutti dove poter realizzare progetti, anche didattici. Quello di far girare software multimediale la vedo come "un qualcosa in più".
Ma anche no, il raspberry è nato per ciò che dici, ma essendo una piattaforma aperta nessuno vieta di farci anche ben altro, l'hardware c'è, specie adesso con il Pi 4, quindi perché non poterlo sfruttare anche per altro e per ciò che si vuole?

Imho il limite delle prime soluzioni non era tanto la potenza bruta (che imho c'era con le dovute considerazioni) nè la mancanza poi colmata di un drivers OpenGL. L'errore e' che talvolta ci si dimentica lo scopo forse "originario" per cui si puo' immaginare una SBC simile sia nata cioe' IMHO automazione, insegnamento alla programmazione, progetti hardware elettronici, etc.. non necessariamente pensionare un pc desktop.
Alla fine "ben venga" la potenza bruta a suo modo ma il collo di bottiglia IMHO era la velocita' di banda tra soc e microsd e tutta la condivisione della banda con le porte USB e Ethernet se non ricordo male almeno fino alla quarta versione ove hanno risolto del tutto la questione distanzandosi dalla precedente in maniera decisa.
Con la memoria ram del primo rpi (256/512MB DDR) e del secondo/terzo (1GB DDR2) su cui una parte era condivisa con la GPU e la limitata velocita' di accesso alla microsd praticamente usarlo come pc desktop mostrava i suoi limiti soprattutto sul web browser ove nel momento in cui finiva la disponibilita' della ram e cominciava a utilizzare lo swap su microsd si finiva in lunghe attese e spesso si faceva prima a riavviare. Non era un problema di renderizzazione OpenGL della pagina web ammesso che sia mai servita.
Bastavano anche le precedenti versioni del soc Cortex A7 o A53 se con molta piu' ram e con la questione microsd/usb/ethernet risolta prima se proprio si deve usarlo come desktop, non ho mai trovato nella potenza della CPU (a parte la prima ovvio) un limite.
E' da tenere presente poi che (fortunatamente) ci gira una customizzazione di debian linux aggiornata che non e' proprio leggera nemmeno per un vecchio computer x64 da 100 watt.
Poi chiaro, ben venga tutto quello che possa "spremere" un po' di potenza in piu'. :) Se consideriamo che sul primo soc, un ARM11 700Mhz la GPU poteva gia' facilmente decodificare video offline in FullHD quando la cpu in se e' appunto paragonabile ad un Pentium II o i primi Pentium III, era impressionante gia' di suo.

Bhe c'è da dire che spesso il problema microSD era dovuto che si usavano SD lente, sul mio Pi 3B+ avevo all'inizio una comune microSD anche se di buona qualità, ma lenta in scrittura e lettura casuale, poi acquistai una microSD Classe A2 e il Pi è diventato una scheggia, avvio e tutto il resto velocissimo.
Ok il Pi è nato per insegnamento ecc. ma essendo aperto uno ci può fare anche tanto altro, c'è una comunità di tante persone volontarie e non che si aiuta a vicenda e questa è una cosa stupenda.
Per quanto riguarda il sistema debian, bhe oddio, ci sono già distro leggerissime basate su debian per vecchi PC, in fin dei conti Raspbian non è altro che un Debian con un ambiente desktop minimale e leggero, LXDE, e un Windows manager altrettanto leggero come Openbox :) e di altre distro simili su normali PC ci sono e girano degnamente anche su un vecchissimo Pentium 4 e 1GB di ram.
Certo usare il browser su un Pi 0/1 è una pazzia, ma già su un Pi2 o meglio un Pi 3(meglio sul 3B+), si può usare il browser discretamente bene, se ci si limita ad 2/3 schede aperte al massimo però a seconda della loro complessità, c'è da dire però che ancora il driver della GPU non funziona tanto bene su chromium, non c'è decodifica video all'interno di esso e alcune parti dell'accelerazione hardware mancano, tanto che un vecchio smartphone con CPU simile va meglio, ma ci stanno lavorando.

L'hardware c'e' perche' lo si e' voluto non certo per caso. Ma se il target fosse rimasto "il prezzo finale" si poteva risparmiare qualcosa forse e ottenere un buon risultato comunque. Come dicevo il precedente Cortex A53 era gia' abbastanza potente per fare tutto. Magari un octa-core A53 @ 2Ghz ad un processo produttivo piu' moderno sarebbe costato meno e comunque imho sarebbe stato accettabile e con consumi presumo inferiori.
A nessuno dispiace la potenza ma non credo la potenza sia mai stata il problema di queste SBC o di quelle equivalenti semmai ram e velocita' di storage erano piu' rilevanti gia' prima.
Ma imho dubito che molti di quanti usano le SBC poi sviluppano progetti in stile Arduino in cui anche la prima versione di rpi al confronto sarebbe fin troppo.

Il driver per il Pi 4 è già in sviluppo da tempo.


Ma anche no, il raspberry è nato per ciò che dici, ma essendo una piattaforma aperta nessuno vieta di farci anche ben altro, l'hardware c'è, specie adesso con il Pi 4, quindi perché non poterlo sfruttare anche per altro e per ciò che si vuole?



Bhe c'è da dire che spesso il problema microSD era dovuto che si usavano SD lente, sul mio Pi 3B+ avevo all'inizio una comune microSD anche se di buona qualità, ma lenta in scrittura e lettura casuale, poi acquistai una microSD Classe A2 e il Pi è diventato una scheggia, avvio e tutto il resto velocissimo.
Forse la microsd era un problema nei primi tempi quando ancora le microsd erano di qualita' varia e decisamente lente ma col passare del tempo imho le microsd erano gia' ben superiori ai limiti di lettura e scrittura della SBC, non quelli della scheda. Guardate le recensioni dell'ultima rpi a tal riguardo e immagino a parita' di microsd e si capisce chiaramente. Sulle rpi 1/2/3 ho provato le "migliori" samsung microsd da 100MB/s in lettura e 90MB/s in scrittura e la differenza con quelle piu' economiche (recenti) non l'ho vista granche'. Ovvio che se si usavano le microsd di telefonini di un decennio fa erano si un limite.
E infatti circa Debian, se si costruisce un computer Pentium4 di ultima generazione con ram DDR2 a go-go e disco ssd pur lontano anni luce tecnicamente da un quad core in multitasking alla fine la percezione e' migliore di queste SBC imho per i test che mi sono capitati rispetto alle ver. 2/3 proprio perche' non sempre la CPU e' il problema ne tantomeno la GPU (figuriamoci quest'ultima per il browser, per quel che ha da fare). Non e' solo un problema di GUI, LXDE e' certamente leggero e l'ho sempre usato ma ormai sono proprio le distribuzioni recenti e relativi kernel che cominciano ad essere pesanti. Se prendi le prime versione di raspbian su rpi1 e le ultime la differenza e' palese.

Forse la microsd era un problema nei primi tempi quando ancora le microsd erano di qualita' varia e decisamente lente ma col passare del tempo imho le microsd erano gia' ben superiori ai limiti di lettura e scrittura della SBC, non quelli della scheda. Guardate le recensioni dell'ultima rpi a tal riguardo e immagino a parita' di microsd e si capisce chiaramente. Sulle rpi 1/2/3 ho provato le "migliori" samsung microsd da 100MB/s in lettura e 90MB/s in scrittura e la differenza con quelle piu' economiche (recenti) non l'ho vista granche'. Ovvio che se si usavano le microsd di telefonini di un decennio fa erano si un limite.

Quelle velocità in scrittura e lettura che leggi, anche ai tempi del Pi 1 si riferiscono però alle letture e scritture sequenziali, ma un OS vive per lo più di letture e scritture casuali, le comuni SD sono molto lente in questo, ci vogliono quelle A2, che ai tempi non venivano usate o non c'erano proprio non ricordo, la SD che avevo prima anch'essa vantava velocità di 60 MB/s o giù di lì, ma in accesso casuale era lentissima.
La differenza tra le migliori Samsung e quelle più economiche non l'hai vista perché di Samsung A2 non ne ho viste sinceramente, è quello che fa la differenza credimi.

E infatti circa Debian, se si costruisce un computer Pentium4 di ultima generazione con ram DDR2 a go-go e disco ssd pur lontano anni luce tecnicamente da un quad core in multitasking alla fine la percezione e' migliore di queste SBC imho per i test che mi sono capitati rispetto alle 2/3 proprio perche' non sempre la CPU e' il problema ne tantomeno la GPU (figuriamoci quest'ultima per il browser, per quel che ha da fare). Non e' solo un problema di GUI, LXDE e' certamente leggero e l'ho sempre usato ma ormai sono proprio le distribuzioni recenti e relativi kernel che cominciano ad essere pesanti. Se prendi le prime versione di raspbian su rpi1 e le ultime la differenza e' palese.
Bhe si, adesso il P1 arranca con l'ultima Raspbian Buster, io ho sia un P1 B che il Pi 3B+, ma ormai il P1 ormai lo uso solo con libreelec, con questo funziona ancora discretamente bene.
In realtà anche la GPU è il problema, i driver ancora sono in pieno sviluppo e l'accelerazione hw non è piena, perché quando sarà completa sono sicuro che almeno un poco la differenza si sentirà, già si vede dal fatto che il Pi 4, il modello base con 1GB di ram va comunque meglio del Pi 3 su chrome ad esempio, la GPU spesso dorme e il lavoro lo fa la CPU, ma anni fa era peggio.

Quelle velocità in scrittura e lettura che leggi, anche ai tempi del Pi 1 si riferiscono però alle letture e scritture sequenziali, ma un OS vive per lo più di letture e scritture casuali, le comuni SD sono molto lente in questo, ci vogliono quelle A2, che ai tempi non venivano usate o non c'erano proprio non ricordo, la SD che avevo prima anch'essa vantava velocità di 60 MB/s o giù di lì, ma in accesso casuale era lentissima.
La differenza tra le migliori Samsung e quelle più economiche non l'hai vista perché di Samsung A2 non ne ho viste sinceramente, è quello che fa la differenza credimi.


Bhe si, adesso il P1 arranca con l'ultima Raspbian Buster, io ho sia un P1 B che il Pi 3B+, ma ormai il P1 ormai lo uso solo con libreelec, con questo funziona ancora discretamente bene.
In realtà anche la GPU è il problema, i driver ancora sono in pieno sviluppo e l'accelerazione hw non è piena, perché quando sarà completa sono sicuro che almeno un poco la differenza si sentirà, già si vede dal fatto che il Pi 4, il modello base con 1GB di ram va comunque meglio del Pi 3 su chrome ad esempio, la GPU spesso dorme e il lavoro lo fa la CPU, ma anni fa era peggio.

So che la differenza nell'accesso sequenziale e random e' quella che conta ma i limiti imho rimangono anche con le A2. Ho provato ottime A1, Samsung di quelle PRO non ricordo che modelli esatti ma certamente costose, i risultati erano sempre simili.
Se si cercano test di velocita' tra la rpi3 e 4 mi pare chiaro che il problema non era tanto la microsd quanto la banda I/O condivisa tra tutto.
Toh, il primo link che mi e' capitato sul motore di ricerca a caso:

"A2-class microSD cards offer no better performance for the Raspberry Pi"
https://www.jeffgeerling.com/blog/2019/a2-class-microsd-cards-offer-no-better-performance-raspberry-pi

"...Not only were both cards underperforming the minimum required spec to meet A2 compliance—by more than half (4000 IOPS read, 2000 IOPS write)—they were also slower than some of my older microSD cards produced years before the 'A1' and 'A2' class designations..."

So che la differenza nell'accesso sequenziale e random e' quella che conta ma i limiti imho rimangono anche con le A2. Ho provato ottime A1, Samsung di quelle PRO non ricordo che modelli esatti ma certamente costose, i risultati erano sempre simili.
Se si cercano test di velocita' tra la rpi3 e 4 mi pare chiaro che il problema non era tanto la microsd quanto la banda I/O condivisa tra tutto.
Toh, il primo link che mi e' capitato sul motore di ricerca a caso:

"A2-class microSD cards offer no better performance for the Raspberry Pi"
https://www.jeffgeerling.com/blog/2019/a2-class-microsd-cards-offer-no-better-performance-raspberry-pi

"...Not only were both cards underperforming the minimum required spec to meet A2 compliance—by more than half (4000 IOPS read, 2000 IOPS write)—they were also slower than some of my older microSD cards produced years before the 'A1' and 'A2' class designations..."

Io avevo proprio una Samsung di quelle che dici te, e passando ad una Sansdisk A2 (non ricordo il modello) l'ho differenza l'ho sentita eccome e tanta, oh certo non sono SSD, ma sicuramente in accesso casuale abbastanza più veloce di un qualsiasi HDD, inoltre il bus SD non è affatto condiviso, ma è su un bus SDIO solo per loro, i limiti derivavano dal fatto che il controller SD dei raspberry fino al 3B+ non supportano una specifica SD (non ricordo quale) che dal Pi 4 è supportata e ha permesso un aumento di velocità.
Dall'articolo che hai postato ci sono SD che non soddisfano i requisiti A2, è vero, ma ci sono nel mercato quelle che le soddisfano eccome, in ogni caso da 600/900 IOPS a anche soli 2500 c'è una bella differenza.
Prima con la Samsung Evo il Pi ci metteva un po' a completare l'avvio, dall'avvio del firmware all'apparizione del desktop passava anche 1 minuto o poco meno, non ricordo con precisione, ma anche l'avvio delle applicazioni, le installazioni e gli aggiornamenti erano lenti, passando alla nuova il boot si completa in meno di 20 secondi.. ed è tutto molto più veloce.

Io avevo proprio una Samsung di quelle che dici te, e passando ad una Sansdisk A2 (non ricordo il modello) l'ho differenza l'ho sentita eccome e tanta, oh certo non sono SSD, ma sicuramente in accesso casuale abbastanza più veloce di un qualsiasi HDD, inoltre il bus SD non è affatto condiviso, ma è su un bus SDIO solo per loro, i limiti derivavano dal fatto che il controller SD dei raspberry fino al 3B+ non supportano una specifica SD (non ricordo quale) che dal Pi 4 è supportata e ha permesso un aumento di velocità.
Dall'articolo che hai postato ci sono SD che non soddisfano i requisiti A2, è vero, ma ci sono nel mercato quelle che le soddisfano eccome, in ogni caso da 600/900 IOPS a anche soli 2500 c'è una bella differenza.
Prima con la Samsung Evo il Pi ci metteva un po' a completare l'avvio, dall'avvio del firmware all'apparizione del desktop passava anche 1 minuto o poco meno, non ricordo con precisione, ma anche l'avvio delle applicazioni, le installazioni e gli aggiornamenti erano lenti, passando alla nuova il boot si completa in meno di 20 secondi.. ed è tutto molto più veloce.
Quando capitera' faro' delle prove con le A2 ma andando a memoria mi sembra di ricordare comunque il limite del bus della microsd a circa 20MB/s quando non overclockata senza nemmeno parlare dell'accesso random. Non a caso sulla quarta versione le cose sono cambiate radicalmente perche' e' cambiato proprio il design del soc. Se prendi un Debian Buster e lo installi su una macchina con 512MB di ram o 1GB scommetto che avra' gran bisogno dell' hard disk con la differenza che il SATA ma perfino l' ATA133 credo avesse qualche marcia in piu'. E comunque non e' una soluzione a prescindere si sarebber migliorato molto con la ram. Immagino che il 900Mhz Cortex A7 della seconda versione con 2 giga di ram avrebbe gia' volato imho. Comunque forse ricordo male ma mi sembra che il WiFi fosse condiviso sulla SDI/O ma potrei sbagliare.

La ram non è davvero un problema, con il Pi 3B+ io aprendo già una scheda con Chromium, e alcune altre applicazioni e servizi in background ho solo 400 MB di ram occupata e non swappa, e con un monitor full HD ho dedicato 128 MB alla GPU, quindi a conti fatti ho ancora più di 400 MB di ram libera, il bus è limitato a circa 25 MB/s o poco più, ma se tu hai una SD A1 che ti fa anche 100 MB/s in sequenziale, anche se all'atto pratico sono 25 MB/s sul Pi, ma poi in casuale mi fa 1/2 MB/s allora è logico che va tutto un po' lento, i migliori HDD in scrittura e lettura casuale fanno non più di qualche MB/s, mentre in sequenziale arrivano anche a 250 MB/s o più.

Credo che ogni sistema cominci ad utilizzare la cache su disco ben prima di arrivare al 100% della ram utilizzata e anche andando sui file di configurazione e cambiando le percentuali di carico tra ram e swap si finiva facilmente nella stessa situazione dopo qualche ora di web browser e tre o quattro tab attivi. Non so quante volte ho visto (ripeto magari non con la migliore microsd A2 ma comunque con microsd samsung delle migliori) l'rpi rimanere con il led acceso fisso ad aspettare immagino il rilascio dallo swap alla ram o comunque a liberarsi dal tab aperto. Non dico ovviamente all'avvio del sistema, ma qualsiasi o.s. anche linux dopo un po' di utilizzo la ram usata cresce. Es. al momento testo una macchina x64 linux con lxde, un solo tab aperto questo sul forum e nient'altro ne app aperte, ho piu' di 1GB di ram occupata sul totale dal processo del browser aperto da ore. Suppongo che lo stesso tab aperto dopo un riavvio magari ne richiederebbe un decimo. Lo stesso imho succedeva anche sull' rpi.

Credo che ogni sistema cominci ad utilizzare la cache su disco ben prima di arrivare al 100% della ram utilizzata e anche andando sui file di configurazione e cambiando le percentuali di carico tra ram e swap si finiva facilmente nella stessa situazione dopo qualche ora di web browser e tre o quattro tab attivi. Non so quante volte ho visto (ripeto magari non con la migliore microsd A2 ma comunque con microsd samsung delle migliori) l'rpi rimanere con il led acceso fisso ad aspettare immagino il rilascio dallo swap alla ram o comunque a liberarsi dal tab aperto. Non dico ovviamente all'avvio del sistema, ma qualsiasi o.s. anche linux dopo un po' di utilizzo la ram usata cresce. Es. al momento testo una macchina x64 linux con lxde, un solo tab aperto questo sul forum e nient'altro ho piu' di 1GB di ram occupata sul totale. Suppongo che lo stesso tab aperto dopo un riavvio magari ne richiederebbe un decimo. Lo stesso imho succedeva anche sull' rpi.

La situazione con il led acceso come dici te io l'avevo con la vecchia SD, ma non perché swappava, ma perché era talmente lenta che faceva fatica, ora non lo fa più.
Lo swappiness sul Pi è settato in modo abbastanza conservativo, cioè ti posso dire che con il mio utilizzo, sempre acceso 24h su 24, con l'utilizzo di ram come ho scritto nel post precedente, circa 400 MB di ram, a volte arrivo a 500 circa, ma solo in certi casi, a volte anche sotto i 400 MB, vedo lo swap sempre a 0 se non in casi rari circa 10 MB o meno, al massimo l'ho visto a 20 MB, non di più.

Magari le aspettative che abbiamo sono differenti. Forse si e' sottovalutata la capacita' che gia' sistemi desktop di una decade fa avevano confrontandole con SBC che non sono nate per rimpiazzare quei sistemi. Oggigiorno qualcuno userebbe un web browser moderno su un Pentium 3/500 con 512MB di DDR1 aspettandosi risultati impressionanti?
Comunque la personale esperienza "come desktop" mi ha lasciato alti e bassi. Ad esempio sono rimasto impressionato dal poter usare software "pesanti" come Gimp o Audacity o Libreoffice o gli stessi web browser fin quando non si aumentavano troppo i tab appunto. Sono rimasto impressionato da un sistema che funziona certamente con pochi watt ed e' completo ma solo un'opinione per quanto vale almeno fino alla penultima provata, non farei paragoni con sistemi desktop nemmeno se prendessi a riferimento socket come l' AM2/3 o il Socket 775.

Secondo me si sta perdendo la vera filosofia del Raspberry. Una mini sched a basso costo accessibile a tutti dove poter realizzare progetti, anche didattici. Quello di far girare software multimediale la vedo come "un qualcosa in più".

Potresti pensare anche allo sviluppo del driver Vulkan in oggetto come un processo formativo.
Ed è anche piuttosto interessante, visto che nasce per una GPU esistente che non è stata pensata per supportare tutto ciò che Vulkan deve mettere a disposizione.