Vyznam dual core

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

[swarm]

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

No, jenom tak pro info sem něco málo přispěju - spíš ale tak pro zajímavost. V jedné hře na které jsem spolupracoval jsem teď vytáhl ze zdrojáků kousky shader kódu. Protože tenkrát byly běžné shader 1.x karty (Radeon8500,9000-9200, GF3Ti, GF4Ti, GF4MX) a shadery tehda nebyly ještě standardizované, tak se muselo dělat víc codepath. Schválně se můžete kouknout na rozdíl zápisu pro karty nvidia a ati. Jako první kousek je už standardizovaný kód Pixel Shaderu 2.0. Tohle je low level možnost programování. Krom toho lze Shadery 2.0 (a vyšší programovat) i ve vyšším jazyce (hlsl, cg), kdy se pak překompilovávaj. To už by se tak trochu dalo přirovnat k tomu Cčku. Ale jako stále to ještě neni ono na univerzální vecičky, toho se vážně dosáhne až u přicházející generace karet jako je G80, přesně jak je to uvedené v tom článku, že tam bude extra driver, který bude schopen nechat kartu provádět Cčkový kód.

----- arb ps 2.0 -----

        const char diffuse_prg_asm[] =
            "!!ARBfp1.0\n"

            "TEMP tex, col;"
            "ATTRIB texcoord = fragment.texcoord;"
            "ATTRIB primcol = fragment.color.primary;"
            "PARAM light_col = program.local[0];"
            "PARAM consts = {2, -1, 0, 0};"
            "OUTPUT outcol = result.color;"

            "TEX tex, texcoord, texture, 2D;"
            "MAD tex, tex, consts.x, consts.y;"
            "MAD col, primcol, consts.x, consts.y;"

            "DP3 col.a, tex, col;"
            "MUL tex, light_col, primcol.a;"
            "MUL outcol, tex, col.a;"

            "END";
        glGenProgramsARB(1, &diffuse_prg);
        glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, diffuse_prg);
        glProgramStringARB(GL_FRAGMENT_PROGRAM_ARB, GL_PROGRAM_FORMAT_ASCII_ARB,
            strlen(diffuse_prg_asm), diffuse_prg_asm);

----- ati ps 1.x -----

        diffuse_prg = glGenFragmentShadersATI(1);
        glBindFragmentShaderATI(diffuse_prg);
        glBeginFragmentShaderATI();
        // Pass #1:
        glSampleMapATI(GL_REG_0_ATI, GL_TEXTURE0_ARB, GL_SWIZZLE_STR_ATI);  // color in the texture
        // reg0 = L.H
        glColorFragmentOp2ATI(GL_DOT3_ATI, GL_REG_0_ATI, GL_NONE, GL_SATURATE_BIT_ATI,
                                           GL_REG_0_ATI, GL_NONE, GL_BIAS_BIT_ATI | GL_2X_BIT_ATI,
                                           GL_PRIMARY_COLOR_ARB, GL_NONE, GL_BIAS_BIT_ATI | GL_2X_BIT_ATI);
        // reg0 = reg0 * con0 = (L.H) * light_color
        glColorFragmentOp2ATI(GL_MUL_ATI, GL_REG_0_ATI, GL_NONE, GL_NONE,
                                          GL_REG_0_ATI, GL_NONE, GL_NONE,
                                          GL_CON_0_ATI, GL_NONE, GL_NONE);
        // reg0 = reg0 * primary_color.alpha = (L.H) * light_color * intensity
        glColorFragmentOp2ATI(GL_MUL_ATI, GL_REG_0_ATI, GL_NONE, GL_NONE,
                                          GL_REG_0_ATI, GL_NONE, GL_NONE,
                                          GL_PRIMARY_COLOR_ARB, GL_ALPHA, GL_NONE);
        glEndFragmentShaderATI();

------ nv ps 1.x ------

       //setup the register combiners to use 1 general combiner (max. 2 on GF 4 MX)
       glCombinerParameteriNV(GL_NUM_GENERAL_COMBINERS_NV, 1);
       //setup the combiner 1
       glCombinerInputNV(GL_COMBINER0_NV, GL_RGB, GL_VARIABLE_A_NV,
       GL_TEXTURE0_ARB, GL_EXPAND_NORMAL_NV, GL_RGB);
       glCombinerInputNV(GL_COMBINER0_NV, GL_RGB, GL_VARIABLE_B_NV,
              GL_PRIMARY_COLOR_NV, GL_EXPAND_NORMAL_NV, GL_RGB);
       glCombinerInputNV(GL_COMBINER0_NV, GL_RGB, GL_VARIABLE_C_NV,
              GL_CONSTANT_COLOR0_NV, GL_UNSIGNED_IDENTITY_NV, GL_RGB);
       glCombinerInputNV(GL_COMBINER0_NV, GL_RGB, GL_VARIABLE_D_NV,
              GL_PRIMARY_COLOR_NV, GL_UNSIGNED_IDENTITY_NV, GL_ALPHA);
       glCombinerOutputNV(GL_COMBINER0_NV, GL_RGB, GL_SPARE0_NV, GL_SPARE1_NV,
              GL_DISCARD_NV, GL_NONE, GL_NONE, GL_TRUE, GL_FALSE, GL_FALSE);
       //setup the final combiner
       glFinalCombinerInputNV(GL_VARIABLE_A_NV,
              GL_SPARE0_NV, GL_UNSIGNED_IDENTITY_NV, GL_RGB);
       glFinalCombinerInputNV(GL_VARIABLE_B_NV,
              GL_SPARE1_NV, GL_UNSIGNED_IDENTITY_NV, GL_RGB);
       glFinalCombinerInputNV(GL_VARIABLE_C_NV,
              GL_ZERO, GL_UNSIGNED_IDENTITY_NV, GL_RGB);
       glFinalCombinerInputNV(GL_VARIABLE_D_NV,
              GL_ZERO, GL_UNSIGNED_IDENTITY_NV, GL_RGB);
       glFinalCombinerInputNV(GL_VARIABLE_G_NV,
              GL_PRIMARY_COLOR_NV, GL_UNSIGNED_IDENTITY_NV, GL_ALPHA);
       glEnable(GL_REGISTER_COMBINERS_NV);

Jinak ten kód je na výpočet difuzní barvy u perpixel (dot3) osvětlení (třeba jako má Doom3 a kdejaká dnešní hra). Výpočet spekulární barvy jsem vyhodil, aby to nebylo zbytečně dlouhé. Tohle je spíš pro rozšíření obzorů.

Petrik: Ty tvoje poslední posty jsou přesně to o čem jsem mluvil.

[Airwolf]

dalsi priklad vyuziti Dual Core> WinXP && Gentoo

[Fox!MURDER]

dalsi priklad vyuziti Dual Core> WinXP && Gentoo

aaa, ze by Xen?

[Airwolf]

aaa, ze by Xen?

ten jeste neni tak stable myslim ?

Kazdopadne> Gentoo+XGL+Beryl nyni (AIGLX nefungovalo zatim)...jedine co me stve ze ATI jeste nema ovladace pro 3D HW akceleraci v XGL Nvidia je bez problemu...

[svaca]

ten jeste neni tak stable myslim ?

Kazdopadne> Gentoo+XGL+Beryl nyni (AIGLX nefungovalo zatim)...jedine co me stve ze ATI jeste nema ovladace pro 3D HW akceleraci v XGL Nvidia je bez problemu...

Ati nebude mit nikdy asi ovladace pro linux ....
1. nikdy neumela ovladace
2. a uz vubec ne pro linux ...

BTW, k threadu ...

Musim priznat, ze na blbem desktopu s WinXP (hry) mi pripada dual nanic ...

Ovsem treba posledni kernely se SMP a 2x Dual core, treba, to je jina kava ...

Staci jen instalace Slackware se zaplym a vyplym SMP (balicky jsou i486) a je to BRUTALNI rozdil ..... Jen kdyby to DVD cetlo rychleji ...

Ovsem ve hnus Windows je mi dual nanic .... Ale tam je mi to taky uplne ukradeny ....

[DOC_ZENITH]

No vezměme si prostě ten základní fakt, dualcore tu neni pro to aby zvyšovalo výkon v aplikacích, nebo znamenalo ňákej pokrok, je tu proto, že výrobci CPU již nejsou schopni adekvátně zvyšovat výkon v single thread. Dualko si člověk mohl postavit od dob Pentia PRO když to potřeboval a mohl to využít. A dual CPU stroj je úplně to samý jak dualcore, kor když komunikujou přes FSB (pravda, K8 je v tomhle trochu vymakanější, taky je to nej serverovej CPU.) A nikdo o to neměl zájem, leda na servery, já jsem si jeden dual postavil už před pár lety, byla to Dual Pentium 2 350 @ 412 a tehdy jsem ještě neměl moc zkušeností a byl jsem z toho nešťastnej, protože jakákovil stejně taktovaná single P2 mi naprosto ve všem co jsem používal podávala stejnej výkon, hlavně v hrách mě to štvalo, tak jsem se toho zbavil. A ony se ty aplikace moc nezměnily, pokud někdo programátory donutí aby psali pro dualcore, bude to jedině ze zoufalství před naprostym zastavenim rozvoje v oblasti CPU.

Jen si to vezměte, jak výrobci už nedovedou zvyšovat frekvenci CPU, koukejte jak šly výrobní procesy za posledních pár let: udáváno v micronech. A frekvenci udávám takovou kam to šlo za naprosto běžnejch podmínek s asi nejlepšim CPU tý technologie a za zavináčem kam asi tak šel taktnout, čili strop tý technologie. Berte to prosim vše jen přinližně, ne úplně doslova.

0.25- Pentium3 Katmai - až 600mhz oficiál @ 700mhz max.

0.18- Athlon XP2100+ Palomio real 1.73ghz @ někam pod 2ghz. Pokud počátám Netburst tak Willamate 2ghz oficiál, dobré kousky oc kolem 2.4ghz.

0.13- AthlonFX 55 clawhammer - 2.6ghz @ 2.8ghz. / Intel P4 Northwood 3.4ghz @ 3.8ghz.

0.09- Athlon FX 57 san diego - 2.8ghz @ 3ghz. / Intel P4 Prescott 3.8ghz @ (upřímě 0, spusta z nich throtlovala i na defaultu s normánim chladičem)

0.065- Zaim jen Intel Conroe 2.93ghz @ 3.8ghz.(Netburst už nezahrnuju) A u AMD se dá předpokládat že nová K8 nebude frekvenčně moc nad tou současnou, AMD tvrdí že hlavní problém současnejch K8 v dosažení vysokejch frekvencí je neoddělené napájení paměťového řadiče a jádra, což se u budoucích socketů změní a K8 půjde prej vejš, a taky nevíme co přinese K8L, no to jsem odbočil.

Čili k čemu jsme došli? Že největší pokrok byl zatim na 0.18micron, od tý doby se to zpomaluje ten pokrok, na 0.13 to bylo ještě skvělý, byl to asi vrchol pro oba výrobce CPU. Ale 0.09 už byla katastrofa. U Intelu jeho prescott naprostá pohroma, stejný frekvence, na stejnejch taktech o chlup horší výkon, díky pomalý L2 cache a ještě k tomu větší zahřejvání a spotřeba. Intel na 0.09 přešel jen s tim, že procesory vyráběné 0.09micron jsou prostě na výrobu znatelně levnější než 0.13 a tak Intel víc vydělal i když ty CPU byly shity.
Ačkoliv v době nástup Prescotta se na něj nadávalo a po nástupu Winschestera u AMD říkalo, jak to AMD zvládlo líp ten přechod, ono to neni tak docela. Ano, AMD to zvládlo líp, jejich CPU na tý samý frekvenci mnohem míň žraly a topily než jejich starší modely, ale to bylo asi tak vše, žádný orgie ve zvyšování taktů se nekonaly, K8 zůstala frtekvenčně prakticky na místě. 2.4ghz Athlon 64 3500+ měl furt 2.4ghz ať už tam byl Newcastle nebo Vencie, akorát Newcastle se dostal průměrně na 2.6ghz po OC a Venice na 2.8, hmm 200mhz, to je zanedbatelné. 0.065micron neni taky niak revoluční, a budoucnost v tom zmenšování výrobního procesu moc neni, intel s tim dělá hype, jakej proces už testuje a AMD vyrábí furt 0.9 ale realita je taková, že tim Intel už moc nezíská, leda číslo a statistiku a možná trochu nižší spotřebu když mu to vyjde, jo a možná levnější produkci. K dalšímu pokroku dojde až se CPU začnou vyrábět úplně jinak, ale kdo ví.

A ještě bych chtěl dodat pro zastánce Dualcore pár věcí, na který se tu podle mě pozapomíná. Mam na vás otázku - využíváte ty 2 jádra naplno najednou opravdu? nebo máte jen dobrej pocit z benchmarků? Je to sice hezký, že si pustíte 2cpumarky najednou s prakticky nulovim zpomalenim výsledků. ale podívejte se na to v praxi, mluvim z dob kdy já jsem měl ten dual. Abych to ňák využil, musel jsem přemejšlet co vůbec mam udělat, začal jsem teda komprimovat nebo kódovat na pozadí video a mezitim si pustit ňákou gamesu. Rychle mě to ale vyvedlo z omylu že tohle půjde. Nejen že tamten program zatížil řadič paměti a snížil drasticky prostupnost do RAM, čili mi FPS šly o 20% dolů, no faj, furt lepší jak 80% při single. To bych překousnul ještě, ale práce disku atd, ta taky byla trochu cejtit (ano, DMA pracovalo dobře), jakmile si hra potřebovala na něco sáhnout na disk bylo to na tejden protože ho už zatěřoval tamten program. Ale vůbec největší problém byl s kapacitou RAM. Ono spousta programů ve win má tu vlastnost prostě zabrat celou volnou ram, přičemž když něco běží na pozadí, narvou to třeba do swapu, jen aby měly co nejvíc ram pro sebe. Ale tohle byla ta katastrofa, protože ta hra hned vycucla ram pro sebe a začala cpát přitom tamten program do swapu, ten ale byl aktivní tak ho win zase tahaly do ram prostě systém byl na to hraní nepoužitelnej, protože jakmile jste se třeba dívali na jednu zeď , win vám mezitim něco hodily do swapu a když jste se otočily tak sek na 2 sekundy než se to načetlo zpátky a takhle to bylo furt. Řekl jsm si fajn, mam na to málo ram, dokoupil jsem 2x takovou, ale to samý, jen to trvalo dýl než ta hra zabrala tu ram zas celou, prtože neunloadovala ty textury z minulejch levelů třeba. Takže jediný pozitivum jsem v celym dualku našel to, že systém měl svižnější odezvy a byl dobrej v renderingu a když měl dělat 2 složitý matematický operace najednou s nízkou náročností (nebo penvně stanovenou) na kapacitu paměti ale v praxi mi to bylo úplně k prdu. A pořád platí že většina lidí co maj třeba přetočený Core2 duo si libujou dobrym výkonem, ale to cejtěj ten dobrej výkon toho jednoho jádra, tý architekury toho CPU, ten výkon tam neni díky tomu dualcore, zkuste si třeba vyřadit jedno jádro tim že ve win odstavíte podporu pro SMP a dost možná rozdíl téměř nepoznáte.

[Over]

Seznam několika her s podporou dual-core cpu....
http://forumz.tomshardware.com/games...pict94969.html

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

[Eagle]

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.

Zdá se, že nejenom že máš deficit inteligence, ale taky jsi lhář.

Eagle, timto jsi definitivne dokazal, ze jsi fakt ignorant.

http://www.zive.cz/h/Uzivatel/f.asp?ARI=131175

Domnívám se, že tvoje existence na tomto fóru by měla co nejdřív skončit.

[Petrik]

Mluvil jsem o projevu tady na foru...nerekl jsem ze nikde nikdy..ale koukam, ze z toho postu na zive asi nemuzes spat, kdyz uz ho tady na foru citujes asi po paty Mozna to je tim, ze na tom zive se mnou hodne lidi souhlasilo Kontrolujes jejich IP, zda neni nekdo z nich nahodou i tady?
Ja se divim, ze me nekdo uz davno nezakazal, vzdyt to je prece rouhani, nesouhlasit s bozskym Eaglem...ale budes se divit, ale dostavam nejenom spatnou karmu, dokonce me i nekteri proti tobe fandi, nechces zakazat i je?
Ale koukam, ze ti zrejmne dochazeji argumenty...

Zdá se, že nejenom že máš deficit inteligence, ale taky jsi lhář.

http://www.zive.cz/h/Uzivatel/f.asp?ARI=131175

Domnívám se, že tvoje existence na tomto fóru by měla co nejdřív skončit.

[SajmoN]

nechceli by ste si toto riesit sukromne?