Rilasciato Doom 3 per Mac

e pensare che questa diatriba è iniziata x nulla! Basta tornare alle prime pagine x farci rendere conto che tutto questo non ha senso, alla fine.

x fek
allora io mi eclisso, quì non sono nessuno!

Re: Re: Re: X Caesar_091

Faccio riferimento a questo tuo topic.
Non so se sei stato preso dalla fretta, oppure hai letto male, ma questo e' cio' che hai scritto.

Riassumendo:

- Il motore 3d di Q3 e' multi threaded? No. Di questo ne sono certo.

- Il gioco e' multi threaded? Su PC sono sicuro di no, su Mac non mi sento di escluderlo a priori anche se mi sembra improbabile per varie ragioni. Ma alcuni benchmark ed un'intervista direbbero il contrario.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: X Caesar_091

Forse ti sei perso un pezzo del tread.... quei test sono stati fatti:
-nel 2000
-con Quake3 1.17
-con MacOS X 10.0 Public Beta

Se quelli recenti non ti sembrano attendibili... questi cosa sono? Come minimo NC

Ma va
Al contrario, i tuoi interventi mi sono sembrati assolutamente precisi.

Re: Re: Re: Re: X Caesar_091

Fammi sapere quando arriverai a trovare la verità assoluta anche dal punto di vista del programmatore. Perché a me che sia single o multi thread poco importa.

Sta di fatto che il guadagno non è dell'1-10% ma decisamente di più.

Re: Re: Re: Re: Re: Re: Re: X Caesar_091

Solo in alcuni test sembra molto piu' del 10% e non in tutte le situazioni. Infatti ho trovato quei test curiosi e fornito alcune spiegazioni a mio avviso plausibili. Nessuno ha parlato di verita' assolute (a parte le tue ovviamente ).

Ad esempio:



La prossima volta ti consiglio di essere piu' educato e meno precipitoso.

programmazione

ora non so se la cosa valga anche per i giochi, lo chiedo a fek, ma che io sappia, un programma x poter beneficiare di più processori (fisici o logici che siano), devono includere particolari librerie, a volte anche proprietarie, librerie che introducono dei costrutti che permettono di specificare a una parte del codice su quale processore dev'essere eseguita. Da quel poco che so, in ambito scientifico il multithread e parallelismo in generale x programmare in c++ (vedi MPI, sui cluster), l'argomento non è affatto banale, ma sicuramente trovare un applicazione del multithreading sui motori 3d è una strada tutta nuova, nonostante i precedenti esperimenti della ID con Q3.

fek, confermi?

Re: Re: Re: Re: Re: Re: Re: Re: X Caesar_091

Se solo avessi un dual G4 o un dual G5 sarei disposto ad invitarti una sera a bere una cosa qui da me e farti vedere con i tuoi occhi come stanno le cose. Non mi invento nulla e non parlo per sentito dire.

Ma attualmente, sfortunatamente, ho solo un G4 singolo e non posso dimostrartelo "live". Però ho accesso a diverse macchine dual CPU quindi l'invito è sempre valido... fattà eccezione per la cosa da bere che dovremmo andare a prendere da un'altra parte



Educato lo sono sempre... e non mi sembra che quella che hai citato rappresenti un'eccezione.

Precipitoso perché?
Ho sempre detto cose vere.
Siete voi che siete partiti convinti del fatto che tutto quello che avevo scritto era una gran baggianata o sbaglio?

Ed vero che le macchine dual CPU sono meno diffuse tra gli utenti x86 se ti riferivi a questo per il "precipitoso".... quindi è normale che magari alcuni l'opzione per il SMP non la conoscevano.

Re: Re: .

La tua risposta al mio intervento che ho quotato (oltre a non essere uno scinitillante esempio di educazione) lasciava presupporre che io avessi scritto una fesseria sul motore 3d di Quake 3.

Inoltre qui hai scritto una cosa non vera:



Ed e' cio' che ho corretto con il mio intervento. Questa e' semplicemente un'affermazione falsa, perche' sia il motore di Q3 sia quello di UT sono strettamente single thread.

Riguardo al game code di Q3 su Mac, ho scritto che non escludo a priori la possibilita' che sia stato riscritto per supportare il multiprocessing, anche se lo trovo improbabile per svariati motivi. Ma l'intervista ed alcuni benchmark sembrano dimostrare il contrario. Non ho altri elementi per giudicare (non ho mai visto il codice sorgente).

Re: programmazione

Piu' che includere particolari librerie si tratta di parallelizzare determinati algoritmi che al momento sono implementati serialmente. Un esempio banale puo' essere la gestione degli oggetti che al momento segue piu' o meno una pipeline seriale di questo tipo (con varie differenze da motore a motore):

1) Controlla se l'oggetto e' visibile
2) Animalo se necessario
3) Prepara il suo render state e le sue texture
4) Spediscilo alla GPU per il rendering

Questo semplice algoritmo e' eseguito passo dopo passo, un passo per volta, dalla CPU. Con piu' CPU potrebbe essere eseguito qualcosa di questo tipo:

- Metti in coda l'oggetto alla CPU con meno oggetti in coda

Per ogni CPU:
- Prendi il primo oggetto dalla coda e controlla se e' visibile
- Mettilo in coda per essere animato
- Quando e' pronto, mettilo in coda per essere renderizzato (serializzato)

Un'unica coda con tutti gli oggetti pronti per essere renderizzati:
- Prendi il primo oggetto in coda e prepara il suo render state e le sue texture
- Spediscilo alla GPU per il rendering

L'ultimo passo dev'essere per forza serializzato, ma gli altri passi possono andare in parallelo sulle varie CPU perche' ogni oggetto puo' essere trattato indipendentemente dagl'altri.
Questo e' solo un esempio per dare l'idea delle complicazioni che si hanno in un render loop non strettamente single-thread.

Non l'ho ancora implementato, ed ho comunque tralasciato tutta una serie di problemi, quali ad esempio l'ordinamento degli oggetti prima del rendering.

In un altro thread e' stato postato un interessante link ad un'intervista a Tim Sweeney (il tech lead di Unreal 3) proprio riguardo al multi processing in un motore 3d.