Ja nevim, proc uz konecne nevznikne jedna CPU (CENTRALNI=jedina vypocetni jednotka). To musi kdejaka periferie neco pocitat? Dnes, kdy je komunikace rychlejsi a efektivnejsi nez vypocty osamocenych "CPU" v periferiich,snad nema smysl praci rozmelnovat, ale naopak vsechnu tvrdou praci sverit povolanym ...

Nie som vyvojar, ale chlapcov z EPICu nemusim. Akosi tychto samozvanych prorokov neuznavam z dovodu toho ze toho nic moc nepredviedli UE3.0 oproti tomu co bolo slubovane v roku 2004 obsahuje tak polovicu. Celkovo ich predpovede su zaujimave a vzdy obhajuju ich cestu a zatracuju vsetko ostatne. Je jasne ze tie ich hry nebudu slapat na konzoliach ak budu vyuzivat silne GPGPU operacie, Fyziku a podobne veci. tz. menej zisku, ale viac prace. Ich demagogia o buducnosti je fakt na usmiatie a pripadaju mi tak tocha ako Bill v Microsofte ked bol este mlady a hlupy.

Já tedy naopak věřím, že by časem mohla objevit varianta, kdy je "skoro vše" integrováno na motherboardu a jsou tam jenom dvě patice. A sice jedna pro CPU a jedna pro GPU. Jo a pak samozřejmě nějaké sloty pro paměti a konektory pro připojení periférií typu HDD apod.

ten rozdiel programovania GPGPU a CUDA alebo jednovlaknove a viacvlaknove (povedzme larrabee) je asi brany skor z hladiska programatora a optimalizacie ako cisto z technickeho hladiska.
Urcite je jednoduchsie pisat v niecom unifikovanom a normalnym prog jazykom podomnom ako je CUDA nez v GPGPU (asi prave je to myslene skor ako low level assembler na karte nez technologia vypoctov na karte).A to iste aj Larrabee, asi sa predpoklada ze intel spravi fajny prechod na tuto platformu, kniznice kde nebude musiet programator az tak riesit ako sa dany algoritmus rozhodi na jadra (teda nebude musiet riesit ked nebude chciet).

S timem ani moc nesouhlasím v otazce zániku GPU, ale fandím mu v boji proti blbosti zvané DirectX. Myslím si že odproštění od DirectX a OpenGL je krok správným směrem.

A v čem je problém napsat vicevláknovou hru? Chce to jen rozdělit program na více úloh a vymyslet šikovné předavání dat mezi nimi. Nic složitého, funguje mi to i na malém procesoru v asembleru s pár byty RAMky, tak proč by to nemělo jít na PC?

"čímž patrně míni ?klasickou jednovláknovou aplikaci?)."Tak to zaručeně nemíní
"Tim viděl a prozkoumal DirectX 11 a jeho komentář na omezenost divného rozhraní se vztahuje i na ně."To je vtip?
"V zásadě se tak hodlá vrátit do pre-DirectX dob"Proboha, už dost ... nějak to přestává být vtipné (bohužel to ani vtipné být nezačalo)
dál už radši nečtu

Michal123: nikdo neříká, že to nejde, prostě je to jenom 2x dražší ... řekl bych, že ta čísla o náročnosti (tj. náročnosti časové = finanční) programování docela sedí.

Doufám že se Timovy prognozy vyplní. Konec konců je to i dost realistické. Na Unreal 4 enginu pracuje už od roku 2003, tedy šest let, byť nejprve jenom sám a větší skupina programátorů se k němu připojila tak před rokem. Je tedy zřejmé, že už si zde lecos odzkoušel a je nesmysl si myslet, že po 6-ti letch vývoje najednou zjistí, že tudy to nejde.

Jeho vize se mi velice líbí. Napsat kod hry v klasickém jazyce (např C++) a pak ho jenom překompilovat překladači k x86, GPU, či Larrabee na jednotlivé výpočetní platformy, je velice flexibilní a univerzální možnost. Ať se jednotlivé kusy HW ukáží, co dokáží s general purpose kodem.

I u dnešních GPU je vidět tahle cesta. Nárůst ALU vzhledem k fixním texturovacím jednotkám je markantní a stejně tak snaha nVidie i ATi zpracovávat na GPU obecné výpočty dokazuje snahu postupně odstranit pochybná API a jít směrem ke general purpose počítání. Ačkoli zatím je to bída. I přes dost brutální hype a zfalšované testy, GPGPU implementace je jen u naprostého minima SW a navíc jde dost často o výpočty v mizerné kvalitě a s nutností si výpočty nechat napřed předžvejkat procesorem. Intel pracuje na Larrabee obsahující jen naprosto nezbytné množství fixních funkcí vzhledem k zpětné kompatibilitě. Carmack koketuje s voxely a raytracingem, stejně jako nVidia, Intel a ATi. Zánik klasické rasterizace je na spadnutí a s ní i fixní funkce texturovacích jednotek v GPU. To je také jediný důvod proč CPU nemůže počítat dnešní grafiku. Klasické shadery se dají krásně počítat ve vektorových jednotkách.

Mimochodem, zajímavý je také jeden starší rozhovor kde tvrdil, že Unreal 4 engine bude vyžadovat minimálně deseti jádrové CPU a dokáží využít maximálněcca 40 jader. Během vývoje se lecos může změnit, ale evidentně se řeči o nemožnosti ve hrách využít větší počet jader ukazují jako liché.

Moc nerozumím, jak to Tim Sweeney myslel. Doufám, že ho článek moc dobře nevystihuje. Jsou tam docela zásadní rozpory a nepřesnosti. Viz CUDA ANO, multi-thread NE, nebo třeba to že současné herní enginy nejsou raytracingové ale rasterizační.

Šmánkote Michale123, to že dokážete naprogramovat pár PIC či Atmelů, které posílají výsledky koordinačnímu procesoru a myslíte si jak je to snadné. Jakpak třeba máte ošetřeno aby to běhalo s jiným počtem procesorů? Také mám trochu praxi (robotika), ale to je vy o koze a článek o voze.
Programy musí běhat na libovolném počtu jader (CPU i GPU). A na světě není jen jeden typ (to je jako stroják přenést z PIC na Atmel). Tak se snažte pochopit, že regulace vytápění v RD s mnoha čidly se samostatnými procesory není to samé. Pokuste se na své platformě napsat třeba starého Wolfštejna a uvidíte.

Michal123> heh napisat mutithread hru no problem hej ? no dobre az na to ze hry vyuzivaju prakticky skoro vsetok hw v pocitaci (GPU,CPU,RAM,disk,cd/dvd rom,sietovka,audio,i/o klavesnica mys a dalsie minoritne extremnosti).
Ano napisat multithreadovu app kde jeden trhead pobezi na jednom jadre na 80% a druhy na druhom jadre povedzme na 20% a hra bude hlasit ze vytazila procak na 100% to fakt neni problem, ale napisat hru aby aspon ako tak linearne skalovala pri zvysovani poctu jadier to uz problem je.Napriklad bezna fpska,sietovy kod.Pri single hre ho mozete prakticky odignorovat ale bacha, ked hrac spusti hru ako server tak uz asi bude potrebovat viac vykonu na spracovanie komunikacie.

A imho rendering kompletne na cpu je podla mna dobra volba.Dnes hry po technickej stranke grafiky vyzeraju vsetky rovnako.Vyvjojari su obmedzeny tym co dokaze hw platforma - nvidia alebo ati.

2TyNyT: Koukam zes toho uz hoodne pozapomel, Glide samozrejme cesta byla, ale 3Dfx nezvladli zcela zasadne marketing a vyvoj novych verzi karet. Glide bylo ve svy dobe min 3x vykonejsi nez tehdejsi pokusy M$ s Dx a pokud nektera gameska nebezela na Glide, nikdo po ni ani nestek.

2Azazel: To neni pravda, alespon ne takto obecne. Udelat vicevlaknovou aplikaci lze i s naprosto stejnymi naklady jako jednovlaknovou, dokonce ve specialnich situacich i levneji. Naopak pak existuji ulohy, ktere lze paralelizovat velice obtizne a pak takove, ktere paralelizovat nelze vubec. Vem si situaci, kdy na jednojadre resis pocitani dvou (nebo vice) vicemene nezavislych veci, ale s tim, ze aelspon u jedne z nich musis mit garantovanou odezvu. To je naprosto klasicky pripad prave her. Chces aby hra reagovala "okamzite" na vstupy hrace, ale hra zaroven pocita napr pohyby cen, chovani NPC (ktere hrac treba zrovna ani nevidi) ... to muze pockat, ovsem ne moc dlouho. Pokud mas vice CPU/GPU/... tak to vse muze bezet zaroven.
Vubec nemluve o tom, ze hruby rozlozeni (pokud mi na tom nesejde) udela samozrejme kompilator.

BTW: Miluju programatory napr v .NET, kazdej jejich canc, byt velky par kB potrebuje desitky/stovky MB knihoven a je 100x pomalejsi nez totez napsano primo pro konretni platformu. Java neni o moc lepsi, tedy jen o tom ze funguje i jinde nez na widlich, coz muze byt jakysi pofiretni duvod. Znam ovsem i znacne mnoztvi C/C++ aplikaci, ktere funguji na mnoha ruznych platformach a na vsech nasobne rychleji a s nasobne mensimi pozadavky. Obavam se, ze dotycny si to predstavuje jako .NET pro prgani games. Jenze to by nejdriv vykon HW musel vzrust cca milionkrat aby to behalo zhruba stejne jako ted.

2vwer: Obávám se, že jsi princip .NET nepochopil. Cílem této platformy nejsou rychlé výkonné aplikace, ale rychlé a snadné programování. A se snadným programováním souvisí málo chyb. Krátký přehledný managed kód je to, co umožňuje, aby programy byly spolehlivé a levné. Sice je každému jasné, že ta samá aplikace v C++ (nebo dokonce v C) bude rychlejší, ale:
1) Bude určitě obsahovat víc chyb.
2) Její vývoj bude trvat déle, tj. bude dražší a nikdo si jí nekoupí (cena je u software až na prvním místě - ostatně jako všudě).
3) Někdo jí musí umět naprogramovat. A není tajemstvím, že programovat v C++ na použitelné úrovni umí méně lidí, než kolik se jich tváří, že to umí.
Z benchmarků vyplývá, že .NET aplikace napsaná průměrným programátorem je rychlejší (!) než C++ aplikace napsaná průměrným programátorem. Ano, když C++ aplikaci napíše profesionál, výsledkem je rychlejší kód... akorát teda už nikdo neříká, kolik vývoj takovým profesionálem bude stát peněz a jak dlouho bude trvat. Nadávat na .NET je známkou nezkušenosti a nepochopení jeho cíle.

re: ZOLLINO @ 198.178.192.1 - včera, 17. srpna 2009, 12:14
Nie som vyvojar, ale chlapcov z EPICu nemusim. Akosi tychto samozvanych prorokov neuznavam z dovodu toho ze toho nic moc nepredviedli UE3.0 oproti tomu co bolo slubovane v roku 2004 obsahuje tak polovicu. Celkovo ich predpovede su zaujimave a vzdy obhajuju ich cestu a zatracuju vsetko ostatne. Je jasne ze tie ich hry nebudu slapat na konzoliach ak budu vyuzivat silne GPGPU operacie, Fyziku a podobne veci. tz. menej zisku, ale viac prace. Ich demagogia o buducnosti je fakt na usmiatie a pripadaju mi tak tocha ako Bill v Microsofte ked bol este mlady a hlupy.

----------------------------------------------

Proč by jejich hry neměli špalat na konzolích? Právě naopak. Sám Tim několikrát zmínil, že Unreal 4 engine (tedy ten 100% napsaný ve skutečném jazyce) je cílen právě na konzole další generace a PC verze bude následovat později. Pokud to dobře chápu, jejich nový engine by neměl řešit nějaké ometení platforem, jako DirectX různých verzí, OpenGL, CUDA, atd. Oni prostě napíší obecný kod nezatížený nějakými fixními funkcemi a pak ho překompilujou pro různé platformy. Bude jim zcela jedno jestli v té konzoli ke HW od ATi, nVidie, Intelu, nebo IBM. Všechny tyhle platformy prostě dostanou obecný general purpose kod, nejprve napsaný například v C++, a budou se s tím muset poprat. Mě to přijde naopak jako méně práce, více flexibility a více zisku.
Mimochodem, také si vzpomínám na nějaký rozhovor s Timem, kde sice tvrdil že na nějaké API už kašlou, ale jejich uplnou eliminaci neočekávají. Není přece žádný problém koexistovat. Vývojáři neschopní efektivně programovat s klasickým programovacím jazykem prostě napíší hru pod nějakým API pro určitou platformu, kdežto oni prostě budou mít engine zcela nezávislý.

vwer : Když o .netu nic nevíš, tak o něm laskavě nepiš .... garantuju ti, že program ve srovnatelné kvalitě udělám v C# netu 2x-3x rychleji než v C++*) a pomalejší to nebude.
 
*) C++ mě už pár let žíví, takže o tom něco málo vím

Eagle_not_registered: souhlas, jenom si dovolím poznamenat, že když profesionál se bude v C# snažit, tak z toho vymáčkne stejnou rychlost jako z C++ (když se snažit nebude, tak je to typicky pomalejší tak o 10%).
 
Mimochodem, 99% programátorů používá určité knihovny a překladače, které mají na rychlost dramaticky větší vliv než použitý "jazyk" ... např. kolekce v MS implementaci STL (C++) jsou děsivě pomalé a i java je dokáže rozválcovat. Dalším příkladem může být GCC na MACu ... nedávno jsme přešli na verzi 4 a rychlost programu se zvýšila prakticky o řád! ... takže spoustu let to bylo děsivě pomalé - ale to nikdo neřešil, protože se o tom "nevědělo".