E' inutile.
I driver funzionano a profili, quando fanno l'aggiornamento "ottimizzato" per un gioco generalmente è solo un profilo che non era presente prima e viene aggiunto o che esisteva e viene rimpiazzato.
Se i giochi vecchi non vengono toccati probabilmente non verranno toccati nemmeno i profili. Non c'è bisogno di fare sta tarantella. Se proprio vuoi, puoi tenerti l'installer della penultima versione, ma lol no sono solo megabyte sprecati
Sapevo anche io questa cosa, ma comunque ho notato che a volte, per qualche motivo magari non dipendentemente direttamente dai drivers, un driver vecchio non mostra problemi o li mostra molto di meno in un contesto specifico, ci sono alcuni esempi che potrei fare, specialmente con schede più vecchie, che non sono nemmeno operabili oltre i drivers di Ottobre scorso, anche se sulla carta lo sono.
Generalmente è come dici te, assolutamente.
Con il cambio architettura ci si potrà aspettare presto una breve successione di driver legacy che poi non verranno più toccati, e quello sarà un buon momento per levarsi certe fisse prevalentemente infondate di torno.
Per adesso tengo quelli di Maggio, dato che quelli beta di Luglio sono usciti prevalmentemente per dare un primo supporto alle schede serie 5700.
Non ti preoccupare, ho terabyte(s) di spazio in totale, su quello al momento non sono affatto carente.
---------------------------------------------------------------
Per spiegare meglio e più concretamente il problema di GCN che ho illustrato un po' semplicisticamente prima, metto giù un po' di dati:
Tutti sanno che l'architettura GCN + limitata ad un massimo totale di 4096 unità di streaming, suddivise in un massimo di 64 compute units (che di per sè non è rilevante per questo esempio) che vengono operate da non oltre 16 pipelines complete, ma tendenzialmente ne vengono usate solo 4, riducendo di fatto l'output delle operazioni più parallelizzabili fino ad un quarto di quanto teoreticamente possibile.
Questo intacca enormemente le prestazioni geometriche, che sono da sempre il tallone d'achille (anche riduttiva come espressione) delle GPU basate su GCN.
In altri tipi di operazioni tipiche da scheda grafica come texture mapping, rastering e shading è sempre stata molto forte, ma poi lì ad un certo punto c'è il discorso della banda passante a fare da tetto prematuro, ma sono comunque numeri eccellenti per il periodo attuale, anche con il collo di bottiglia di memoria che si portano dietro dal periodo post-Terascale.
Questo di base le rende schede non adatte per i videogiochi, che tendono a richiedere più operazioni su molte meno pipeline (idealmente, la metà o anche meno di quelle che GCN dovrebbe usare per dare il meglio) per questioni di consistenza (meno frametime ballerini causati da cicli di latenza poi difficilmente individuabili ed aggirabili), e sicuramente, da come fanno capire le spiegazioni degli esperti di API e renderer, di carico di lavoro del programmatore che deve adattare il renderer al modo di lavorare della scheda, se la deve supportare.
La soluzione? C'è, o almeno, ci doveva essere.
Un progetto abbastanza importante per la direzione dell'ex CTO di Radeon Technologies, Raja Koduri, era l'implementazione effettiva del "primitive discard" o geometria primitiva in sostituzione del metodo tradizionale, per portare le capacità di tutte le schede radeon supportate da:
- 4 triangoli per ciclo di clock.
a:
- 11 triangoli per ciclo di clock. Un icremento del 260% sul metodo di calcolo della geometria attualmente in uso.
Questo avrebbe portato probabilmente le prestazioni di buona parte delle schede GCN da Tonga in poi ad un livello di scaling geometrico pari all'attuale architettura Nvidia (composta da Maxwell, Pascal, Turing) e rendendo con tutta probabilità una Radeon Vega 56 veloce quanto una GTX 1080ti se i driver prevedevano un'implementazione globale di questi primitives.
Ma poi il tutto è stato cancellato.
EhBeh
Connettiti
Registrati subito
36
Torna su
in compenso sempre le asus per le memorie sono idilliache.
