Hlavní navigace

Názory k článku Grafické algoritmy implementované v 3D akcelerátoru Voodoo 1

Článek je starý, nové názory již nelze přidávat.

  • 7. 1. 2010 11:16

    kvr kvr

    Ten hlavní klad není ani tak v lepším pokrytí (ono je to diskutabilní – 1/x při větších x nemá zrovna vhodný průběh, i když u větších x je to zde samozřejmě méně podstatné).
    Primárně jde ale o to, že při promítnutí (horizontální) čáry je vzdálenost mezi dvěma body 1/lineární, tedy při jejím vykreslení stačí spočítat z0 a z1 (vzdálenost začátku, konce), inverse_zstep = (1/z1–1/z0)/pixel_cnt a s každým pixelem pouze přičítat postupně inverse_zstep a vyhnout se tak náročnému dělení.

    Nevím, zda tím byl myšlen onen „konstantní krok mezi vzdálenostmi“, takže pro jistotu pro vyjasnění :)

  • 7. 1. 2010 13:02

    ondra.novacisko.cz

    ono jde hlavně o to, že s celočíselným Z se uživateli zdá, že Z je hrubý pro blízké objekty a jemný pro vzdálené objekty. Při reálném Z je ten průběh takový, že blízké objekty mají detalněji odstupńovaný Z, než vzdálenější.

    Ono je to dvousečný, protože při tomhle způsobu práce se Z mají vzdálenější objekty znatelný Z alias, který může být rušivějšá, než alias u blízkých objektů, který nemusí být až tak hrubý, jako u toho převráceného způsobu zápisu. Všechny tyhle problémy efektivně řeší 32-bitový Z buffer, který má 65536× jemnější vzorkování a kde volba formátu už nehraje takovou roli (DEPTH-BUFFER vs Z-BUFFER v D3D terminologii)

  • 7. 1. 2010 13:53

    Pavel Tišnovský

    Pravda, 32bitovy Z-buffer (nejlepe w-buffer resp. jak pises DEPTH-BUFFER) uz je dostatecny, pokud tedy programator nenastavi uplne nesmyslne hodnoty do transformacnich ma­tic.

    Problem s Voodoo 1 spocival v tomto pripade v tom, ze texturovaci DRAM byla oddelena od framebufferu, takze programator proste nemel moznost si napriklad pro CAD aplikace (objekty bez textur) naalokovat 32bitovy Z-buffer nebo zvetsit rozliseni a naopak, pokud potreboval vic texturovaci pameti (a ozelel napriklad Z-buffer, protoze sortil scenu), taky s tim nemohl nic moc delat.

  • 7. 1. 2010 12:35

    ondra.novacisko.cz

    Double buffering: Kdo to neviděl na vlastni oči, ten si to asi nedokáže představit. Problém není v tom onom „lomu“ v půlce obrazovky. Double-buffering obvykle stačí v případě, že data do front-bufferu kopírujeme, tedy nepřepínáme. Kopírovat je nutné, pokud Vaše 3D aplikace běží v okně, nebo je spíš statická, kde překreslení celé obrazovky v backbufferu při přepnutí zabere víc času, než kopírování změn.

    Při kopírování bez čekání na V-Retrace dochází k viditelného lomu. Ne však při přepnutí. Přepnutí totiž může dojít až při návratu paprsku, čili nikoliv v okamžik vyslání příkazu. Týká se to tedy všech VGA karet, ale také Voodoček. Pokud vím, novější karty to umí kdykoliv, proto se čekání na návrat většinou potlačuje.

    Pokud karta neumí přepnout okamžitě, ale příkaz provede až při návratu paprsku, pak od přenutí do konce běhu uživatel stále vidí front-buffer, ale aplikace si myslí, že už je to back-buffer. Následující příkaz, kterým většinou je smazání bufferu pozadím tedy způsobí dost znatelné bliknutí spodku obrazovky začínající na místě, kde stál paprsek v době vyslání příkazu přepnutí. Pokud navíc stihne aplikace generovat obraz rychlostí rovnou obnovovací frekvenci monitoru, pak uživatel trvale vidí jen horní půlku obrazovky, v dolní půlce má trvale barvu pozadí. Pokud je aplikace pomalejší, tak horní (zhruba) půlka je plynulá, dolní půlka poblikává.

    Triple-buffering tenhle problém potlačuje. Nevýhodou triple bufferingu je zpoždění. Zatímco u double bufferingu uživatel vidí scénu jeden snímek pozadu, u triple-bufferingu jsou to snímky dva. Pokud aplikace generuje obraz s nižší obnovovací frekvencí, může to uživatel pocítit, například na reakci myši, kdy myš po obrazovce „plave“.

    U nových grafických karet už výběr double-triple není až tak zásadní. U akčních scén pomůže triple buffering redukci lomů (ze kterých může bolet hlava – zapojení motion bluru je efektivně redukuje také), ale jinak stačí double buffering a zbývající paměť využít pro textury.

  • 7. 1. 2010 12:50

    ondra.novacisko.cz

    Zdálo by se, že paměť hloubky řeší problém překryvů bez nutnosti řadit scénu. Není to tak úplně pravda.

    Velkým zdržovákem všech grafických karet je overdraw, tedy kresba velkých ploch. Dříve uváděný výkon v trianglech za sekundu je tedy zavádějící, zajímavější je číslo udávající počet pixlů za sekundu. Přitom ani to není správně, protože nakreslit pixel na obrazovce může být dost náročné, zejména pokud je to spojeno s komplikovaným výpočtem v pixel shaderu.

    Voodoočka ovšem také dost znatelně trpěly na overdraw a pár velkých otexturovaných ploch je umělo vytížit dokonale, než tisíce malých trojúhelníků.

    Výhodou Z-testu je také to, že je v celé pipe-line dost vysoko a pokud pixel neuspěje v Z-testu, další operace se vynechají, ušetří se výkon.

    Proto má stále smysl řadit scénu odpředu dozadu. Kreslit nejprve objekty nejblíž, a pak objekty nejdal.

    Dalším důvodem řazení je alpha-blending. Tady musíme scénu řadit odzadu dopředu. Lze to i dělat obráceně, ale musíme mít k dispozici alpha-buffer.

    Proti tomu jde ale řazení scény s ohledem na změnu stavu. Právě tohle je největší problém všech těch grafických engine, které mají různých výkon na stejným HW. Většina dnešních karet dosahují největšího výkonu při proudovém zpracování dat. Pokud ale scénu musím řadit, zvětšuje se množství fragmentů, které nelze zpracovávat proudově, musí se proudy přerušovat. Ušetřený výkon na Z-testu tak můžeme ztratit na přerušování proudu. Univerzální řešení neexistuje.

  • 7. 1. 2010 13:21

    Pavel Tišnovský

    Presne tak, usporadani objektu ve scene urcite renderovacimu vykonu pomuze, ale Tebou zminovane serazeni polygonu je uz nizkourovnova operace.

    Nejlepsi je mit navic nad scenou (kdyz je scena opravdu velka, tj. interiery a exteriery ve hrach) vybudovanou nejakou dalsi datovou strukturu, treba BSP, portaly, hierarchickou mrizku nebo okludery (tak je to tusim resene v Mafii, ktera ma hodne exterieru, takze portaly by zde nebyly efektivni).

  • 17. 1. 2010 13:08

    Diagon Swarm (neregistrovaný) ---.157.broadband3.iol.cz

    Z článku to vyznívá, že použití řazení polygonů místo z-bufferu je pomalejší, ale při počtu polygonů, který v té době scény měly, to bylo rychlejší řešení. Voodoo1 byl dost rychlý akcelerátor, ale kdo měl něco pomalejšího od ATI/S3/whatever, tak mohl ve hrách vypnutím z-bufferu (tj přepnutím na řazení polygonů) získat nezanedbatelné množství fps navíc. Z nejznámějších her té doby si pamatuju třeba Need for Speed… tam šel vypnout z-buffer snad ještě u čtvrtého dílu.