Dinox PC

PI Hardware/ GPGPU, transcodifica video accelerata

Un confronto tra le tre piattaforme oggi in commercio e che dichiarano benefici per operazioni un tempo inarrivabili per l'hardware casalingo. Sorpresa: tra Intel, Nvidia e AMD la spunta la prima

L'arrivo delle nuove CPU Intel Sandy Bridge ha creato un certo entusiasmo attorno a diversi temi grazie, quasi esclusivamente, alle caratteristiche ed alle performance del controller grafico integrato on chip. Un processore Core di seconda generazione è infatti in grado di fare molto bene sfruttando la potenza combinata di CPU e GPU, garantendo al contempo consumi relativamente limitati.

La presenza di un core grafico in un sempre crescente numero di modelli di processore (AMD con le APU ed Intel con Sandy Bridge, per ora) fa sì che quello GPGPU resti un argomento di scottante attualità. E quando si parla di General Purpose Computing abbinato ai chip grafici, le prime applicazioni che vengono in mente sono quelle che ruotano attorno al settore della transcodifica video. Forse non tanto perché sia l'utente a fare simili richieste, quanto perché sono i produttori stessi a sottolinearne continuamente i vantaggi.

Tornando con la mente al passato recente quando NVIDIA, pioniera in questo senso, svelò al mercato l'esistenza di CUDA, uno dei primi software commerciali che si affacciavano sulla scena portava il nome di Badaboom. Uno strumento per la transcodifica video che permette di sfruttare la potenza di calcolo delle GPU NVIDIA per trasformare un flusso video da un formato all'altro.

Il processo di transcodifica

In realtà il processo di trasformazione dei flussi video, sia nelle fasi di codifica che decodifica, è stato sempre a cuore dei tre principali produttori di schede grafiche. Intel, NVIDIA ed AMD, facendo forza sulle estreme doti di potenza di calcolo parallelo delle rispettive soluzioni, hanno dapprima pensato di integrare moduli che potessero accelerare la decodifica, incaricando la VGA di svolgere nuovi compiti del processo stesso ad ogni nuova revisione rilasciata sul mercato. Alla logica di General Purpose, che man mano è stata migliorata, sono stati invece lasciati i compiti di codifica.

Ci teniamo a precisare che, nonostante i seri sforzi, il processo di transcodifica video non può essere reso completamente parallelo. Ci sono delle operazioni, come quelle di entropy encoding, sintax encoding, entropy decoding e sintax decoding, che vanno eseguite nella maniera tradizionale seriale e dunque devono essere assegnate alla CPU.

Per accelerare le operazioni di codifica video, AMD e NVIDIA si rifanno alle loro rispettive tecnologie proprietarie APP e CUDA. Intel passa invece per Quick Sync Video che utilizza blocchi funzionali del core grafico integrato nelle CPU Sandy Bridge, per accelerare via hardware tutte le operazioni necessarie al processo di transcodifica video. Purtroppo questo garantisce il funzionamento di tale tecnologia solo con le schede madri con chipset H67 e solo se si sta effettivamente utilizzando il core grafico integrato in Sandy Bridge: sarebbe stato molto più interessante avere sempre a disposizione la stessa tecnologia anche nel caso di utilizzo di una scheda grafica discreta (probabilmente tale possibilità verrà offerta con l'introduzione dei prossimi chipset Z68).

Le funzioni del processo di transcodifica video possono essere riassunte in tre blocchi principali: la decodifica del flusso dal formato nativo, la fase di preprocessing e poi la codifica nel nuovo formato richiesto dall'utente.


Implementazione Intel Quick Sync Video

Con Sandy Bridge Intel ha introdotto il supporto via hardware per tutte le fasi di elaborazione video garantendo così, almeno sulla carta, maggiori prestazioni ed efficienza. Con APP e CUDA, il processo risulta sulla carta meno efficiente in quanto deve necessariamente essere eseguito sulla CPU e sulla GPU e deve prevedere uno scambio di dati e comandi fra le due entità. In generale la CPU prende in carico il flusso video e lo invia alla GPU ordinando di eseguire la decodifica. Il risultato viene poi rimandato alla CPU che eventualmente esegue le operazioni di preprocessing e poi lo prepara nuovamente per la GPU che esegue il processo di codifica. Questo scambio di dati non è necessario nel caso di Sandy Bridge grazie alla presenza di un modulo completamente dedicato e della cache L3 condivisa per lo scambio dei dati.

In ogni caso è sempre necessario che, chi sviluppa un software di transcodifica, lo scriva appositamente per ognuna di queste tecnologie. Di certo non si tratta della situazione ideale, tanto che più volte abbiamo auspicato si facesse riferimento agli standard esistenti (leggasi Direct Compute 11) in modo da semplificare la vita tanto agli sviluppatori quanto agli utenti finali.
Notizie collegate
7 Commenti alla Notizia PI Hardware/ GPGPU, transcodifica video accelerata
Ordina
  • in effetti come facciamo noi utenti a comprare tutto e provare tutto incrociato... ?

    grande articolo, grazie
    non+autenticato
  • Visto che altri chiedono ulteriori test più generici, potresti fare qualcosa di basilare: l'inversione di una matrice grande. Così hai controllo totale, e non incorri in possibili errori di implementazione nei programmi che usi.
    Non conosco APP, ma realisticamente un codice per l'inversione di una matrice può essere scritto pressochè uguale al CUDA.

    Piuttosto, questa soluzione on chip di Intel permette solo la decodifica video (come il nome suggerirebbe) o permette programmazione generica, CUDA-like, per qualsiasi operazione?
    non+autenticato
  • Quella di Intel - Quick Sync - è dedicata alla sola transcodifica video
  • alla amd è alla HD radeon 6xxx e non 5xxx...
    non+autenticato
  • ottima disamina, come nello stile di DinoX ma trovo l'argomento un po' troppo "limitato" alla sola transcodifica video, e per giunta con l'utilizzo di un solo software di gestione.
    credo che ci sia molta responsabilità di Arcsoft in quei risultati, più che nelle routine di codifica CUDA/APP (soprattutto nel primo test dove uno dei file ha una dimensione di 1/6 rispetto agli altri 3... e ti credo che ha una qualità pessima, è stato encodato ad un bitrate ENORMEMENTE inferiore!)
    non+autenticato
  • Pienamente d'accordo con te.

    I benchmark su tali sistemi andrebbero fatti con le seguenti premesse:
    - Stesso codec
    - Stesso bitrate
    - Stesso numero di passaggi di analisi-codifica
    - Stessa sorgente
    - Stessa risoluzione in uscita
    - Stesso spazio di colore in uscita
    - Stessi filtri applicati in fase di codifica

    E ad essere valutati oltre alla qualità visiva altrimenti detta "ad occhio" e il tempo di codifica, ci sarebbero i valori di rumore del filmato (PSNR)
    non+autenticato
  • Trovo sempre ottime le critiche specie se fatte in questo modo. Voglio però far notare alcuni aspetti che forse non sono emersi:

    1. Anzitutto non usiamo un solo software ma due (Arcsoft Media Converter 7 e Cyberlink Media Espresso). Ne avremmo potuti includere altri ma questi sono attualmente (almeno dall'indagine che abbiamo svolto) gli unici compatibili con CUDA, APP e Quick Sync

    2. Sono d'accordo sulla responsabilità di chi produce il software tanto che nelle conclusioni diciamo proprio questo.

    3. I benchmark sono stati fatti nelle stesse condizioni. O meglio, usando le stesse impostazioni di base che i due software mettono a disposizione (senza scendere nei dettagli) e modificando solo la voce "Codifica/decodifica via hardware o software"
    -----------------------------------------------------------
    Modificato dall' autore il 14 marzo 2011 21.15
    -----------------------------------------------------------