Vyznam dual core

[swarm]

Ten Tvuj clovek z icq uplne potvrdil to co rikam. O laplaceovkach pravdepodobne nema ani paru a "kodi" si neco cemu si rika fyzika. Opravdu zarny priklad. Myslim, ze jsi se ptal dobre, ale nespravne osoby Tim ho nechci shazovat, treba umi jine veci, ale fyzika a vicevlaknove programovani to nebude. Simulace v automobilovem prumyslu me zivi takze o tomhle neco malo vim. Kdyby treba vedel ze mat. modely ze Simulinku jdou vyexportovat do C bez toho aniz bych musel neco vedet o solveru... Jenze spoustu lidi proste nevi.

Ten člověk dělal arkádovku. Jestli nezná extra fyziku, tak to bylo v konkrétní hře skoro jedno. Ten rozhovor jsem uváděl k jiné části této diskuze. Btw je fajn, že děláš fyziku pro nějaký simulace. Jak moc jsou ale realtime? jsou schopný krmit vykreslovací engine, co musí jet 100fps?

[richie08]

Ten člověk dělal arkádovku. Jestli nezná extra fyziku, tak to bylo v konkrétní hře skoro jedno. Ten rozhovor jsem uváděl k jiné části této diskuze. Btw je fajn, že děláš fyziku pro nějaký simulace. Jak moc jsou ale realtime? jsou schopný krmit vykreslovací engine, co musí jet 100fps?

Chtel jsem tim jen rici, ze clovek ktery nema poneti jak se sestavuji matematicke modely fyzikalnich deju a nikdy nedelal vicevlaknovy kod tezko muze tohle soudit.

Btw simulace dynamiky motoru nebo CFD je radove hodne pomalejsi, naopak zase simulace podvozku, spotreby nebo zrychleni vozidla pres nejaky jizdni cyklus radove rychlejsi. Bezne pouzvame na takoveto simulace laptopy a pokud 25 minutovy jizdni cyklus trva vypocitat zhruba do 10s (zhruba 150x rychlejsi nez realtime) tak si myslim ze tohle zvladne v pohode realtime i stare Pentium. Jenze najdi mi vyvojare games, ktery tohle vi.

[PiT]

Btw simulace dynamiky motoru nebo CFD je radove hodne pomalejsi, naopak zase simulace podvozku, spotreby nebo zrychleni vozidla pres nejaky jizdni cyklus radove rychlejsi. Bezne pouzvame na takoveto simulace laptopy a pokud 25 minutovy jizdni cyklus trva vypocitat zhruba do 10s (zhruba 150x rychlejsi nez realtime) tak si myslim ze tohle zvladne v pohode realtime i stare Pentium. Jenze najdi mi vyvojare games, ktery tohle vi.

Jasne. A prirataj si k tomu spocitanie kolizii polygonov nie par kvadrov namiesto objektov ale kompletnej sceny co vidis a papa aj na 5 nasobne rychlejsom stroji ako dnesny najrychlejsi DC...

[swarm]

Jenze najdi mi vyvojare games, ktery tohle vi.

Najdi si na netu nějaké přednášky o fyzice z "Game Developer Session" (videa jsou stopro volně ke stažení na netu....google poradí) každoročně pořádaného v Brně. Tam si můžeš srovnat určitou úroveň. Doporučuju ti schválně si pustit i takové, ve kterých se řeší nábor do firem a co po tobě budou chtít. Třeba tě to trochu vyvede z omylu.
Jinak, co se tak dívám třeba na nezávislou herní vývojářskou scénu, tak většina lidí studuje právě přední vysoké školy (lidi z jaderky a elektro na ČVUT, kopa Matfyzáků a obdobné školy v Brně...jejich názvy rád zapomínám). Dělání her je pro programátory pomalu tím nejtěžším zaměřením, jaké si mohou zvolit, a často ne zrovna obdobně ohodnoceným. Stále mám pocit, že na herní programátory se tu nahlíží jako na "programátory databází" s letmou znalostí 3D API .

Jinak srovnáníreálných simulací s herní simulací mi nepřijde úplně vhodné, protože ve hrách jsou opravdu komplexní scény, a tak je potřeba si tu náročnost vynásobit x-krát. Nemyslim si, že by současná fyzika ve hrách byla zapříčiněna tím, že na světě máme samé hloupé herní vývojáře, co do opravdové fyziky moc nevidí. Viz první odstavec

[Petrik]

Jasny je ze vyvojari dobrych her nemuzou byt zadni tupci marne ale vzpominam, kdy jsem videl ve hre dobrou fyziku, kdyz nepocitam havok ci aegia. Ted k temto dvema: nejak si nedokazu predstavit, jak jinak by slo udelat tak dobrou fyziku bez pouziti nejake formy pokrocile fyzikalni simulace. Taky naroky na CPU naznacuji, ze to uz nebude zadna ochcavka, ale relativne velmi presny fyzikalni modelovani. Zkuste si treba v HL2 nebo FEARu strelit do nejaky poveseny lampy nebo do nejakyho lana, to je fakt husty, co to udela. Kazdopadne si myslim ze cim vice procesoroveho casu tyto enginy dostanou, tim lepe takze dokud nebude fyzika na grafikach, vivat DC

Najdi si na netu nějaké přednášky o fyzice z "Game Developer Session" (videa jsou stopro volně ke stažení na netu....google poradí) každoročně pořádaného v Brně. Tam si můžeš srovnat určitou úroveň. Doporučuju ti schválně si pustit i takové, ve kterých se řeší nábor do firem a co po tobě budou chtít. Třeba tě to trochu vyvede z omylu.
Jinak, co se tak dívám třeba na nezávislou herní vývojářskou scénu, tak většina lidí studuje právě přední vysoké školy (lidi z jaderky a elektro na ČVUT, kopa Matfyzáků a obdobné školy v Brně...jejich názvy rád zapomínám). Dělání her je pro programátory pomalu tím nejtěžším zaměřením, jaké si mohou zvolit, a často ne zrovna obdobně ohodnoceným. Stále mám pocit, že na herní programátory se tu nahlíží jako na "programátory databází" s letmou znalostí 3D API .

Jinak srovnáníreálných simulací s herní simulací mi nepřijde úplně vhodné, protože ve hrách jsou opravdu komplexní scény, a tak je potřeba si tu náročnost vynásobit x-krát. Nemyslim si, že by současná fyzika ve hrách byla zapříčiněna tím, že na světě máme samé hloupé herní vývojáře, co do opravdové fyziky moc nevidí. Viz první odstavec

[Eagle]

Dnes vyšel zajímavý článek na The Inquirer. Někdo z redakce hovořil s vývojáři her o možnosti využití quad-core:

We spoke with many developers including some big names and we learned that they can’t make much sense out of quad or more core CPUs. They confirm that they can put two cores to good use but not much more. The main problem is that the performance is far from scalable.

You have to spend both time and money to resource the programmer to try to make sense out f the dual core CPU. It takes up to a year to optimise the game for more threads and even if you make the perfect job you can count on twenty to thirty percent performance increase, and this is the best case scenario.

Once you start making the multi threaded game you end up making and having the multithreaded bugs as well.

You can keep one core busy with the physics and collision detection, second core will have to wait for the score to move on with the Artificial intelligence while the third core could possible calculate the graphic data. In this best case scenario you have to realise that the core number two and three would always have to wait for the core number one to finish its job and pass the job to the cores two and three. In this concept there is absolutely no place for quad core as games are non parallel applications. A game developer expert said that you can use the core number four to stream and load the data in the game and this is what the guys at Remedy did at IDF quad core demonstration. But this takes time and money and it is not commonly embraced by developers.

Game developers are in the dawn of dual core programming and now all the sudden AMD and Intel wants them to go quad core. For the time being Quad cores are good for rendering and serves but not for games.

So if you want to play games, you can forget about quad cores, you simply don’t need them and can gain just marginal performance out of them. Give the developers some time and this might change, but we are talking quarters not months.

Zvýraznil jsem nejdůležitější část. To docela mění zde nastolený směr diskuze - zjevně nebude problém zatížit jedno jádro výpočtem fyziky a kolizí, potíž bude v tom, že chceme-li, aby tato fyzika probíhala realtime (tj. aby například jedno auto neprojelo celé druhým a až pak byla zjištěna kolize), musí být fyzika spočítána hodně rychle, protože se jedná o sekvenční záležitost. A je zřejmě jasné, že když data musíme překopírovat z jednoho CPU do druhého, může DC dokonce i zpomalovat výpočet.

Možná by to šlo vyřešit tak, že jedno jádro bude počítat kolize a fyziku pro jeden frame dopředu, zatímco další jádra aktuální frame. To ale bude docela potíž z hlediska synchronizace a taky tam bude určité zpoždění reakcí na uživatelům vstup (čili zdaleka to nebude optimální).

[richie08]

Dnes vyšel zajímavý článek na The Inquirer. Někdo z redakce hovořil s vývojáři her o možnosti využití quad-core:



Zvýraznil jsem nejdůležitější část. To docela mění zde nastolený směr diskuze - zjevně nebude problém zatížit jedno jádro výpočtem fyziky a kolizí, potíž bude v tom, že chceme-li, aby tato fyzika probíhala realtime (tj. aby například jedno auto neprojelo celé druhým a až pak byla zjištěna kolize), musí být fyzika spočítána hodně rychle, protože se jedná o sekvenční záležitost. A je zřejmě jasné, že když data musíme překopírovat z jednoho CPU do druhého, může DC dokonce i zpomalovat výpočet.

Možná by to šlo vyřešit tak, že jedno jádro bude počítat kolize a fyziku pro jeden frame dopředu, zatímco další jádra aktuální frame. To ale bude docela potíž z hlediska synchronizace a taky tam bude určité zpoždění reakcí na uživatelům vstup (čili zdaleka to nebude optimální).

2 eagle:
1) Zalezi koho se vlastne ptal. "Expertem" muze by kde kdo, treba jako ten koho tu predhodil Swarm.
2) Byl bych opatrnejsi a prilis bych se neopiral o Fuadovy zavery. Pokud vim tak Fuad neni odbornikem ani na fyziku ani na programovani.
3) Jakkoli to cele vyzniva negativne pro QuadCore (a vic), pro DC vyuziti zrejme je velke => pobezi mnohem rychleji nez na SC.
4) Nevim proc by se jadra mela navzajem zdrzovat kopirovanim dat. Pokud se kazde bude zabyvat uplne jinou cinnosti (tedy jedno fyzikou, druhe grafikou - asymetricka vlakna) a budou si vymenovat pouze vysledky, tak tenhle specificky pripad vubec nenastane. Zda se mi, ze se ponekud demagogicky snazis zvelicovat nevyhody DC.

[Petrik]

Ted mi dosla jedna vec: tento problem je jiz totiz vyresen, jelikoz PPU Aegia ve hrach funguje a tento problem tam zrejmne nenastava, nebo je nejak elegantne osetren Navic, prenost dat z PPU pres PCI-E x16 do CPU je radove pomalejsi a ma radove vetsi latence, nez prenost dat z jednoho jadra DC do druheho, takze v pripadne DC to bude mnohem bezproblemovehjsi.
Jeste jedno upresneni ke GRAW: defautlne jede cela fyzika na havoku, PPU se pouziva pouze pokud je k dispozici na specialni efekty jako jsou vybuchy a pod. Jelikoz GRAW by mel umet vyuzit DC,a to pry dost vyrazne, predpokladam, ze prave havok bezi oddelne.

Dnes vyšel zajímavý článek na The Inquirer. Někdo z redakce hovořil s vývojáři her o možnosti využití quad-core:



Zvýraznil jsem nejdůležitější část. To docela mění zde nastolený směr diskuze - zjevně nebude problém zatížit jedno jádro výpočtem fyziky a kolizí, potíž bude v tom, že chceme-li, aby tato fyzika probíhala realtime (tj. aby například jedno auto neprojelo celé druhým a až pak byla zjištěna kolize), musí být fyzika spočítána hodně rychle, protože se jedná o sekvenční záležitost. A je zřejmě jasné, že když data musíme překopírovat z jednoho CPU do druhého, může DC dokonce i zpomalovat výpočet.

Možná by to šlo vyřešit tak, že jedno jádro bude počítat kolize a fyziku pro jeden frame dopředu, zatímco další jádra aktuální frame. To ale bude docela potíž z hlediska synchronizace a taky tam bude určité zpoždění reakcí na uživatelům vstup (čili zdaleka to nebude optimální).

[Eagle]

Nevím, zda mi někdo argumentoval tady nebo na Živě, ale mrknul jsem teď na IncrediBuild, který by měl zrychlovat kompilování na Visual C++. Fakt mě to pobavilo, je to za peníze a licenční politika je opravdu velice "příznivá". Za jednu licenci chtějí 329 dolarů a za podporu každého dalšího jádra pak dalších 149 dolarů!!! To jste si ze mě dělali legraci, že?

Standardní edice Visual Studia 2005 je za 299 dolarů.

[richie08]

Ted mi dosla jedna vec: tento problem je jiz totiz vyresen, jelikoz PPU Aegia ve hrach funguje a tento problem tam zrejmne nenastava, nebo je nejak elegantne osetren Navic, prenost dat z PPU pres PCI-E x16 do CPU je radove pomalejsi a ma radove vetsi latence, nez prenost dat z jednoho jadra DC do druheho, takze v pripadne DC to bude mnohem bezproblemovehjsi.
Jeste jedno upresneni ke GRAW: defautlne jede cela fyzika na havoku, PPU se pouziva pouze pokud je k dispozici na specialni efekty jako jsou vybuchy a pod. Jelikoz GRAW by mel umet vyuzit DC,a to pry dost vyrazne, predpokladam, ze prave havok bezi oddelne.

To nebude nikdy fungovat! Kdyz se nestihaji kopirovat data mezi jadry na jednom CPU, co pak nejaka karta v PCI-E nebo GPU. Jsem si jist, ze miliony, ktere investuji do vyvoje Ageia, nVidia a Ati prijdou vnivec.
Aneb co bys cekal od cloveka, ktery nikdy nenaprogramoval vicevlaknovy program a ceka na to az to za nej udela kompilator