Loading časy DXT textúr

[Peto]

Ako funguje DXT kompresia?. Zabera podstatne menej miesta v pamati. Ale ako to je s loadingom?, načitana textura z DDS sa rovno uloži na disk alebo sa ešte prevádza na nejaký iný formát pre grafickú kartu.

Urobil som malý test.. loadoval som cubemapu o veľkosti 1024 z DDS, cez D3DXCreateCubeTextureFromFileEx(). Bez mip mappingu, D3DPOOL flag nehral v časoch podstatnú rolu.

1. Textura uložená na disku v A8R8G8B8 do pamate som chcel nahrať DXT1 = cca 1800ms
2. Textura uložená na disku v DXT1 do pamate som chcel nahrať DXT1 = cca 2200ms
3. Textura uložená na disku v DXT1 do pamate som chcel nahrať A8R8G8B8 = cca 600ms
4. Textura uložená na disku v A8R8G8B8 do pamate som chcel nahrať DXT1 = cca 300ms

Zda sa že v potom nemá zmysel mať textury rovno v DXT1 (až na to že zaberaju menej miesta na disku), môžu byť moje časy správne alebo robím niekde niečo zle?. Textury som ukladal cez oficialny D3D Texture Tool. Čas som meral cez timeGetTime() a zapis do log suboru. Release verzia projektu aj DX.

[Ladis]

Treba Unreal Tournament 2003/2004 ma textury jako JPEGy (pravdepodobne ve kvalite 100%). Zabira to na disku min nez DXT (nepocitam vzhledove odpuzujici DXT1) a konverze pri nahravani do 3D API je rychla. (Jeste dodam, ze Unreal Tournament 98 naopak mel ulozene textury v DXT1, pokud se nemylim.)
_________________
Award-winning game developer

[Marek]

Jo děláš něco hrozně špatně. Load DXTn textury z DDS by měla být ta nejrychlejší věc. Jiný formát by se neměl vyplatit ani používat. Použitím JPG se věci ještě zpomalí, protože dochází k dekompresi a následující kompresi do DXTn za běhu, což může být hnusný (viz dále). V OpenGL to funguje tak, že načtu DDS, celý buffer z DDS vytáhnu bez úprav do paměti a načtu přes glCompressedTexImage2D. Dojde pouze k obyčejné kopii do VRAM a je fakt hodně rychlá. Z tvého příkladu to vypadá, že děláš navíc dekompresi a znova kompresi (obojí probíhá na cpu). Problém může být v tom, že jsi do DDS neuložil mipmapy, v takovém případě se na cpu musí textura dekomprimovat, spočítat mipmapy a každá z nich zkomprimovat, což je hodně pomalé. Chyba taky může být někde v implementaci D3DX - na to kašli, použij vlastní funkce na načítání DDS a ruční load přímo do D3D. DDS formát je lehkej - hlavička a raw data. Ideální případ je mít v DDS uložené textury v DXTn včetně mipmap v DXTn.

/* EDIT: Teď jsem si všimnul, žes tam mipmapy ani nepoužíval, tak nic no */

V OpenGL to jde ještě víc urychlit a ušetřit si jednu kopii textury v paměti, princip je následující:
- Vytvořit Buffer Object o velikosti textury a locknout
- Otevřít soubor
- Načíst obrázek v DXTn přímo do Buffer Object.
- Unlock
- Nastavit Buffer Object jako PBO a zavolat glCompressedTexImage2D a pointer na data NULL. To bude tahat texturu z Buffer Object, kterou už má ale driver nahranou v managed paměťovém prostoru.
V D3D by to taky mohlo jít stejným způsobem, snad.

DXT1 není o nic horší než jiné varianty a je to asi nejvhodnější formát díky kompresnímu poměru 1:8 a ultra-rychlému loadingu na GPU. Dále DXT1 umí 1bit průhlednost, což se hodí na transparentní objekty (někteří tady zbytečně používají DXT5). Není to hnusný, jak říká Ladis. Driver totiž provádí rychlou kompresi a nejde mu o kvalitu, naopak existují offline kompresory (např. aplikace AMD Compressonator), u které komprese trvá mnohem dýl, ale proběhne daleko kvalitněji. Ten Compressonator umí generovat mipmapy a umí i 3DC kompresi (1- and 2-channel komprese), takže doporučuju na předzpracování všech textur. Jednu vyjímku tvoří cubemapy, tam se musí mipmapy počítat trochu inteligetněji (pro každou stranu sahat pro pixely i do vedlejších stran), tady bych použil nástroj AMD CubeMapGen a Compressonator bych použil jen na kompresi. Do DXTn nemá smysl dávat akorát HDR textury, jinak bych do něj dal všechno. Důležitý je mít správně optimalizovanej loading, aby se to vyplatilo.
_________________
AMD Open Source Graphics Driver Developer

[Peto]

Eosie> Diky moc za odpoved.. to som presne potreboval vediet ze robim nieco zle . Pozriem na google a skusim obist D3DX. Fuu ked ta pozrem na tie cisla.. tak by mi to mohlo poriadne znizit loading casy

[Peto]

Tak chyba nebola ani tak v D3DX. Problem robil parameter ColorKey vo funkcii texture managera som mal nejaku inu default hodnotu ako 0 , co sposobovalo dekompresiu a kompresiu. No super ze som sa to dozvedel az teraz

[VladR]

Nenechal si nahodou robit CPU bitmapy ? Lebo to trva pekelne dlho pri viacerych vacsich (>2048) DXT texturach. Preto sa cez DXTool daju ulozit aj mipmapy. Nepoviem ti presne cisla, ale naposledy co som to meral, to bol velky rozdiel. Takze, pozri si, ci aj ten parameter ma spravnu hodnotu.