Alfonso Maruccia

GPU, Khronos scende davvero in basso

Novità per le API grafiche e GPGPU di Khronos Group, che alla sempre più agguerrita concorrenza risponde con un nuovo progetto incompatibile con OpenGL pensato per il software e l'intrattenimento del futuro

Roma - La nuova generazione di OpenGL ("GLnext") si chiama Vulkan, è incompatibile con la storica tecnologia grafica ed è in grado di portare miglioramenti tecnologici paragonabili a quelli della concorrenza. Con una differenza sostanziale: come già OpenGL, Vulkan gira su qualsiasi piattaforma e sistema operativo senza restrizioni imposte dall'alto.

Vulkan, in sostanza, è la risposta di Khronos Group a Mantle di AMD, DirectX 12 di Microsoft e Metal di Apple, una API per la grafica tridimensionale pensata per avvicinare le applicazioni e i programmatori al "freddo metallo" dei transistor di una GPU sfoltendo gli strati intermedi sin qui appannaggio dei driver di periferica.

Con Vulkan gli sviluppatori potranno avere accesso a funzionalità di basso livello finora off-limits come la gestione della memoria e dei thread, il controllo degli errori e altro ancora, aprendo nuove possibilità di realizzare simulazioni e rendering complessi con performance sensibilmente superiori a OpenGL.
Vulkan fa in sostanza le stesse cose che dovranno fare le succitate API concorrenti, ma Vulkan ha la stessa vocazione multipiattaforma di OpenGL e quindi non si limita a girare su Windows (DirectX 12), su una sola marca di GPU (Mantle) o un solo ecosistema di gadget mobile (Metal).

A Vulkan si accompagna un'altra importante novità chiamata SPIR-V, vale a dire un nuovo linguaggio intermedio per la compilazione degli shader grafici che semplifica il lavoro agli sviluppatori e adotta lo stesso approccio snellito degli shader di DirectX 12. SPIR-V, però, unifica gli shader grafici con quelli computazionali tradizionalmente deputati alla CPU, e non a caso la tecnologia è parte integrante delle nuove specifiche OpenCL 2.1 (anch'esse al debutto assieme a Vulkan) per le applicazioni GPGPU.

Alfonso Maruccia
Notizie collegate
26 Commenti alla Notizia GPU, Khronos scende davvero in basso
Ordina
  • Le OpenGl hanno il problema che non girano su ARM ... Vulkan invece si, per questo non sn compatibili con OpenGl.
    non+autenticato
  • non è certamente il motivo più importante

    la vera ragione sta nell'architettura completamente differente della nuova api

    ma il nocciolo della questione è che quest'api ti dà:

    1. performance migliori
    2. meno bug
    3. driver più semplici
    4. maggior controllo in mano alle applicazioni
    non+autenticato
  • - Scritto da: collione
    > 1. performance migliori
    > 2. meno bug
    > 3. driver più semplici
    > 4. maggior controllo in mano alle applicazioni

    5. maggiori difficoltà per gli sviluppatori che devono usarle.

    Non dimentichiamo che le OpenGL, pur con i loro limiti dovuti a 25 anni di storia e retrocompatibilità, offrono delle API di livello più alto. Con Vulkan solo le grandi software house (e, speriamo, grandi progetti open source) saranno in grado di creare motori grafici, gli altri dovranno limitarsi ad appoggiarsi a questi progetti.
    non+autenticato
  • Ma l'idea è che chi non ha i mezzi non dovrebbe mettersi a pasticciare con i motori grafici
    non+autenticato
  • > Ma l'idea è che chi non ha i mezzi non dovrebbe
    > mettersi a pasticciare con i motori
    > grafici

    Io penso a progetti tipo Blender, per dirne uno. Usano ancora le OpenGL 1.x, perché sono tutt'ora la più facili da usare per questo tipo di software! Credo che l'intero mondo dei modellatori 3D e CAD sia in una stuazione simile.
    non+autenticato
  • - Scritto da: collione
    > Ma l'idea è che chi non ha i mezzi non dovrebbe
    > mettersi a pasticciare con i motori
    > grafici

    la tua idea forse, il resto del mondo non nasce studiato e impara dai propri errori, pasticciando e sperimentando.
    non+autenticato
  • - Scritto da: Fra

    > Le OpenGl hanno il problema che non girano su ARM
    > ... Vulkan invece si, per questo non sn
    > compatibili con
    > OpenGl.

    Le OpenGL "complete" non girano su AMR, ma OpenGLSL sì.
    Vulkan è stato progettato con il mobile in mente, quindi è pensato per girare anche con poche risorse.
    non+autenticato
  • - Scritto da: Fra
    > Le OpenGl hanno il problema che non girano su ARM
    > ... Vulkan invece si, per questo non sn
    > compatibili con
    > OpenGl.

    Non c'è nessuna incompatibilità fra OpenGL e ARM. In genere su telefoni e aggeggi del genere non ci sono le OpenGL complete ma le OpenGL ES, con alcune cose in meno, ma non ha nulla a che vedere con l'architettura della CPU/GPU.
    non+autenticato
  • > Non c'è nessuna incompatibilità fra OpenGL e ARM.
    > In genere su telefoni e aggeggi del genere non ci
    > sono le OpenGL complete ma le OpenGL ES, con
    > alcune cose in meno, ma non ha nulla a che vedere
    > con l'architettura della
    > CPU/GPU.

    Esattamente. In realtà le GLES che sono state definite anche loro da Khronos, richiedono al programmatore di scriversi gli shaders a mano, cosa che le GL non fanno, in quanto gli shaders sono già compilati.

    Peccato che per ogni luce che piazzi devono calcolare l'effetto su ogni singolo pixel della scena e se usi l'alpha channel la complessità diventa ancora maggiore.

    Consentendo al programmatore di scrivere gli shaders, gli consenti di scegliere il giusto compromesso tra velocità e complessità, che serve a lui, cablandosi applicazioni su misura e per questo sono lo standard delle WebGL.

    Quello che però sembra veramente rivoluzionario, è la definizione dell'OpenCL.

    Considerato che il processore di un modulo grafico di uno smartphone è in grado di eseguire centinaia di calcoli vettoriali paralleli in virgola mobile in un microsecondo, poter riusare questi dati a livello di CPU invece che per la semplice rappresentazione grafica, è una possibilità completamente nuova nello sviluppo di giochi e algoritmi vari.
    non+autenticato
  • - Scritto da: Luppolo
    > > Non c'è nessuna incompatibilità fra OpenGL e
    > ARM.
    > > In genere su telefoni e aggeggi del genere non
    > ci
    > > sono le OpenGL complete ma le OpenGL ES, con
    > > alcune cose in meno, ma non ha nulla a che
    > vedere
    > > con l'architettura della
    > > CPU/GPU.
    >
    > Esattamente. In realtà le GLES che sono state
    > definite anche loro da Khronos, richiedono al
    > programmatore di scriversi gli shaders a mano,
    > cosa che le GL non fanno, in quanto gli shaders
    > sono già
    > compilati.

    Eh? No, questa differenza non esiste. Devi scriverti gli shader, se li vuoi usare, qualunque sia la versione di OpenGL.


    > Quello che però sembra veramente rivoluzionario,
    > è la definizione dell'OpenCL.
    >
    >
    > Considerato che il processore di un modulo
    > grafico di uno smartphone è in grado di eseguire
    > centinaia di calcoli vettoriali paralleli in
    > virgola mobile in un microsecondo, poter riusare
    > questi dati a livello di CPU invece che per la
    > semplice rappresentazione grafica, è una
    > possibilità completamente nuova nello sviluppo di
    > giochi e algoritmi
    > vari.

    Questa non è una novità, è da anni che si fa.
    non+autenticato
  • Forse non hai capito che il punto portato avanti da Khronos non è ampliare ciò che già esiste, ma ridurlo per renderlo adatto ai dispositivi poco potenti.

    Ovviamente le GL supportano gli shaders, però puoi anche non usarli e se non li usi, fanno tutto loro con il Gourad shading e l'alpha, dando per scontato la potenza di calcolo.

    Le GLES ti obbligano ad usare gli shaders e quindi sei obbligato a vedere le cose da un punto di vista diverso.

    Per quanto riguarda OpenCL invece, il linguaggio è standard ma non è implementato su gran parte dei sistemi.

    Per esempio non c'è nello standard di programmazione Android, la cui piattaforma base è Java su ARM e quindi, avrebbe sicuramente bisogno di un incremento di prestazioni anche su altri fronti, oltre alla rappresentazione grafica.
    non+autenticato
  • le OpenGL hanno fallito => ennesimo fallimento del mondo open.
    Ci fosse un progetto open che venga adottato seriamente!
    non+autenticato
  • Apache2 quindi lo mettiamo nel cesso direttamente?
    non+autenticato
  • Lo standard TCP-IP al bando!
    E' open pure lui!

    Lascialo stare, non sa ma parla.
    non+autenticato
  • - Scritto da: Giulia
    > Apache2 quindi lo mettiamo nel cesso direttamente?

    ma anche si, meglio nginx
    non+autenticato
  • concordo!
    Per il software specialistico non e' la soluzione
    non+autenticato
  • - Scritto da: mimmo
    > concordo!
    > Per il software specialistico non e' la soluzione

    Frase più sbagliata non la potevi dire.

    Sai chi continuerà a usare OpenGL per anni a venire?
    I software CAD/CAM e di modellazione 3D, roba specialistica come poche.

    In questi programmi si usano pochi poligoni, zero texture e certe volte addirittura solo il wireframe: con le OpenGL hanno già prestazioni ottime, figurarsi se si mettono a smazzarsi pure la memoria e la sincronizzazione del multithreading "perké le Vulkan sono più fike XD XD"...
    Le lib ad alto livello vivranno ancora a lungo.
  • - Scritto da: dumah

    > le OpenGL hanno fallito => ennesimo fallimento
    > del mondo
    > open.
    > Ci fosse un progetto open che venga adottato
    > seriamente!

    Le OpenGL vengono usate su tutti i giochi mobile, per Android e per iOS, oltre che per diversi giochi per Windows e praticamente tutti quelli per Linux e OSX.

    Se chiami fallimento questo, voglio fallire anche io!
    non+autenticato
  • Ehm.

    sad fsafdf sa
    asf asdf sadf asdfasfa sdf?

    Okay?

    Pressochè è quello che devi avere in testa tu.
    non+autenticato
  • - Scritto da: dumah
    > le OpenGL hanno fallito => ennesimo fallimento
    > del mondo
    > open.
    > Ci fosse un progetto open che venga adottato
    > seriamente!

    Sei proprio convinto di quello che vai dicendo (o che ti fanno dire)?