Aktuality  |  Články  |  Recenze
Doporučení  |  Diskuze
Grafické karty a hry  |  Procesory
Storage a RAM
Monitory  |  Ostatní
Akumulátory, EV
Robotika, AI
Průzkum vesmíru
Digimanie  |  TV Freak  |  Svět mobilně

Sapphire Radeon X800XL - vyplatí se 512MB karta?

16.6.2005, Zdeněk Kabát, recenze
Sapphire Radeon X800XL - vyplatí se 512MB karta?
Do ruky se nám dostala první grafická karta s 512MB paměti a tak jsme se na ni samozřejmě důkladně podívali. Jedná se o Radeon X800XL od společnosti Sapphire, jehož výkon by mnozí očekávali vysoko nad současnou 256MB verzí. Je tomu ale skutečně tak? Podívejme se na kartu detailně...

Co přináší 512MB grafické paměti?



Abychom si vysvětlili, k čemu je taková kapacita paměti potřeba, musíme si objasnit funkci grafické paměti jako takové. K vykreslení libovolné scény potřebuje mít grafický čip přístup k mnoha datům - primárně to jsou Z-buffer, barevné informace, geometrie scény apod., což jsou údaje, které se velmi často mění (např. díky shaderům), a proto k nim musí vést co nejrychlejší cesta. Další data, která se ukládají do lokální paměti, jsou textury - ať už se jedná o typické grafické bitmapy, nebo o textury potřebné k bump mappingu, normálovému mapování nebo displacement mappingu. Tyto textury už ovšem mohou nabývat podstatnějších velikostí.


Příklad normálového mapování

Když se potřebné textury již nevejdou do lokální paměti (frame bufferu), jsou swapovány do paměti systémové. To má ovšem jeden základní zádrhel, a to výrazně pomalejší přístup. Pokud bychom brali v úvahu sběrnici AGP, tak i nejrychlejší specifikace AGP 3.0 (8x) dovoluje maximální přenosy o rychlosti 2,1 GB/s. Sběrnice PCI Express je na tom již o něco lépe a zvládá 4 GB/s každým směrem. Ve srovnání s přístupem do lokální paměti je to ale stále velmi málo - např. Radeon X800XL má propustnost díky 256-bitové sběrnici a pamětem na 490MHz cca 31,36 GB/s, tedy prakticky osmkrát více.

Přestože do systémové paměti vede daleko pomalejší cesta, byl tento způsob ukládání grafických dat použit u posledních low-endových GPU. Technologie jako TurboCache (GeForce 6200 "NV44"), přes. HyperMemory (Radeon X300SE) mají lokální RAM jen 16MB nebo 32MB a zbytek dat ukládají přes PCI Express do systémové paměti.

Nyní se tedy dostáváme k tomu, proč používat větší paměť. Pokud jsou ve hře potřeba tak velké textury, že překročí velikost frame bufferu, má tento stav velký dopad na výkon. Ovšem protože současné 3D akcelerátory používají komprese (např. S3TC, DXT, 3Dc), většinou se podaří i velké textury do paměti vměstnat. Samozřejmě tomu pomáhají i vývojáři, jejichž hry ve velké většině případů vyhovují všem mainstreamovým kartám, které mají dnes 128MB, a na maximální detaily nevyužijí víc než současných 256MB u hi-endových modelů.


Různé komprese normálové mapy

Při jakém nastavení by tedy bylo možné 512MB využít? Odpovědi jsou momentálně dvě - vysoké rozlišení a velká úroveň FSAA. Rozlišení bývá často omezeno na 1600x1200 a když už nějaká hra dovoluje více, nastává pro změnu problém u monitorů a nedostatečné obnovovací frekvence. Proto přichází na řadu FSAA.

FSAA, nebo-li Full Scene Anti-aliasing je způsob vyhlazování hran objektů, při kterém jsou jejich přechody hladké a nikoliv zubaté. Může pracovat v různých módech - základní je Multisampling, který vyhlazuje jen pixely na okrajích, a Supersampling, jehož úkolem je vyhladit celou scénu tak, že ji vyrenderuje ve dvoj- nebo čtyřnásobném rozlišení a výsledek poté interpoluje. Je tedy jasné, že MS využije jen o něco málo více paměti, SS vždy tolikrát více, kolik je jeho stupeň. Maximální FSAA současných grafických karet je 6x FSAA u ATi (sparse-sample MSAA) a 8x FSAA u nVidie (4x RGMS + 2x OGSS).

Jak vysoké rozlišení, tak FSAA ovlivňují velikost dat v back bufferu (slouží k uložení "rozpracované" scény, např. FSAA před sloučením do výsledného rozlišení) a ve front bufferu (připravený výstup na monitor). Při rozlišení 1600x1200, 6x FSAA, 32-bitové barevné hloubce, 24-bitovém Z-bufferu a 8-bitovém stencil bufferu zaberou tato data přibližně 100MB paměti a pro textury je tedy určen zbytek. Kdybychom použili 100 textur s rozlišením 512x512 v plné barevné hloubce, zaberou "jen" 100MB a stále dostačuje 256MB grafická karta. Je tedy vidět, že pro využití 512MB je potřeba opravdu velmi náročná aplikace.

Cesta ke grafickým orgiím otevřená



Předchozí odstavce měly objasnit využití paměti ve své surové podstatě, ovšem grafické aplikace mohou z vyšší kapacity benefitovat i jinak. Jedná se o různé efekty vytvářené převážně za použití shaderů, které potřebují ke správné funkcí více paměti, než jen na jeden snímek s daným rozlišením a hloubkou. O co se jedná:
  • Mapování textur: Jak jsem již zmiňoval, můžeme sem zahrnout Bump Mapping, Normal Mapping a Displacement Mapping. BM je záležitostí spíše okrajovou (využívá se hlavně Paralax Mapping, nebo-li virtuální DM) , ale k tvoření detailních modelů bez zvyšování geometrického detailu se používají metody druhá a třetí. Čím detailnější textura, tím přesnější model.
  • Motion Blur: Takto se nazývá efekt rozmazání v důsledku pohybu objektu. Celý front buffer se takto uloží do textury, která se následující snímky používá společně s efektem prolnutí (blending). Čím delší "stopu" chceme zanechat, tím více textur o velikosti odpovídajícími rozlišení monitoru je třeba použít.
  • HDR Rendering: High Dynamic Range se používá v současnosti snad jen ve hře Far Cry (patch 1.3), přestože je výrazným přínosem ke kvalitě obrazu. Místo výpočtů scény v 32-bitové celočíselné hloubce se používá 64-bitových dat s plovoucí desetinnou čárkou (FP16), což zabírá dvakrát více paměti.
  • Geometrický detail: Více paměti dovolí vývojářům používat detailnější modely prostředí i postav. Toho lze samozřejmě docílit i použitím normálového mapování a displacement mappingu.

V tuto chvíli nejen já, ale hlavně herní vývojáři tvrdí, že 512MB paměti nepotřebujeme, ale potřebovat budeme. Pochyby se zdvojnásobováním grafické RAM se objevovaly vždy a vždy se také objevovat budou. Nicméně, než udělím nějaké závěrečné soudy, podívejme se na testovanou kartu od Sapphire.

Za informace k této kapitole děkuji serveru Beyond3D.