Re: Jak efektivne texturovat I BEZ MMU :-)

[Pavel Narozny <troda@cbnet.cz>]

...
>> Jiste ze ano. MMU je ti v tomhle zcela na hovno. 100% reseni je tzv.
>> swizzling, kteri vymysleli koderi na PC (mozna bych jeste nasel jmeno

> Offset do 256x256 bajtu velke textury se obvykle da zapsat napriklad
> jako [v7..v0][u7..u0]. [u,v] je ona souradnice bodu v texture.
> Pokud k texture pristupujeme prez takto vytvorenou adresu samozrejme
> dochazi k velkym skokum v adresovem prostoru
> (a zbytecne se naplnuje/vyprazdnuje cache a delaji se dalsi zbytecne
> nepodlozenosti...).

...jen ten problem s cache :))  A to staci na srazeni rychlosti. :)

> Nic nam vsak nebrani v tom trochu tuto adresu upravit (a adekvatne
> dopredu upravit vzhled a organizaci textury v pameti).
> Je to vlastne obdobne onomu "swizzlingu", jak ho popisoval Fido. Zrejme
> se jedna jen o jiny popis obdobne metody.

Jasne...

> Uvadim to tu proto, ze to takto muze byt nekterym lepe pochopitelne
> a taky, ze je to obecny popis reseni problemu "indexace velkych tabulek".
> Pouziti MMU se mi jevi jako metoda zalozena na pouziti brutalni sily.
> Navic "hardware dependant"....defor

S mmu.lib ani ne, ale je to 'tak trosku hacky way', jak bych tak rekl.
Chce to davat pozor na to, co se deje, s mmu se musi opatrne...
V zasade je mozna jeste jedna cesta (zajimave, ze to nikdo neuvedl),
a to 'OS way'. Exec ma par funkci, co jsou 'zneuzitelne'.
Treba CacheFreeze(). Co to? ZMRAZI obsah cache.
...samozrejmne je VHODNE si vlastni kod predtim nahrat do kese, ze...
Kdyz je cache vyrazena z provozu - jen nebere dalsi data, READ je mozny! -
samozrejmne nelze pristupovat k pameti burst zpusobem, takze zadny
'cache overkill' nehrozi. Hmmm. Jo, jasne, move16 bude stale burstovat,
jenze to je copy funkce, to nikomu neva ;)

> P.S.:
> Z predchazejich velmi vulgarnich mailu mne zaujalo jen jedine. Otazka
> "nepouzivani emulovanych instrukci FPU". Ted uz je nam vsem jasne, ze
> nase skvela motorola 040/060 neumi spocitat ani jednu goniometrickou
> funkci a funkce k nim inverzni.

Primo nikoliv, ale myslim, ze to vsichni zucastneni vi :)

> Je alibisticke se domnivat, ze _zadny_ procesor tento vypocet (a navrch
> jmenuje CORDIC a je soucasti mnoha procesoru (je to smutne, ale fsin,
> fcos atd. ma i Intel...).

Fakt???

> Ponechme vsak stranou hw implementaci goniometrickych funkci a
> soustredme se na to, jak tedy obejit tento nemaly problem.
> Troda je nejvetsim odpurcem pouzivani emulovanych instrukce, sam vsak
> nikdy neprinesl zadne reseni tohoto tiziveho problemu.

Sorry, nejsem coder. Napada me jedine rozlozeni tech funkci (zde je mozna
jeste mala optimalizace, protoze ne vzdy ta 'emulace' musi byt 'general'),
ale to samy jsi navrhl i ty a to samy se pouziva X let... Nic noveho
pod sluncem.

> Z praktickeho hlediska ma pogramator k dispozici tri moznosti:
> 1. Pouzit emulovanou instrukci (emulovanou goniometrickou instrukci),
> a tak si vyzadat zavolani obsluhy vyjimky a provedeni vypoctu obvyklymi
> aritmetickymi instrukcemi (tusim, ze ji obsluhuje 68040.library). Tady
> velmi zalezi na tom, jak kvalitne emulovane tyto instrukce jsou (v praxi
> na verzi knihovny).

Vsechny novejsi verze jsou OK. Starsi (a ty pre verze), to bylo ale
radosti, obcas ;)))))
Nevyhoda - library dependent (ok, in most cases...) a speed.

Mimochodem, malo kdo to vi, ale vis co delaji ty CyberPatchery a Oxy
Patchery, ze jo? ;)

> 2. Sam v programu zavolat funkce mathtrans.library (popr. jine) a dale
> se spolehat na totez jako viz.1
> 3. Naprogramovat si vypocet goniometrickych funkci sam. Zde ma
> programator opet na vyber.

Yup! I kdyz pro 4k intra je to nepouzitelny, a mozna i 40/64k budou
mit 'problemky', tak ta posledni verze Tenu ma stejne vic kvuli hudbe,
takze...

> At uz trivialni reseni vypoctu tabulky sin/cos s urcitou presnosti (a
> interpolovani "mezihodnot") nebo presne reseni prez rozvoj Taylorovy
> rady. Prvnim zpusobem se da vicemene pokryt 99% vsech nutnych vypoctu
> gon. funkci v demo produkcich. Inverznim vyhledavanim v tabulce (plus
> interpolace) se da spocitat i inverzni funkce. Ne nepodstatna je ovsem
> vec prakticke realizace. Zkuste si predstavit, ze napriklad pocitate
> funkci kombinaci nekolika harmonickych prubehu (casto se timto zpusobem
> generuji textury). A tak musite jen v jedne funkci vyvolavat svuj
> vypocet funkce radove v desitkach volani. Snad tim usetrite nejakou
> drahocenou sekundu, ale ztratite tim hodiny sveho casu implementovanim
> neceho, co uz tady bylo udelano davno a je (napriklad) implementovano
> prave v onech knihovnach, ktere se volaji pri vyvolani vyjimky.

...a prave to volani vyjimky...  uz vis co myslim? ;)

> Osobne radeji travim cas delanim neceho noveho (at uz z meho
> subjektivniho pocitu, nebo podle objektivnich meritek) nez
> implementovanim postupu, ktere jsou stare jako pocitace samy
> a neprinasejici nic pozitivniho a konstruktivniho.

Zatr, implementujes to jednou a staci, no ne?  :(

See ya!

Pavel Narozny, Troda of PEGAS, troda@cbnet.cz

"Intel inside, idiot outside."