Mod e prestazioni

[tea_bag97]

Salve a tutti, questa volta avrei una domanda di carattere un po' più tecnico del solito. KSP è arrivato alla release ufficiale e la vanilla è piuttosto stabile, è ben ottimizzata e sul mio PC gira senza problemi a 60fps e oltre finché non si superano le 100 parti in un veicolo. Il problema sorge quando vengono installate mod: siano alterazioni al gameplay come FAR, l'aggiunta di nuove parti come KW Rocketry o di elementi estetici come l'Astronomer's Pack, vanno tutte ad inficiare negativamente sulle prestazioni del gioco. Ognuna però agisce in maniera differente, che io non conosco. Dalla mia esperienza posso immaginare che mod che aggiungono parti occupano più RAM e rallentano i caricamenti, mod come FAR, Deadly Reentry e RemoteTech rendono i calcoli che il gioco deve eseguire più complessi e quindi richiedono un maggiore sforzo da parte della CPU(?), mentre le mod che migliorano la grafica, come EVE e l'Astronomer's Pack sono per me un mistero.

Un paio di giorni fa ho provato a installare per la prima volta l'Astronomer's Pack, e ho notato che purtroppo era necessario avviare il gioco in OpenGL, che stranamente nel mio caso, a differenza di Scott Manley o Bob Fitch, rende l'immagine spigolosa, come se l'antialiasing non venisse applicato. Ciononostante il frame rate si aggirava tra i 20 e i 25, quindi immagino che questa mod non vada ad impegnare solo RAM e CPU, forse anche la GPU? La cosa più strana è che riscontravo tale frame rate anche nel VAB, il che mi impensierisce perché apparentemente non ci sono effetti dell'AP in quella scena. C'è qualcosa che mi sfugge.

Se qualcuno di voi è in grado di far girare il gioco a frame rate decenti, magari oltre i 30, avendo installato l'Astronomer's pack, o anche solo EVE, insieme a poche altre mod come FAR, sarebbe così gentile da svelarmi come fare? Grazie in anticipo.

In ogni caso questa è la mia configurazione:

-OS: Windows 7 Ultimate x64

-CPU: AMD FX-8150 8-core 3.6GHz

-RAM: 16GB DDR3

-GPU: AMD Radeon R7 200 Series

[Signo]

Per quanto di mia conoscenza KSP non è il software più ottimizzato del mondo: i colli di bottiglia di solito sono la CPU e la RAM.

A KSP non piacciono i tuoi 8 core e li utilizza malamente.

In più se hai la versione a 32 bit non è importante che tu abbia 16GB di RAM ma piuttosto il "clock" della RAM visto che il limite teorico è poco sotto i 4GB.

Per quanto riguarda il rallentamento nel VAB dipende dal fatto che ora attraverso la porta vedi effettivamente l'esterno e non uno sfondo, quindi le risorse per gli abbellimenti estetici sono comunque impegnate.

Ho la tua stessa impressione (e gli spigoli) utilizzando openGL, mi tocca perchè sono un utente di EVE.

Si spera che con il passaggio a Unity 5 molte di queste problematiche siano risolte (sempre per quanto di mia conoscenza la maggior parte delle cose sono imputate a Unity 4.6).

A mio modo di vedere c'è anche un problema nel calcolo aerodinamico durante i "passaggi di turbolenza" che crea parecchio lag: il passaggio della barriera del suono carica la cpu in maniera abnorme così come il contatto con la barriera "too fast too low" per citarne un paio.

KSP: 1.0.4 x32

OS: Win7 Home premium x64

CPU: [email protected] (overclock - BLCK 100 - Turbo 40 - VCore 1.20V - VDRAM 1.5V)

RAM: 16GB@1600MHz

GPU: GeForce GTX 970

Edited August 1, 2015 by Signo

[tea_bag97]

Quindi, se uno dei problemi maggiori è causato dal multicore, è possibile fare in modo che KSP utilizzi soltanto una quantità limitata di core, diciamo 2-3, di modo tale che i processi non vengano "spezzettati" tra tutti e 8 i core, per rendere teoricamente il gioco più veloce? Anche perché monitorando le prestazioni della CPU in diretta, soltanto un paio di core vengono impegnati oltre il 15%, il resto rimane piuttosto inutilizzato, inutilmente a mio parere.

[Signo]

Credo che KSP ne usi uno solo, quindi si autolimita da se.

Il problema è (senza nulla togliere) il software che non sfrutta le risorse.

[tea_bag97]

Quindi finché il gioco non passerà ad Unity 5, sempre se lo farà, non sarà possibile risolvere questi problemi?

E poi mi rimane ancora questo cruccio: come fa Scott Manley a far girare il gioco così fluidamente con praticamente più mod di quelle che uso io? Possibile che sia solo grazie alla maggiore potenza della CPU?

[Signo]

Manley è un noto fan di linux, quindi probabilmente la sua è una installazione linux x64.

[diomedea]

In realtà, Scott lavora per Apple (sul serio) ed ha accesso a configurazioni non ancora disponibili al pubblico. Non meraviglia quindi che abbia più potenza per far girare al meglio KSP. Nè dovrebbe meravigliare che sappia usare al meglio il computer con KSP, di certo conosce meglio di altri come ottimizzarne le prestazioni.

Edited August 2, 2015 by diomedea

[tea_bag97]

Quindi Scott avrebbe accesso a versioni di iOS o KSP che gli permettono di far girare il gioco in x64, o ad un hardware più potente? Perché se il problema del lag può essere risolto installando Linux e quindi potendo giocare in x64, lo faccio subito.

[Signo]

Esiste un workaround per utilizzare la versione x64 anche su Windows.

[tea_bag97]

E la versione x64 mi farebbe avere prestazioni migliori, oltre a crash meno frequenti? Tra l'altro, da quanto ho sperimentato di persona, la versione x64 per Windows è molto più buggata di quella per Linux. Se così fosse, varrebbe la pena di installare Linux su una partizione per giocare ai giochi con Unity in x64?

[Signo]

Sui crash non garantisco, anzi... Per il resto da quello che si capisce dalle devnotes l'aggiornamento dovrebbe essere prossimo, credo ti basterà un po' di pazienza per vedere se vale la pena di organizzare la partizione.

Dopo l'aggiornamento se non sarai ancora soddisfatto linux sarà sempre lì che ti aspetta.

[diomedea]

E la versione x64 mi farebbe avere prestazioni migliori, oltre a crash meno frequenti? Tra l'altro, da quanto ho sperimentato di persona, la versione x64 per Windows è molto più buggata di quella per Linux. Se così fosse, varrebbe la pena di installare Linux su una partizione per giocare ai giochi con Unity in x64?

Sui crash non garantisco, anzi... Per il resto da quello che si capisce dalle devnotes l'aggiornamento dovrebbe essere prossimo, credo ti basterà un po' di pazienza per vedere se vale la pena di organizzare la partizione.

Dopo l'aggiornamento se non sarai ancora soddisfatto linux sarà sempre lì che ti aspetta.

Beh, permettetemi qualche chiarimento. Attualmente, dato che Squad non supporta x64 per Windows (a causa di tanti bug non individuabili e quindi non risolvibili nell'ambiente di sviluppo usato, che fino alla KSP 1.0 è Unity 4.6.1 a 32 bit), per utilizzare KSP in versione Win x64 occorre usare il "community trick" (in pratica, sostituendo alcuni files, tra cui KSP.exe, con quelli distribuiti da Unity, ovviamente da rinominare). Il "trick" non ha alcuna certificazione ufficiale, non è stato testato in ambiente controllato, appare funzionare su alcune configurazioni ma non esiste alcuna garanzia. E men che meno, gli add-ons non sono testati per funzionare con tale "versione", quindi eventali (probabili) bug non sarebbero necessariamente affrontati.

Una nota in particolare: ci sono bug, specifici su Win x64, sicuramente ancora esistenti nelle ultime build ufficiali di KSP 64bit. Dato che il codice relativo non è cambiato, sarebbe quantomeno sorprendente se sparissero solo per aver usato il "trick". Ma tali bug si notano solo in modalità specifiche: il più serio si ha solo in modalità carriera, è facile che passi inosservato.

Circa la versione 1.1, che dovrebbe essere riproposta anche in versione Win x64 (grazie al nuovo editor 64-bit di Unity5), per ora è presto per poter indicare quando arriverà e quali bug possano esserci (purtroppo qualcuno scappa sempre). Dato che i test devono ancora iniziare, e le ultime versioni hanno richiesto (+/-) 3 mesi complessivi di test per la 0.90, 5 mesi per la 1.0, sarebbe almeno sorprendente se i test con la prima versione nel nuovo ambiente a 64bit (ancora tutto da vedere) possano richiedere di meno.

Date queste premesse, se esiste la possibilità di installare anche Linux, ritengo sarebbe al momento la soluzione migliore. Anche Linux ha le sue specifiche fisime, ed ogni tanto saltano fuori bug noiosissimi solo in quell'ambiente. Ma quanto a prestazioni, sicuramente per ora è l'ambiente dove KSP gira al meglio.

[Signo]

Mi era sembrato di sentire nell'ultimo video che Max dicesse che la versione unity 5 stava per essere passata alla QA per settimana prossima e che addirittura se fosse stata pronta prima della 1.1 poteva tranquillamente essere numerata 1.0.qualcosa. Ovviamente non si è sbilanciato però sembrava più fiducioso per U5 che per altro.

Comunque nemmeno io mi sono sbilanciato sul trick. Ho solo detto che esiste e che di sicuro crasha. E che creare una partizione Linux è uno sbattimento e magari conviene aspettare.

[tea_bag97]

Davvero grazie mille a entrambi per i chiarimenti, adesso rimane solo un dubbio da fugare: KSP gira meglio su Linux nel senso che essendo possibile allocare più memoria si possono installare più mod e quindi si possono rendere i crash per Access Violation meno frequenti o migliora anche la performance da un punto di vista del frame rate?

[diomedea]

Davvero grazie mille a entrambi per i chiarimenti, adesso rimane solo un dubbio da fugare: KSP gira meglio su Linux nel senso che essendo possibile allocare più memoria si possono installare più mod e quindi si possono rendere i crash per Access Violation meno frequenti o migliora anche la performance da un punto di vista del frame rate?

Premetto intanto che non posso parlare per esperienza diretta, in quanto il sistema che uso per KSP non è configurato per entrambi gli OS, quindi niente confronti sperimentali.

Inoltre, mi scuso anticipatamente coi puristi se dovessero riscontrare inesattezze in quanto segue.

Sicuramente ogni OS 64bit è in grado di indirizzare 18 exabytes= 18*10^18 bytes, il limite è relativo alle applicazioni, l'OS gestisce la memoria (virtuale) per loro rendendo disponibile solo quanto le applicazioni possono indirizzare, quindi 4 GB nel caso di programmi a 32 bit. Quindi KSP compilato per girare in ambiente 64bit (su Linux) può utilizzare tutta la memoria (virtuale) che l'OS consente. Circa le prestazioni, occorre però chiarire che la memoria può essere individuata in dispositivi anche molto differenti, comunque mi limito a considerare il caso classico di RAM e Memoria di massa. L'OS riceve richieste di allocazione di memoria da parte di tutte le applicazioni e servizi attivi, e distribuisce la preziosa RAM in base alla priorità. Avere altre applicazioni attive, in particolare se in alta priorità, inevitabilmente causerà l'allocazione di spazio sulla Memoria di massa ritardando le operazioni. Quindi anche KSP potrebbe essere rallentato se altre applicazioni risultano prioritarie. Dato che la CPU può solo utilizzare direttamente RAM, è necessario ricaricare le pagine necessarie dalla Memoria di massa prima di proseguire con le operazioni, se l'applicazione era stata messa a priorità inferiore. E naturalmente ritravasarle dalla RAM se nuovamente l'OS dovesse dare priorità ad altre applicazioni.

In pratica, le applicazioni 64bit non vanno in crash per mancanza di memoria (Access Violation), a meno che si saturi anche la Memoria di massa, ma possono essere rallentate per carenza di RAM. Aumentare la RAM aiuta molto; se proprio non si può avere sufficiente RAM per tutto, potrebbe convenire usare una Memoria di massa molto veloce almeno per velocizzare i travasi. Ovviamente gli SSD sono molto più prestanti degli HDD, ma se utilizzati come unità di swap si rovinano anche in fretta.

L'altro importante fattore circa la RAM sono quindi le altre applicazioni e servizi attivi. In questo, Linux è molto più parsimonioso di Windows, le sue applicazioni di sistema richiedono meno risorse. Mentre invece Windows pare "compiacersi" nell'aprire ogni genere di servizio in background, all'insaputa dell'utente, servizi che spesso sono configurati in automatico per usare alta priorità (quindi RAM) non appena un evento lo richieda. E purtroppo anche diversi software che girano sotto Windows usano lo stesso concetto. Quindi, Windows richiede una configurazione "ad hoc" per poter far funzionare i nostri programmi al meglio, con prestazioni adeguate; Linux consente all'utente maggiore controllo e (a meno che sia l'utente stesso a voler aprire troppe cose insieme) risultando in tempi di processazione migliori.

Dato che KSP comunque usa un unico thread (che sia per Windows o Linux non fa differenza, è il runtime di Unity 4.6 che non consente altrimenti), non ci sono differenze circa l'utilizzo della CPU. E pertanto non occorre nemmeno (per ora) esaminare come i due OS gestiscono il multithreading ed il bilanciamento su processori multipli. Sarà da vedere con Unity5 l'effettivo livello di simultaneità ottenibile in KSP.

Discorso a parte (ma sicuramente importante) quello relativo al frame rate. Che dipende in sostanza dalla velocità con cui la CPU riesce ad alimentare la GPU, e quindi dalla velocità della GPU nel realizzare i "frame" richiesti. Qui torna il discorso circa l'occupazione da parte di altre applicazioni e servizi, se si spartiscono gli stessi processori su cui gira il thread di KSP. Ma se sia CPU che GPU sono le stesse per un dato computer, ciò che può cambiare sono le interfacce grafiche. Linux opera con OpenGL; Windows usa di default DirectX, ma può anche passare a OpenGL. In questo, alcuni riportano che OpenGL sia lievemente più lento di DirectX. Nella mia esperienza, non ho trovato alcuna differenza apprezzabile di velocità. Ed anche come qualità, OpenGL è ormai alla pari. Comunque potrebbero essere riscontrati alcuni difetti grafici in particolari condizioni, causa differenza di implementazione delle librerie, su alcune famiglie di GPU (legate agli specifici driver delle case).

Conclusione: senz'altro niente più crash per mancanza di memoria, minori rallentamenti nell'esecuzione, che potrebbero anche avere effetto sul framerate. Con forse minori problemi grafici in determinate condizioni.

[tea_bag97]

Scusate per la risposta attardata, ma sono appena rientrato in possesso del mio pc. Attualmente tra frame rate basso e memoria scarsa il problema che preme di più è il primo, rende impossibile giocare. Quello che mi piacerebbe sapere con precisione è se sia possibile far girare su una configurazione come la mia (l'elenco è nel primo post del thread) KSP con l'Astronomer's Pack ad almeno 30 fps. Tra l'altro mi ricordo che ai tempi della 0.23 ero in grado di far girare il gioco con molte più mod, tra cui la Better Atmospheres V5... mi ricorda quasi il passaggio di Minecraft dalla 1.2.5 alla 1.3.2, quando installare mod è diventato di colpo più difficile.

In ogni caso ho installato l'Astronomer's senza componenti aggiuntivi come tempeste di sabbia o altro, solo quanto necessario.

[Nansuchao]

L'Astronomer su Windows è sconsigliabile, per quanto bellissimo, è troppo pesante. Se non puoi fare a meno di abbellire visivamente il tuo KSP (ed hai perfettamente ragione), ti conviene usare la Renaissance Compilation. Abbellimento a livelli impressionanti e minore utilizzo di RAM rispetto all Astronomer.

Tornando un attimo sul discorso OPENGL, la cosa riguarda molto la configurazione specifica del tuo computer ed eventualmente anche i driver. Sul mio precedente pc, con la 0.90, usavo una marea di mod (ed avevo parecchi crash), ma potevo farlo solo con DirectX11 (che mandano molte operazioni relative alla grafica direttamente alla GPU), mentre sul pc attuale solo OPENGL mi da qualche risultato in termini di prestazioni.

La cosa migliore che puoi fare è provarle entrambi e vedere quale, nel tuo caso specifico, da i risultati migliori.