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

Cappej

13-06-2014, 16:25

MOOOLTO CARINA COME INIZIATIVA!!

Ma quindi posso anche pensare di usare questo sistema anche ad esempio su un telefono di fascia alta per rasformarlo in un "pc" attaccandolo ad uno schermo?

cedo sia il contrario, trasforma qualsiasi PC in android con prestazioni superiori... vista la potenza di calcolo delle CPU da fisso e/o notebook.
c'ho capito poco, ma "credo" si chiami Console, perchè diventa una sorta di console android sulla quale far girare applicazioni...
Comunque non è molto chiaro... credo parli solo di PC e non MAC (in modalità nativa non virtualizzata) anche se dietro di lui ci sono diversi Apple

frankie

13-06-2014, 16:33

Non sarà android 5 che sbarcherà con un interfaccia desktop?

Khronos

13-06-2014, 16:36

0:57,

Android è un TradeMark,

Windows no?

lol.

laverita

13-06-2014, 16:38

Poi c'è chi dice che la droga non fa male.

SCR1

13-06-2014, 17:13

Funziona anche con windows 7?
Sarei tentato di provarlo su un pc u po datato.
Però non sono 10 dollari ma 16 da donare , o sbaglio?

thedoctor1968

13-06-2014, 17:56

è un piacere che si sta ritornando alla grande alle open gl

bonzoxxx

13-06-2014, 18:29

mi piacerebbe provarlo, piu che altro per vedere se aumenta o meno l'autonomia di un notebook.

riguardo al giocare... boh, non ho interesse a riguardo

Z80Fan

13-06-2014, 20:16

La boiata del secolo insomma.

Un bidone di OS per smartphone (lo dico per lo più dal lato sviluppatore; lato utente *FORSE* si salva un pochino) messo su un PC...

Bon si, se uno il PC lo deve usare come soprammobile, allora metterci Android può essere una buona idea...

E intanto, nel video, neanche un piccolo demo della loro mirabolante interfaccia a finestre... :rolleyes:

è un piacere che si sta ritornando alla grande alle open gl

Non si è mai andati via da OpenGL (ES in questo caso), anzi, dopo Mantle, D3D12, Metal (e nessuna notizia da Khronos riguardo OpenGL 5 e ES 4), il periodo in cui rischia veramente di morire è questo.

bonzoxxx

13-06-2014, 20:25

mi sfugge l'utilità di android su pc...

sempre che se ho un pc che riesce a far girare 8.1 (e probabilmente il SO microsoft successivi) di android me ne frega relativamente.

Pier2204

13-06-2014, 21:09

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

LMCH

13-06-2014, 23:11

è un piacere che si sta ritornando alla grande alle open gl

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.

LMCH

13-06-2014, 23:21

Non si è mai andati via da OpenGL (ES in questo caso), anzi, dopo Mantle, D3D12, Metal (e nessuna notizia da Khronos riguardo OpenGL 5 e ES 4), il periodo in cui rischia veramente di morire è questo.

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).

Z80Fan

14-06-2014, 00:29

No, se sviluppi giochi o roba grafica per Android, iOS, macOS, console Sony o Nintendo esiste solo OpenGL come API "di base".

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.

ComputArte

14-06-2014, 08:40

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

acerbo

14-06-2014, 13:16

Lo scopo di questa iniziativa?

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

acerbo

15-06-2014, 11:37

Ma Windows in un tablet è un miglioramento, android nel pc è l'equivalente informatico dello zucchero nel serbatoio della benzina :asd:

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

LMCH

15-06-2014, 17:34

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).

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.

Playstation e Wii NON usano OpenGL, ma delle librerie proprietarie.
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.

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.

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).

Z80Fan

15-06-2014, 18:07

Mah! Probabilmente verrà usata dai game engine

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.

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

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 (http://www.opengl.org/wiki/GLAPI/glDrawElementsInstancedBaseVertexBaseInstance)), allora bisogna ammettere che c'è qualcosa che non va.

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).

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 (http://www.khronos.org/opengles/adopters/) (anche se dubito riesca a analizzare ogni singola parte della specifica).