Newsgroup: it.comp.hardware.video-3d
Titolo: [OT] Giochi, multithreading, e ottimizzazioni artigianali !!!

Non so se qualcuno di voi ha provato la demo, o la versione definitiva di 
need for speet pro street.
Il gioco stuttera, ma questa non è una novità per la serie nfs, ma per la 
qualità video offerta, ha un framerate veramente bassino.
Ho provato a seguire il suggerimento di un utente del forum di hwupgrade
http://www.hwupgrade.it/forum/showthread.php?p=19829362#post19829362
constatando che effettivamente il framerate con questo trucchetto aumenta in 
modo abbastanza marcato
Da così
2007-11-26 22:17:32 - nfsdemo
Frames: 6993 - Time: 158067ms - Avg: 44.240 - Min: 25 - Max: 87
A così
2007-11-26 22:11:30 - nfsdemo
Frames: 8931 - Time: 146750ms - Avg: 60.858 - Min: 38 - Max: 110
Problema di programmazione del gioco, o dello scheduler di windows ?
Ipotesi su cosa possa causare un malfunzionamento che si riesce a risolvere 
solamente in modo artigianale, giocando con l'affinità del processo  ? 

 ha scritto nel messaggio 
news:SmH2j.179838$%k.31...@twister2.libero.it...

ma nfs pro street e' giocabile con una HD2600XT? 

 ma nfs pro street e' giocabile con una HD2600XT?
Scarica la demo e provala. 

 solamente in modo artigianale, giocando con l'affinità del processo  ? 
Sai dirmi quanti thread si avviano con il gioco? E' possibile che (ed è
un errore grave nella programmazione ad agenti se capita troppo spesso)
ci sia un thread che per continuare necessiti che un secondo thread lo
"sblocchi". Ora, se questi thread sono su singola CPU, per forza, a
causa del round robin, saranno tutti eseguiti un po'. Su doppia CPU
potrebbe capitare che quello che deve sbloccare finisca spesso dietro
quello principale che ha un tempo di occupazione del core superiore se
non addirittura priorità superiore: il risultato è che la seconda CPU
mette in pausa il thread e lo sposta in fondo alla coda (not ready), col
risultato che prima di essere eseguito deve attendere non solo lo
sblocco dallo stato di pausa ma anche il riscalamento della coda
d'esecuzione: questo potrebbe portare il dual core a performare
leggermente peggio del single core.
Dato comunque che i meccanismi di scheduling di Windows, Linux e OSX
sono noti, compiere un errore del genere è abbastanza importante. Tanto
più che una correzione via patch di un problema simile porta via molto
tempo di lavoro.
-- 
Danilo Pianini
"DanySK"
MSN: danysk_AT_alientech_DOT_it
Skype: 
dany.sk
www.astice.org
Consigliere membro del direttivo
Direttore della rivista "I2 - Informa Ingegneri"

 forza, a causa del round robin, saranno tutti eseguiti un po'. Su
fresco da esami dany? sarà il tuo terzo post che favelli sui processi :D
-- 
---------------------------------------
www.polesineonline.com
Il portale del Polesine
www.artenelweb.net
 


Chettedevodì, si vorrà "esibire"...LOL :P

 ha scritto nel messaggio
news:GfV2j.180236$%k.31...@twister2.libero.it...

E comunque pure io in passato ho riscontrato queste anomalie con alcuni
titoli... ovvero che andassero meglio generalmente con una cpu single core
rispetto ad una dual (intesi che la microarchitettura tra le due cpu fosse
simile, frequenza compresa). Per non parlare poi dell'epoca dei P4 con
tecnologia HT...


La cosa singolare è che questo non va meglio con affinità su unico processo, 
ma il framerate subisce un escalation facendo transitare l'affinità sui 
singoli core in alternanza, per poi ripristinandola su ambedue i core.
Questo è un esempio
1) Il gioco parte, affinità sue due core, framerate 23fps
2) Metto l'affinità solamente sul secondo core, framerate ancora a 23fps
3) Metto l'affinità solamente sul primo core, framerate a 25fps
4) Metto l'affinità su tutti e due i core... boom... framerate a 50fps
Per la croncaca con Vista, non ci sono caxxi...

 Sai dirmi quanti thread si avviano con il gioco?
15 thread


Volevo dire affinità su un unico core :)

 
MMmhh... mi pare strano. Cioè una cosa del genere accadrebbe se c'è un 
carico tale da saturare i due core. Ma senza nessun carico di lavoro mi 
sembra molto molto strano che un thread resta appeso perché ha una bassa 
priorità. Di solito un leggero peggioramento c'è per via dei cache miss 
dovuti allo scheduling prima di quà e poi di là, ma mi sembra strano che 
sia di tale entità! Non è che sia il solito problema dovuto ai time 
stamp counter?

 counter?
No, dopo ulteriori test il problema non è il l'affinità ma questo...
http://img137.imageshack.us/my.php?image=nuovo1nc7.jpg
In pratica passando dal gioco al desktop e viceversa attraverso alt+tab 
sembra esserci un notevole memory-leak, i 4 picchi corrispondono a quando 
dal desktop si ritorna al gioco, quando il videomemory usage supera una 
certa soglia il framerate raddoppia.
Un'altra cosa strana che emerge da questi grafici è che la memoria video non 
sembrerebbe allocata solamento sulla memoria locale della scheda video, ma 
anche sulla ram di sistema, e sembra quasi che il framerate aumenti quando 
ripassando dal desktop al gioco, ques'ultimo non riesca più ad allocare 
sulla ram di sistema, ma allochi esclusivamente sulla ram locale della 
scheda video.

 fresco da esami dany? sarà il tuo terzo post che favelli sui processi :D
Nono, ormai un po' ne è passato... Quasi un anno da Sistemi Operativi 1 :D


 stamp counter?
L'effetto sommato di tanti cache miss mi sembra difficile, anche e
soprattutto considerando che attualmente le cache sono sopra il MB.
Oltretutto le RAM attuali non è che siano chiodi, difficile passare da
50 a 25 fps. Per di più non si spiega come il cambio di assegnamento dei
thread possa migliorare le prestazioni.
A me quel fenomeno fa pensare che ci sia qualche thread che va
"sbloccato"... O ha nice sbagliato, o c'è qualche problema di priorità.


 scheda video.
Questo è piuttosto strano, di norma l'allocazione della memoria video
viene gestita direttamente da API-driver-OS. Evidentemente con NFS hanno
cercato di migliorare il caching finendo con lo sbattere da qualche parte...
In ogni caso il fatto che la cosa non sia dovuta al multithreading è
positiva :P



Sembra un problema simile a quello riscontrato da questo utente
http://www.nvnews.net/vbulletin/showthread.php?t=95930
E' interessante verificare che nel caso specifico č stato sufficiente usare 
il flag D3DUSAGE_WRITEONLY, anzichč D3DUSAGE_DYNAMIC|D3DUSAGE_WRITEONLY per 
risolvere, chissą se quei cazzoni della EA o chi per loro ci arriveranno ?
In effetti dalla documentazione della MS 
http://msdn2.microsoft.com/en-us/library/bb172625.aspx
 con il 
D3DUSAGE_DYNAMIC sono i driver che determinano dove allocare, evidentemente 
i FW iniziano ad allocare sulla memoria di sistema.
Non c'č qualche gentile possessore di schede Ati, o nVidia con tagli di 
memoria "normali" che potrebbe verificare se anche con queste schede 
l'allocazione della memoria video con questo gioco, inizia, dalla non-local 
video memory ?

 i FW iniziano ad allocare sulla memoria di sistema.
E' probabile anche che non se ne escano con delle patch ma che nVidia
faccia a modo di infilare un profilo nei prossimi driver. Se avessi il
gioco proverei volentieri io sulla mia Radeon X1950XTX per vedere se
cambia la situazione passando ad ATi.



Basta la demo :) 

 Basta la demo :) 
Weekend successivo (dopo il prossimo) torno a casa e faccio la prova,
allora... :D



Ok :)