Vyznam dual core

[THX]

to bych musel vymyslet nejakou mnohem slozitejsi konstrukci a nebo to merit v us ... coz se mi fakt moc nechce ... si hraj chvili ty ...

udelat atomicky fci, ktera nad 10MB scenou pocita napr. odlesky si dost dobre atomicky nedovedu predstavit.

atomicky robis iba dvojicu (kontrola na lock + precitanie). A tiez samozrejme atomicky zamykas.

Zlozitejsiu konstrukciu robit vobec nemusis, staci ked das medzi citanie a zapis nejaku fuknciu, ktora dlho trva (napr. 100x spocitat sinus alebo nieco take), alebo snad aj sleep(1). Myslim ze v linuxe je nejaky prikaz time (alebo tak nejak), ktory vie zistit ako dlho bezal proces.

Ide len o to, zmerat aky velky overhead znamena zamykanie.

[Fox!MURDER]

atomicky robis iba dvojicu (kontrola na lock + precitanie). A tiez samozrejme atomicky zamykas.

Zlozitejsiu konstrukciu robit vobec nemusis, staci ked das medzi citanie a zapis nejaku fuknciu, ktora dlho trva (napr. 100x spocitat sinus alebo nieco take), alebo snad aj sleep(1). Myslim ze v linuxe je nejaky prikaz time (alebo tak nejak), ktory vie zistit ako dlho bezal proces.

Ide len o to, zmerat aky velky overhead znamena zamykanie.

JENZE! kdyz potrebujes konzistentni scenu, tak si bud musis udelat atomicky kopii xMB dat, coz te stoji cas a pamet, nebo udelat atomicky celej ten proces, nebo to proste zamknout.

[THX]

JENZE! kdyz potrebujes konzistentni scenu, tak si bud musis udelat atomicky kopii xMB dat, coz te stoji cas a pamet, nebo udelat atomicky celej ten proces, nebo to proste zamknout.

no ale to len ak by si tie odlesky pocital v jednej fukncii. Tiez by si to mohol spravit nejak tak (i ked neviem ako presne) ze by kazda fukncia pocitala iba odlesk jedneho objektu. Na zaciatku vsetky thready si nacitaju informacie o svojich objektoch, spocitaju paralelne a nakoniec zapisu pomocou zamkov. Ide len o to, ci to ma zmysel takto rozkladat - teda o kolko sa predlzi zapis koli zamykaniu oproti zrychleniu sposobenemu paralelnym vypoctom.

Nechajme to na kona - ten ma vacsiu hlavu. Alebo este na valve. Az bude vydana ta hra, tak uvidime. Ale myslim ze quaka sa im tiez do istej miery podarilo paralelizovat, tak by som netvrdil ze sa to valve nepodari tiez.

[Over]

Synchronization Functions
http://msdn.microsoft.com/library/de..._functions.asp
http://msdn.microsoft.com/library/de...calsection.asp

[Fox!MURDER]

Synchronization Functions
http://msdn.microsoft.com/library/de..._functions.asp
http://msdn.microsoft.com/library/de...calsection.asp

no critical section je ocividne totez, co mutex, jen na nizsi urovni, tudiz rychlejsi, ale nevim, cos tim chtel naznacit

resp. asi to odpovida mutexu v pthreads ...


edit: ted na to koukam, ze tohle by mohlo bejt to, co vlastne asi Valve implementovali po svym. A v linuxu, to vypada, ze takovahle funkcionalita treba uplne chybi ...
http://msdn.microsoft.com/library/de...izesrwlock.asp
jenze vista/longhorn only ...

[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.

[Eagle]

Ale ved tam ti prave ludia od valve pisu, ze takychto situacii, kedy sa len cita je 95% a zamykanie (a teda nemoznost paralelneho spracovania) nastava iba v 5% pripadov.

95 nezávislých + 5 závislých situací != 100 situací s 5% pravděpodobností závislosti

pozri - valve dokaze pri renderingu paralelne pocitat pohlady z roznych kamier, efekty atd.

To možná ano, ale na to už potřebuješ mít hotovou fyziku, která je sériová.

si ju budes moct obenchmarkovat na jednom a na viacerych jadrach.

Benchmark ti řekne jen výkon. Pokud tento není za jinak stejných okolností (což třeba u WinRARu není), pak je výsledek zavádějící.

To mi pride ako keby sa tajilo, ze audio/video kodeky su stratovou kompresiou. Stoji ta strata kvality za to? Ano, stoji to zrychlenie enkodingu za to, ano.

Mně ne, já vždycky preferuju co nejvyšší kvalitu. Proto mám třeba hardware takový, jaký mám - novější totiž obsahuje více chyb, což mi za ten dodatečný výkon nestojí. Až je vychytají, bude upgrade. Do té doby nic.

A co sa tyka dokazov - urobme to naopak. Ty mi dokaz, ze niektore veci NIE JE MOZNE multithreadovat.

Už jsem ti tady uváděl příklad s fyzikou ve hře. Logickou posloupnost akcí v tomto případě nelze změnit (... protože je to podobné jako priorita operátorů v matematickém příkladě).

kapitalista atd.

Nejsem kapitalista. To jen na okraj.

Prave diskusia (a prispevky do nej) by mala byt taka, aby citatel ziskal po precitani nove informacie (a nie iba niecie osobne nazory a postoje).

Ano, to získal. Ale ne od vás, protože vy se jen oháníte větami typu "jde to, támhle Pepa to umí". Už ale nedokážete zdůvodnit, jak je to možné. Jen názory převzaté z webu, ale logická posloupnost vesměs žádná. Nikdo tady nebyl schopen zodpovědět, jak by bylo možné počítat fyziku ve hře paralelně s renderingem scény.

no ale to len ak by si tie odlesky pocital v jednej fukncii. Tiez by si to mohol spravit nejak tak (i ked neviem ako presne) ze by kazda fukncia pocitala iba odlesk jedneho objektu. Na zaciatku vsetky thready si nacitaju informacie o svojich objektoch, spocitaju paralelne a nakoniec zapisu pomocou zamkov. Ide len o to, ci to ma zmysel takto rozkladat - teda o kolko sa predlzi zapis koli zamykaniu oproti zrychleniu sposobenemu paralelnym vypoctom.

S tím se dá jakž takž souhlasit (ty odlesky by nesměly ovlivňovat jeden druhý, což ale asi nelze zaručit - např. odlesk postavy o vodní hladinu na skleněnou zeď, na kterou svítí ještě něco), ale bohužel tohle není paralelismus, který by ti přinesl nějaké obrovské množství výkonu navíc. Jenom kdybys měl hodně objektů, mohlo by ti to něco dát, ale to řádově tak pár desítek procent navíc IMHO. Mimochodem, není tohle náhodou věc, kterou dělá grafická karta?

[swarm]

Mno....koukám, že vás to tu ještě stále nepustilo...někteří z vás (většina?) si tu představuje programování her asi jako Hurvínek válku, tak si myslim, že ta diskuze je úplně bezpředmětná. Nebo tu snad někdo programoval nějakou hru? Klidně se přihlašte. Tady vám nikdo hlavu neutrhne .

Popravdě jsem myslel, že horší diskuze než když se baví vývojáři o sexu už být nemůže. Ale když se baví nadšenci do overclockingu o programování her, tak je to možná ještě slabší .

[Fox!MURDER]

Mno....koukám, že vás to tu ještě stále nepustilo...někteří z vás (většina?) si tu představuje programování her asi jako Hurvínek válku, tak si myslim, že ta diskuze je úplně bezpředmětná. Nebo tu snad někdo programoval nějakou hru? Klidně se přihlašte. Tady vám nikdo hlavu neutrhne .

Popravdě jsem myslel, že horší diskuze než když se baví vývojáři o sexu už být nemůže. Ale když se baví nadšenci do overclockingu o programování her, tak je to možná ještě slabší .

buhuheheh dobrej postreh ...

nahodou, ja ted budu do skoly programovat damu. a just to napisu multithreadove

[MadCap]

buhuheheh dobrej postreh ...

nahodou, ja ted budu do skoly programovat damu. a just to napisu multithreadove

pozor aby si to s tym AI neprehnal a nemusel si na to potom pouzivat quad core procesor! Jedno jadro by to predsa nemohlo zvladnut popri vsetkom co k tomu patri (DX10 grafika je snad samozrejma nie?)

[swarm]

nahodou, ja ted budu do skoly programovat damu. a just to napisu multithreadove

No, minulý semestr jsem měl do jednoho předmětu taky hru (C, OpenGL) a využít jednoho jádra na procesoru a jednoho na grafický kartě myslim zrovna úplně stačilo .

[Anduril]

pozor aby si to s tym AI neprehnal a nemusel si na to potom pouzivat quad core procesor! Jedno jadro by to predsa nemohlo zvladnut popri vsetkom co k tomu patri (DX10 grafika je snad samozrejma nie?)

Ja bych mel spise strach, aby hraci vubec hru dokoncili tak, jak maji. Zvlaste kdyby kazdy hrac mel jedno vlakno >:} By pak jeden hrac mohl skakat pres jineho, ale ten uz by tam nebyl. Ale jinak tady vidim idealni vyuziti dualcore - co hrac, to vlakno. Na clovece nezlob se v plnem obsazeni uz to chce quad core

[Fox!MURDER]

pozor aby si to s tym AI neprehnal a nemusel si na to potom pouzivat quad core procesor! Jedno jadro by to predsa nemohlo zvladnut popri vsetkom co k tomu patri (DX10 grafika je snad samozrejma nie?)

no, nevim, jesli java umi DX10 a stejnak grafiku dela nekdo jinej. ja mam nastarosti to AI ...

MadCap: vsak AI by melo bejt 'tunable' ... a je fakt, ze s damou by nemel bejt problem vytizit klidne 10 jader ...

Anduril: a co teprv model 'co kamen, to jadro' nebo 'co policko na hraci desce, to jadro'

[Petrik]

No jisteee, napsal jsem tetris v textovym rezimu v turbo pascalu Mimochodem, co si o tom pripravovanym valve engine myslis ty?

Mno....koukám, že vás to tu ještě stále nepustilo...někteří z vás (většina?) si tu představuje programování her asi jako Hurvínek válku, tak si myslim, že ta diskuze je úplně bezpředmětná. Nebo tu snad někdo programoval nějakou hru? Klidně se přihlašte. Tady vám nikdo hlavu neutrhne .

Popravdě jsem myslel, že horší diskuze než když se baví vývojáři o sexu už být nemůže. Ale když se baví nadšenci do overclockingu o programování her, tak je to možná ještě slabší .

[swarm]

Mimochodem, co si o tom pripravovanym valve engine myslis ty?

Mno, já jsem teda nic kolem toho nečetl (ani momentálně na to nemám nějak čas) a tento thread jsem si prolítl dost rychle. Četl jsem o tom jenom tu novinku na cdr. Nevim jestli to bylo překladem a nebo z toho novinkář něco vytratil, ale takhle mi to připomělo svou vypovídací hodnotou marketingový kecy na PR slajdech nVidie.

[Rainbow]

O tych hrach (a o sexe ) by bolo vhodne zalozit novy thread.
Uz je tu poriadny bordel a rozdelit to poriadne nejde, tak aby sa to nemuselo zamknut.

[THX]

Tak v suvislosti s hernymi enginami ma napada pouzit pipelining podobne ako u procesorov. Napr. ak mam dvojjadrovy procesor, tak pustim herny engine 2x, jeden pocita parne, jeden neparne snimky.
Niekedy priblizne v polke vypoctu a renderingu prveho snimku by sa precital vstup od usera pre druhy snimok, ktory by spocitalo (a dalo renderovat) druhe jadro. Ked by bolo toto druhe jadro priblizne v polke vypoctu, prve uz dokoncilo cely snimok a moze znova nacitat vstup a zacat kreslit dalsi frame.

[šaman]

To možná ano, ale na to už potřebuješ mít hotovou fyziku, která je sériová.

Mohl by mi nekdo vysvetlit, proc se tu po několikáté "fyzika" uvažuje jako nevhodná k paralelizování?
Podle mych informaci leží budoucnost (a vlastně už i současnost-Havoc,Ageia) simulace mechaniky (i te herni) v MBS(MultiBodySystem). A MBS je problematika,pro jejiz reseni je paralelizace velmi vyhodna.

[swarm]

Tak jsem nadhodil téma i jinde, na jistě úrodnější půdě...

http://www.ceskehry.cz/forum/viewtopic.php?t=4791

[Petrik]

kratka citace pro Eagla:

1) Jaká má programování MT (multithreadově) ve hrách (i obecně) úskalí?
Největším úskalím je podle mě neznalost programátorů. Kdo to s vlákny nezná, ten to dělat nemůže.

2) Jak moc vyžaduje vyšší nároky na znalosti programátora?
Podle mě je to principiálně v pohodě, pokud je člověk vystudovaný programátor. Problémy pocítí pouze programátoři-samouci, kteří jsou zvyklí se učit jen to, co je zrovna "in", a zatímco 3D grafiku už dělají třeba 10 let, s vlákny to pro ně je nová věc poslední doby.


3) Zabere to programátorovi víc času? Jak moc se to projeví?
Jak mám zkušenost, dělání her funguje obvykle neřízeným lavinovitým či intuitivním stylem "začneme a nějak to dopadne", použití vláken bude vesměs dost pracné. Kdyby se na to ale šlo systematicky a správně, tak to podle mě nebude složité.

Nic proti, ale ty jsi vystudovany ekonom, ze?

Tak jsem nadhodil téma i jinde, na jistě úrodnější půdě...

http://www.ceskehry.cz/forum/viewtopic.php?t=4791

[Fox!MURDER]

Nic proti, ale ty jsi vystudovany ekonom, ze?

tohle mi prosim nedelej, vypadam pak ve skole jako debil, kdyz se tady na chodbe smeju na cely kolo!

[MadCap]

Tak jsem nadhodil téma i jinde, na jistě úrodnější půdě...

http://www.ceskehry.cz/forum/viewtopic.php?t=4791

jak tam tak kukam a vidim jak sa fyzika a zvuk a kdeco pocita vo vlaknach, tak je sice jasna vyhoda multicore, ale toto predsta stihne aj single core teda pokial ta fyzika nebude pre simulaciu jadroveho vybuchu, hudba pre 50 orchestrov a AI ako hal9000

[THX]

jak tam tak kukam a vidim jak sa fyzika a zvuk a kdeco pocita vo vlaknach, tak je sice jasna vyhoda multicore, ale toto predsta stihne aj single core teda pokial ta fyzika nebude pre simulaciu jadroveho vybuchu, hudba pre 50 orchestrov a AI ako hal9000

Vo feare mas napriklad nastavenie zlozitosti fyziky - a je to v nastaveni CPU. Takze sice sa to teraz da stihat aj na jednom procesore, ale to len preto, ze sucasne hry su robene, aby to stihal singlecore. S vyssou zlozitostou fyziky sa zvysuje aj narocnost. Tak sa kludne moze stat ze hry budu mat dva urovne fyziky - low pre slabe procesory a high pre vykonne DC. Urcite by som si vedel predstavit lepsiu fyziku ako je teraz (napr. prudenie kvapalin, kyvanie sa siat, fukanie vetra a kyvanie listov na strome atd.).

[MadCap]

Vo feare mas napriklad nastavenie zlozitosti fyziky - a je to v nastaveni CPU. Takze sice sa to teraz da stihat aj na jednom procesore, ale to len preto, ze sucasne hry su robene, aby to stihal singlecore. S vyssou zlozitostou fyziky sa zvysuje aj narocnost. Tak sa kludne moze stat ze hry budu mat dva urovne fyziky - low pre slabe procesory a high pre vykonne DC. Urcite by som si vedel predstavit lepsiu fyziku ako je teraz (napr. prudenie kvapalin, kyvanie sa siat, fukanie vetra a kyvanie listov na strome atd.).

jo tak to si rad pockam kym to niekto naprga zatial aj ten FEAR utiahnem sempronom

[THX]

jo tak to si rad pockam kym to niekto naprga zatial aj ten FEAR utiahnem sempronom

skus si na tom semprone urobit benchmark - raz daj physics na low a raz na high, ze aky to bude mat plyv. Inac ked nemas physics na high, tak sa niektore veci nedaju - ak strelis do tlakovej flase, tak ostane na zemi. Ak mas physics high, tak normalne zacne lietat ako napr. v hl2.

Na digitlife vysiel nejaky test procesorov, je tam sempron 3600+ a A64 x2 3600+ co su uplne rovnake procaky, az na to ze ten druhy je dual core (2ghz, 256k cache). Takze si mozete porovnat vykon. Zaujimave je to najma v hrach, kde ma celkovo X2 asi o 20% vyssi vykon. Obrazky maju robene ako flash, takze to sem nemozem dat.

EDIT:
na anandtechu vysla rozsirena verzia toho clanku o valve enginoch a je tam este jeden benchmark (a ine testovacie zostavy)
http://anandtech.com/tradeshows/showdoc.aspx?i=2868