SteamOS verso un cambiamento epocale: arrivano i layer di compatibilità per Android e Arm

[Redazione di Hardware Upg]

Link alla notizia: https://gaming.hwupgrade.it/news/vid...rm_159337.html

Valve ha annunciato due enormi novità per SteamOS: FEX e Lepton. Il primo consente di eseguire le applicazioni x86-64 su architettura Arm, mentre il secondo estende la compatibilità delle applicazioni Android a SteamOS

Click sul link per visualizzare la notizia.

[Amigomerlo]

Chissà se arriveranno a far si che l'app android consenta l'installazione diretta di giochi pc.

[jepessen]

Ma non sarebbe tipo vietato da ogni EULA di ogni videogioco il reverse engineering ed in generale lo smandruppamento dei file del gioco, ergo vietandone una eventuale ricompilazione?

[Amigomerlo]

Originariamente inviato da jepessen

Ma non sarebbe tipo vietato da ogni EULA di ogni videogioco il reverse engineering ed in generale lo smandruppamento dei file del gioco, ergo vietandone una eventuale ricompilazione?

I layer di compatibilità si "limitano" a tradurre le chiamate per sfruttare librerie native di una certa architettura, su altre architetture. I file di gioco non vengono modificati in alcun modo e li si usa "da supporto originale".

[supertigrotto]

Pico monta Android, Quest monta Android, Samsung Xr monta Android,se non vogliono ritrovarsi con 4 giochi in croce per steam frame e stimolare la produzione di giochi VR devono fare così,steam non è né Sony,ne Nintendo ne Microsoft che hanno posizioni più solide.

[jepessen]

Originariamente inviato da Amigomerlo

I layer di compatibilità si "limitano" a tradurre le chiamate per sfruttare librerie native di una certa architettura, su altre architetture. I file di gioco non vengono modificati in alcun modo e li si usa "da supporto originale".

Beh. insomma... L'articolo parla espliciamente di "ricompilazione binaria", ed anche il sito FEX-Emu lo conferma, dicendo

On the technical side, FEX features an advanced binary recompiler that supports all modern extensions of the x86(-64) instruction set, including AVX/AVX2. The heart of this recompiler is a custom IR that allows us to generate more optimized code than a traditional splatter

Quindi si, il codice lo ricompila... Poi se la ricompilazione rimane in memoria oppure se fanno un altro file non lo so, ma smandruppa proprio i files, non e' come Wine, per dire, che lascia i file inalterati ma permette le chiamate alle funzioni windows.

[maxsona]

Non si potrebbe fare in modo che il gioco si compili in fase di installazione sul dispositivo su cui è installato?

[jepessen]

Originariamente inviato da maxsona

Non si potrebbe fare in modo che il gioco si compili in fase di installazione sul dispositivo su cui è installato?

No per diversi motivi, fra i quali:

1. Compilare sulla macchina dove e' installato il gioco significa rendere disponibili i sorgenti del gioco, cosa che per ovvi motivi non vogliono fare, cosi' come gli asset etc.
2. Oltre al gioco bisogna tenere conto di un sacco di dipendenze esterne, strumenti di sviluppo, librerie acquisite con licenza etc.
3. Ovviamente ci deve essere un compilatore adatto installato nel PC, e non e' detto per motivi di aggiornamenti etc, che se il gioco compila su un compilatore, allora compila su tutti
4. E oltre al compilatore ci sono sicuramente un sacco di tool proprietari per la compilazione, tool che autogenerano il codice, tool di conversione di asset, tool di pacchettizzazione, tool....... Insomma, ci siamo capito
5. Un gioco puo' essere fatto con diversi linguaggi di programmazione, ognuno dei quali richiede un compilatore a parte
6. La macchina puo' tranquillamente non essere adatta alla compilazione, per numero di processori, di RAM etc.
7. Compilare un gioco significa avere a disposizione una quantita' enorme di spazio su disco, specialmente se bisogna compilare asset etc.
8. Anche quando la macchina fosse in grado di compilare, ci vorrebbe un'enormita' di tempo su un singolo computer.
9. La licenza e i sistemi anticopia vanno a farsi benedire

[lollo9]

jepessen una cosa per volta

wine intanto via di qui che non c'entra che lui sì reimplementa le API win32

FEX fa quello che fanno qemu user mode o rosetta, vale a dire leggere il flusso di istruzioni x86-64, tradurre blocchi in aarch64 e tenerli in memoria, con una cache. "ricompilazione binaria" e' letteralmente questo: ne' un file riscritto ne' bisogno di sorgenti, l'eseguibile su disco resta identico byte per byte, l'hash prima e dopo e' lo stesso. non ti serve nessun tool di sviluppo od altre amenità: il ricompilatore ha già tutto in pancia, un dizionario ISA su ISA e tanta euristica

il file non "sa" che sta passando per una ricompilazione binaria
che poi, il tuo ryzen fa esattamente la stessa cosa quando converte le istruzioni x86 in micro-op, e non risulta smandruppi i file

quanto a FEX, i traduttori binari campano di cache: il codice caldo viene rieseguito milioni di volte e ritradurlo a ogni giro ti mangerebbe il budget per frame. i binari che si automodificano invece (packer, drm che si scompattano in memoria, jit interni ai motori ecc.) invalidano i blocchi gia' tradotti e costringono a rifare il lavoro. il dazio prestazionale si paga tutto li'
in ogni caso, la cache e' artefatto di FEX, il binario x86 nessuno lo tocca

sull'EULA: non c'e' reverse engineering di niente. quello che viene reimplementato e' il set di istruzioni intel/amd, che non appartiene a chi ti vende il gioco. altrimenti sarebbero illegali qemu, rosetta, box64 e compagnia cantante. non lo sono da trent'anni, non iniziano certo adesso
il motivo e' sempre che nessuno tocca il binario del publisher.

l’artefatto del publisher viene letto così com’è ed eseguito

[jepessen]

Originariamente inviato da lollo9

jepessen una cosa per volta

wine intanto via di qui che non c'entra che lui sì reimplementa le API win32

che e' quello che ho detto, wine si comporta diversamente da FEX e non va a modificare il codice dell'eseguibile

FEX fa quello che fanno qemu user mode o rosetta, vale a dire leggere il flusso di istruzioni x86-64, tradurre blocchi in aarch64 e tenerli in memoria, con una cache.

"ricompilazione binaria" e' letteralmente questo: ne' un file riscritto ne' bisogno di sorgenti, l'eseguibile su disco resta identico byte per byte, l'hash prima e dopo e' lo stesso. non ti serve nessun tool di sviluppo od altre amenità: il ricompilatore ha già tutto in pancia, un dizionario ISA su ISA e tanta euristica

E questo e' vietato dalla EULA. Nel ho presa una a caso, quella di Death Stranding. Punto 6-C:

L'utente accetta espressamente di non estrarre informazioni, decodificare, disassemblare, decompilare o tradurre il Prodotto software o altresì di non tentare di ottenere il codice sorgente del software,

Questo e' quello che fa FEX, perche' di fatto decompila il software per ricompilarlo in un altro modo, poco importa se rimane tutto dietro le quinte e rimane tutto in memoria, l'operazione e' sempre quella. il fatto che sia euristica etc non toglie il fatto che stia estraendo informazioni dalle librerie per riutilizzarle in altro modo, specialmente un cambio architettura.

il file non "sa" che sta passando per una ricompilazione binaria
che poi, il tuo ryzen fa esattamente la stessa cosa quando converte le istruzioni x86 in micro-op, e non risulta smandruppi i file

Non c'entra, lui legge le istruzioni fatte per lui e basta. Poi internamente il processore le rielabora per le pipeline, caching etc, ma sono cose che rimangono dentro il processore e comunque non si tratta di riprodurre la libreria per un'altra architettura. Il processore fa quello per cui e' progettato perche' se non fosse cosi' semplicemente non potrebbe funzionare il software. Qua non parliamo di codice elaborato dal processore per eseguirlo, si tratta di un altro software che decompila al volo una libreria per modificarne il codice per un altro scopo, quello di eseguirlo per un'altra architettura.

quanto a FEX, i traduttori binari campano di cache: il codice caldo viene rieseguito milioni di volte e ritradurlo a ogni giro ti mangerebbe il budget per frame. i binari che si automodificano invece (packer, drm che si scompattano in memoria, jit interni ai motori ecc.) invalidano i blocchi gia' tradotti e costringono a rifare il lavoro. il dazio prestazionale si paga tutto li'
in ogni caso, la cache e' artefatto di FEX, il binario x86 nessuno lo tocca

Come ho gia' detto, e' vietata l'operazione di decompilazione, poco importa se rimane in cache oppure no, perche' e' sempre codice che poi viene riutilizzato, cosa vietata.

sull'EULA: non c'e' reverse engineering di niente. quello che viene reimplementato e' il set di istruzioni intel/amd, che non appartiene a chi ti vende il gioco. altrimenti sarebbero illegali qemu, rosetta, box64 e compagnia cantante. non lo sono da trent'anni, non iniziano certo adesso
il motivo e' sempre che nessuno tocca il binario del publisher.

l’artefatto del publisher viene letto così com’è ed eseguito

Di nuovo non e' cosi'. Lo scopo finale e' eseguire il programma su un'altra architettura, ma per farlo il codice viene reimplementato eccome, l'hai detto tu stesso. Ripeto, il fatto che cerce operazioni rimangano in cache e siano trasparenti per noi non significa che non accadano. Il fatto inconfutabile e' che il processore esegue un codice, per quanto adattato, diverso da quello originale, per farlo FEX estrae dati e logica dalle librerie e le ricompila e le esegue. Questo e' vietato dalla EULA.

[Amigomerlo]

Ma i file di gioco non vengono toccati.
Sono le istruzioni a venire elaborate. Le chiamate alle librerie, di diversa natura. Ieri ho provato a rispondere da telefono ma continuava a sloggarmi, poi lollo è intervenuto con una precisione e una chiarezza che non avrei mai potuto vantare.
Semmai potrebbe essere Microsoft ad avere pretese (per quanto riguarda il layer proton e similari).

[jepessen]

Originariamente inviato da Amigomerlo

Ma i file di gioco non vengono toccati.
Sono le istruzioni a venire elaborate. Le chiamate alle librerie, di diversa natura. Ieri ho provato a rispondere da telefono ma continuava a sloggarmi, poi lollo è intervenuto con una precisione e una chiarezza che non avrei mai potuto vantare.
Semmai potrebbe essere Microsoft ad avere pretese (per quanto riguarda il layer proton e similari).

Again, i file di gioco non vengono modificati, ma vengono letti, decompilati e ricompilati in un altro formato.e questo e' vietato dalla EULA che vieta di estrarre informazioni e dati dai file di gioco, che e' esattamente quello che fa FEX.

[ZeroSievert]

Originariamente inviato da maxsona

Non si potrebbe fare in modo che il gioco si compili in fase di installazione sul dispositivo su cui è installato?

Originariamente inviato da jepessen

No per diversi motivi, fra i quali:

1. Compilare sulla macchina dove e' installato il gioco significa rendere disponibili i sorgenti del gioco, cosa che per ovvi motivi non vogliono fare, cosi' come gli asset etc.
2. Oltre al gioco bisogna tenere conto di un sacco di dipendenze esterne, strumenti di sviluppo, librerie acquisite con licenza etc.
3. Ovviamente ci deve essere un compilatore adatto installato nel PC, e non e' detto per motivi di aggiornamenti etc, che se il gioco compila su un compilatore, allora compila su tutti
4. E oltre al compilatore ci sono sicuramente un sacco di tool proprietari per la compilazione, tool che autogenerano il codice, tool di conversione di asset, tool di pacchettizzazione, tool....... Insomma, ci siamo capito
5. Un gioco puo' essere fatto con diversi linguaggi di programmazione, ognuno dei quali richiede un compilatore a parte
6. La macchina puo' tranquillamente non essere adatta alla compilazione, per numero di processori, di RAM etc.
7. Compilare un gioco significa avere a disposizione una quantita' enorme di spazio su disco, specialmente se bisogna compilare asset etc.
8. Anche quando la macchina fosse in grado di compilare, ci vorrebbe un'enormita' di tempo su un singolo computer.
9. La licenza e i sistemi anticopia vanno a farsi benedire

Oddio.. programmando con .NET e Java in teoria lo puoi fare. Pero' sicuramente non su giochi AAA (.NET e' molto usato, ma di solito e' accoppiato a un engine ad alte prestazioni in C++)

EDIT:

Forse la cosa che ci si avvicina di piu' e' webassembly. Sarebbe interessante capire quanto si perde per strada in termini di performance rispetto a un binario nativo. Sicuramente qualche ottimizzazione non e' possibile con WASM.

[ZeroSievert]

Originariamente inviato da jepessen

Again, i file di gioco non vengono modificati, ma vengono letti, decompilati e ricompilati in un altro formato.e questo e' vietato dalla EULA che vieta di estrarre informazioni e dati dai file di gioco, che e' esattamente quello che fa FEX.

Boh.. pero' a me questo non sembra tanto diverso da fare un'emulazione. Certo, FEX ha un compilatore JIT, ma il concetto e' lo stesso.

Che poi anche wine e qualsiasi binary loader "smandruppano" a loro modo gli eseguibili. Alla fine devono mappare i dati nelle varie regioni di memoria, settare i permessi di lettura/scrittura/esecuzione delle stesse, fare il link delle librerie dinamiche, relocazioni, etc. etc. I file eseguibili non vengono caricati in memoria "cosi' come sono" anche sulla loro piattaforma nativa.

Il punto e' decidere cosa vuol dire "estrarre informazioni". Se questo FEX non distribuisce le informazioni del binario a giro, non vedo il problema. Che e' alla fine e' il senso delle voci EULA che hai citato.

EDIT:

Ho letto che anche QEMU ha una IR intermedia dei binari letti. Ergo "smandruppa" e "ricompila" pure lui. La differenza e' che questo FEX e' piu' specializzato per X86.

EDIT 2:

Comunque nel caso non sarebbe FEX che viola la EULA ma chi lo usa. Anche se continuo a pensare che nessun produttore si metterebbe a fare una causa legale per questo visto che non e' neanche detto che ne uscirebbe vittoriosa.

[zanarkand]

Non c'era già GameNative a fare questo lavoro?
Certo, richiede uno smart bello carrozzato. L'ho provato sul mezzo vetusto Mi 9T e riesce ad installare ma non avvia. Non ce la fa