V2 má ale dvě TMU, tzn., že každá má polovinu, sdílet to nelze3dfx.fun píše:Klidně. Já SLI nepotřebuju. Je to pro Glide gamesy
btw: V2 (v.8MB) má 4MB na frame a 4MB na textury ne? 12MB má 4MB frame/8MB textury
takže 8MB V2 má 2MB/TMU a 12MB V2 má 4MB/TMU 
Mám za to, že při single texturingu se ty textury rozhazujou rovnoměrně podle využití paměti, protože stejně jedna z těch jednotek v tu chvíli nejede. Ale jistej si tim nejsem, asi si na tom udělám nějaké testy, než rozdám tu poslední kartu.no-X píše:V2 má ale dvě TMU, tzn., že každá má polovinu, sdílet to nelze
[WWW] 
Ani zde se nám vlastně pamět nemusí zaplňovat rovnoměrně, protože textury při multitexturingu nemusí být stejně velké. I když jak teď nad tím přemýšlím, tak vlastně to API si ty větší textury může házet na přeskáčku, protože co jsme kdysi dělali nějakou hříčku, kterou jsme testovali i na Voodoočkách, tak V1 i V2 umí pouze additivní a multiplikativní blending, tudíž nezáleží na pořadí TMU (to je právě ta mnou oplakávaná extenze GL_ARB_texture_env_combine, která na těchto kartách chybí, ta zprostředkovává další blending módy mezi texturovými jednotkami). Kdyby se vlastně nemohly umisťovat větší textury na multitexturing do jednotky, která má zrovna více volné paměti, tak by se celkem snadno stalo, že už nemůžeme nahrát žádnou texturu, protože paměť primární TMU je zaplněná, zatímco paměť sekundární TMU má ještě z části volno.). Pokud ale máme texturu pro daný triangl v paměti druhé TMU, tak ta se z ní normálně načte, pošle se do první TMU, tam se s ní nic nestane a putuje dál do FB jako v prvním případě.. [WWW] Všechno beru, ale tenhle argument neswarm píše:Kdyby se u single texturingu nepoužíval tenhle způsob, tak by byla ta paměť dost neefektivně využitá - to by si teda inženýři z 3dfx rozhodně nedovolili, zas tak levná nebyla
Podívej na efektivnost využití paměti na V2SLI, nebo na V5 [WWW] Heheno-X píše:Všechno beru, ale tenhle argument neswarm píše:Kdyby se u single texturingu nepoužíval tenhle způsob, tak by byla ta paměť dost neefektivně využitá - to by si teda inženýři z 3dfx rozhodně nedovolili, zas tak levná nebyla
. [WWW] 
(pokud teda nedojde na trilineární filtraci ...no jestli se nechápem, tak za pár postů se určitě pochopíme - před druhou hodinou ranní určitě spát nepůjdu, protože mám ještě dost práce na zítra, takže se nám tu diskuze může ještě pěkně rozrůst ), tak tam by se to určitě projevilo. Dál může by mohl být problém při multitexturingu, protože se mezi TMU musí ty textury správně rozkládat, takže možná ta 12MB verze má víc možností nějak si to tam líp rozházet (možná ). Otázka je pokud bychom pustili nějakou hru, která nepoužívá víc jak 4MB paměti pro textury a nepoužívá multitexturing, jaký by byl potom rozdíl výkonu (třeba Turok nebo něco podobnýho by mohl posloužit) - tam by ten rozdíl neměl být velký, jestli vůbec. ...snad až o víkendu se najde čas na nějaké testování. [WWW] 
(v předchozích testech na tomshw totiž 8MB i 12MB vycházejí prakticky stejně). Až 4MB.no-X píše:moje otázka: Mohou být při single-texturingu využity pro textury až 4MB, nebo max. 2MB?
Možná ano, možná ne. Nemám tady glide sdk, takže se nemůžu podívat jak to to API rozhazuje. Já mám za to (zjednodušeně), že se textura nahraje do paměti té jednotky, která je prázdnější. Takže se ta paměť vyplňuje rovnoměrně. Kdyby se při single texturingu nahrávaly textury jenom do paměti první jednotky, tak by se taky potom mohlo stát, že až se tam bude chtít nahrát další textury pro něco s multitexturingem, tak by se to tam nemuselo vejít, protože už by byla paměť jedné jednotky plná, i když by ta druhá byla úplně prázdná (při multitexturingu musí už být ty dvě dané textury každá v paměti jiné TMU). Tady by byl totiž pak problém, že by v podstatě skoro nikdy nešla využít všechna pamět karty.no-X píše:Podle mě to znamená, že paměť druhé TMU se při single-texturignu vůbec nevyužívá.
[WWW]
) přesunout do příslušné sekce, např. Hardware 
