Názory k článku
Grafické karty a grafické akcelerátory (22)

Cg v nekterych profilech samozrejme podporuje celociselny datovy typ (int),pro pouziti nekterych vymozenosti modernich shaderu,jako je treba indexovani registru,je to nezbytnost.

Ano máte pravdu, ale obecně to použitelné není . Teď si ale nejsem jistý, jestli je možné pomocí intů vytvářet i vektory a matice (a provádět potom operace typu skalární a vektorový součin).

vzhledem k velkemu spektru profilu,ktere Cg podporuje,je obecne pouzitelna jen velmi uzka skupina veci.
operace,o nichz pisete,zrejme lze s inty uskutecnit,rozhodne se ale nebudou provadet jako SIMD.
to uz ale vice postradam bitove operace nad inty..

To je pravda, bitové operace by se hodily. Já jsem se o těch operacích s maticemi a vektory zmínil kvůli "ortogonalitě" jazyka, tj. když jde nějaká operace provést s jedním datovým typem, měla by jít provést i s typem jiným (pokud to samozřejmě alespoň trošku dává smysl). Teoreticky by mohlo být rychlejší zpracovávat dejme tomu barvy texelů ve vektoru integerů (int4) než floatů (float4), ale ne na dnešních GPU, kde je většina operací v HW podporována na floatech (tedy ne nutně na plném počtu bitů, ale to už jsou speciality).

Jo, už jsem to v nové specifikaci našel: The int type is preferably 32-bit two’s complement. Profiles may optionally treat int as float. Pořád jsem měl zafixované, že GPU integery neumí, ale jak je vidět, časy se mění.

Zajimave,
jen takovy lama dotaz,
o kolik je treba takove nasobeni matic v GPU rychlejsi nez na CPU? Melo by smysl/jde li to vubec nacpat do GPU naky data, nechat je projet programem shaderu a precist zas naspatek? Ze by se to mohlo hodit treba i na neco jineho jak grafiku a pokud by to mohlo bezet autonome bez zasahu CPU. A bylo by mozne pritom normalne pouzivat 2D jadro na vykreslovani GUI zatim co by 3D cast pocitala?

No v případě, že by se na GPU nacpalo málo dat a po výpočtech by se zase musely hned vrátit zpět by se výpočet moc neurychlil - spíš naopak, protože by se mosela připočíst komunikace po sběrnici a po portu. Pokud je však těch dat hodně a pracuje se s nimi iterativním způsobem, dají se jednou nacpat do paměti pro textury a potom už je zrychlení znatelné (ta data se samozřejmě do texturovací paměti musí vejít, jinak jsme zase u pomalé sběrnice, CPU a pamětí). Obecně čím více výpočtů nad méně daty, tím je GPU díky SIMD apod. výhodnější (paradoxně má grafika mnohdy právě opačné požadavky). Mám dojem, že tímto způsobem se měla urychlovat nová verze Seti@Home nebo podobný distribuovaný projekt.

ohledne reseni obecnych problemu na GPU vzniklo cele odvetvi vyzkumu,nazyvane "general purpose computations on GPU" (gpgpu.org).
tady je survey ktery shrnuje vyzkum z posledni doby.

Jo pisou toho tam dost, ale zatim sem nikde nenasel nic ke stazeni, aspon nejaky zdrojak na jednoduchy vypocet.

Pokud vim, tak exx. projekt umoznujici komprimaci videa do DivX v GPU ATI Radeon 9500 a vyssich. Ostatni vyuziti ale muze byt stejne uchylna zalezitost jako pokusy projektu na opensource.creative.com pouzivat jadro EMU10k1 jako druhy procesor (pred par lety jsem to zkousel, v jakem stavu to je dnes netusim)

Nojo, výkon dnešních GPU je s výkonem nějakého zvukového čipu těžko srovnatelný (já vím, SB tam mají nějaký signálový procesor spojený s 3D zvukem, ale stejně to chroustá mnohem míň dat než GPU).

Teď jsem se díval, které algoritmy se v GPU úspěšně vyřešily a patří mezi ně:
- Radiozita
- Ray Tracing (to je poměrně známá věc ze SigGraphu)
- Výpočet stínů
- FFT
- Lineární algebra
- Řazení v databázi! (prý 20x rychlejší než na P4)

m