Hardware Upgrade Forum - View Single Post - Microsoft pensa ad implementare Folding@Home su XBox 360

dsajbASSAEdsjfnsdlffd · 11-05-2007, 11:18

come hanno gia riportato altri, la gestione dell'audio multicanale prende circa 1/3 di un thread hardware. trovi informazioni più dettagliate direttamente sui siti microsoft ed anche nella documentazioen ufficiale XNA (che è free e se hai voglia di informarti un po puoi scaricare) oltre che naturalmente nella documentazione ufficiale dell'sdk della 360

ai una percezione un po sbagliata di quanto tempo richieda la gestione dell'input, è un operazione banale e richiede pochissimo tempo CPU tanto che l'hub USB o il suo alterego wireless si occupa della decodifica del protocollo di per suo e la cpu deve fare solo la fatica di guardar dentro ad un pacchettino ben confezionato, guarda credo sia davvero qualcosa dell'ordine di poche decine di istruzioni. di un thread hardware se lo vuoi quantificare sarà del tipo 0.0001%

ti assicuro che lo fa anche uno Z80 a 12 MHz in modo più che soddisfacente.

poi noncapisco il tuo accanimento sulel parole "in order" sembra che tu intenda che un processore in order non può fare multitasking. sono tra l'altro due cose decisamente slegate

una console è una macchina di cui conosci a menadito l'hardware e il sw che ci gira sopra puoi sapere con buona precisione quando gli operandi di un operazioen saranno disponibili, un buon compilatore ottimizzato è ingrado di ordinare decisamente bene le istruzioni e ad ogni modo essendoci 1 solo sw che gira per volta inuna console gli eventuali delay sono assolutamente stimabili e verificabili, queste cosniderazioni sono cosi valide che pure sony ha scelto un processore in order.

come ben sai le spu funzionano alla grande quando cooperano in stream
cioè puoi definire un flusso di dati che passano da una spe all'altra per completare una computazione un po come fossero dsp in catena.

un gioco non funziona proprio cosi, è più che altro composto da task paralleleche concorrono ad uno stesso risultato piuttosto che da tanti task sequenziali.
come hai detto c'`e la gestione dell'audio della fisica dell'ai

come noti sono operazioni molto ortogonali tra loro questo consente di farle elvolvere in parallelo avento solo pochi punti di sincronia tra loro

l'architettura a core indipendenti di xenon a mio avviso è molto più appropriata per i videogiochi su una console che lá rchitettura a stream di cell è vero che puoi metterre ogni SPE su unsingolo compito ma CELL si vanta di essere un processore sinergico, e far fare ad ogni SPE una cosa singola non ha molto a che fare col concetto di sinergia, peccato eh?

forse sarebbe stato più arguto sceglier eun processore più economico e più parallelizzabile di cell questa è la critica che spesso si sente muovere contro sony per la sua scelta sul processore cell, buonissima cpu ma non molto calata nel ruolo di cpu per console.

per quanto riguarda il geometry shader, hai sbagliato pezzo di hardware per "andarglielo a dire" prova a vedere cosa ti risponde suo cugino xenos invece di chiederlo a xenon.

per la fisica. siamo rimasti che ho almeno ancora due thread hardware e mezzo su cui far andare la fisica, molto più semplici da programmare che 4-5 spe sinergiche di cell, certo con potenze di punta inferiori, ma anche qui, vuoi che facciamo folding o giochiamo a qualcosa?
la potenza di xenon è più che adeguata alle computazioni che classicamente si fanno a fare alla CPU nei videogame, poi se tu sei un ninja e vuoi rivoluzionare l'architettura dei videogiochi per metterci dentro chissà quale fiscia sbalorditiva, allora cell è la scelta per te, armati di pazienza tanto tempo e soldi per lo sviluppo, metti anche inconto che quando il tuo gioco sbalorditivo sarà finito il tuo concorrente ne avrà gia venduti 20 meno sbalorditivi ma altrettanto divertenti (il divertimento è una funzione che non dipende esclusivamente dalla bontà della fisica implementata ci sono giochi divertenti senza fisica...)

se l'obbiettivo è perdere quote di mercato cell è la strada giusta.

11-05-2007, 11:18	#40
dsajbASSAEdsjfnsdlffd Registered User Iscritto dal: Mar 2005 Messaggi: 923	come hanno gia riportato altri, la gestione dell'audio multicanale prende circa 1/3 di un thread hardware. trovi informazioni più dettagliate direttamente sui siti microsoft ed anche nella documentazioen ufficiale XNA (che è free e se hai voglia di informarti un po puoi scaricare) oltre che naturalmente nella documentazione ufficiale dell'sdk della 360 ai una percezione un po sbagliata di quanto tempo richieda la gestione dell'input, è un operazione banale e richiede pochissimo tempo CPU tanto che l'hub USB o il suo alterego wireless si occupa della decodifica del protocollo di per suo e la cpu deve fare solo la fatica di guardar dentro ad un pacchettino ben confezionato, guarda credo sia davvero qualcosa dell'ordine di poche decine di istruzioni. di un thread hardware se lo vuoi quantificare sarà del tipo 0.0001% ti assicuro che lo fa anche uno Z80 a 12 MHz in modo più che soddisfacente. poi noncapisco il tuo accanimento sulel parole "in order" sembra che tu intenda che un processore in order non può fare multitasking. sono tra l'altro due cose decisamente slegate una console è una macchina di cui conosci a menadito l'hardware e il sw che ci gira sopra puoi sapere con buona precisione quando gli operandi di un operazioen saranno disponibili, un buon compilatore ottimizzato è ingrado di ordinare decisamente bene le istruzioni e ad ogni modo essendoci 1 solo sw che gira per volta inuna console gli eventuali delay sono assolutamente stimabili e verificabili, queste cosniderazioni sono cosi valide che pure sony ha scelto un processore in order. come ben sai le spu funzionano alla grande quando cooperano in stream cioè puoi definire un flusso di dati che passano da una spe all'altra per completare una computazione un po come fossero dsp in catena. un gioco non funziona proprio cosi, è più che altro composto da task paralleleche concorrono ad uno stesso risultato piuttosto che da tanti task sequenziali. come hai detto c'`e la gestione dell'audio della fisica dell'ai come noti sono operazioni molto ortogonali tra loro questo consente di farle elvolvere in parallelo avento solo pochi punti di sincronia tra loro l'architettura a core indipendenti di xenon a mio avviso è molto più appropriata per i videogiochi su una console che lá rchitettura a stream di cell è vero che puoi metterre ogni SPE su unsingolo compito ma CELL si vanta di essere un processore sinergico, e far fare ad ogni SPE una cosa singola non ha molto a che fare col concetto di sinergia, peccato eh? forse sarebbe stato più arguto sceglier eun processore più economico e più parallelizzabile di cell questa è la critica che spesso si sente muovere contro sony per la sua scelta sul processore cell, buonissima cpu ma non molto calata nel ruolo di cpu per console. per quanto riguarda il geometry shader, hai sbagliato pezzo di hardware per "andarglielo a dire" prova a vedere cosa ti risponde suo cugino xenos invece di chiederlo a xenon. per la fisica. siamo rimasti che ho almeno ancora due thread hardware e mezzo su cui far andare la fisica, molto più semplici da programmare che 4-5 spe sinergiche di cell, certo con potenze di punta inferiori, ma anche qui, vuoi che facciamo folding o giochiamo a qualcosa? la potenza di xenon è più che adeguata alle computazioni che classicamente si fanno a fare alla CPU nei videogame, poi se tu sei un ninja e vuoi rivoluzionare l'architettura dei videogiochi per metterci dentro chissà quale fiscia sbalorditiva, allora cell è la scelta per te, armati di pazienza tanto tempo e soldi per lo sviluppo, metti anche inconto che quando il tuo gioco sbalorditivo sarà finito il tuo concorrente ne avrà gia venduti 20 meno sbalorditivi ma altrettanto divertenti (il divertimento è una funzione che non dipende esclusivamente dalla bontà della fisica implementata ci sono giochi divertenti senza fisica...) se l'obbiettivo è perdere quote di mercato cell è la strada giusta.