Vyznam dual core

[Eagle]

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

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

Super anketa! Akorát jsem nečekal tak špatné výsledky pro dual-core. Mít poměr 4 / 21 v neprospěch multithreadingu u vyvíjených enginů je dost špatné. Takový pesimista jsem nebyl.

[tomase]

Anketu s 25hlasmi na fore komunity ceskych vyvojarov hier moze povazovat za nieco vypovedajuceho iba blazon.

[Eagle]

Anketu s 25hlasmi na fore komunity ceskych vyvojarov hier moze povazovat za nieco vypovedajuceho iba blazon.

Je pravda, že statistika preferuje kvůli přesnosti vzorek 50 měření, nicméně pro takto jednoduchou hypotézu postačí i 25. Jenom blázen ignoruje stav věcí a snaží se prosazovat své fantasmagorické teorie i přes nezvratné důkazy.

[MadCap]

thx > mna na testy procesorov neposielaj a radsej mi ani nerad ako mam co pustit ked som si to skusal sam na kope cipov a hier (vratane FEAR)

[Eagle]

thx > mna na testy procesorov neposielaj a radsej mi ani nerad ako mam co pustit ked som si to skusal sam na kope cipov a hier (vratane FEAR)

Já to taky měřil a souhlasím. Testuju s nastavením grafiky na minimum a procesoru na maximum. Výsledek?

Takže v první řadě závislost na velikosti L2 cache. Core 2 Duo E6300 dá o 47 % vyšší minimální fsp (zejména díky velké rychlé L2 cache 2 MB), přičemž ale stojí o 146 % víc. Děkuji, nechci.

[THX]

thx > mna na testy procesorov neposielaj a radsej mi ani nerad ako mam co pustit ked som si to skusal sam na kope cipov a hier (vratane FEAR)

Ak si niekde robil ten test s fearom physics na low a potom s rovnakym nastavenim ale physics na high tak sem s nim.

Super anketa! Akorát jsem nečekal tak špatné výsledky pro dual-core. Mít poměr 4 / 21 v neprospěch multithreadingu u vyvíjených enginů je dost špatné. Takový pesimista jsem nebyl.

nj, ale 10 odpovedi je ze nevime jak na to...
A tiez 4 ze u pristiho projektu to pouziju. No a u zvysnych to nebudu pouzivat - nie vzdy ma multithreading zmysel.

[MadCap]

preco by som pouzival minimalne, ked jediny procesor, ktory mal dropy prilis nizke je celeron D s 256kB cache (drop==minimal fps)

[Eagle]

nj, ale 10 odpovedi je ze nevime jak na to...

A co si myslíš, že je největší problém trhu práce v ČR ? Jednoznačně nedostatek kvalifikovaných pracovníků! To platí v každém odvětví. Odborníků je málo a ti jsou zase drazí, protože obvykle o svých přednostech vědí. Čili i toto je faktor, který je zapotřebí zohlednit.

[THX]

preco by som pouzival minimalne, ked jediny procesor, ktory mal dropy prilis nizke je celeron D s 256kB cache (drop==minimal fps)

aby sa ukazalo kolko z celkoveho zatazenia procesora zabera samotna fyzika
eagle: ale to ze niekto nevie ako na to, neznamena ze to nie je mozne... Verim, ze casom sa to naucia aj tito ludia.

[Petrik]

Aha, takze nejdriv tu tvrdis, ze hra napsat MT nejde. Pak jsi rikal, ze jde, ale ze to je "prasarna se snizenou vystupni kvalitou" a najednou se divis, nove enginy (ceskych her) se malo pisi MT. Ze by tento thread a mozna i "kecy" od cloveka s "deficitem inteligence" meli nejaky vyznam? Ze bys treba fakt uveril nejen ze to jde, ale ze se to i realne zacina pouzivat? Bravo! Skoda ze neumis uznat, ze jsi se milil, ale to neumi hodne lidi, tak si z toho nic nedelej.

Me naopak dost prekvapilo, ze min 4 lidi v CR z 21 pise ceske hry MT! Predpokladam totiz, ze hodne ceskych her MT nidky nevyuzije, jelikoz nejsou vypocetne narocne.

Super anketa! Akorát jsem nečekal tak špatné výsledky pro dual-core. Mít poměr 4 / 21 v neprospěch multithreadingu u vyvíjených enginů je dost špatné. Takový pesimista jsem nebyl.

[MadCap]

ty asi nevies ake hry sa v CR vyvijaju vsak? ked si toto trepol (nie su vypoctovo narocne)

[Petrik]

Netvrdil jsem, ze zadna dobra mezi nimi neni, vim ze se chystaji nejake hodne kvalitni FPSka, ale stejne si myslim, ze vetsina ceskych her budou spise nizkonakladovky. Nebo mi chces, tvrdit, ze vetsina ceskych her, co se ted vyviji, budou hry typu FEAR?

ty asi nevies ake hry sa v CR vyvijaju vsak? ked si toto trepol (nie su vypoctovo narocne)

[MadCap]

ty si myslis, ze sa tu vsetko robi "v malom" ? Je tu par silnejsich firiem, ktore robia skvele tituly a neodvazil by som sa tvrdit ze ich buduce projektu budu "nenarocne" aj ked nemusia byt zrovna ako FEAR (ktory je imho aj tak slaby)

[Petrik]

Az po FEAR souhlas, myslim ze jsem s tim uz souhlasil v minulem prispevku, nebo ti pripada ve sporu s timto?
Ad FEAR: oznacit hru s nejlepsi grafikou v dobe sveho uvolneni, ale mozna i ted (co ma lepsi?), s nejlepsi fyzikou (spolu s HL2 a GRAW) a dost dobrou AI jako "slaby"? Uznavam, ze dej neni nic extra, ze to je porad to samy, ale po technicke strance, o ktere se tu ted myslim bavime predevsim, to je jedna z nej FPS her, mozna uplne nejlepsi. Tomu samozrejmne odpovida i narocnost, presto si ale myslim, ze je to vyborne zoptimalizovana hra, vzhledem k tomu, jaka je. Skoda jen, ze ma dost slabou podporu DC.

ty si myslis, ze sa tu vsetko robi "v malom" ? Je tu par silnejsich firiem, ktore robia skvele tituly a neodvazil by som sa tvrdit ze ich buduce projektu budu "nenarocne" aj ked nemusia byt zrovna ako FEAR (ktory je imho aj tak slaby)

[Eagle]

aby sa ukazalo kolko z celkoveho zatazenia procesora zabera samotna fyzika
eagle: ale to ze niekto nevie ako na to, neznamena ze to nie je mozne... Verim, ze casom sa to naucia aj tito ludia.

Ani já nezpochybňuju, že časem bude MT aplikací přibývat. To ale neznamená, že jsou teď. A pokud můžu nákup odložit, tak ho odložím, protože na tom jedině vydělám. Dual-core bohužel není spása a jak tento thread a ona anketa dokázaly, vyvíjet nové aplikace stojí programátory čas, a tedy ve výsledku i peníze, což samozřejmě nechce nikdo dát. A to pomíjím, že spousta situací se do multithreadingu převádí pomocí prasáren, kdy nejsou identické výsledky.

[Petrik]

Par pozamek k vyuziti GPU pro jine vypocty nez graficke.
Folding@home pred nejakym casem uvolnilo betu GPU klienta, ktery je cca 20x-30x rychlejsi nez CPU klient. Az po tud dobre zpravy. ted to horsi:
klient je urcen jen a vyhradne pro ATI Radeon X1900/1950, protoze jej udajne bylo nutne z velke casti napsat primo na konkretni cip. Zadny jiny chip pry navic nedosahuje potrebneho vykonu, takze Eaglovy uvahy o 100x a vetsim vykonu GPUcek v debate o cellu jsou min. prehnane. Navic je velmi zavisly na konkretni verzi DX a predevsim ovladacu. Pokud to chapu dobre, pro kazdou novou verzi ovladacu jej patrne bude nutne pokazde upravit, aby fungoval dobre, stejne tak pro kazde vydani directX, ktere mimochodem vychazi snad kazdy mesic nove. Dalsi neprijemna vlastnost tohoto GPU klienta je fakt, ze graficky ovladac se musi velmi casto dotazovat GPU jadra, zda je hotove, coz pry zere cca 25% systemoveho casu CPU.
Co z toho vypliva? Predpokladam ze programatori standfordske univerzity nejsou nejaci lameri, takze pokud to udelali takto "blbe", patrne k tomu byl nejaky duvod. Ono to tak je ostatne i ve hrach, kde se bezne stava, ze pro nove hry je potreba upravit/opravit ovladace, aby to fungovalo dobre. U pocitani grafiky se ale sem tam nejaka drobna chybka ztrati, u jinych ukolu to tak byt nemusi a klient folding@home je toho prikladem. Pokud se tedy programovani pro GPU nejak zasadne nezmeni, vidim veliky problem se spravnou funcnosti s ruznymi verzemi DX a driveru. Tento problem u vice jadrovych CPU nehrozi, proto si myslim, ze pouzivat GPU na pocitani neceho jineho nez grafiky bude min. velmi komplikovane a spise nez toto reseni se zacne prosazovat SW schopny vyuzivat vice jader CPU. Mimochodem, masivne MT programovani se pri pouziti GPU stejne vyhnout nejde, protoze pokud to chapu dobre, tak X1900 se tvari jako 48 procesoru, je tedy nutne mit min. 48 vlaken, aby bylo GPU vyuzito cele. Jinak se take pripravuje klient pro cell v playstation 3, tak jsem zvedav, jak na tom bude vykonove vzhledem ke GPUckam

http://folding.stanford.edu/FAQ-ATI.html

Mimochodem, pokud chcete prispet k rozvoji mediciny, pripojte se k folding@home!

[MadCap]

zvatlas tu o vyuziti GPU na starej atine, dnes je tu doba unified shaderov a tie pojdu vyuzit univerzalne a lepsie to len na okraj

[Petrik]

Fer. Takze odted uz nebudou vubec zadne problemy s ovladaci ve hrach? Parada Takze vlastne uz ani nebude potreba vydavat nove ovladace, ze Vsadim se s tebou, ze min ze zacatku tech problemu bude vyrazne vice nez nyni. Mozna, ze az se stav ustali, az budou stabilni ovladace a az se programatori pro ne nauci psat, tak to bude lepsi nez nyni, ale nejak neverim tomu, ze najednou vsechny problemy spojene s psanim v high-level grafickem jazyku pominou. Nevim, kde presne je chyba, zda u vyrobcu ovladacu / HW, nebo u programatoru, ktery pisou pro 3D API, ale nejak to porad idealne nefunguje...v kazdem novem vydani driveru jsou hromady oprav pro konkretni bugy ve hrach...kdyz to srovnam se svetem SW pro CPU, tak to je nebe a dudy....nebo snad intel a AMD vydavaji nove revize CPU / mikrokodu pro nove verze programu? nevsiml jsem si
A jinak X1950 jeteda hodne stara ATina, souhlas se divim tem programatorum ve standfordu, ze to rovnou nenapsali pro HW, ktery bude za 5 let...vis MAdcape, ono napsat takovy SW nejakou dobu trva a to se nezmeni ani do budoucna.

PS: poznamka pro uzivatele, ktery mi stale dava spatnou karmu za "invektiva": Doufam ze madcap ji dostane take za to "zvatlani"

zvatlas tu o vyuziti GPU na starej atine, dnes je tu doba unified shaderov a tie pojdu vyuzit univerzalne a lepsie to len na okraj

[THX]

zvatlas tu o vyuziti GPU na starej atine, dnes je tu doba unified shaderov a tie pojdu vyuzit univerzalne a lepsie to len na okraj

no, ciastocne pise k veci, pretoze ukazuje vyuzitie vysoko paralelneho (a menej univerzalneho) hw. Na novych nvidiach (a snad R600) by sa to malo dat vyuzit este lepsie.

A k tomu co tu hovori eagle, ze DC je drahe a ze programovanie pre DC je drahe. Aj vyvoj novej architektury je drahy. A co ty vies, kolko z ceny C2D je za to druhe pridane jadro (ja tvrdim ze to je ta mensia cast) a kolko je na zaplatenie nakladov za vyvoj? A ten vyvoj (ktory kritizujes ze je slaby a ze sa pouzivaju lacne triky s pridanim druheho jadra a ze by si rad 5ghz 10 isssue single core za 10kc) je celkovo dost drahy. Vyrobne naklady su u novych procesorov iba mensou castou ceny. Navyse instruction level paralelizmus nemozno zvysovat donekonecna. Dobrym prikladom je itanium, ktory aj ked vsetky programy kompilujes priamo pren (a teda na nom nespustas nejake starsie neoptimalizovane programy ako je to zvykom v x86), tak stale nedokazal vacsinou vyuzit tych 6 "pipeline" co mal.
Programovanie vo viacerych threadoch len robi to, co procesor sam nedokaze - odlisit nezavisle casti kodu. Na servroch to ma OS lahke - tam bezi vela nezavislych threadov a tak nie je problem vyuzit takyto procesor. Ale u thread level paralelizmu uz nedokaze sam procesor odlisit thready a preusporaduvat instrukcie. Reorder buffery tiez nemozes zvacsovat donekonecna, pretoze po istom case budes uz mat aj tak instrukcie spracuvajuce vysledky predch. vypoctov, takze instr. level paralelizmus tiez nemozno donekonecna zlepsovat. A navyse - ak si pustis program ktory vypisuje momentalne IPC procesora, tak zistis ze to aj tak v priemere a pri beznej praci nie je nejak vela.
Predstav si, ze by novy procesor od intelu nebol dual core, ale single core, ale za to s 8 pipeline a hyper threadingom. Tam by si tiez musel optimalizovat, aby si dokazal vyuzit potencial tohto "sirokeho" jadra. A musel by si to optimalizovat rovnako ako na DC. Navyse by to malo asi este nejake dalsie nevyhody (napr. teraz ked sa ti jedno jadro nepodari, tak snad to este mozes stale predat ako single core procak).

A ak povazujes itanium za uspesny, tak napr. taky vyvoj G80 stal 400mil dolarov, ale do itania islo uz 20 miliard. To je trocha rozdiel. Navyse - HP prestal vyrabat PA risc a Alfu, takze vymizla (lacnejsia - lebo netrebalo novy sw) konkurencia. Itanium zdaleka nie je taky uspech, ako sa prezentuje (vzhladom na to kolko stal vyvoj toho procaka, kolko stoji (a kolko stoja servre)). Z pohladu nakladov a zisku je to oproti x86 totalny prepadak.

[swarm]

Fer. Takze odted uz nebudou vubec zadne problemy s ovladaci ve hrach? Parada Takze vlastne uz ani nebude potreba vydavat nove ovladace, ze Vsadim se s tebou, ze min ze zacatku tech problemu bude vyrazne vice nez nyni. Mozna, ze az se stav ustali, az budou stabilni ovladace a az se programatori pro ne nauci psat, tak to bude lepsi nez nyni, ale nejak neverim tomu, ze najednou vsechny problemy spojene s psanim v high-level grafickem jazyku pominou. Nevim, kde presne je chyba, zda u vyrobcu ovladacu / HW, nebo u programatoru, ktery pisou pro 3D API, ale nejak to porad idealne nefunguje...v kazdem novem vydani driveru jsou hromady oprav pro konkretni bugy ve hrach...kdyz to srovnam se svetem SW pro CPU, tak to je nebe a dudy....nebo snad intel a AMD vydavaji nove revize CPU / mikrokodu pro nove verze programu? nevsiml jsem si
A jinak X1950 jeteda hodne stara ATina, souhlas se divim tem programatorum ve standfordu, ze to rovnou nenapsali pro HW, ktery bude za 5 let...vis MAdcape, ono napsat takovy SW nejakou dobu trva a to se nezmeni ani do budoucna.

PS: poznamka pro uzivatele, ktery mi stale dava spatnou karmu za "invektiva": Doufam ze madcap ji dostane take za to "zvatlani"

Normálně to nedělám, ale teď už si to neodpustim. Možná by se dalo říct, že to bude takové malé OT. Petříku, Petříku, máš tady v tomhle threadu skoro nejvíc postů. Já jsem to tu nečetl celé, ale poslední příspěvky, co od tebe čtu, jsou vážně spíše jen výpady. To už na forech bývá běžné, ale pokud chceš argumentovat, tak musíš mít argumenty a taky skill, kterym to můžeš podložit a nějak ty argumenty prodat. To ty ale nemáš a tak by ses neměl snažit tak útočit. Vypadá to pak dost směšně. Pokud je nouze o odborníky, co by přispěli do diskuze, tak je lepší ať je thread spíš prázdnější, než ho takhle "nastavovat".

No a abych napsal ještě něco málo k tématu. Vem si, že ty ovladače momentálně nejsou zrovna připravené na něco takového u těch grafických karet, až dojde k nějaké pokročilejší iniciativě ještě u vývojářů ovladačů, tak se to může hned změnit. Pokud tady srovnáváš CPU a grafiky (což mi přijde hodně uhozený), tak musíš brát v potaz, že CPUčka jsou všechna kompatibilní navzájem (proto to x86 ). Grafiky jsou mezi sebou těžce nekompatibilní (což jim taky umožňuje být mnohem výkonější pro jednotlivé účely). Chyba je momentálně tedy v ovladačích. nVidia i ATI jsou velcí hráči a pochybuju, že se nechytnou již brzy dostatečně silně této příležitosti (zisků).

Jo a ještě na závěr bych zmínil, že řešit jestli je lepší používat druhé jádro nebo grafický procesor (aspoň tak trochu vyzněl tvůj příspěvek) je totálně mimo. Už jenom na příkladě s tou ATInou. Zaměstnáním obou jader na CPU bychom asi 30x vyššího výkonu nezískali.

[Petrik]

sorry, ale taky neco napisu.
O GPU tady zacal Eagle, ktery napsal neco v tom smyslu, ze vice jadrove procesory jsou nesmysl, a ze kdyz uz je potreba vetsi vykon, tak ze to jde pomoci GPU. Takze pokud ti srovnani GPU a CPU pripada "uhozeny", reklamuj to u Eagla, ja s tim nezacal. Zaroven take reaguji na jeho posty z debaty o cellu, kde take argumentoval, ze cell je nesmysl a ze GPU je mnohem lepsi a vykonejsi. Ja jsem tam psal neco v tom smyslu, ze vyuziti GPU pro jine nez graficke operace bude min problematicke a ze vykon GPU nebude zdaleka tak ohromny, jako pro graficke operace...take jsem zduraznoval, ze zatim neni zadna realna aplikace pouzivajici GPU. Proto jsem tedy sem napsal, ze uz tedy nejaka je, ale ze to je dosti problematicke a ze nejenom podle meho nazoru to v nejblizsi budoucnosti nebude lepsi.
Kdyz si prectes muj post o F@H GPU klientu, tak tam nenajdes zadny "vypad", proste jsem jen shrnul, jak tato konkretni realna aplikace funguje a jake jsou s ni problemy. Na tento celkem neutralni post reagoval madcap vypadem, ze akorat zvatlam a ze jsem uplne mimo, protoze uz je prece jedna dostupna grafika s unifikovanymi shadery, ktera vse zazracne zmeni. Jakej jsem trotl, ze.

Ted k veci, i kdyz je mi jasne, ze podle tebe a dalsich odborniku to budou jen naproste zvasty.

1)ovladace nejsou pripravene na neco takoveho.

No oni nejsou pripravene ani na hry, kdyz je autori musi porad opravovat, ze? Nebo tobe propada normalni, ze v kazdem vydani novych driveru jsou opravy pro bugy, ktere se projevuji v novych hrach? Me proste pripada, ze cely navrh toho 3D API je natolik slozity, ze neni mozne jej pouzivat a psat pro nej ovladace, aniz by se neustale musely opravovat nejake drobne, ale obcas i dost zasadni chyby. Pokud se to ale pouziva pouze pro grafiku ve hrach, tak to ani moc nevadi...hraci si proste stahnou nove drivery a je to, nejaky ten spatne vykresleny stin ci textura nikoho nezabije....pro jine pouziti to vsak muze mit katastrofalni nasledky.

2) grafiky jsou mezi sebou tezce nekompatibilni

To je mimo jine duvod, proc si myslim, ze jen tezko muzou uspet jako nahrada CPU. Pravda je, ze s pomoci 3D API se vsechny muzou jakoby pouzivat stejne, ve hrach to tak vpodstate funguje, ale pro jine pouziti to je zda se problematicke.

3) řešit jestli je lepší používat druhé jádro nebo grafický procesor...

Samozrejmne, ze 30x vetsi vykon se druhym jadrem neziska, ale zase tam maj jistotu, ze aplikace psana pro vice CPU pobezi vzdy spravne, coz u GPU nyni neplati a pochybuji, ze nekdy bude.

Pokud to z toho jeste dostatecne nevyznelo, tak duvod, proc jsem vubec zacal s debatou o GPU vs. CPU je ten, ze vyuziti GPU pro jine vypocty nez graficke sice muze prinest obrovsky narust vykonu, ovsem zaplaceny velikymi problemy s drivery, DX a pod. Proto ma podle me smysl vykon dohanet pomoci vice jader, protoze tam sice v soucasne dobe takovy narust ocekavat nelze, ale zato to je bez problemu s kompatibilitou. Navic se pomalu, ale jiste zacinaji objevoval CPU ala Cell, ktere jdou na vec zcela jinak a to se muze ukazat jako vytezna strategie. Shrnuto a podtrzeno: vice jader podle me smysl ma, protoze ocekavat, ze super vykonna GPU vse spasi, je min. v blizke budoucnosti dosti nepravdepodobne.
Ale jinak je klidne mozny, ze placam naproste kraviny, to necham na posouzeni kazdeho ctenare. Jen jsem proste dal priklad realneho pouziti GPU a problemu s tim spojenych....ze se to nekomu nehodi do kramu, za to nemuzu.

PS: "Grafiky jsou mezi sebou těžce nekompatibilní (což jim taky umožňuje být mnohem výkonější pro jednotlivé účely)"
Ja myslel, ze vsechny grafiky chteji delat vice mene to same, totiz pocitat grafiku pro hry, resp pocitat ukoly zadane nejakym 3D API. Jake jsou tedy ty "jednotlive ucely", pro ktere jsou mezi sebou tezce nekompatibilni? ...jasne, je to vypadek, ale kdyz pouzijes nesmyslny argument na obhajobu toho, ze placam kraviny a nemam skill, tak se nemuzes divit, ze.

Normálně to nedělám, ale teď už si to neodpustim. Možná by se dalo říct, že to bude takové malé OT. Petříku, Petříku, máš tady v tomhle threadu skoro nejvíc postů. Já jsem to tu nečetl celé, ale poslední příspěvky, co od tebe čtu, jsou vážně spíše jen výpady. To už na forech bývá běžné, ale pokud chceš argumentovat, tak musíš mít argumenty a taky skill, kterym to můžeš podložit a nějak ty argumenty prodat. To ty ale nemáš a tak by ses neměl snažit tak útočit. Vypadá to pak dost směšně. Pokud je nouze o odborníky, co by přispěli do diskuze, tak je lepší ať je thread spíš prázdnější, než ho takhle "nastavovat".


No a abych napsal ještě něco málo k tématu. Vem si, že ty ovladače momentálně nejsou zrovna připravené na něco takového u těch grafických karet, až dojde k nějaké pokročilejší iniciativě ještě u vývojářů ovladačů, tak se to může hned změnit. Pokud tady srovnáváš CPU a grafiky (což mi přijde hodně uhozený), tak musíš brát v potaz, že CPUčka jsou všechna kompatibilní navzájem (proto to x86 ). Grafiky jsou mezi sebou těžce nekompatibilní (což jim taky umožňuje být mnohem výkonější pro jednotlivé účely). Chyba je momentálně tedy v ovladačích. nVidia i ATI jsou velcí hráči a pochybuju, že se nechytnou již brzy dostatečně silně této příležitosti (zisků).

Jo a ještě na závěr bych zmínil, že řešit jestli je lepší používat druhé jádro nebo grafický procesor (aspoň tak trochu vyzněl tvůj příspěvek) je totálně mimo. Už jenom na příkladě s tou ATInou. Zaměstnáním obou jader na CPU bychom asi 30x vyššího výkonu nezískali.

[swarm]

...vykon GPU nebude zdaleka tak ohromny, jako pro graficke operace...

No. Co jsou grafické operace? Mám zkušenost s programováním pixel shaderů (dokonce i combinerů na GF4MX - to je něco jako pixel shader, ale bez texture shaderu) a co myslíš, že tam je. Jenom matematika. To nejsou nějaký "extra" grafický operace, to jsou prostě úplně normální matematický úkony. Pokud víme, co od grafiky chceme, tak z ní můžeme vymačnout neskutečný výkon proti CPUčku, ale samozřejmě její okruh působnosti je podle toho i omezenější. Už trochu OT, no.

Kdyz si prectes muj post o F@H GPU klientu, tak tam nenajdes zadny "vypad",...

Nemluvím o žádném konkrétním postu (a už vůbec ne zrovna o tamtom), ale podívej se jakým způsobem píšeš své příspěvky.

PS: "Grafiky jsou mezi sebou těžce nekompatibilní (což jim taky umožňuje být mnohem výkonější pro jednotlivé účely)"
Ja myslel, ze vsechny grafiky chteji delat vice mene to same, totiz pocitat grafiku pro hry. Jake jsou tedy ty "jednotlive ucely", pro ktere jsou mezi sebou tezce nekompatibilni?

No, nevim jestli je to napsané, tak aby to každý pochopil (asi ne), ale šlo o to, že pokud vememe si vememe nějaký účel (třeba počítat grafiku nebo cokoli jiného), tak výkonnější řešení bude vždycky, když ty zařízení se nemusí starat sami o zpětnou kompatibilitu. To je rozdíl přístupu k CPU a ke GPU. Výhoda je, že u GPU se tohle dá i celkem provozovat, tahle strategie. U CPU by to bylo o dost horší prosadit, ale byly by pak výkonnější. Ale tohle je už fakt OT.

...jasne, je to vypadek, ale kdyz pouzijes nesmyslny argument na obhajobu toho, ze placam kraviny a nemam skill, tak se nemuzes divit, ze.

Hehe, výpadek a výpad neni to samé . Bereš si všechno moc osobně, neni to dobrý způsob, jak komunikovat v diskuzích.

Možná by tato část diskuze měla probíhat spíš v jiném threadu. Zítra si jdu hrát s IEEE-488, tak už na to dneska dlabu.

[Fox!MURDER]

Petriku, Petriku ...
a) prosim, zpomal. osobni utoky nic nevyresej a jediny co ti prinesou bude K- ... bylo by vazne fajn, kdybysis kazdej svuj prispevek pred odeslanim aspon 3krat precet a pokusil se odstranit vsechny osobni vypady. tohle ma bejt vecna diskuze a ta se da vest i uplne neosobne (to po tobe nikdo nechce, ale snazim se tim naznacit, ze rozhodne mas prostor, kam se smerovat)
b) problem s nekompatibilitou grafik vidim spis v rozhranich a ovladacich, nez v grafikach samotnejch. navic to tvoje opravovani chyb se tyka prave jen grafiky. karta ty vypocty udela spravne, ale kdyz ji driver(hra) predaj spatny data, je spatnej i vysledek. kdyz delas exaktni vypocty (molekularni dynamika), je uplne jedno, co je na vstupu tech algoritmu. proste to prechroustaj a vyplivnou presnej vysledek. kdezto u grafiky staci, abys mel spatne umistenej objekt, blbe namapovanou texturu, spatne naprogramovanej shader a je to hned videt.
c) reseni nekompatibility vidim ve vytvoreni nejakyho HALu v podobe treba DirectMath, nebo OpenAML, nebo neceho na ten zpusob. priznavam predem (doufam ze me nekdo opravi/doplni) ze nevim, jak vypada programovani shaderu v tuhle chvili, ale takova prdestava driveru, kterej obsahuje (napr.) C compiler, kterej Ceckovej zdrojak shaderu prechrousta do strojaku konkretni grafiky, tak aby tam sel spustit ... resp. tohle by se mozna autorum nemuselo moc libit, takze by bylo potreba udelat nejakej meta-strojovej kod (neco jako napr. bytecode javy).
d) dalsi problem s tou ATI akceleraci F@H je v tom, ze windows to proste porad berou jen jako grafiku a tudiz napr. kdyz clovek zamkne stanici, windows vyresetujou kontext grafiky a tudiz zrusej ty vypocty co tam bezej. to se musi zmenit.
e) ono by to vubec mozna bylo nejjednoduseji resitelne, kdyby se ta karta rozdelila na dve virtualni (GPU a FPU) s plovoucim poctem jednotek fungujicich v kazdem z modu...


btw. vsimli jste si ? historie se opakuje... (kdo si jeste vzpomene na 80387?)


Edit: sakra, to jsem jim to pekne vymyslel (jsem si konecne precet neco o tom jak tyhle GP vypocty na G80 fungujou ... http://www.anandtech.com/video/showdoc.aspx?i=2870&p=8)

[Petrik]

1) graficke operace, pokud se nepletu, je dost specificka skupina matematickych vypoctu, predpokladam ze naprosta vetsina jsou goniometricke funkce a operace v plovouci carce obecne. to jiste neni cela matematika, jako napriklad integrovani atd. Jasne, ze grafika je schopna spocitat temer cokoli, ale otazka je jak rychle. Jeste do nedavne doby, do prichodu G80, byly IMHO GPU optimalizovany prave na pocitani ruznych sin a cos, ktere umi provadet skutecne neskutecne rychle pro jine operace byt tak rychle nemusi, coz dokazuje "pouze" 20-30x vetsi rychlost F@H klientu. Pouze proto, ze pro ty skutecne graficke operace je rozdil ve vykonu klidne 3 a vice radu.
2)kdyz me lidi urazeji, viz Eagle, ktery me nekolikrat oznacil za jedince s deficitem inteligence, tak se nemuzes divit, ze si to nenecham libit...ja ostatni alespon neurazim, pouze se snazim argumentovat.
3)Ale grafiky jakoby jsou zpetne kompatibilni....vim jak to myslis...mame proste nejake API, ktere rozumi urcitym instrukcim typu namaluj caru a pod. Toto API to preda driveru, ktery zna HW grafiky, prechrousta ji to do jejiho strojoveho kodu a grafika to provede. To asi vime vsichni. Principialne to je neco hodne podobneho je napr. java, pyton, php a pod. Pokud se pletu, opravte me pls. Problem je v tom, ze ty 3D API, resp. graficke ovladace jsou zrejmne natolik slozite, ze tam neustale vznikaji chyby. Navic, kazda hra vypada na ruzne grafice jinak, proste kazdy driver resi ty ukoli trochu jinak, coz je docela problem. To je jako kdyby javovy program daval jine vysledky na G5 a na x86. Pokud nekdo navrhne nejake nove, jednoduzsi API, jako tu navrhnul Fox, ktere pujde snadno debugovat a kde bude zarucena spravnost vysledku, bude to super. Zatim ale nic podobneho realne pouzitelneho neni, nebo se to alespon nepouziva.

No. Co jsou grafické operace? Mám zkušenost s programováním pixel shaderů (dokonce i combinerů na GF4MX - to je něco jako pixel shader, ale bez texture shaderu) a co myslíš, že tam je. Jenom matematika. To nejsou nějaký "extra" grafický operace, to jsou prostě úplně normální matematický úkony. Pokud víme, co od grafiky chceme, tak z ní můžeme vymačnout neskutečný výkon proti CPUčku, ale samozřejmě její okruh působnosti je podle toho i omezenější. Už trochu OT, no.

Nemluvím o žádném konkrétním postu (a už vůbec ne zrovna o tamtom), ale podívej se jakým způsobem píšeš své příspěvky.


No, nevim jestli je to napsané, tak aby to každý pochopil (asi ne), ale šlo o to, že pokud vememe si vememe nějaký účel (třeba počítat grafiku nebo cokoli jiného), tak výkonnější řešení bude vždycky, když ty zařízení se nemusí starat sami o zpětnou kompatibilitu. To je rozdíl přístupu k CPU a ke GPU. Výhoda je, že u GPU se tohle dá i celkem provozovat, tahle strategie. U CPU by to bylo o dost horší prosadit, ale byly by pak výkonnější. Ale tohle je už fakt OT.

Hehe, výpadek a výpad neni to samé . Bereš si všechno moc osobně, neni to dobrý způsob, jak komunikovat v diskuzích.

Možná by tato část diskuze měla probíhat spíš v jiném threadu. Zítra si jdu hrát s IEEE-488, tak už na to dneska dlabu.

[Fox!MURDER]

1) graficke operace, pokud se nepletu, je dost specificka skupina matematickych vypoctu, predpokladam ze naprosta vetsina jsou goniometricke funkce a operace v plovouci carce obecne. to jiste neni cela matematika, jako napriklad integrovani atd. Jasne, ze grafika je schopna spocitat temer cokoli, ale otazka je jak rychle. Jeste do nedavne doby, do prichodu G80, byly IMHO GPU optimalizovany prave na pocitani ruznych sin a cos, ktere umi provadet skutecne neskutecne rychle pro jine operace byt tak rychle nemusi, coz dokazuje "pouze" 20-30x vetsi rychlost F@H klientu. Pouze proto, ze pro ty skutecne graficke operace je rozdil ve vykonu klidne 3 a vice radu.
2)kdyz me lidi urazeji, viz Eagle, ktery me nekolikrat oznacil za jedince s deficitem inteligence, tak se nemuzes divit, ze si to nenecham libit...ja ostatni alespon neurazim, pouze se snazim argumentovat.
3)Ale grafiky jakoby jsou zpetne kompatibilni....vim jak to myslis...mame proste nejake API, ktere rozumi urcitym instrukcim typu namaluj caru a pod. Toto API to preda driveru, ktery zna HW grafiky, prechrousta ji to do jejiho strojoveho kodu a grafika to provede. To asi vime vsichni. Principialne to je neco hodne podobneho je napr. java, pyton, php a pod. Pokud se pletu, opravte me pls. Problem je v tom, ze ty 3D API, resp. graficke ovladace jsou zrejmne natolik slozite, ze tam neustale vznikaji chyby. Navic, kazda hra vypada na ruzne grafice jinak, proste kazdy driver resi ty ukoli trochu jinak, coz je docela problem. To je jako kdyby javovy program daval jine vysledky na G5 a na x86. Pokud nekdo navrhne nejake nove, jednoduzsi API, jako tu navrhnul Fox, ktere pujde snadno debugovat a kde bude zarucena spravnost vysledku, bude to super. Zatim ale nic podobneho realne pouzitelneho neni, nebo se to alespon nepouziva.

1) no nevim, rek bych ze na render 3D sceny je potreba vic, nez jen goniometricky fce. viz:

Instruction 	Description 	Clocks
add 	Sum 	1
dp3 	Three-components dot-product 	1
dp4 	Four-component dot-product 	1
dst 	Distance vector 	1
expp 	Exponential 10-bit precision 	1
lit 	Lighting coefficients 	1
logp 	Logarithm 10-bit precision 	1
mad 	Multiply and add 	1
max 	Maximum 	1
min 	Minimum 	1
mov 	Move 	1
mul 	Multiply 	1
rcp 	Reciprocal 	>1
rsq 	Reciprocal square root 	>1
sge 	Set on greater or equal than 	1
slt 	Set on less than 	1
sub 	Subtract 	1

Table 2. Vertex shader general instructions

Macro instructions include:
Instruction 	Description 	Slots/clocks
exp 	Exponential base 2 full precision 	12
frc 	Fraction 	3
log 	Logarithm base 2 full precision 	12
m3x2 	3×2 vector matrix multiply 	2
m3x3 	3×3 vector matrix multiply 	3
m3x4 	3×4 vector matrix multiply 	4
m4x3 	4×3 vector matrix multiply 	3
m4x4 	4×4 vector matrix multiply 	4

2) kdyz te nekdo urazi, tak se na nej vys**, ted mu ledatak davas za pravdu.
3) precti si ten muj link o G80 to co jsem tu s tak velkou vervou vymyslel, vymyslel nekdo uz 4 roky zpet ...