Console OS: Android con mouse e tastiera su un comune PC o tablet Windows

Lo scopo di questa iniziativa?

Con il pc non ci telefono, al limite uso Skype, giocare ai giochini da smartphone su PC? ..na figata
Non capisco il senso

Si è già "ritornati", su tutti i dispositivi Android l'accelerazione grafica avviene via OpenGL ES, come pure su iOS e sui mac.
Inoltre visto che il BSP per sistemi Android è essenzialmente Linux più tutta una serie di librerie native (incluso OpenGL ES) la cosa ha avuto ripercussioni positive anche su un sacco di prodotti embedded.

No, se sviluppi giochi o roba grafica per Android, iOS, macOS, console Sony o Nintendo esiste solo OpenGL come API "di base".
Non parliamo poi della rinascita di OpenGL in ambito embedded ("trainato" dalla disponibilità dei BSP basati su Linux per SoC utilizzabili anche per realizzare dispositivi Android).

Apple ha già presentato Metal per iOS, che credo fermamente diventerà l'API grafica principale (sopratutto quando gli engine verranno adattati; non ci sono molte app che usano direttamente OpenGL); su MacOS X forse arriverà; non è così critico dato che non ci sono così tante applicazioni che sfruttano massicciamente la grafica (il GPGPU è molto più importante in MacOS).

Playstation e Wii NON usano OpenGL, ma delle librerie proprietarie.

L'unico posto dove OpenGL può rimanere è Android, dato che è ovvio che a Google non interessa niente degli sviluppatori o delle prestazioni del suo sistema.


Il problema è che OpenGL è un'API pesantissima e estremamente obsoleta nei suoi concetti fondamentali: estremamente CPU-bound, nessun multithreading, relativamente bassa integrazione con funzioni GPGPU, gestione delle risorse molto gravosa per il driver etc.
D3D 11 soffre degli stessi problemi (principalmente la mancanza di "vero" multithreading lato CPU), ed è per questo che Microsoft in D3D 12 ha riprogettato le basi dell'architettura, prendendo molte idee da Mantle; praticamente si sta passando da API che "fanno tutto e anche il caffè" a API più leggere, con meno funzioni ma più generiche e sopratutto molto più veloci (praticamente rispecchiano l'hardware grafico moderno).

Khronos Group (l'ente che standardizza OpenGL) ancora non ha fatto dichiarazioni su OpenGL 5 e OpenGL ES 4, il che mi preoccupa un pochino perchè (da sviluppatore e fan di OpenGL) non vorrei che si ripresentasse la situazione di OpenGL 3, dove promisero una grande evoluzione ma alla fine rimase la stessa vecchia API con qualche funzincina in più.
Diciamo che rimane Nvidia che ha tutto l'interesse ad avere un'API veloce che può far concorrenza a Mantle, e sicuramente premerà al consiglio OpenGL (di cui lei fa parte) per creare una nuova API che sia competitiva e che sfrutti al meglio il suo hardware (Nvidia già da tempo ha creato delle estensioni OpenGL che permettono di sfruttare estremamente bene l'hardware moderno).


Quindi quello che intendevo nel mio commento era questo: OpenGL deve reinventarsi per rimanere al passo coi tempi e non essere sottomessa da queste nuove alternative che stanno nascendo.

Fuffa per spiare ancora meglio!

Che i "vecchi " sistemi operativi avessero buchi è stranoto, ma andare ad installare un OS studiato per avere caratteristiche NATIVE per rubare dati significa darsi la zappa sui piedi....almeno per chi vuole mantenere protetti o solo suoi i dati che genera sul proprio elaboratore. Imho

Se microsoft ha messo windows nei tablet perché uno non puo' mettere android nel desktop?

Se windows in un tablet ARM é un miglioramento allora corro a mettere lo zucchero nella macchina!!!

Mah! Probabilmente verrà usata dai game engine, ma mi sembra troppo di basso livello da essere usata direttamente dalla maggior parte degli sviluppatori che producono per iOS e MacOS X ed il supporto per OpenGL non viene mica rimosso.


Se non sbaglio PS3 usava una versione modificata di OpenGL ES 1 con estensioni, il Wii pure esso una libreria custom che si rifà ad OpenGL.



Oppure per supportare hardware decisamente più variegato, nonostante tutti i difetti e le cose migliorabili, OpenGL risulta essere la scelta migliore.

Il problema maggiore che ho con OpenGL sono i driver buggati che certi produttori hanno il coraggio di commercializzare e non patchare (tipo l'idiotissimo bug che ancora adesso piaga i Samsng Galaxy Tab 3 basati su Soc Marvell con GPU GC1000 Vivante, un fottuto parametro sbagliato in una tabella di configurazione).

Esatto, quello che ho detto io: la maggior parte dei giochi 3D "importanti" già usa un engine e non direttamente OpenGL, quindi basta aggiungere il backend Metal all'engine per rendere compatibile l'app. Ovviamente OpenGL rimarrà per retrocompatibilità con le app non aggiornate e/o engine che non verranno adattati, ma è evidente che Apple sta cercando di spingere in modo da lasciarla come ultima scelta.



OpenGL è l'UNICA scelta (e di conseguenza diventa la migliore), perchè è l'unica API che un produttore può implementare senza tanti pensieri ed è già ben conosciuta dagli sviluppatori; fare una versione proprietaria non avrebbe senso.

Riguardo l'hardware variegato, la GPU moderne si rifanno più o meno tutte agli stessi modelli di funzionamento; anche le GPU embedded hanno architetture flessibili tanto quanto quelle da sistema desktop. Un'ipotetica OpenGL ES 4 può tranquillamente essere più "di basso livello" e comunque prendere una grandissima parte di SoC. Magari non sarà bassa quanto Mantle o Metal, magari invece che 10x draw calls ne fa solo 8x, ma di sicuro deve allontanarsi dal modo corrente di operare: quando esistono almeno 20 modi diversi solo per avviare un disegno, ogni versione che fa qualcosa di *leggermente* diverso dalle altre (arrivando a funzioni quasi comiche tipo questa), allora bisogna ammettere che c'è qualcosa che non va.



I problemi ai driver sono sia a causa della mentalità "quando gira un cubo va bene" degli sviluppatori di SoC, sia perchè anche OpenGL ES, che dovrebbe essere la versione "leggera" per sistemi embedded, è veramente un'API immensa che rende complicatissima la scrittura dei driver.

Un driver più sottile e semplice ha meno code-path da testare e da rendere funzionanti, quindi diminuisce intrinsecamente il numero di bug e di differenze tra driver e driver, per la felicità sia dei programmatori del driver, sia dei programmatori di app.
Un'API più semplice semplifica anche la creazione di tool di test automatico e di certificazione, cosa che solo da poco è stata rilasciata (anche se dubito riesca a analizzare ogni singola parte della specifica).

Ottima idea