Prefetch = spekulativní načítání dat ještě před tím, než jsou potřeba.

160bit je délka prefetch, což nemá s kapacitou moc společného. Například FPU jednotka taky může používat 80bit proměnné, což také není číslo příliš dobře kompatibilní s mocninami dvou.

Pentium M tuto sběrnici používá taktéž.

Ano, Pentium­-M toto využívá taky. Ale je to právě modifikace, která zůstala z P4

Nikoli, je to skutečně tak, že programátor disponuje šestnácti 64bit registry. Více viz https:­/­/www.svethardware.cz­/art_doc­-EC20FC74EB3582DFC1256DAA00294E90.html .

díky za rychlou odpověď :)

Díky bohu za rozumnou úroveň komentářů, jen doufám že se sem taky nepřestěhují teenagerské diskuze z PCT. Úplně stačí kouknout na tu pod dnešním článkem od Štefka, ta je fakt jen pro silný nervy :(

Nebojte, redakce Světa hardware nikomu nebude odpovídat větami typu ­"Co to tady blabolis?­", ­"No mozna si nekdo stoji na vedeni­" nebo ­"Ja nevim ale mi prijdes trosku mimo spise ty... a­)neumis cist; b­)nemyslis­". Snažíme se mít jistou úroveň, která odpovídá etickým zásadám. Zároveň příspěvky čtenářů, které nějak napadají ostatní či obsahují nevhodná slovní spojení, mažeme. Pokud tito pokračují v činnosti, je jim zablokován přístup. Chceme, aby diskuze na Světe hardware měly úroveň a aby čtenáři poskytly další informace k tématu.

To je dobře, dnes jsem kvůly tomuto tvrzení zabrousil na konkurenční web a co tam autor článku o jisté grafice předváděl...
eh, honem rychle zpět :­)
Je fakt, že celkově vzato tady i když si lidé vjedou do vlasů, snaží se ­"utlouci­" druhého argumentama a ne urážkama.

Mrkni treba na http:­/­/www.phys.uu.nl­/~steen­/web02­/overview02.html, sice anglicky a mirne zastarale, ale jako zaklad staci.

Proc pri kompilaci?

Prekladac na to ma vic prostredku.
Prekladac muze najednou pracovat s vetsi casti kodu, delat komplikovanou analyzu, atd..
Pro napraveni ­'spatneho­' kodu by procesor musel byt hoodne dobry.

Proc na CPU?
CPU ma vic informaci o behovych zalezitostech, jako treba pravdepodobnosti skoku na podmince atd.
Prekladac vytvari kod pro nejakou virtualni platformu, ktera ma omezeni ­(pocet registru, na ruznych CPU trva stejna instrukce jinak dlouho­), ale nejde ji porad menit jak kdo potrebuje. Proto treba prejmenovavani registru, prerovnavani instrukci...
Neda se pocitat s tim, ze kod vygeneroval kvalitni prekladac, mozna spis s opakem;­)

Asi by se dalo rict, ze pokud budete mit dost informaci o vyslednem CPU­(HW­), predikovatelny tok programu atd. tak potreba optimalizaci na CPU vyrazne klesne, pripadne budou mit tak maly efekt, ze to nebude mit smysl je delat. Ale to pomalu znamena mit na kazdou konfiguraci HW zvlast zkompilovany software. Ale i to se da, viz treba Sourcemage distribuce Linuxu ­(bohuzel ne kazdy se o sve zdrojaky rad podeli­), pripadne kompilace vysledneho kodu az za behu na zpusob Javy.

Ano, jde o kompatibilitu s minulosti. Kdyz to hodne zjednosusim, tak mne by treba nevadilo, kdyby Microsoft zkompiloval instalacky Woknous s vyuzitim SSE3. Muj procik to umi, ale co ten tvuj? Me by se to zrychlilo, ale ty by jsi brecel. :­) Stejne tak kompilace na miru P4 zrovna nevyhovuje Athlonu XP i bez pouziti SSE instrukci.

Abych pravdu rekl, tak me docela udivuje, ze tu jeste nemame moznost obejit dekoder a dalsi casti a krmit CPU primo v jeho vnitrnim kodu. Pravda je, ze by byly komplikace s ruznymi verzemi jader, ale pokud nekdo chce vyzdimat z CPU maximum, tak by si s tim urcite rad dal praci. Nebo mit aspon pristup k vysledku dekodovani a moct ho nacacheovat­/ulozit na disk.

Pánové, nepřeceňujte programátory. Spoustě her chybí dokonce i optimalizace prováděné kompilátorem! Ano, programátoři se často neobtěžují ani za ony tři minuty zapnout pár přepínačů.

To je tim, ze finalni kompilaci dela casto uplne nekdo jiny.

To nebolo az tak o optimalizacii ako o instrukcnej sade. 64bit je uz tu a dalsia sanca na prechod k rychlejsej instrukcnej sade sa nekona?

Tak si ku Itanium, to je zavisle na kompileru. O tom je vyse v diskusi uz psano, ale vzhledem k tomu, jak se programuje pro PC, tak budme radi, ze aspon neco se optimalizuje na urovni procesoru. To bych to chtel videt kdyby to zaviselo, jako u Itania, jen na programatorech a jak si nastavi kompiler... Tam se programuje trochu jinak, jde o jine penize a a taky aplikace na to jsou jinak placene. Neni problem vyplaznout za rocni podporu, kde jsou upgrady 150 000 Kc a neomezena verze stoji 650 000 Kc...

No tomu rikam odpoved:­) Ja si nechci kupovat Itanium, pouze rikam, ze me prijde logicke umoznit obejit nektere ne nutne potrebne casti procesoru.

A ziskatelny vykon imho neni jedina vyhoda. Kazda bezici jednotka spotrebovava energii, a takova predkompilace do jeste nativnejsiho kodu by je umoznila vypnout a usetrit.

Když pominu to, že bys musel mít pto každou verzi procesoru extra binárku tak nativní kód bude nautně větší. A sousta kódu neníani tak bržděná pomalostí procesoru ale pomalostí pamětí. Copak s tím asi udělá potřeba načíst větší kód programu?

Mikrokód. Lisp Machine. Xerox Alto. Hardware optimalizovaný na vyšší jazyk. Já myslím, že by to šlo i dneska. :­-)

Spis nez na spiknuti bych to videl spis na neochotu­/lenost lidi ke zmene. Da se argumentovat treba tim, ze M$ cilene nevytahlo 64bit system driv a nedivil bych se, kdyby to byla pravda, na druhou stranu velkou cast uzivatelu u M$ nic nedrzi a kdo chce, tak uz si 64 bitu davno uziva.

Kolem uvedení 64bit woken, bylo jasné, že MS čeká na uvedení Intel processoru s EMT64. Nedivil bych se, kdyby bylo v nejvyšších kancelářích zamčené něco, co se my nikdy nedozvíme. Firmy musí spolupracovat a oslabení konkurence je sice nefér, ale normální.
Viz třeba NVidia a ULI. Teď je jasné, že NV koupila ULI aby ztížila život ATI ­(a samozřejmě i proto, aby si vylepšila NForce4)

A ty mas kupeny WinXP­(2k3­)64bit? Dost o tom pochybujem. V MS myslia ekonomicky, nema zmysel nahanat vydanie software a starat sa o support­(ktory firmu stoji nemale prostriedky­), pokial pren neexistuje patricna HW zakladna. Pockat na vedsie rozsirenie 64bit CPU je logicky tah, ktoremu sa z ekomnomickeho pokladu sotva da nieco vytknut.

Vyckavat? To se podle mne hluboce mylis.

Logicky tah je delat OS tak, aby si jej byl schopen portovat s co nejmensi namahou na co nejvice platforem ­(minimalne na ty ­"nejpouzivanejsi­").

64bitovy SuSE Linux byl v dobe, kdy jeste AMD64 byla jen marketingova novinka. Myslim ze se tomu rika neco jako vize, ci vyhoda na trhu apod. Vyckava pouze ten, kdo ma prazdne ruce a nema smysl si lhat do kapsy.
PJ

Domnívám se, že poměrně jednoduché bude:

1­) přidat další instrukční dekodér ­(tj. mít čtyři­) ­-> zvýší počet microOPs, dopad bez dalších změn je ale diskutabilní

2­) upravit SSE jednotky na 128bit ­-> zvýší výkon v SSE na úroveň, kde by procesor mohl být konkurenceschopný ­(podle testu Sandra Multimedia Benchmark dosahuje Conroe na stejné frekvenci cca. trojnásobného ­(!­) výkonu v celočíselném SSE oproti stejně taktovanému Athlonu 64 X2­)

3­) Optimalizovat trasování tak, aby nebylo 64bit, ale 128, tj. aby ony 128bit SSE jednotky byly k něčemu.


Co už vidím jako větší problém, je předělání out­-of­-order na více záznamů a na práci s více microOPs za takt. Stejně tak implementace Memory Disambiguation a fúzování určitě nebude tak jednoduchá ­(zejména microOPs fusion­). A konečně úprava pipeline z hlediska počtu Issue Portů a počtu jednotek je dost komplikovaná.

Počet nutných změn mi přijde příliš velký na to, aby to AMD za půl roku stihlo. Nehledě na to, že i v současné části by bylo nutné upravit termální management, protože bez něj by se ­"naboostovaný­" procesor asi upekl. Také by museli upravit pipeline z hlediska počtu stupňů, něco teď evidentně A64 brzdí, když se Conroe se čtrnácti má dostat na 3.33 GHz, zatímco AMD horko těžko dosahuje 3 GHz a teplem to není. Prostě AMD teď naráží na to, že od roku 1999 ­(K7­) neproběhly na jejich architektuře žádné razantní změny v oblasti out­-of­-order zpracování, a tak jim nově vytvořený procesor s mnoha inovacemi a širokým paralelismem může pořádně ­"zatopit­".

Děkuji za odpověď.
Toho jsem se obával. Taky mě zaráží proč už 2 roky tu jsou pořád ty samé A64­-ky.
Děkuji za článek a těšim se, že zapátráte a opět poinformujete co s tím tentokrát AMD hodlá dělat.
Ta firma měla moje sympatie díky Ath­-XP, ale teď nějak trestuhodně zaspali. Odezva burzy asi bude taky rychlá.
Mějte se..

Prečo stagnujú tu 2 roky A64 ??? lebo nemajú už 4 roky konkurenciu od Intelu :­) inak keď v 4­/4 roka 2006 Intel dá na trh Conroe tak uchmatne poslednú 1­/4 2006 AMD zo ziskov a nie celý rok. Na rok 2007 AMD tu stratu prekoná 64nm procakmi a intel keď zase 4 roky bude spať, tak zase sme za tom istom ako teraz s vývojom :­(

Podle nejnovějších zpráv by měl být Conroe uveden již v červenci 2006. Prý to prohlásil sám CEO Intelu.

Parada tak v 6 mesiaci to tu máme už sa teším na testy kto s koho AM2 či Conroe :)

To neni argument.. vývoj musí pokračovat, už jen proto, že ho my zákazníci stále platíme, a vývojáři za něj berou plat!
Podle informací co mám, jsou zisky v Q4 nejvyšší. Intel má toto perfektně naplánováno. Navíc jestli bude mít ještě i část Q3, tak mu v celkovém objemu bude patřit rok 2006. Současné chytré slevy jsou součástí plánu návratu do obecného povědomí zákazníků.

BTW: Nestihnout vánoce stálo už nejeden počítač existenci ­(následnovník Sinclaira =?­).

:­) ešte by som porozmýšľal najlacnejšie Conroe čo som videl v tabulách bude stáť 7000Kč bez DPH takže do zostavy za 20000­-30000Kč s DPH sa nevtesná a ruku na srdce koľko je takých čo investujú viacej ako 40000Kč, takže pochybujem že by po 2Q 2006 predajcom ostávali na sklade AMD­-čka ale na druhej strane ich cena pôjde pekne dole :­)

Najlacnejsie modeli by mohli byt s cenou nizsie­(ale distributori asi zariadia opak­), ale aj tak netreba hned davat do PC 50000SK. Ja budem skladat niekedy v 3­/4 roka pre saba dalsie PC kde budu kladene naroky hlavne na CPU­(DC, virtalizacia je bonus, ktory ja mozno nevyuzijem, ale tych par korun by som uz priplatil, clovek nikdy nevie­), hry na tom nikdy ziadne nebudu­(to usetri velke peniaze za grafiku­) a s takou zostavou by som sa mal zmestit do 30000SK­(zavysi aj od toho aky LCD zvolim­) a urcite nie som jediny kdo potrebuje nehernu zostavu. Teraz pekne pockam ako sa vyfarbia nove CPU v oboch taboroch a potom sa rozhednem podla momentalnej ceny, vykonu a dostupnosti, ale Intel ma u mna male plus za dobre skusenosti s ich cipsetmi­(len tazko im hladat konkurenciu u desktopovich cipsetov pre AMD­) a doskami.

Co se týká té frekvence, tak to bych tipl, že není ani problém architektury, ale spíše toho, že intel je oproti ostatním výrobcům ­"křemíku­" cca o rok až dva napřed. Tzn. kdyby měl intel vyrábět procesory amd, tak by se taky dostal s frekvencí cca o 10­-20% výše, než je teď amd.
Doteď touto obrovskou výhodou jen kompenzoval nedostatky NetBurstu, teď i díky tomu bude mít ohromně navrch.

je to i problem architektury, za kazdy hodinovy cyklus musite spocitat jednu stupen pipeline ­- cim kratsi tyto stupne mate, tim vice muzete procesor taktovat ... amd uz ma celkem dlouho 12 stupnu, netburst zacinal tusim na 25 a koncil kolem 35 ... to znamena ze vypocet operace byl rozdelen na extremne male kroky ­(kratke stupne pipeline­) diky tomu jsou teoreticky uzasne taktovatelne ­(az na 7­-8GHz mozna vic­), ale narazi na teplotni barieru ... amd diky dlouhym stupnum pipeline moc taktovat nemuzete, protoze i sebelepsim vhlazenim budou v procesoru nastavat pocetni chyby, protoze nekde se nestihne neco vcas spocitat, tak se dal pracuje se straou hodnotou a chyba se siri ... kolik a jake stupne ma core nevim

Core má 14 stupňů pipeline. Kde to oproti Pentiu M natáhli, to zatím nebylo zveřejněno.

uvidime jak se intelu povedli udelat kratke ... s prihlednutim k postupu technologii by to mohlo ji tak do 4,5GHz

A to skade vieš že ohromne ma na vrch Intel ??? a k čomu k 286 :D myslím že porovnávaš budúcu platformu Conroe z niečím od AMD :­) zatiaľ testy Conroe robil Intel a v reálu možno bude ohromne výkonný ale ja sa račej nechám prekvapiť a pozriem si test napr. na tejto stránke a pozriem si porovnanie skutočného výrobku Conroe s AM2 a potom za rozhodnem či výkon­/cena Intel či AM2 :­) z tým ohromným výkonom by som porozmýšľal hovory sa o 20%
Intel si na Conroe urobil obrovskú reklamnú kampaň bol by som rád keby aspoň z polovici to bola pravda aj keď som optimista ale rohlíkom sa opiť nedám :­)

V otazce vyrobniho procesu nejsem odobornik, ale nedvano jsem cet, ze SOI ­(AMD­) je lepsi nez strained silicon ­(Intel­) ... tudiz si nejsem tak jisty s tou prevahou Intelu na tomto poli ­(?­).

A toto je IMHO ta hlavní otázka. Jaktože nedošlo k žádné změněn v architektuře procesoru? Opravdu u AMD nic v tomto směru nedělají?
SPEKULACE: co když mezitím vyzkoušeli spoustu novinek, zjistili co funguje a co ne ale protože jejich vyráběný procesor si stále byl schopen dát Intel k obědu a ani se nezakuckat tak nic neuvedli do výroby ­(ono uvedení do výroby stojí docela dost peněz­). Pak by dávalo smysl si počkat na to, co Intel předvede a podle toho upravit nový procesor ­(zvolit tu správnou hranici mezi bude to ďábelsy výkoné oproti bude se to snadno a bez problémů vyrábět a bude to levné­).
KONEC SPEKULACE

Ja nevim jak ty, ale hlavni zisky jdou z mainstreamu nebo snad ne? Kazdej si nemuze dovolit CPU 30000Kc, ale uz cpu za cca 3000­-7000Kc cili tak v prumeru dejme tomu A643000+ nebo adekvatni Intel....

Pokud se naplní předpovědi, pak by nejlevnější Conroe měl stát kolem pěti tisíc s DPH ­- https:­/­/www.svethardware.cz­/art_doc­-17AA16C0BBCD473FC1257144003C97D5.html . To by pro AMD byl značný problém, protože by na ně zbyl jenom low­-end. Zbytek by okupoval Intel.

Dobře uznávám, že jsem to trochu přestřelil, budou tam všechny segmenty, ale Hi­-End jsou nejsnažší zisk, jsem někde četl. Navíc dělají firmě pověst.
Jinak já samozřejmě nechci nijak škodit AMD, konkurence je sakra potřeba. Nicmeně AMD opravdu asi zaspalo. Doufám, že nová FAB má nějaký trumf v rukávu.
Jinak pohled na akcie AMD není dobrý, klesají od března.
Intel je na tom sice ještě hůř, ale Core to může zasadně otočit. Zdá se, že pokryje celý trh.
AMD by to mohlo stát i existenci.

tak existenci asi ne...ale je asi pravde že letos toho amd s am2 moc nepředvede, podle meho to amd opět rozjede s ddr3 pametma nastupem hypertransportu3.0 a 65nm proces někdy příští rok. amd ma pro 65nm pripravene nove technologicke postupy atd. tim se dočkáme vyšší vtěžnosti z 300mm waferů, tím se ještě o malinko zvýší konečná frekvence no a kdyš k tomu vyladěj k dokonalosti stávající k8 architekturu tak takový Athlon FX­-70 na 2x3,5GHz 2x2MB L2 + 3MB L3 cache roznese celý intel na kopytech...:­)podle meho se amd jen tak nedá.

Buduci rok uz Intel bude prechadzat na 45nm tak okrem mozneho zlepsenia parametrov je tu jasna moznost na znizenie vyronych nakladov a teda ak nebude najlepsi moze byt aspon lacnejsi, tak ako to predvadza teraz.

A co ti brani v tom si postavit HTPC s AMD? Samotny porcesor uz toho dneska moc nedela, o hlavni se stara grafika a poradna zvukova karta ­(nebo externi dekoder ­- zesilovac­). Nebo si snad myslis, ze dnesni prumerne AMD64 3000+ nezvladne prehravat filmy a za dva­-tri roky az budes obmenovat je zvladat nebude? Vzdyt dnesni CPU se pri prehravani filmu doslova flakaji, tak na co takovy vykon ­(nehlede na spotrebu, vyzarene teplo atd.­).

vypada to pro ni blede ... coz je celkem skoda, protoze je daleko lepsi nez x86, halvne po architektonicke strance ... inzenyri intelu na ni odvedli spickovou praci ... takze skoda chybejiciho sw

To bohužel není až tak docela pravda. Itanium je jistě zajímavý produkt, má ale jednu vadu, která mu zcela brání v tom, aby byl použit na desktopech. Tou vadou je, že nemá dekódování ­- instrukce jsou přímo posílány do výpočetních jednotek. O konkrétní naplnění jednotek se stará kompilátor při vytváření programu. Pro dosažení optimálního výkonu je tak zapotřebí pokaždé pro nové jádro program překompilovat ­(proto Intel od dob původního 1 GHz Itania II skoro nic nezměnil, jen přidal cache­). To v desktopech nelze realizovat, neboť většina kódu není ­(z pochopitelných důvodů­) distribuována formou zdrojáků a navíc co by na to řekli typičtí uživatelé, kteří jen chtějí něco zapnout a jinak se o to nestarat? Itanium by bylo možná dobré pro Linuxovou komunitu, ale pro Windows určitě ne. Navíc by znemožňovalo konkurenci, protože oba výrobci by museli dělat totéž.

Mimochodem, tak jak Itanium stojí a běží dnes, je vhodné pro náročné vědecké či serverové aplikace s velkým paralelismem. Typický desktopový program ale chce úplně něco jiného ­- rychlé sekvenční vykonávání. Paralelismus je u desktopu jakousi formou luxusu, která zvyšuje výkon.

mluvil jsem o tom, ze ma dobry navrh, ne o tom, ze je dobre zpetne kompatibilni ... nebylo by potreba psal kompilator znovu pro kazde Itanium, protoze v ramci IA64 by byly procesory kompatibilni ... zde bych rad pripomenul, ze prave jazyky, ktere jsou distribuovany formou byte­-code tento problem resi ­(napr. Java, protoze se vzdy kompiluji az na cilove plaforme a daji se dokonce optimalizovat pro velikost bloku cache apod­)

add nema dekodovani instrukce: jedna se o RISC procesor takze je logicke, ze ji nema ­(pokud tim myslite prevod komplexni instrukce na microOPs, coz je fakticky CISC na RISC­)

dalsi co procesoru chybi a je to dobre, protoze to zkracuje pipeline, snizuje spotrebu a zjednodusuje jadro, je out­-of­-order execution a pozastavovani pipeline pri datovych zavislostech ­(pocita se s tim, ze tohle by mel udelat kompilator a strojovy kod by mel byt uz takto osetreny­) ... je logictejsi instrukce preusporadat jednou pri kompilaci, nez to delat pokazde na tomtez miste v kodu primo v procesoru

dalsi skvele vlastnosti ­- VLIW ­(paralelismus­) a podminene instrukce ­(brutalne zrychluje kratke if statementy)

Nevím, jestli jsem se dobře vyjádřil. Intel vyvíjí Itanium II už od jeho uvedení tuším v roce 2000 pouze tak, že mu přidává cache. Tím totiž brání potřebě kód překompilovat. Mezi Itaniem I a Itaniem II je velký rozdíl v počtu výpočetních jednotek. Pokud dáte Itaniu II kód vytvořený pro Itanium I, výkon nebude optimální. Samotné překompilování na nový model pomocí nového Intel Compileru přineslo tehdy nějakých 5 až 10 % výkonu navíc ­"zdarma­". Z tohoto důvodu je zcela nezbytné pro každé Itanium mít vlastní kompilátor, který zohlední jeho výpočetní možnosti. Pokud kód nebude překompilován, spousta jednotek zůstane ležet ladem. Z tohoto pohledu se jeví x86 jako vhodnější architektura pro desktop, neboť ono sypání příkazů do výpočetních jednotek je čistě věcí hardware, který je pochopitelně optimalizován pro každou architekturu jinak, a tak dochází k vyššímu využití. I kdyby všechny programy byly dodávány se zdrojákem, ona kompilace pro Itanium je dost časově náročná, protože musí zohlednit závislosti, prefetch atd., tedy všechno to, co v x86 dělá ­(byť potenciálně s nižší efektivností­) specializovaný hardware.

Itanium je VLIW ­(very long instruction word­) procesor. Nazývat ho RISC je IMHO poměrně nešťastné, protože typické RISCové procesory fungují trochu jinak.

souhlas ... ono by bylo optimalni mit i u 386 na kazdy procesor zvlast kompilator ­(napr. na amd64 urcite aby se vyuzilo­) ... prave proto je zde dobre reseni distribude byte­-code ­(jen pripomenu ze posledni JavaVM uz jednou zkompilovane class uklada ve zkompilovane podobe a nemusi je pri kazdem spusteni kompilovat znovu ­- coz diky tomu, ze si muzete v Jave napsat vlastni ClassLoader bylo mozne uz davno, ale ted je to primo v dodavce­) ... ano kompilace pro itanium je pomerne narocna, protoze dela vse co by procesor delal v realnem case, coz je ale z hlediska architektury dobre
add zlepsovani: ono na itaniu neni moc co zlepsovat, protoze novejsi design zatim neni znamy a cache ­(resp. jeji latence­) byla tim co itanium brutalbe brzdila
add VLIW: ok beru ... ale VLIW je jen v podstate nekolik RISC instrukci velde sebe, takze se jen rozdeli napr. po 64bitech, ale dekodovat se stejne nemusi

btw: hodne zajimavy je i posledni UltraSPARC od Sunu, ktery je open source, ma podobne technologie a ma pri osmi jadrech spotrebu 72Watt a pritom kazde jadro dokaze plnohodnotne zpracovavat 4 vlakna ­- coz je 32 vlaken na procesor

UltraSPARC a Itanium jsou procesory, které jsou optimalizovány pro multithreaded silně paralelizované použití. Troufám si tvrdit, že kdyby se typický program pro PCčka překompiloval pro Itanium, jeho výkon bude ve srovnání s Conroe ubohý ­- většina programů by prostě nedokázala šest ALU využít. A s multithreaded programy to nevypadá o nic lépe. Sice teď dual­-core získávají na popularitě, z hlediska software se ale stále nic moc nezměnilo, a přínos dual­-core je tak stále spíše u specializovaných programů a multitaskingu než v obecném zvýšení výkonu. Snad na tom něco změní Speculative precomputation.

mate pravdu vetsina her multithread nedokaze vubec vyuzit, tam by to bylo hodne slabe ­(na druhou stranu bych se nebal vyuziti vsech alu­) ... nicmene uz jsou nove hry, ktere budou schopny vlakna vyuzivat a spustenych aplikaci je na jednom pocitaci samozrejme vice ­(kazda minimalne 1­) ... server je samozrejme uplne jina zalezitost, kde treba pro kazde prichozi spojeni udrzujete jedno vlakno ... v takovych situacich je narust vykonu vice nez citelny a podpora vice vlaken je dokonce velka vyhoda, protoze je nemusite tak casto prepinat
do budoucna je multitread urcite dobra volba, ja jako programator v jave vyuzivam mnoho vlaken uz davno a to o tom ani nemusim vedet ­- garbage collector, gui se renderuje ve zvlastnich vlaknech, udalosti se zpracovavaji ve zvlastnich vlaknech, ...

Nejsem si stopro jistý ale někde jsem četl že hlavní autory Itánia přetáhlo AMD k sobě.

V poslední době se to stává extrémně často :­-­(. Průběžně sleduji hodnocení článků a jasně z toho vychází, že třeba jeden dva lidé dají pětku, zatímco všichni ostatní jedničku. Nevím, zda jsou to omyly nebo chce někdo škodit, každopádně navrhnu nějaké zlepšení hodnotícího systému ­(například barevné odlišení­).

Tak už přibyla další pětka :­-­( . Aktuální skóre je ­(27x 1 + 2x 5­) ­/ ­(27 + 2­) = 1,28. Škoda, zbytečně to snižuje hodnocení.

Tak zaveďte ­(teď nevím jak se této technice říká­) to, že do výpočtu celkového hodnocení nezahrnete X nejlepších a X nejhorších výsledků.
Např. 1% nejelpších a 1% nejhorších výsledků dává, že při 100 hodnoceních by se do výpočtu nedostala jedna nejlepěí a jedna nejhorší známka.
Pokud by to byly např. 4%, pak se na každých 25 hlasů smaže jedna nejlepší a jedna nejhorší známka a vyšlo by Vám hodnocení ­(­(27­-1­)x1 + ­(2­-1­)x5­)­/­(­(27­-1­) + ­(2­-1­)­) tj 1,15 .
Naopak pokud by někdo dostával horší známky, tak by mu to průměr zhoršilo.
Taková hranice 4% nebo 5% ­(na každých 20 hodnocení jedna nejlepší a jedna nejhorší pryč­) je myslím ideální.
Myslím, že toto je celkem elegantní a hojně využívaný způsob.

kdepak ... graficke karty jsou prakticky vektorove pocitace ... jde o to, ze gpu si nacte primo z gram velke mnozstvi dat ­(traba texturu­) a provede na vsech jejich prvcich ­(pixelech­) absolutne stejnou operaci ­- u programovatelnych shaderu uz libovolnou operaci ­(napr. pripocteni osvetleni ke kazdemu pixelu­) ... da se to popsat takhle:
instrukce gpu: nacti pixel 0 ­- 1024, proved na vsech pricteni svetla, uloz pixely 0 ­- 1024 ... navic cele tohle probiha najednou v pipeline, takze nektere pixely jsou na ceste z pameti a vypoctene uz vali zpet
instrukce cpu: nacti pixel 0, proved pricteni svetla, uloz pixel 0, nacti pixel 1, proved pricteni svetla, uloz pixel 1, nacti pixel 2, ... presto ze i operace v cpu probihaji paralelne, tak vyzaduji ohromne mnozstvi instrukci, nemluve o tom, ze po kazdem pixelu testuje procesor, jestli uz ten aktualni pixel neni posledni, coz si bere dalsi vykon

Takhle to vubec neni.
O nejake nacitani a ukladani pixelu se programator shaderu vubec nestara. Shader je vlastne jednoduchy program v assemleru, pracujici se 4­-slozkovymi vektory a bere v uvahu pouze jeden konkretni pixel, na kterem je spusten. Tento program je automaticky spustem na kazdem zpracovavanem pixelu.
A instrukce ­"pricti svetlo­" je taky zajimava :­). Tak slozite instrukce GPU nema. Ty jsou podobne jako v CPU, ale trochu modernejsi ­(spis jako RISC­) a trochu vice graficky orientovane ­(skalarni soucin­).

ano programator se o nacteni pixelu nestara, ale gpu ano ... ten to udela presne jak jsem psal ­(nacte ohromne mnozstvi pixelu­/vertexu­/textelu a posle ho do shaderu­) ... funkce pricteni svetla uz je dnes realizovatelna prave diky pixel shaderum ­(dokonce se tak pocitaji stiny ­- jeste s pomoci cube map a podobne­) ... jinak prave vlastnost nacitani pixelu v rade s nulovou latenci ­(po prvnim pixelu­) je nejpodstatnejsi vlastnosti gpu

jeste dodam, ze se jedna o MIMD architecturu ­- Multiple Instruction Multiple Data ­- tj vice instrukci na vice datech ... znamena to ze na kazdem jednom v pixelu z te rady nactenych ­(multiple data­) se spusti prave programatorem napsany shader ­(multiple instruction)

MIMD architektura byla pouze Gefoce FX a to jeste jen castecne ­(jen uvnitr pixel shaderu­). Pixely pro shadery vznikaji v rasterizatoru ­(tedy v prostredni casti pipeline GPU­) a je jich presne tolik, kolik je pixel pipelines ­(teda treba 24 pro GF7800­/7900­).
Nacitani pixelu z pameti se deje jen na konci pipeline pro alpha­-blending a z­/stencil a tato cast neni programovatelna a vykonavaji ji ROPs jednotky, kterych je stejne nebo mene, nez pixel­-pipelines ­(u GF7800­/79000 je jich 16­).

Nechtěl by někdo z vás, kdo tomu rozumíte, napsat článek na téma jak funguje moderní GPU? Ale detailně, aby bylo řečeno, jak do čipu přichází kód a data, jaké jednotky provádí které operace, jaké jsou tam výhody­/nevýhody, možné problémy atd. Něco takového bychom určitě ocenili a bylo by to velmi zajímavé.

muzu ... mam za sebou predmet architektury pocitacovych systemu a tam se to detailne probira ... bohuzel casu neni mnoho, takze snad ma kolega zajem

Zmíním se šéfredaktorovi, aby vás kontaktoval na vašich emailových adresách.

OMG. Vy chcete udelat kozla zahradnikem ?!?! :)

Wessan: nechci podceňovat tvoje znalosti, ale dokážeš jasně popsat funkci i moderních Radeonů ze série X1000? , která je stará několik měsíců? Popsat technologie jako FAST14 apod.?
Osobně za člověka, který se opravdu vyzná v grafických kartách, považuji pana Jiřího Součka. I když od něj najdete články především v hlavním konkurenčním magazínu, již nějaký ten měsíc nic nenapsal a to je škoda. Nebál bych se tvrdit, že od tohoto člověka by byl článek „jak funguje moderní GPU“ opravdu tím, co by měl být. Znalosti autora si lze ověřit taktéž na některých fórech…
Jsem dosti skeptický co se týká jiných lidí, nechci ale nikoho předem odsuzovat. Cituji Eagla: „Dokumentace grafických karet je dost ubohá ­(resp. není veřejná­). Mimochodem, to je také důvod, proč vám žádný z redaktorů není schopen říct, jak grafická karta funguje“.
Tak jsem řekl, to co jsem potřeboval, pan Souček, jestli tohle čte, by mohl zvážit něco takovéto napsat ­(stejně tomu sám nevěřím, ale zkusil jsem to?­)

K tomuto článku: dobrá práce, dal bych Vám jedničku, ale nejsem registrovaný a kvůli tomu se registrovat…

technologie fast14 umoznuje jen beh na vysokych frekvencich nemyslim, ze ma vliv na to jak principielne funguji shadery a vubec cely proces, ktery probiha na grafickych kartach

na graficke karty se jde divat mnoha zpusoby, od jednoducheho vysvetleni principu ­(ktere jsou verejne zname­), pres nejaky podrobnejsi popis jednotlivych jednotek ­(ktery je taky relativne znamy­), popis usporadani pameti, ktera je dulezitou soucasti graficke karty ­(taky zname­), optimalizacni techniky ­(komprese textur, efektivni cliping, komprese z­-bufferu­), vyuziti gfx pro negraficke ucely ... ale kdyby mel nekdo popsat jak presne tohle ma nvidia nebo ati implementovane, tak bude informace hledat horko tezko, protoze je to obchodni tajemstvi ... pana Jiriho Soucka neznam, ale jestli je to nejaky expert na problematiku, tak to muze byt idealni clovek na takovy clanek

pokud muzu doporucit, tak je lepsi materialy o grafickych kartach hledat spise u nvidie, nez u ati, protoze ati sice dokaze udelat rychle cipy, ale co se tyce nejakych sluzeb pro vyvojare­/ovladacu­/nastroju byla na tom velmi bidne co si pamatuju ­(uz delsi dobou v c++ nepracuji­)

MIMD ­- ano je uvnitr shaderu ­(sekvence jednoduchych instrukci­), ale kde jinde byste ji chtel mit?
ano ... pixely pro pixel shader vznikaji v rasterizatoru ­(dojde textura ve streamu, vypadne stream pixelu ktere se predaji pixel shaderum­), dulezite je ze vsechny tyhle operace jedou streamovane za sebou
ale porad za vas gpu krmi pixel shader streamem pixelu a predava vypadla data dal
uprimne: nevim jestli si nerozumime, ale opravdu jsem nepochopil, na co jste narazel, jestli na to ze jsem do detailu nepopsal cely proces ­(snazil jsem se to maximalne zjednodusit­), nebo jestli je tam nejaka chyba

Vsechny soucasne GPU maji SIMD shadery. Presneji ~8­-48 nezavislych 4­-slozkovych SIMD procesoru. Kazdy procesor je vicemene ­(vice ATI, mene Nvidia­), nezavisly a obsahuje scitacku, nasobicku, invertovacku­/odmocninu a nejakou ROM pro LUT.
V rasterizatoru se rozhodne s texturami nepracuje, natoz ve streamu. Rasterizator jen urcuje, ktere pixely patri do trojuhelniku a ty potom putuji do shaderu. Textura se vzorkuje primo z shaderu a adresa vzorku nemusi byt predem znama ­(takze zadne streamy­).
Jinak, presne vnitrni fungovani grafickych cipu je velmi casto patentovano. A jak je znamo, patenty jsou verejne. Staci jen nahlednout... :)

neco mi rika ze vsechny pixely ­(na texturovanem trojuhelniku­) jsou soucasti textury => pracuje se s texturami
ad nepracuje se ve streamu: vy si vazne myslite, ze si gui posila do pameti zadosti o jednotlive pixely? vite co by to bylo za pocet pametovych operaci? a jake by se nasbiraly latence, nez by se vykreslila 2048x2048 textura? ... ona se vytvori v rasterizatoru maska jejiz logickym soucinem se velmi rychle zjisti adresy potrebnych pixelu a gather se postara, aby dorazili ve streamu s minimalni latenci do shaderu

Textury jsou samozrejme v cache.

V dobach Voodoo 1 platilo, ze trojuhelnik byl pokryt predem znamou texturou. Rasterizator ted somozrejme vubec nevi, jakym zpusobem se bude vzorkovat a jestli vubec. Souradnice textury jsou vypocitavany v shaderech a az instrukce TEX ­(v ruznych variantach­) dela filtrovany a perspektivne korigovany look­-up do textury. Tech textur muze byt az 16­/trojuhelnik.

Popsana metoda se nazyva dependent­-read a poprve byla zavedena v GeForce3. Bez dependent­-read by to dneska opravdu neslo.

Zakladni princip neni vykreslovani textury, ale pixelu a pro pixely se pak dela look­-up do textur ­(a ne naopak­) !!!!!!

BTW: Ja si nemyslim, ja vim :)

Jen jsem chtel jeste dodat, ze textury uz davno neslouzi jen jako obrazek pokryvajici polygon, ale spis jako look­-up tabulky pro ruzne komplexni vypocty.

S timto nelze souhlasit, shadery nejsou architekturou MIMD protoze instrukce se provadi regularne ­(sekvencne­). MIMD je z technickeho hlediska obtizne proveditelna, pokud existuje pak jde vetsinou o pseudo MIMD, coz neni noic jineho nez sekvencni SIMD ­- viz napr. instrukce MAD.

jj souhlasim ... je to jen o tom, jak se procesor jevi navenek ... cela ­"mimd­" operace se provede jako sekvence prikazu vertex­/fragment programu ... je otazka co je skutecna mimd operace, protoze i CISC instukce se ve finale rozlozi na jednotlive RISC instrukce, ktere se vykonaji sekvencne ­(jinak to lide zatim neumi­) a pokud se CISC provede najednou, tak je to zase jen jedna instrukce ... takze z tohoto hlediska MIMD neexistuje ... za MIMD se tedy obecne povazuje, kdyz sekvence vypocetnich jednotek provede postupne nejake operace na streamu dat ... tak to chapu ja, kdyztak me opravte

Blahopreji Eaglovi, je to fakt machr