Link alla notizia: https://www.hwupgrade.it/news/sistemi/jetson-agx-orin-il-nuovo-cervello-di-nvidia-per-i-robot-e-fino-a-6-volte-piu-potente_102344.html

NVIDIA ha annunciato Jetson AGX Orin, una board di sviluppo per diversi settori embedded, tra cui la robotica e l'ambito sanitario, che grazie a 12 core Arm e una GPU Ampere offre fino a 6 volte più potenza di calcolo rispetto alla precedente Jetson AGX Xavier.

Click sul link per visualizzare la notizia.

Conosco bene la vecchia Xavier... un mostriciattolo! Peccato per la complessità dell'hardware che lo rende difficile da usare.

Questo nuovo hardware mi fa ben sperare per una futura consolle nintendo portatile, molto più potente.

Conosco bene la vecchia Xavier... un mostriciattolo! Peccato per la complessità dell'hardware che lo rende difficile da usare.
Ma non vedo più da tempo core ARM basati su Project Denver: ormai nVidia utilizza le classiche IP ARM.

Si vede che ha abbandonato il suo core ARM.

/OT

Ma non vedo più da tempo core ARM basati su Project Denver: ormai nVidia utilizza le classiche IP ARM.

Si vede che ha abbandonato il suo core ARM.

/OT

Ho lavorato con i proci famiglia Carmel con GPU Volta. Delle bestie di processori per l'epoca ma NVIDIA ha fatto di tutto per complicare il più possibile la vita degli sviluppatori: già solo arrivare a caricare il kernel era un delirio fra partizioni protette e contro partizioni (non ti dico cos'è calcolare un hash ad un livello così basso), ma poi ad esempio anche la gestione del boot del core R5 safety che in teoria si fa in 30 righe era resa molto difficile dalle scelte di NVIDIA (se fatta fuori dall'ambiente ubuntu consigliato).
Praticamente uscire dalla pessima distro ubuntu che davano a disposizione era davvero dura, se poi come nel mio caso dovevi scrivere il bootloader toccava fare un giro a Lourdes. Mancavano tante cose fra cui il supporto a KVM o Xen, le patch RT che dovetti portare con una versione custom del kernel e tante altre cose che resero poco popolari quelle soluzioni.

Credo che sia anche per questo che sono tornati verso architetture più standard, eccetto ovviamente la parte video. Certo è che è stato un lavoraccio ma anche un piacere scrivere per quelle CPU, in 35W erano dei piccoli mostri per l'epoca.

Ho lavorato con i proci famiglia Carmel con GPU Volta. Delle bestie di processori per l'epoca ma NVIDIA ha fatto di tutto per complicare il più possibile la vita degli sviluppatori: già solo arrivare a caricare il kernel era un delirio fra partizioni protette e contro partizioni (non ti dico cos'è calcolare un hash ad un livello così basso), ma poi ad esempio anche la gestione del boot del core R5 safety che in teoria si fa in 30 righe era resa molto difficile dalle scelte di NVIDIA (se fatta fuori dall'ambiente ubuntu consigliato).
Praticamente uscire dalla pessima distro ubuntu che davano a disposizione era davvero dura, se poi come nel mio caso dovevi scrivere il bootloader toccava fare un giro a Lourdes. Mancavano tante cose fra cui il supporto a KVM o Xen, le patch RT che dovetti portare con una versione custom del kernel e tante altre cose che resero poco popolari quelle soluzioni.
:eek: Ma nVidia non ha pensato a come supportare gli sviluppatori?!? Mi sembra allucinante quello che hai riportato.
Credo che sia anche per questo che sono tornati verso architetture più standard, eccetto ovviamente la parte video. Certo è che è stato un lavoraccio ma anche un piacere scrivere per quelle CPU, in 35W erano dei piccoli mostri per l'epoca.
I consumi non erano superiori rispetto ai core ARM dell'epoca con prestazioni simili? Visto che non era un'architettura ARM, ma doveva ricorrere a un traduttore in parte hardware, e ha parecchia memoria come cache per i blocchi di codice tradotti, penso che avrebbe dovuto consumare di più rispetto a una soluzione nativa.

:eek: Ma nVidia non ha pensato a come supportare gli sviluppatori?!? Mi sembra allucinante quello che hai riportato.

Loro davano per scontato che i dev avrebbero usato la versione di Ubuntu preparata da Nvidia e magari cambiato il kernel. Non li ha sfiorati l'idea che qualcuno volesse far girare applicazioni barebone o che per varie ragioni qualcuno potesse avere bisogno di scrivere il bootloader.

In ogni caso anche la stabilità degli strumenti software al 2020 non era delle migliori, ricordo il programma per fare il flash dell'OS falliva non deterministicamente (cioè a parità di condizioni ogni tanto non ci riusciva) e personalmente non sono mai riuscito a farlo funzionare via ethernet, ma solo via usb.

Nota che in altre piattaforme della famiglia Jetson non era così, ad esempio le Jetson piccole (Nano e Tx2) erano molto più stabili. Credo che il problema sia stato nella grandissima complessità di gestione introdotta con la famiglia di proci "grandi" e la volontà di inserire feature forse (azzardo) troppo complesse rispetto allo standard dei sistemi embedded per automotive e all'esperienza di NVIDIA stessa nel settore.

I consumi non erano superiori rispetto ai core ARM dell'epoca con prestazioni simili? Visto che non era un'architettura ARM, ma doveva ricorrere a un traduttore in parte hardware, e ha parecchia memoria come cache per i blocchi di codice tradotti, penso che avrebbe dovuto consumare di più rispetto a una soluzione nativa.

Aveva una GPU che le altre soluzioni si sognavano, giustificavano i consumi così.


EDIT Alla fine per me è stata un'esperienza positiva, sono entrato in contatto con diversi maintainer del kernel linux ed ho visto un mondo che non conoscevo, però ecco... non abbiamo ricomprato un'altra soluzione di Nvidia per sistemi "embedded". :D

Non lo metto in dubbio. Da sviluppatore trovo estremamente stimolanti sfide come queste, per cui, a parte ovviamente il carico di lavoro e lo stress nel lavorare in quelle condizioni, c'è anche da divertirsi :D oltre al ben più importante ritorno in termini di know-how acquisito E networking.

Grazie per le spiegazioni. Quindi, come pensavo, il valore aggiunto non era la CPU, ma la GPU.

Assolutamente sì, la gpu.

Assolutamente sì, la gpu.

confermo