| Zobrazit předchozí téma :: Zobrazit následující téma |
| Autor |
Zpráva |
frca
Založen: 28. 07. 2007
Příspěvky: 1561
|
 Zaslal: 15. duben 2012, 17:05:40 Předmět: Správa textur |
 |
|
Představte si modelovou situaci:
Mám hru, která je rozdělená na levely. Aby byl loading kratší, chci pro následující level zachovat v paměti textury z předchozího (na co je zbytečně mazat, ne?). ALE: V určitém momentu bude už těch textur v GPU paměti moc, a tak by bylo záhodno ty nejdéle nepoužívané odmazat. Jak mám detekovat ten okamžik, kdy už bych měl začít textury odmazávat?
Zajímá mě zejména řešení v OpenGL 2.x, ale i DirectX 9.
_________________
www.FRANTICWARE.com |
|
| Návrat nahoru |
|
 |
nou
Založen: 28. 07. 2007
Příspěvky: 1050
|
| Zaslal: 15. duben 2012, 17:57:42 Předmět: |
|
|
toto riesit nemusis. asi yb som proste vsetky textury oznacil pred nacitavanim nejakym flagom. a potom prote len zacal nacitavat nove level pri ktorom zistis ktore este potrebujes. tym texturam ten flag vynulujes. a ked skoncis tak proste odmazes tie ktorym ostal.
riesit to nemusis pretoze driver aspon na ATI (ale na 90% aj nvidia) nacitava textury do VRAM az v momente kedy su potrebne teda zavolas prvy glDraw*() s nabindovanou texturou.
inak existuje http://www.opengl.org/registry/specs/ATI/meminfo.txt a http://developer.download.nvidia.com/opengl/specs/GL_NVX_gpu_memory_info.txt
ale ako som povedal pokial nemas problem s RAM tak proste len nacitaj novy level a odmaz to potom. ovladac si to potom uprace sam.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú. |
|
| Návrat nahoru |
|
|
frca
Založen: 28. 07. 2007
Příspěvky: 1561
|
| Zaslal: 15. duben 2012, 18:40:25 Předmět: |
|
|
Ale teď si představ, že se bude střídat level v interiéru a exteriéru. Čili dost rozdílné sady textur. V takovém případě by se mi hodily textury i z několikátého levelu nazpět.
_________________
www.FRANTICWARE.com |
|
| Návrat nahoru |
|
|
frca
Založen: 28. 07. 2007
Příspěvky: 1561
|
| Zaslal: 15. duben 2012, 18:48:58 Předmět: |
|
|
Už vím. Jakou nejmenší paměť na textury můžu předpokládat u karet podporujících OpenGL 2.x/DirectX9? Nebo spíš jaký objem textur je ještě rozumný na této třídě HW? Nastavím to natvrdo a bude.
_________________
www.FRANTICWARE.com |
|
| Návrat nahoru |
|
|
nou
Založen: 28. 07. 2007
Příspěvky: 1050
|
| Zaslal: 15. duben 2012, 18:58:49 Předmět: |
|
|
no povedal by som ze tych 512MB sa da predpokladat u relativne novsich kartach ktore boli kupene na to aby sa na nich hralo. a postol som ti sposob ako zistit velkost volnej VRAM. takze staci hned pri starte si to zistit. taktiez driver si tie textury prehadzuje z RAM do VRAM podla potreby. ak nejaka textura je nacitana ale sa nekresli tak sa pri nedostatku miesta v VRAM proste presunie do RAM.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú. |
|
| Návrat nahoru |
|
|
frca
Založen: 28. 07. 2007
Příspěvky: 1561
|
| Zaslal: 15. duben 2012, 19:04:44 Předmět: |
|
|
Kdyby ty ovladače nebyly tak přechytřelé, všem by se nám žilo líp - jak vývojářům driverů, tak vývojářům aplikací.
_________________
www.FRANTICWARE.com |
|
| Návrat nahoru |
|
|
Ladis
Založen: 18. 09. 2007
Příspěvky: 1537
Bydliště: u Prahy
|
| Zaslal: 15. duben 2012, 20:28:13 Předmět: |
|
|
OpenGL to snad dělá minimálně od dob Doom 3, ne? Že všechny textury jsou v RAM a do VRAM dává ty nejčastěji volané. Direct 3D to dělá od verze 10. Ani v jednom API tedy už nejde říct "tuhle texturu chci jen ve VRAM a uvolním si tak kus RAM". Takže limitující je jen množství RAM, ne VRAM. Příklad: Na PC s 2 GB RAM si veme Windows 7 0,8 GB, tvoje hra řekněme 0,5 GB, tak pokud nahraješ 1 GB textur/dat, tak ti bude 0,3 GB už swapovat na disk (plus spousta počítačů má sdílenou grafiku bez VRAM, ono taky na všem s výkonem >= GeForce 9300 pustím i AAA hry na Unreal 3 enginu z roku 2009).
_________________
Award-winning game developer |
|
| Návrat nahoru |
|
|
frca
Založen: 28. 07. 2007
Příspěvky: 1561
|
| Zaslal: 15. duben 2012, 20:50:20 Předmět: |
|
|
Já chci na Linux nějaké dostatečně low level 3D API, a ne tento napůl low level, napůl hi level moloch! Navíc s tak v mnoha ohledech idiotským rozhraním 
Edit: No dobře, nechal jsem se unést, možná to ve verzích >= 3.0 je už lepší, to nemůžu posoudit, protože jsem je zatím nezkoušel.
_________________
www.FRANTICWARE.com |
|
| Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava
|
| Zaslal: 15. duben 2012, 21:33:43 Předmět: Re: Správa textur |
|
|
| frca napsal: |
Představte si modelovou situaci:
Mám hru, která je rozdělená na levely. Aby byl loading kratší, chci pro následující level zachovat v paměti textury z předchozího (na co je zbytečně mazat, ne?). ALE: V určitém momentu bude už těch textur v GPU paměti moc, a tak by bylo záhodno ty nejdéle nepoužívané odmazat. Jak mám detekovat ten okamžik, kdy už bych měl začít textury odmazávat?
Zajímá mě zejména řešení v OpenGL 2.x, ale i DirectX 9. |
Uděláš si std::map<nazev souboru, textura*> a při vytvoření tam tu texturu přidáš a nastavíš jí počet referencí na 1. Až tu texturu budeš načítat znova, tak se nejdřív podíváš do toho seznamu a když tam není, tak ji načteš. Když tam je, tak ji vrátíš a zvýšíš jí počet referencí na 2. Nikdy nemažeš textury přímo, ale jenom jim odebereš referenci. Mazání uděláš tak, že projdeš seznam a smažeš ty, které mají počet referencí 0.
Př:
1) Uvolníš starý level.
2) Načteš nový level.
3) V tuto chvíli necháš smazat textury se seznamu, co mají počet referencí 0, tj. nepoužívané v aktuálním levelu.
Tím zajistíš, že při přechodu na nový level se načte jenom to, co ještě načteno nebylo, a uvolní se jenom to, co už není potřeba. Držet v paměti nějak dlouho textury, co nepoužíváš, nedoporučuju.
Stejný postup se dá aplikovat na modely, shadery atd.
| nou napsal: |
| riesit to nemusis pretoze driver aspon na ATI (ale na 90% aj nvidia) nacitava textury do VRAM az v momente kedy su potrebne teda zavolas prvy glDraw*() s nabindovanou texturou. |
Já to v driveru dělám tak, že textury načtu vždy do oblasti RAM, kterou GPU vidí, a pak řeknu GPU, ať si to k sobě zkopíruje (CPU obvykle k celé VRAM nemá přístup) a tu kopii v RAM zase smažu. Tedy po zavolání TexImage už je naplánovaný přesun do VRAM. Nevím, jak to dělají uzavřený drivery, ale pokud ti zrovna nedochází paměť, tak je to způsob, kterej funguje docela dobře.
| Ladis napsal: |
| OpenGL to snad dělá minimálně od dob Doom 3, ne? Že všechny textury jsou v RAM a do VRAM dává ty nejčastěji volané. |
OpenGL to tak vždycky určitě nedělá, OpenGL si ve skutečnosti může dělat, co chce. Co je to "nejčastěji volané"? Určitě není jen limitující množství RAM. Je tam víc úrovní:
- VRAM
- RAM, kterou GPU vidí (obvykle to je tak, že kolik má GPU paměti, tolik navíc může využívat RAM), tato RAM je obvykle neodswapovatelná.
- Zbytek RAM, kterou GPU nevidí.
- Swap. (to se spíš ale nepoužívá)
Také u integrovaných grafik, co používají RAM, tak ta oblast paměti je taky neodswapovatelná.
_________________
AMD Open Source Graphics Driver Developer |
|
| Návrat nahoru |
|
|
kerekes
Založen: 29. 07. 2007
Příspěvky: 57
|
| Zaslal: 16. duben 2012, 08:03:04 Předmět: |
|
|
Marek:
Ako to funguje na PC ak je pre nacitanie textury pouzity PBO? Ide to priamo do VRAM, alebo stale sa drzi kopia textury aj v RAM?
Minimalne na ps3 sme mali problem s tym, ze nam klasicky loadnute textury zasierali RAM, takze sme presli na nacitanie cez PBO - a spravalo sa to tak, akoby sa ziadna kopia v RAM nevytvarala a textura sla priamo do VRAM. Dost to aj zrychlilo loading.Ma zmysel takto to riesit aj na PC? alebo je to tam jedno?
Diki |
|
| Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava
|
| Zaslal: 17. duben 2012, 01:07:05 Předmět: |
|
|
| kerekes napsal: |
Marek:
Ako to funguje na PC ak je pre nacitanie textury pouzity PBO? Ide to priamo do VRAM, alebo stale sa drzi kopia textury aj v RAM?
Minimalne na ps3 sme mali problem s tym, ze nam klasicky loadnute textury zasierali RAM, takze sme presli na nacitanie cez PBO - a spravalo sa to tak, akoby sa ziadna kopia v RAM nevytvarala a textura sla priamo do VRAM. Dost to aj zrychlilo loading.Ma zmysel takto to riesit aj na PC? alebo je to tam jedno? |
To závisí, co s tím driver dělá. Já do uzavřených driverů nevidím. PBO je úplně stejný buffer jako vertex buffer nebo uniform buffer. V pohodě se dá jeden buffer používat jako VBO, PBO a UBO zároveň. Výhoda PBO je, že má k dispozici API bufferů pro načítání textur. Pro textury je to fakt hnusný API a blbě se to implementuje, ale lepší než drátem do oka. Výhoda je, že tu kopii mezi texturou a bufferem u PBO může dělat GPU, takže CPU je od toho osvobozeno. Je třeba si uvědomit, že hlavní výhoda PBO je v tom, že k té paměti může hned přistupovat GPU. To se nedá říct o obyčejné paměti, kterou si sám alokuješ (samozřejmě to jde taky, ale je to komplikovanější). Takže teoreticky se PBO vyplatí.
Pokud jde o kopii v RAM - to je věc driveru. Když ještě nebyl spolehlivý memory magement pro VRAM a data se tam mohly ztratit třeba při přepnutí rozlišení, tak bylo potřeba dělat kopii v RAM. Dneska už to tak není (hlavně teda je možno nastavit konektor monitoru, aby četl framebuffer z libovolné adresy v paměti, takže v zásadě je všechno jenom "off-screen" textura).
_________________
AMD Open Source Graphics Driver Developer |
|
| Návrat nahoru |
|
|
VODA
Založen: 29. 07. 2007
Příspěvky: 1721
Bydliště: Plzeň
|
| Zaslal: 17. duben 2012, 18:05:49 Předmět: |
|
|
Tento thread ve mě vyvolal pocit, že bych měl upravit knihovnu textur (manager textur) a tak jsem nakonec upravil i knihovnu shaderů... 
Díky, potřeboval jsem si odpočinout od bakalářky programováním nečeho jiného. 
_________________
Opravdovost se pojí s trýzní... |
|
| Návrat nahoru |
|
|
|
Hlavní strana
FAQ
Test
Hledat
Seznam uživatelů
Uživatelské skupiny
Registrace
Ke Stažení
Nastavení
Přihlášení
Calendar
