Internet Explorer 11 e Windows 8.1 sfruttano la GPU per gestire i JPG

Internet Explorer 11 e Windows 8.1 sfruttano la GPU per gestire i JPG

Tra le novità promesse dall'aggiornamento 8.1 di Windows Microsoft segnala una nuova modalità di gestione dei file JPG che prevede lo sfruttamento della GPU in alcune fasi del processo di decoding

di Fabio Boneschi pubblicata il , alle 13:31 nel canale Sistemi Operativi
MicrosoftWindows
 

In un lungo e interessante post Microsoft descrive le modalità con le quali Internet Explorer 11 e Windows 8.1 riescono a gestire in modo più rapido e efficiente sotto il profilo energetico le immagini in formato JPG. I risultati promessi sono di tutto rispetto: per Microsoft il nuovo aggiornamento del sistema operativo e il conseguente update del browser porterà a una velocità di caricamento delle immagini JPG superiore del 45% con una riduzione della memoria utilizzata di circa il 40%.

Per ottenere questo risultato Microsoft ha previsto un miglior utilizzo della GPU presente sui dispositivi che permette di sgravare la CPU di parte del carico e di parallelizzare una componente del processo sfruttando le risorse video. Microsoft per supportare l'importanza di questa novità parte da due dati importanti: ad oggi il 61% dei dati scaricati dal web è costituito da immagini e di queste il 45% sono in formato JPG.

Per spiegare come Internet Explorer 11 e l'utilizzo della GPU offra interessanti vantaggi della fase di deconding di un'immagine JPG è necessario un accenno al processo inverso, cioè a come tale immagine viene creata a partire dal contenuto bitmap.

La prima fase della codifica JPG prevede la conversione dell'immagine bitmap dallo spazio colore RGB a quello YCbCr. Nello spazio RGB l'immagine viene scomposta utilizzando le tre componenti colore rosso, verde e blu, mentre quello YCbCr prevede un canale Y dedicato alla luminanza, e due canali dedicati alle differenze rispetto al blu (Cb) e al rosso (Cr). Questa fase è assai interessante e le due immagini seguenti lo mettono in chiara evidenza.

Nello spazio colore RGB tutte le componenti rosso, verdi e blu hanno un elevato numero di particolari che viene percepito dall'occhio umano. La medesima immagine nello spazio colore YCbCr colpisce per un dettaglio: per l'occhio umano la componente Y (luminanza) è quella che offre il maggior numero di informazioni, mentre le due componenti colore Cb e Cr hanno un impatto inferiore.

Il processo di codifica ora prevede l'applicazione della compressione nota come Chroma Subsampling. Infatti, partendo dal presupposto che l'occhio umano è assai più sensibile al canale Y i due canali Cb e Cr possono essere compressi applicando un processo di compressione che prevede un downscale orizzontale pari a 2 (subsampling 4:2:2), o un processo che prevede il ricampionamento anche sull'asse verticale (4:2:0).

Questa operazione di compressione comporta notevole risparmio in termini di memoria utilizzata e Microsoft nel proprio post indica che un'immagine JPG convertita nello spazio colore YCbCr e sottoposta a subsampling 4:2:0 utilizza il 62,5% in meno di memoria rispetto alla bitmap RGB originale. Il processo di decodifica termina con l'applicazione della trasformata discreta del coseno (DCT) e con l'utilizzo dell'algoritmo di codifica di Huffman.

Quanto appena descritto viene realizzato in modo molto semplice per l'utente dai più diffusi software di editing per immagini nel momento in cui si selezionano l'opzione "salva immagine per il web" e il formato JPG.

A grandi linee abbiamo descritto le fasi che permettono di ottenere un file JPG più leggero da trasferire e da gestire. Abbiamo quindi i presupposti per capire come avvenga il processo inverso e quali novità vengano introdotte da Internet Explorer 11 con l'utilizzo della GPU.

Il processo tipicamente applicato da Internet Explorer nelle versioni precedenti prevede l'applicazione dell'algoritmo mostrato in figura che ripercorre a ritroso tutte le fasi descritte precedentemente.

Rispetto a questo schema Internet Explorer 11 è in grado di effettuare le ultime due operazioni sfruttando le risorse della GPU nel momento in cui l'immagine viene visualizzata. La CPU viene quindi sgravata dalle operazioni di upsampling e di conversione nello spazio colore RGB ottenendo così il duplice vantaggio di ridurre il tempo di occupazione della CPU e più in generale del processo relativo alla visualizzazione di un'immagine.

Per beneficiare di queste novità rimane ovviamente il requisito che le immagini JPG utilizzino lo spazio colore YCbCr e vengano sottoposte a una compressione 4:2:2 o 4:2:0, circostanza abbastanza comune attualmente sul web. Microsoft indica un risparmio in termini di tempo necessario alla visualizzazione fino al 30% inferiore e in termini assoluti si parla di poche decine di millisecondi, ma questo valore varia da immagine a immagine.

Per essere veramente compreso il vantaggio offerto da IE11 e Windows 8.1 va però visto in senso più generale e non relativo alla singola immagine JPG processata. Va infatti considerato che i contenuti web sono sempre più arricchiti di immagini, tanto che le parti di testo in molte situazioni occupano porzioni minime del display.

Ma oltre a questo aspetto ormai più che evidente la nuova modalità di gestione dei JPG da parte di Microsoft permette una miglior gestione delle risorse che si traduce in svariati vantaggi: minor memoria occupata, minor tempo di occupazione della CPU, ottimizzazione dell'utilizzo della GPU. Queste singole ottimizzazioni hanno poi ricadute dirette sul consumo energetico inferiore.

Microsoft rilascerà Windows 8.1 il prossimo 18 ottobre e attualmente il nuovo sistema operativo è in fase RTM. Attendiamo il rilascio ufficiale per conoscere quanto in pratica queste novità avranno impatto sull'utilizzo pratico del browser da parte dell'utente.

12 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Bivvoz17 Settembre 2013, 13:41 #1
Mi fa piacere vedere che MS si sta dando da fare.
Non tanto per quanto trattato in questo caso che è interessante ma se mi è concesso dirlo è una cosa basilare per chi un po' mastica video e immagini.
La cosa interessante è come MS stia riprendendo a lavorare seriamente per portare i suoi OS e browser a competere seriamente con gli altri.
Perché diciamolo chiaramente tutto questo è pensato per ottimizzare i consumi nel settore mobile.

Che hanno perso un po' il treno qualche anno fa è chiaro a tutti e forse anche comprensibile, puntavano tanto sui dispositivi mobili senza riscontrare grande successo prima del boom che quando c'è stato il boom non ci hanno creduto subito.
Però sembra che ora siano decisi a riguadagnare terreno.
Kouta17 Settembre 2013, 14:00 #2
veramente se non erro jpeg dovrebbe supportare anche rgb e yuv 444
inoltre mi sembra assurdo che si sfrutti la gpu per il solo chroma upsampling e per la conversione in rgb, dato che sono le due operazioni più semplici tra quelle da effettuare, mentre la idct che è molto più complessa viene lasciata alla cpu.

[s]ps inoltre non so di cosa si fanno alla ms, ma se usi il 420 (o 411 o 402 ecc) è difficile che risparmi il 62.5% (ottenere quindi il 37.5%), dato che la riduzione a livello di dati grezzi è del solo 50% (4+4+4 = 12int vs 4+2+0 = 6int per blocco di 2x2 pixel).[/s]
leggo ora che è intesa dopo la compressione in jpeg... rispetto alla bitmap... il che non è assolutamente vero, dato che, a causa della dct, molto dipende dalla complessità dell'immagine e dalla compressione adottata (dato che jpeg è una compressione lossy).

es lena, in bmp rgb24 viene 769kB, in jpeg 444 viene 447kB, in 422 viene 293kB, e in 420 viene 225kB (jpeg fatti a qualità 100 senza ottimizzazioni con fsresizer, dato che ps, anche con "salva per il(lo) web" mi fa ugualmente in 444...)
vitus8117 Settembre 2013, 14:10 #3
Originariamente inviato da: Kouta
inoltre mi sembra assurdo che si sfrutti la gpu per il solo chroma upsampling e per la conversione in rgb, dato che sono le due operazioni più semplici tra quelle da effettuare, mentre la idct che è molto più complessa viene lasciata alla cpu.


Parole sante

Credo tra l'altro che la IDCT si presti abbastanza bene all'implementazione su GPU.

In ogni caso mi pare un po' overkill: non è certo la decodifica del jpg che rende lenti i browser.
Nui_Mg17 Settembre 2013, 14:13 #4
Originariamente inviato da: Bivvoz
Però sembra che ora siano decisi a riguadagnare terreno.

La vedo dura, si dimostrano ancora troppo indietro sui principali concorrenti (perfino gratuiti), almeno sulle cose che contano, come l'aderenza alle feature già fissate di html5 e della conseguente modernizzazione/interoperabilità del web.
scilvio17 Settembre 2013, 14:27 #5
con tutto quello che abbiamo oggi nessuno utilizza ancora il formato jpeg2000 già per quest'ultimo un accelerazione avrebbe più senso
diabolikum17 Settembre 2013, 15:13 #6
Prima di iniziare a parlare di aderenza ad HTML5, ricordiamolo tutti che non è ancora ratificato come standard.
eeetc18 Settembre 2013, 17:06 #7
Ma invece di sfruttare la GPU solo per una cosa così specifica perché non la utilizzano per tutto il rendering del desktop?
Bivvoz18 Settembre 2013, 18:10 #8
Originariamente inviato da: eeetc
Ma invece di sfruttare la GPU solo per una cosa così specifica perché non la utilizzano per tutto il rendering del desktop?


Perché il rendering del desktop viene già eseguito dalla gpu ma non da internet Explorer
eeetc18 Settembre 2013, 19:40 #9
Originariamente inviato da: Bivvoz
Perché il rendering del desktop viene già eseguito dalla gpu ma non da internet Explorer

Se la GPU gestisse già tutto il rendering di Windows non ci sarebbe bisogno di accelerare esplicitamente ciò che ci gira dentro no?
Non conosco i dettagli ma credo che il desktop vada a pesare in gran parte sul processore, lasciando in idle la scheda grafica, infatti disabilitando l'accelerazione grafica non si notano grosse differenze nel comportamento del desktop.
Bivvoz18 Settembre 2013, 21:04 #10
Originariamente inviato da: eeetc
Se la GPU gestisse già tutto il rendering di Windows non ci sarebbe bisogno di accelerare esplicitamente ciò che ci gira dentro no?
Non conosco i dettagli ma credo che il desktop vada a pesare in gran parte sul processore, lasciando in idle la scheda grafica, infatti disabilitando l'accelerazione grafica non si notano grosse differenze nel comportamento del desktop.


Non è che il desktop è crysis e impatta sulle prestazioni, pensavi veramente di notare differenze in termini di prestazioni?

Windows non può accelerare quello che gira sul desktop per il semplice fatto che non è lui a gestirlo.
Può accelerare il desktop inteso come gestione delle finestre, gli effetti, le trasparenze, ecc. ma come puoi pretendere che acceleri quello che gira nella finestra se è gestito da un altro programma?
Per esempio se apro autocad Windows dovrebbe accelerarlo di suo secondo te? Ti sembra possibile?

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^