Questa è davvero una ottima idea, se funziona correttamente e senza overhead particolari. Chissà in quanto AMD risponderà. Ad intuito sembra una soluzione applicabile un po' per tutti
Questo commento è stato nascosto automaticamente.
Questa è davvero una ottima idea, se funziona correttamente e senza overhead particolari. Chissà in quanto AMD risponderà. Ad intuito sembra una soluzione applicabile un po' per tutti
Si ottima cosa..... Da prendere esempio.

Pero in questo caso serve per attutire le prestazioni scarsine di questi processori
Questo commento è stato nascosto automaticamente.
Questa è davvero una ottima idea, se funziona correttamente e senza overhead particolari. Chissà in quanto AMD risponderà. Ad intuito sembra una soluzione applicabile un po' per tutti
AMD non ha CPU ibride, però...i core sono tutti "performance"
Questo commento è stato nascosto automaticamente.
1
APO è una delle cose più anti informatica che leggo da anni. il sistema operativo dovrebbe essere agnostico verso i programmi user space che esegue. Qua abbiamo invece una cosa che gira a livello kernel (quindi è come se fosse il SO) che deve venir aggiornata app per app. Quindi è il sistema operativo che modifica il proprio comportamento in base all'app che viene eseguita.

questa roba è semplicemente una porcheria, che nel tempo mostrerà tutti i suoi limiti architetturali
Questo commento è stato nascosto automaticamente.
APO è una delle cose più anti informatica che leggo da anni. il sistema operativo dovrebbe essere agnostico verso i programmi user space che esegue. Qua abbiamo invece una cosa che gira a livello kernel (quindi è come se fosse il SO) che deve venir aggiornata app per app. Quindi è il sistema operativo che modifica il proprio comportamento in base all'app che viene eseguita. questa roba è semplicemente una porcheria, che nel tempo mostrerà tutti i suoi limiti architetturali
manda un curriculum ad intel, così almeno ti prendono.
Questo commento è stato nascosto automaticamente.
APO è una delle cose più anti informatica che leggo da anni. il sistema operativo dovrebbe essere agnostico verso i programmi user space che esegue. Qua abbiamo invece una cosa che gira a livello kernel (quindi è come se fosse il SO) che deve venir aggiornata app per app. Quindi è il sistema operativo che modifica il proprio comportamento in base all'app che viene eseguita. questa roba è semplicemente una porcheria, che nel tempo mostrerà tutti i suoi limiti architetturali
E l'upscaling e no perché non è la stessa cosa che la risoluzione nativa. Il DLSS no perché i fotogrammi sono fake. L'APP no perché è una porcheria.... Ma alla fine se per l'utente finale che nel 90% dei casi non è un informatico e vede il suo gioco preferito viaggiare ad alta risoluzione con tutto attivato molto "fluido" con praticamente la stessa qualità grafica, ma chissenefott....
Questo commento è stato nascosto automaticamente.
APO è una delle cose più anti informatica che leggo da anni. il sistema operativo dovrebbe essere agnostico verso i programmi user space che esegue. Qua abbiamo invece una cosa che gira a livello kernel (quindi è come se fosse il SO) che deve venir aggiornata app per app. Quindi è il sistema operativo che modifica il proprio comportamento in base all'app che viene eseguita. questa roba è semplicemente una porcheria, che nel tempo mostrerà tutti i suoi limiti architetturali
Mmm, e perché mai, scusa? Il SO usa tecniche standard (es lo scheduler) che potrebbero non essere ottimali per ogni uso. Magari se hai excel, word, Chrome, gimp e teams aperti, lo scheduler fará il suo lavoro egregiamente, ma siccome il game developer non ha accesso proprio a tutto, se l'OS si prende la briga di ottimizzare l'esecuzione dei propri processi in base all'applicazione che sta girando, perché no? Non sarebbe lo stesso se l'OS mettesse a disposizione una API che il gioco puó usare per scegliere l'algoritmo e precisare alcuni parametri di esecuzione?
Questo commento è stato nascosto automaticamente.
Intel sta usando i soldi freschi dello Stato per fare un po' di marketing con idee a basso costo, cercando di risollevarsi dalla sua (autoprovocata) disastrosa condizione.
L'idea dell'APO non è malvagia, ma Intel dovrà alzarne parecchie di 'asticelle' per riprendersi.
Questo commento è stato nascosto automaticamente.
0
Non sarebbe lo stesso se l'OS mettesse a disposizione una API che il gioco puó usare per scegliere l'algoritmo e precisare alcuni parametri di esecuzione?
questa sarebbe esattamente la cosa corretta da fare. il SO mette a disposizione un modo per permettere all'app di scegliere quale scheduler (o altro) usare. È quindi a carico dell'app scegliere la configurazione più idonea per se stessa.

Al contrario con APO è il SO a decidere la configurazione per ogni app, e questa cosa crea mille problemi. se non li vedete, studiate :D

DLSS upscaling o frame generator non c'entrano una mazza, ma comunque architetturalmente parlando sono corrette.
(il fatto poi che il FG sia quasi una truffa marketing è un altro discorso)
Questo commento è stato nascosto automaticamente.
E l'upscaling e no perché non è la stessa cosa che la risoluzione nativa. Il DLSS no perché i fotogrammi sono fake. L'APP no perché è una porcheria.... Ma alla fine se per l'utente finale che nel 90% dei casi non è un informatico e vede il suo gioco preferito viaggiare ad alta risoluzione con tutto attivato molto "fluido" con praticamente la stessa qualità grafica, ma chissenefott....
chissenefo**e mica tanto, hai ragione a dire che all'utente interessa vedere il giochino o l'app che gira bene, ma avere sotto il cofano tecnologie acerbe o del tutto "modaiole" rende il tutto fragile e insicuro
Questo commento è stato nascosto automaticamente.
APO è una delle cose più anti informatica che leggo da anni. il sistema operativo dovrebbe essere agnostico verso i programmi user space che esegue. Qua abbiamo invece una cosa che gira a livello kernel (quindi è come se fosse il SO) che deve venir aggiornata app per app. Quindi è il sistema operativo che modifica il proprio comportamento in base all'app che viene eseguita. questa roba è semplicemente una porcheria, che nel tempo mostrerà tutti i suoi limiti architetturali
Forse non sai che anche AMD usa una cosa simile per le sue CPU multi chiplet per decidere come gestire i thread che altrimenti finirebbero sul chiplet errato causando una diminuzione delle prestazioni.
Peggio ancora per i multi chiplet dove uno solo ha la cache X3D.. in quel caso, se avvii un gioco, l'altro chiplet, quello senza cache, viene letteralmente spento così che non ci sia alcuna confusione su dove eseguire i thread dei giochi, con tutti i benefici energetici associati.
La pratica di correggere il normale comportamento dello scheduler dell'OS è sempre esistita, perché una ipotetica API deve essere usata dal programmatore, ma non tutti la userebbero e sicuramente non funzionerebbe per codice non più mantenuto.
E così si mette una pezza come si può.
Che è poi quello che fanno anche i driver grafici rispetto alle librerie grafiche, cioè sistemare le porcate che fanno i programmatori per meglio ottimizzare ordine di chiamate e dati su cui queste operano.
Non mi sembra che qualcuno sia mai salito in cattedra a dire: eh, ma che porcata i driver grafici, significa che le architetture fanno schifo. Anche se ormai sono grandi GB, e lo sono perché contengono un sacco di codice supplementare da eseguire per questa o quella specifica applicazione/gioco.
Semplicemente si usa il metodo migliore per correggere le inevitabili porcate che improvvisati programmatori producono. Se aspetti che siano loro a sistemare i problemi, passano anni, sempre che ne siano capaci.
Questo commento è stato nascosto automaticamente.
questa sarebbe esattamente la cosa corretta da fare. il SO mette a disposizione un modo per permettere all'app di scegliere quale scheduler (o altro) usare. È quindi a carico dell'app scegliere la configurazione più idonea per se stessa. Al contrario con APO è il SO a decidere la configurazione per ogni app, e questa cosa crea mille problemi. se non li vedete, studiate :D DLSS upscaling o frame generator non c'entrano una mazza, ma comunque architetturalmente parlando sono corrette. (il fatto poi che il FG sia quasi una truffa marketing è un altro discorso)
No, quello che deve studiare sei tu perché mi sa che di scheduler e i motivi per cui il suo normale funzionamento debba essere modificato a seconda dell'app che vien eseguita ce ne sono a bizzeffe e non si risolvono con una semplice API che potrebbe non essere usata dal programmatore o non essere più valida al cambio dell'architettura della CPU.
Questo commento è stato nascosto automaticamente.
chissenefo**e mica tanto, hai ragione a dire che all'utente interessa vedere il giochino o l'app che gira bene, ma avere sotto il cofano tecnologie acerbe o del tutto "modaiole" rende il tutto fragile e insicuro
Tecnologia "acerbe o modaiole".. che gran bel odo di dire "non so un caxxo dell'argomento ma sparo a zero perché nel titolo c'è scritto Intel".
Questo commento è stato nascosto automaticamente.
Questa è davvero una ottima idea, se funziona correttamente e senza overhead particolari. Chissà in quanto AMD risponderà. Ad intuito sembra una soluzione applicabile un po' per tutti
AMD è già in vantaggio su questa cosa avendo un bel driver CPU che cambia il comportamento della CPU quando si eseguono i giochi sui processori multi-chiplet.
Cerca di accorpare tutti i thread sullo stesso chiplet se i chiplet sono uguali, se invece c'è n'è uno con la cache X3D e l'altro no, allora spegne proprio quest'ultimo e usa solo il primo per evitare casini di allocazioni sbagliate dei thread.
E sarò comunque costretta a fare una cosa del genere con i processori che integrano sia i core espansi che quelli compatti (C-core) se li porta sul desktop. Nel mobile frega niente a nessuno che tanto vende quattro portatili in croce e quindi anche lei per ora non ha fatto nulla.
Questo commento è stato nascosto automaticamente.