Vyznam dual core

[THX]

Ty neumíš číst? Přímo na CDR ti to v diskuzi vysvětlil WoodyIS. Dovolím si citaci:

"Nic ve zlem, ale docela jsem se pobavil u vety: "Přistupují k tomu celkem logicky tak, že pustí o jedno méně podřízených vláken, než je počet jader a k tomu jedno hlavní vlákno, které se stará mimo jiné i o synchronizaci". Problem totiz neni v tom, kolik vlaken vytvorit, ale co do nich dat tak, aby intenzivne pracovala na svych datech a byla navzajem nezavisla, aby na sebe navzajem nemusela cekat. Protoze je to jedna cast me prace, tak sem se tesil, jak nam to Gabe prozradi a ono nic "

"We gravitated towards creating a custom work management system that's designed specifically for gaming problems - its job is to keep the cores 100% utilised. We make it so that there are N-1 threads for N cores, with the other thread being the master synchronisation thread. The system allows the main thread to throw off work to as many cores as there might be available to run on, and it also allows itself to be subjugated to other threads if needs be."

The engine uses lock-free algorithms to solve one of the major problems of threading - access to data. Many of us have come across a similar problem before - if you're trying to edit a database or a web page whilst someone else is already doing a similar thing, you end up with one person overwriting the other person's data. The problem is the same when it comes to multiple threads accessing one data set in-game.

"We realised that, 95% of the time, you're trying to read from a data set, and only 5% of the time are you actually trying to write to it, to modify it. So, we just allowed all the threads to read any time they want, and only write when the data was locked to that thread."


viac -> http://www.bit-tech.net/gaming/2006/...e_Engin/1.html

[Eagle]

blablabla

A co to jako dokazuje tahle tvoje citace? To mi netvrď, že jsi programoval multithreadově, když mi na mojí poznámku odpovídáš tímhle.

[THX]

"We realised that, 95% of the time, you're trying to read from a data set, and only 5% of the time are you actually trying to write to it, to modify it. So, we just allowed all the threads to read any time they want, and only write when the data was locked to that thread."

Zamykanie teda pouzivaju, ale zistili ze nastane iba v 5% pripadov, preto povolili citanie bez zamku. Co je na tom nepochopitelne?

[Eagle]

Zamykanie teda pouzivaju, ale zistili ze nastane iba v 5% pripadov, preto povolili citanie bez zamku. Co je na tom nepochopitelne?

"Zjistili, že autonehoda nastává jen v 0,1 % případů jízdy autem. Proto povolili automobily bez deformačních zón a bez bezpečnostních pásů."

Už chápeš ten nesmysl textu?

blaboly

Domnívám se, že jsem ti jasně řekl, co si o tobě myslím a co je podmínka další diskuze s tebou. Opět jsi projevil svůj deficit inteligence, tak si asi budeš muset hovořit sám se sebou. Ostatní mají aspoň nějakou kulturu projevu.

[Fox!MURDER]

"Zjistili, že autonehoda nastává jen v 0,1 % případů jízdy autem. Proto povolili automobily bez deformačních zón a bez bezpečnostních pásů."

Už chápeš ten nesmysl textu?

me to docela smysl dava. stejne se to pouziva napr. v databazovejch aplikacich. ono je to mozna jen trosku nesikovne napsany...

[Eagle]

me to docela smysl dava. stejne se to pouziva napr. v databazovejch aplikacich. ono je to mozna jen trosku nesikovne napsany...

Jenže v databázích s tím budeš mít úplně stejný problém. Pokud dva uživatelé otevřou ten samý záznam, následně ho modifikují a uloží, vznikne ti konflikt, popř. druhý ukládající přepíše práci prvního. A jak bys tohle chtěl u hry ošetřit?

[Fox!MURDER]

Jenže v databázích s tím budeš mít úplně stejný problém. Pokud dva uživatelé otevřou ten samý záznam, následně ho modifikují a uloží, vznikne ti konflikt, popř. druhý ukládající přepíše práci prvního. A jak bys tohle chtěl u hry ošetřit?

So, we just allowed all the threads to read any time they want, and only write when the data was locked to that thread.

tzn. neodstranujou zamky uplne. odstranujou zamky pro cteni.

stejne to dela napr. MySQL, ktery pouziva read-only zamky. dalsi, ale dosti komplikovana a nevim jak efektivni cesta by mohlo bejt pouziti transakci ...
mozna to, kdyby se nejakym zpusobem implementovalo v HW, by mohlo udelat docela divy ...

[Eagle]

tzn. neodstranujou zamky uplne. odstranujou zamky pro cteni.

To je sice hezký, ale co to mění na stavu věcí? Pokud jeden thread má přečíst data, změnit je, zapsat a následně druhý je přečíst, změnit a zapsat, tak tím, že druhému umožníš je přečíst v době, kdy první thread nedokončil svojí práci, způsobíš načtení starých dat, a tedy porušení integrity.

[THX]

Jenže v databázích s tím budeš mít úplně stejný problém. Pokud dva uživatelé otevřou ten samý záznam, následně ho modifikují a uloží, vznikne ti konflikt, popř. druhý ukládající přepíše práci prvního. A jak bys tohle chtěl u hry ošetřit?

Tak si to precitaj este raz. Ak to mas problem pochopit. Sice sa tam pise, ze "lock-free", ale hned v tej istej citacii mas ze zamykanie sa pouziva pri zapise. Teda, lock-free to je len v tych 95% pripadoch, kedy sa cita.

Modifikacia = zapis/prepis dat = LOCK.
Pokial su data zamnknute, nikto iny s nimi nemoze pracovat, teda ani iny thread ich citat, alebo prepisat. Nedojde k strate integrity.

Ak sa data nemodifikuju, tak nie su zamknute, teda ako 20 threadov naraz chce na 20 jadrach citat, tak to proste precitaju naraz a subezne, bez toho aby sa to muselo zamykat a citat jeden po druhom.

"Zjistili, že autonehoda nastává jen v 0,1 % případů jízdy autem. Proto povolili automobily bez deformačních zón a bez bezpečnostních pásů."
Domnívám se, že jsem ti jasně řekl, co si o tobě myslím a co je podmínka další diskuze s tebou. Opět jsi projevil svůj deficit inteligence, tak si asi budeš muset hovořit sám se sebou. Ostatní mají aspoň nějakou kulturu projevu.

Lenze oni nepovolili zapis/prepis bez zamykania.
Ak sa ti nepacia petrikove prispevky, tak na ne nereaguj. Neviem co sa ti nepaci na petrikovej kulture prejavu, zatial som si nikde nevsimol, aby napadal teba a tvoju intelingenciu (zato ty jeho ano).

Ja som hlavne zvedavy, kolko FPS to prida vyslednej hre, nakolko mi z toho clanku je jasne, ze oni neurychluju to gro hry, co uz maju, ale sa snazia paralelizovat a tym urychlit veci, ktore tam pridavaju - len niektore efekty (dazd, obrazovky na scene a pod). O AI a pod. su tam iba "vzrusene" dristy, ziadne dokazy (a prave AI je jedna z veci, kde ma Valve imho velke rezervy).

V clanku je pekne rozobrate, ze pouzivaju rozne "druhy" threadingu a rozne pristupy. Staci sa pozriet na tie obrazky.
Takze o co ide:

Coarse threading: is the process of taking whole systems and putting them on to individual cores. It's a conceptually simple task to put rendering on one core, AI on another, physics on another and so on. Tom continues, "This essentially allows these systems to stay single threaded, and they only have to be multithreaded when it comes to synchronising them to a timeline thread to put them all back in order."

Teda renering bezi na jednom jadre. Ai na inom, fyzika na dalsom. Myslim ze AI a fyzika bola celkom dobra uz v hl2, takze tymto vlastne menia uz aj gro hry.

Fine-grain threading: takes a more intricate approach. The idea behind this method of threading is to take many similar or identical tasks and spread them across cores - for example, taking a loop that iterates over an array of data. In the case of a 1000 loop process, you just split it up by the number of cores. You need to make sure that each of the operations is independent and doesn't affect another data set - but this is tricky to do, because the time per work unit can be variable and managing the timeline of outcomes and consequences can get difficult.

Takze do threadov rozdeluju uz aj "single threaded veci", ktore same o sebe bezia dost dlho na to, aby malo zmysel ich delit a znova spajat. Napr. cyklus, ktory sa iteruje 1000x (a v kazdom ktoru napr. modifikuje nejaky objekt) rozdelis medzi viacero jadier, kazde z nich vykona nejaku inu iteraciu z tych 1000. Ale hned sa tam aj pise, ze toto je velmi tazke dosiahnut a neda sa to vyuzit vsade, takze to maju pouzite iba tam, kde sa im to podarilo rozumne implementovat. Myslim ze toto zasahuje aj do "gra enginu".

a nakoniec:

Hybrid threading: is the approach that Valve eventually decided to take. It is, you'll be unsurprised to learn, a mixture of coarse and fine threading. "It's attempting to use the appropriate tool for the job in multiple combinations," according to Tom. "So, some systems operate really well just being parked on a core - an example is sound mixing. It doesn't really interact, doesn't really have a frame constraint, it works on its own set of data, and so it's really happy being pushed off."

Teda tu sa pise, ze napr. zvuk dali do oddeleneho threadu. To myslim tiez zasahuje do gra hry. Tiez treba este brat v uvahu, kolko ludi ma SB audigy, a kolko ma integrovanu "softwareovu" zvukovku na doske - u tychto ludi je spracovanie zvuku este narocnejsie na procesor.



a este...

Hybrid rendering: One example is in calculating what is going to be rendered, and this relies on a critical part of the Steam engine, the 'world list'. "We first have to figure out - what are the areas of the BSP that you're going to render? Then, okay, what objects are in those portions? Up until the point that you're actually going to draw them, you're CPU bound. You have to work out all these calculations from multiple points of view - the player's view, then say, the view of TV monitors in the scene, then the point of view of reflections in water."

"To apply a hybrid threading model, we revised the pipeline. Now, we construct the rendering list from the world list in parallel - we can calculate the TV, water and player rendering lists at the same time across cores. We can then do things like running all the character bone transforms across the cores, too."

Nebavili sme sa tu niekolko stranok dozadu, ze rendering sa neda /sa velmi zle paralelizuje? Valve to zvladli. A teraz otazka - bude episode 2 3x drahsia (ako tu eagle tvrdi ze multithreaded vyvoj je 3x drahsi) ako episode 1? Nemyslim.

Tiez mam nejake take tusenie, ze unreal engine 3 bude do istej miery vyuzivat mutithreading (aspon tak, aby vedel rozumne vyuzit druhe jadro)

Protože jsem ekonom a tohle mě nezajímá. Hry hraju jen staré (= ty, které měly nějakou hratelnost a nápad) a v IT by mě nikdo adekvátně nezaplatil.

no mne to dost casto pripada ako, protože JÁ a ostatní me nezajíma.

[Eagle]

2 THX: Fakt mám čím dál tím víc pocit, že jsi nikdy nic neprogramoval. Poukazování na to, že zápis = zamčeno, je neskutečná hloupost. Kdyby šlo jen o čtení, tak se jedná o zcela nezávislé záležitosti, u kterých by se žádná synchronizace nemusela řešit, a tedy by nebyl potřeba žádný zámek. Takových situací ale jistě nebude mnoho. Protože kdyby bylo, tak je multithreading legrace.

A k té reakci na PiTa - už tady kolikrát zaznělo, že AI, fyzika a rendering jsou čistě sériové záležitosti, neboť nemůžeš renderovat něco, o čem nevíš, jak se bude pohybovat. Pokud to někdo dělá nezávisle, tak to vede ke zhoršení výstupní kvality. Hodláš-li operovat se slovy typu "Valve to zvladli", tak laskavě dokaž, jak si to zvládnutí představuješ reálně provedené tak, aby to nebyla z nouze ctnost. Řeknu ti to samé co Petrikovi - pokud chceš, abychom se nadále nad tímto tématem bavili, přednes tady konkrétní programátorská řešení, jak bys to udělal. Kecy stažené z webu mě nezajímají, protože programátoři by samozřejmě nikdy veřejně nepřiznali, že jimi provedený multithreading je za cenu snížení kvality - u kodeku H.264 to taky běžně neříkají, protože to není věc, kterou by se mohli chlubit.


Uff, mám pocit, že jedině Fox!MURDER tady ví, o co kráčí.


PS: Samozřejmě, že mě zajímá to, co je výhodné pro mě. Co je dobré pro tebe, je mi úplně fuk. Tohle je kapitalismus, společnost preferující individualismus a vlastní užitek.

[Masster]

Nebavili sme sa tu niekolko stranok dozadu, ze rendering sa neda /sa velmi zle paralelizuje? Valve to zvladli. A teraz otazka - bude episode 2 3x drahsia (ako tu eagle tvrdi ze multithreaded vyvoj je 3x drahsi) ako episode 1? Nemyslim.

Episoda 2 samozrejme 3x drazsi nebude a to z jednoho prosteho duvodu.
Valve nevyviji Source engine jen pro Episodu 2, ale pouziva ho pro x dalsich projektu a od vydani HL2 se na enginu neustale pracuje.

[Petrik]

Jelikoz jsme tu vsichni (nebo min. vsichni co s tebou nesouhlasi) proti tobe asi jen tlupa blbcu s deficitem inteligence, nasel jsem ti doufam alespon trochu oponenta na urovni. Nejakej clovek jmenem Sambous1 v debate o valve a jeho engine http://www.cdr.cz/a/diskuze/8684/0#140288 napsal:

No predelavat hry co uz jsou.... je asi mrhani zdrojema , ale do budoucna je to nutnost... multicore je budoucnost tak proc to nevyuzit... a narust vykonu roste matematicky s poctem jader... u hernich engines budoucnosti se stim urcite pocita...nas engine uz ma podporu ncores/cpus uz prakticky od zacatku... predelavat jiz hotovej engine bude-je urcite dost narocny... u jiz napsanejch her.. byl problem hned od toho co se multicore reseni objevilo..... baz patchu ve voknech a modifikovanejch driverech procaku se prakticky kazda stara hra na multi core cukala kuli diferentnimu casu na jadrech.

Jestli te zajimaji konkretni algoritmy ci primo casti kodu, muzes si s nim o tom popovidat. Az ti vysvetli, jak udelat MT herni engine, aniz by to byla "prasarna se snizenou vystupni kvalitou" , podelis se o to s nama? Jestli te to opravdu zajima, jak tady porad tvrdis, urcite bys ho mel zkontaktovat Pak se treba uvidi, jetli "pravda boli", jak jsi napsal me

Domnívám se, že jsem ti jasně řekl, co si o tobě myslím a co je podmínka další diskuze s tebou. Opět jsi projevil svůj deficit inteligence, tak si asi budeš muset hovořit sám se sebou. Ostatní mají aspoň nějakou kulturu projevu.