| Zobrazit předchozí téma :: Zobrazit následující téma |
| Autor |
Zpráva |
Quiark
Založen: 29. 07. 2007
Příspěvky: 816
Bydliště: Chlívek 401
|
 Zaslal: 25. březen 2009, 17:58:27 Předmět: |
 |
|
No, ale pokud si je člověk na 110% jist, že nebude potřebovat více instancí té grupy objektů, tak singleton je o dost jednodušší a rychlejší řešení...
Laethnes: Ty nápady s dynamickým rozdělováním práce atd. jsou hezké, ale v praxi to bude podle mě dost těžké udělat a to i pro zkušenějšího člověka. Podobně s tím "ideálním" návrhem enginu... bohužel v praxi se ideální návrh většinou udělat nepodaří 
:3 << to je smajlík model "Zoidberg"?
_________________
Mám strach |
|
| Návrat nahoru |
|
 |
Laethnes
Založen: 14. 02. 2008
Příspěvky: 38
|
| Zaslal: 25. březen 2009, 18:43:11 Předmět: |
|
|
Tak jo, díky za nápady a pomoc, nějak už to zpracuju
| Quiark napsal: |
No, ale pokud si je člověk na 110% jist, že nebude potřebovat více instancí té grupy objektů, tak singleton je o dost jednodušší a rychlejší řešení...
Laethnes: Ty nápady s dynamickým rozdělováním práce atd. jsou hezké, ale v praxi to bude podle mě dost těžké udělat a to i pro zkušenějšího člověka. Podobně s tím "ideálním" návrhem enginu... bohužel v praxi se ideální návrh většinou udělat nepodaří
:3 << to je smajlík model "Zoidberg"? |
Ideální není nikdy nic  . S tím počítám, ono koneckonců se říká, že vícevláknové programování je obecně značně náročnější, nicméně dneska během hodiny (ani nevím, proč na ty přednášky chodím :3) mě napadla další věc - udělat ty jednotlivé sub-enginy tak, že bude jasné, co je možno dělat dál (jakoby fronta). Mno a pustím libovolné množství vláken (ano, tohle je tak trochu nadsázka) a každé se podívá na to, co je třeba udělat nejaktuálněji a do toho se pustí. Pak si další vlákna vezmou to, co je potřeba dělat dál nebo, pokud další práce čeká na výsledky toho, co se momentálně počítá, prostě počká. Mno a pak je "jen" potřeba udělat jednotlivé části tak, aby byly co nejméně závislé na aktuální práci ostatních. Např. grafický systém musí počkat na to, až kolizní spolu s objekty spočtou novou pozici objektů. Tak prostě budou dvě pole s pozicemi - hotové (vykreslovaný snímek) a nové, kam se ukládají rozpočítané data. A až se data dopočítají a grafika vykreslí, jen se nové data překopírují.
Ano, vím že si to nejspíš představuju moc zjednodušeně, ale do návrhu tohodle se teprve chystám, takže ani nemám sehnaných moc materiálů atd.
:3 - Zoidberg? Tak to by mě fakt zajímalo, jaks na to přišel . Mno, tohle je smajlík používaný v manga a anime (otoč si ho jako klasické smajlíky jako je ). Naráží tak trochu na plyšáky, ale především se takovýto výraz objevuje v krapet škodolibé situaci, nebo když někdo něčeho dosáhne i přes snahu tomu zabránit s výrazem "A máš to :3". Každopádně já to moc nepoužívám ve škodolibém smyslu (maximálně tak "omyl :3"), ale spíš jako "A je to!" (v krapánek pat-a-mat-ovském stylu :3), nebo když chci něco nadlehčit |
|
| Návrat nahoru |
|
|
Augi
Založen: 28. 07. 2007
Příspěvky: 782
Bydliště: Čerčany
|
| Zaslal: 25. březen 2009, 19:58:11 Předmět: |
|
|
| Laethnes napsal: |
| Mno a pustím libovolné množství vláken (ano, tohle je tak trochu nadsázka) a každé se podívá na to, co je třeba udělat nejaktuálněji a do toho se pustí. |
Podívej se na pojem thread-pool - to by mohlo být to vymyšlené kolo, které hledáš
Ale možná bych to raději udělal tak, že grafika by měla jedno vlákno a fyzikální engine by se podělil o zbytek jader (to bych nechal v režii fyzikálního enginu samotného).
| Laethnes napsal: |
| Tak prostě budou dvě pole s pozicemi - hotové (vykreslovaný snímek) a nové, kam se ukládají rozpočítané data. A až se data dopočítají a grafika vykreslí, jen se nové data překopírují. |
V zásadě se to tak dá dělat - fyzika něco vypočítá a grafika si ta data vezme při dalším vykreslování. Takže fyzika si vnitřně drží aktuální (počítané) hodnoty a navenek dává poslední vypočítané (a dále neměněné) hodnoty. |
|
| Návrat nahoru |
|
|
Laethnes
Založen: 14. 02. 2008
Příspěvky: 38
|
| Zaslal: 25. březen 2009, 20:42:38 Předmět: |
|
|
| Augi napsal: |
| Laethnes napsal: |
| Mno a pustím libovolné množství vláken (ano, tohle je tak trochu nadsázka) a každé se podívá na to, co je třeba udělat nejaktuálněji a do toho se pustí. |
Podívej se na pojem thread-pool - to by mohlo být to vymyšlené kolo, které hledáš
Ale možná bych to raději udělal tak, že grafika by měla jedno vlákno a fyzikální engine by se podělil o zbytek jader (to bych nechal v režii fyzikálního enginu samotného).
| Laethnes napsal: |
| Tak prostě budou dvě pole s pozicemi - hotové (vykreslovaný snímek) a nové, kam se ukládají rozpočítané data. A až se data dopočítají a grafika vykreslí, jen se nové data překopírují. |
V zásadě se to tak dá dělat - fyzika něco vypočítá a grafika si ta data vezme při dalším vykreslování. Takže fyzika si vnitřně drží aktuální (počítané) hodnoty a navenek dává poslední vypočítané (a dále neměněné) hodnoty. |
Hm - hm, jasně, jak už jsem psal, zatím dělám návrhy, takže o tohle se budu zajímat později (k programování se stejně nedostanu před koncem semestru :3), ale rozhodně dík za info a tipy |
|
| Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava
|
| Zaslal: 26. březen 2009, 00:32:36 Předmět: Re: Eh... |
|
|
| Laethnes napsal: |
| A jak se začnou výrazně rozšiřovat čtyř a více jádrové procesory, bude problém vůbec mít dost modulů, které lze paralelizovat (omlouvám se, nevím, jak to napsat spisovně) |
To je spisovně. Spíš než na explicitní použití vláken bych se snažil využít paralelní for cyklus (více iterací pustí zároveň). Pro náročnější úlohy jako třeba fyzika je to ideální a nemusí být potřeba ani zámky, když se to správně udělá. Další výhodou je, že tak snadno využiješ všechny cpu a nemusíš se moc předem starat, kolik jich bude. Paralelní for cyklus je dost jednoduchá konstrukce (vyžaduje téměř nulovou znalost vláken). Poskytují ho různé knihovny, v C++ např. Threading Building Blocks (TBB) nebo OpenMP (vyžaduje podporu compileru). Jinak TBB má třeba i paralelní sort, kontejnery, které jsou optimalizované pro paralelizaci (fronty atd.), a jiné vychytávky. Explicitní vlákna bych použil pro speciální účely a ideálně bych jich neměl víc jak počet prstů na jedné ruce. Některé z případů použití explicitních vláken je pak třeba čtení dat z disku (je přece blokovací), síťový přenos, přehrávání zvuku nebo i ten fyzikální engine (který ale dále použije paralelní for).
| Laethnes napsal: |
| Např. grafický systém musí počkat na to, až kolizní spolu s objekty spočtou novou pozici objektů. |
Místo čekání bych pustil oba zároveň. Grafika vykreslí, co právě má, a fyzika už počítá další snímek. Po skončení obou se překopírují data z fyziky do grafiky a jede se nanovo. (Některé hloupé drivery používají při čekání na GPU busy-waiting (při SwapBuffers), což je prasárna a bezpečně ti to vyžere jedno jádro, na to je třeba si dát pozor.)
_________________
AMD Open Source Graphics Driver Developer |
|
| Návrat nahoru |
|
|
Laethnes
Založen: 14. 02. 2008
Příspěvky: 38
|
| Zaslal: 26. březen 2009, 08:03:31 Předmět: Re: Eh... |
|
|
| Eosie napsal: |
| Laethnes napsal: |
| A jak se začnou výrazně rozšiřovat čtyř a více jádrové procesory, bude problém vůbec mít dost modulů, které lze paralelizovat (omlouvám se, nevím, jak to napsat spisovně) |
To je spisovně. |
Aha, já jen že můj slovník ve Firefoxu, co jsem si po své předchozí chybě nainstaloval, nějak nevzal :3.
| Eosie napsal: |
Spíš než na explicitní použití vláken bych se snažil využít paralelní for cyklus (více iterací pustí zároveň). Pro náročnější úlohy jako třeba fyzika je to ideální a nemusí být potřeba ani zámky, když se to správně udělá. Další výhodou je, že tak snadno využiješ všechny cpu a nemusíš se moc předem starat, kolik jich bude. Paralelní for cyklus je dost jednoduchá konstrukce (vyžaduje téměř nulovou znalost vláken). Poskytují ho různé knihovny, v C++ např. Threading Building Blocks (TBB) nebo OpenMP (vyžaduje podporu compileru). Jinak TBB má třeba i paralelní sort, kontejnery, které jsou optimalizované pro paralelizaci (fronty atd.), a jiné vychytávky. Explicitní vlákna bych použil pro speciální účely a ideálně bych jich neměl víc jak počet prstů na jedné ruce. Některé z případů použití explicitních vláken je pak třeba čtení dat z disku (je přece blokovací), síťový přenos, přehrávání zvuku nebo i ten fyzikální engine (který ale dále použije paralelní for).
|
Hm, tak to je pro mě novinka (ne že bych vlákna prozatím studoval kdovíjak do detailů, říkal jsem si, že co je v SDL mě bude stačit :3). To je hodně zajímavé.
Mno počet - osobně bych se ho snažil držet na počtu jader, u jedno jádrového procesoru jen 2 a to engine, načítaní souborů. U toho načítání vidím naprosto dokonale, jak je potřeba na jedné hře, která se vždycky hrozně seká když začne načítat (není optimalizovaná na načítání z pomalých disků, jak mám ten v notebooku).
| Eosie napsal: |
| Laethnes napsal: |
| Např. grafický systém musí počkat na to, až kolizní spolu s objekty spočtou novou pozici objektů. |
Místo čekání bych pustil oba zároveň. Grafika vykreslí, co právě má, a fyzika už počítá další snímek. Po skončení obou se překopírují data z fyziky do grafiky a jede se nanovo. |
Eh, promiň, že jsem to nenapsal jasněji - v kontextu to měl být příklad, který právě při dobrém programování lze udělat paralelně a tohle jsem chtěl vyjádřit právě jako příklad, že tak by to nemuselo být.
| Eosie napsal: |
| (Některé hloupé drivery používají při čekání na GPU busy-waiting (při SwapBuffers), což je prasárna a bezpečně ti to vyžere jedno jádro, na to je třeba si dát pozor.) |
Hm, dík za upozornění |
|
| Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava
|
| Zaslal: 26. březen 2009, 17:15:31 Předmět: Re: Eh... |
|
|
| Laethnes napsal: |
| U toho načítání vidím naprosto dokonale, jak je potřeba na jedné hře, která se vždycky hrozně seká když začne načítat (není optimalizovaná na načítání z pomalých disků, jak mám ten v notebooku). |
Tak to ti asi jenom swapuje. Ono cokoliv načítat z disku v renderovacím vlákně v průběhu hry je seberažda a nemyslím si, že by byli tak blbí. Také do video paměti jde načítat asynchronně, je dobré to připojit k tomu čtení z disku, zde jsem to popsal. A zapomeň na nějakou dekomprimaci souborů při načítání, chceš přece, aby to vlákno nemělo na vytížení CPU vliv...
_________________
AMD Open Source Graphics Driver Developer |
|
| Návrat nahoru |
|
|
Laethnes
Založen: 14. 02. 2008
Příspěvky: 38
|
| Zaslal: 27. březen 2009, 15:47:32 Předmět: Re: Eh... |
|
|
| Eosie napsal: |
| Laethnes napsal: |
| U toho načítání vidím naprosto dokonale, jak je potřeba na jedné hře, která se vždycky hrozně seká když začne načítat (není optimalizovaná na načítání z pomalých disků, jak mám ten v notebooku). |
Tak to ti asi jenom swapuje. Ono cokoliv načítat z disku v renderovacím vlákně v průběhu hry je seberažda a nemyslím si, že by byli tak blbí. Také do video paměti jde načítat asynchronně, je dobré to připojit k tomu čtení z disku, zde jsem to popsal. A zapomeň na nějakou dekomprimaci souborů při načítání, chceš přece, aby to vlákno nemělo na vytížení CPU vliv... |
Swap? Mno, to si moc nemyslím (i když Windowsy jsou na to dost blbé :3), mám 1GB RAMky, Windows mě žerou okolo 200-300M (včetně antiviru apod.) a samotná hra 400-500M, když si zapnu správce úloh, napíše vytížení okolo 800M. Ale tohle mě nenapadlo, občas mě přijde, že to swapuje, i když není potřeba. Zkusím swap vypnout a co to udělá :3. Dík za upozornění.
Mno a dík za info a odkaz, jdu se pustit do čtení. A dík za upozornění v rámci komprese;) |
|
| Návrat nahoru |
|
|
|
Hlavní strana
FAQ
Test
Hledat
Seznam uživatelů
Uživatelské skupiny
Registrace
Ke Stažení
Nastavení
Přihlášení
Calendar
