1) Jde o to, ze *zadne* API neda uzivateli (-programu, ne toho API) nic (primo). Proto DX10 v tomto IMO nemuze byt horsi nez kterekoli jine. Naproti tomu, pokud posuzujete *neprimy* uzitek (vyplatu v pulce dalsiho mesice), pak je a) obrovsky, i kdyz neni zatim videt; b) stejny, jako u jinych povedenych API, protoze vzdy ho nejdrive musi vyuzit programatori, nez se vysledky dostavi k uzivateli (v kazdem zamestnani dostanete penize az dalsi mesic, takze kvuli tomu nebudete jedno zavrhovat). Screenu bude jiste jiz v pristim roce dost, ackoli o celoplosnem rozsireni se nebude dat mluvit jeste asi radu let.
5) Prave ta veta, kterou jste sem nyni vlozil, dava smysl. Staci ji prelozit. Nemluvi se v ni totiz vubec o "narustu pametove narocnosti" - ten se objevil ve chvili, kdyz poprve programator vyuzil 128bitovy format textury, ne tehdy, kdyz mu nekdo slibil (DX10.1), ze s ni muze delat povedene kousky a budou fungovat vsude. Tohle je neprijemny dopad (uprimne ci dobre myslene) snahy fakta pri prekladu z cizich materialu "okecat", pritom to puvodni sdeleni je spravidla jasne, vystizne a presne...
3) Dekuji, uz me to nerajcuje :)
Vlastne me to uz vubec nerajcuje, ve skutecnosti jsem si tu vubec nechtel s nekym dopisovat :) Pouze muj pohar tolerance nepresnosti ve vyjadrovani a faktickych, gramatickych ci slohovych chyb pretekl prave u Vaseho clanku, ackoli zrovna ten by si to zaslouzil mene, nez mnohy jiny tady i jinde (prinejmensim po gramaticke strance:). Takze jsem se nechal trochu unest (omlouvam se) a hnidopissky to vsechno zkritizoval.
5) Prave ta veta, kterou jste sem nyni vlozil, dava smysl. Staci ji prelozit. Nemluvi se v ni totiz vubec o "narustu pametove narocnosti" - ten se objevil ve chvili, kdyz poprve programator vyuzil 128bitovy format textury, ne tehdy, kdyz mu nekdo slibil (DX10.1), ze s ni muze delat povedene kousky a budou fungovat vsude. Tohle je neprijemny dopad (uprimne ci dobre myslene) snahy fakta pri prekladu z cizich materialu "okecat", pritom to puvodni sdeleni je spravidla jasne, vystizne a presne...
3) Dekuji, uz me to nerajcuje :)
Vlastne me to uz vubec nerajcuje, ve skutecnosti jsem si tu vubec nechtel s nekym dopisovat :) Pouze muj pohar tolerance nepresnosti ve vyjadrovani a faktickych, gramatickych ci slohovych chyb pretekl prave u Vaseho clanku, ackoli zrovna ten by si to zaslouzil mene, nez mnohy jiny tady i jinde (prinejmensim po gramaticke strance:). Takze jsem se nechal trochu unest (omlouvam se) a hnidopissky to vsechno zkritizoval.
Odpovědět0 0
1) Pokud berete v uvahu neprimy vytezek, pak je ten Vas vyrok prinejmensim kratkozraky, protoze uzivatele (predevsim hraci) z toho budou tezit obrovskou merou ve chvili, kdyz native DX10 tituly zaplavi trh. Vzdyt to je jako tvrdit, ze z chozeni do prace nic nemate, protoze vyplatu dostanete az v pulce dalsiho mesice...
5) Ne tak docela. To co tam (i nyni) pisete, by znamenalo, ze prechod na DX10.1 prinese vetsi pametove naroky kvuli nutnemu pocitani s FP32. Jenomze tak to neni - naroky na pamet jsou pro DX 10 i 10.1 stejne a odpovidaji volbe formatu textury. Pouze s 10.1 ma programator garantovano, ze kdyz pouzije 32bitovy format textury, tak mu to pobezi na kazde karte stejne.
6) Spatna interpretace - "64bit integer pixel format" je format textury, kde kazdy kanal je celociselny a 16bitovy (napriklad R16G16B16A16_SINT). VYPOCTY, ktere zminujete, budou 16bitove.
3) Kdyby se micky chovaly nezavisle, tak vypocty muzete idealne paralelizovat (nezavisle operace jsou novodobym snem programatora :)) a na 1000 vypocetnich jednotkach si spocitate 1000 micku za cenu jednoho. "Nezavisle" a "musime serializovat" nejsou pojmy, ktere by sly dohromady.
5) Ne tak docela. To co tam (i nyni) pisete, by znamenalo, ze prechod na DX10.1 prinese vetsi pametove naroky kvuli nutnemu pocitani s FP32. Jenomze tak to neni - naroky na pamet jsou pro DX 10 i 10.1 stejne a odpovidaji volbe formatu textury. Pouze s 10.1 ma programator garantovano, ze kdyz pouzije 32bitovy format textury, tak mu to pobezi na kazde karte stejne.
6) Spatna interpretace - "64bit integer pixel format" je format textury, kde kazdy kanal je celociselny a 16bitovy (napriklad R16G16B16A16_SINT). VYPOCTY, ktere zminujete, budou 16bitove.
3) Kdyby se micky chovaly nezavisle, tak vypocty muzete idealne paralelizovat (nezavisle operace jsou novodobym snem programatora :)) a na 1000 vypocetnich jednotkach si spocitate 1000 micku za cenu jednoho. "Nezavisle" a "musime serializovat" nejsou pojmy, ktere by sly dohromady.
Odpovědět0 0
Ackoli je to obecny trend vsech ceskych internetovych IT magazinu, tady mi to neda a musim vytknout uroven clanku:
1) "Po nepříliš úspěšném DirectX 10, jenž koncovým uživatelům nic moc nepřineslo, se nikdo nemůže divit" -- tahle veta postrada smysl. Ktere API kdy co prineslo uzivatelum? API je pro programatory a uzivatele se to muze dotknout pouze neprimo diky jejich produktum! DX10 je revolucni skvele navrzene API a az vejde v obecnou platnost (=bezna podpora low-end HW), tak se to ZATRACENE odrazi na kvalite her, protoze programatorovi usetri pekny ranec trablu.
2) "Multi-sample buffer reads and writes - obecně kvalitnější FSAA" -- zvlastni vystrel do tmy. Tohle je ale specifikum uz DX10. U DX10.1 se pouze pridala ta sama podminka pro depth buffer.
3) "Totiž kolize míček - míček je zcela pochopitelně věc počítaná sériově, každý míček se chová "nezávisle" a nelze přesně určit, co se stane v dalším okamžiku." -- aha! Takze protoze micky se chovaji nezavisle, tak se pocitaji seriove? :)
4) "Je stanoven minimální požadavek na 4 vzorky MSAA (minimální podpora 4x MSAA) - to vše samozřejmě ve spojení výpočtu s shadery jak je vyžadováno u DirectX 10." -- ve spojeni vypoctu s shadery? To je nejaky dramaticky preklad ci co? Co tim chtel vlastne basnik rici?
5) "Nutnost počítání čísel v plovoucí desetinné čárce pomocí FP32 (což je dvakrát tak náročný výpočet oproti dosud převážně používané FP16). ..." -- cely tento odstavec je nesmysl. Jedine co se v tomto smeru pridalo, je povinna podpora FILTRACE FP32 textur, vsechno ostatni zustava stejne. Jeste stale jsou podporovany (a nejblizsi desetilieti jiste budou) FP16 textury a rozhodne tedy neni 16bitovym flatum konec. Proto take zminovane "vetsi naroky na pamet" postradaji smysl - porad mate sirokou volbu texturovych formatu a kazdy ma sve pametove naroky! (Tedy, dobre, abych to neprehanel - posledni veta o HDR je rozumna :).)
6) "Výpočty s pevnou desetinnou čárku při "míchání"/spojování textur (blending) musí nutně být typu Int16, tedy 64-bitové výpočty." -- ne, nemusi, a nejsou 64bitove. Stejne jako v pripade FP32 filtrace - povinna je pouze podpora, programator ma stale moznost vyuzit jine formaty textur s nizsi presnosti. Mimochodem, Int16 textura obnasi 16 bitu na kanal (prekvapive), takze vypocty jsou 16bitove (v pripade 4kanalove textury to znamena ctyri 16bitove vypocty - docela rozdil).
... ja vim, ze rychly (nesmyslny) preklad odstavcu ze zahranicnich clanku je levnejsi, ale casto takovy clanek pak postrada prakticky vyznam!
1) "Po nepříliš úspěšném DirectX 10, jenž koncovým uživatelům nic moc nepřineslo, se nikdo nemůže divit" -- tahle veta postrada smysl. Ktere API kdy co prineslo uzivatelum? API je pro programatory a uzivatele se to muze dotknout pouze neprimo diky jejich produktum! DX10 je revolucni skvele navrzene API a az vejde v obecnou platnost (=bezna podpora low-end HW), tak se to ZATRACENE odrazi na kvalite her, protoze programatorovi usetri pekny ranec trablu.
2) "Multi-sample buffer reads and writes - obecně kvalitnější FSAA" -- zvlastni vystrel do tmy. Tohle je ale specifikum uz DX10. U DX10.1 se pouze pridala ta sama podminka pro depth buffer.
3) "Totiž kolize míček - míček je zcela pochopitelně věc počítaná sériově, každý míček se chová "nezávisle" a nelze přesně určit, co se stane v dalším okamžiku." -- aha! Takze protoze micky se chovaji nezavisle, tak se pocitaji seriove? :)
4) "Je stanoven minimální požadavek na 4 vzorky MSAA (minimální podpora 4x MSAA) - to vše samozřejmě ve spojení výpočtu s shadery jak je vyžadováno u DirectX 10." -- ve spojeni vypoctu s shadery? To je nejaky dramaticky preklad ci co? Co tim chtel vlastne basnik rici?
5) "Nutnost počítání čísel v plovoucí desetinné čárce pomocí FP32 (což je dvakrát tak náročný výpočet oproti dosud převážně používané FP16). ..." -- cely tento odstavec je nesmysl. Jedine co se v tomto smeru pridalo, je povinna podpora FILTRACE FP32 textur, vsechno ostatni zustava stejne. Jeste stale jsou podporovany (a nejblizsi desetilieti jiste budou) FP16 textury a rozhodne tedy neni 16bitovym flatum konec. Proto take zminovane "vetsi naroky na pamet" postradaji smysl - porad mate sirokou volbu texturovych formatu a kazdy ma sve pametove naroky! (Tedy, dobre, abych to neprehanel - posledni veta o HDR je rozumna :).)
6) "Výpočty s pevnou desetinnou čárku při "míchání"/spojování textur (blending) musí nutně být typu Int16, tedy 64-bitové výpočty." -- ne, nemusi, a nejsou 64bitove. Stejne jako v pripade FP32 filtrace - povinna je pouze podpora, programator ma stale moznost vyuzit jine formaty textur s nizsi presnosti. Mimochodem, Int16 textura obnasi 16 bitu na kanal (prekvapive), takze vypocty jsou 16bitove (v pripade 4kanalove textury to znamena ctyri 16bitove vypocty - docela rozdil).
... ja vim, ze rychly (nesmyslny) preklad odstavcu ze zahranicnich clanku je levnejsi, ale casto takovy clanek pak postrada prakticky vyznam!
Odpovědět0 0
