Optimalizace asm

[frca]

Zkouším optimalizovat voxel algoritmus a nabyl jsem podezření, že nejpomalejší je přístup do velkého kusu paměti (2 MB).
Vytvoři jsem minimální example:
https://www.franticware.com/files/dosbench/main.cpp
V assembleru to je:
https://www.franticware.com/files/dosbench/main.s

Tato část trvá asi 175 cyklů 486DX2 66 MHz, což mi přijde nějak moc:

[OndraSej]

S cache 8 kB, nebo kolik to má, bude ten náhodný přístup do paměti zabiják.

Ale 175 cyklů mi přijde taky trochu moc. Zkoušel jsi, kolik stojí ten rand(), případně ho nahradit konstantou, inkrementem a případně inkrementem s modulem (udělaným přes andl)?

Edit: podle této přiručky, strana 805 by rozdíl mezi cache hit a cache miss měl být cca 2 cykly, takže těch 175 je fakt hodně.
_________________
http://trionteam.net

[mar]

pokud jde o samplování heightmapy/textury s barvami a je to opravdu o memory accessu, kolik mají ty textury - 1kx1k?

pokud to je ten access, tak bys měl vidět silný propad výkonu při otočení kamery o 90 stupňů

tak buď zkusit menší texturu nebo pokud je k dispozici dost paměti,

tak mě ještě napadlo udělat si transponované verze textur (ale 2 extra MB na 486ce asi nebude úplně cool)

počítám že ten fetch je zarás 8-bit heightmapa a 8-bit barva

a pak použít tu nebo onu podle toho, jaký je access pattern,

tzn. pokud |stepy| > |stepx|, swapnout a použít transponované textury, worst case 45 stupňů to ale nevyřeší

ještě mě napadla další věc - nejstarší trik v historii - co takhle zkusit mipmapy? určitě se to bude vařit vzadu, kde se tak jako tak sampluje v podstatě v dost random částech té textury

mimapy pro heightmapu budou triviální, pro barvy to bude kvůli paletě trochu složitější, ale dá se udělat třeba perceptual fit, tzn. vážit error podle barev - myslím 0.3*red, 0.59*green a 0.11*blue

ještě by se pak dal k tomu zkusit třeba tiling těch textur, ale to nevím, jestli už není na 486ku moc hardcore a jestli by se to neuvařilo na dekódování indexů, něco jako třeba uložit to blokově a řekněme 4x4 texely by byly blízko v paměti, něco takového

[frca]

Zajímavé nápady; v původním examplu nejvíc opravdu žral ten rand(). Budu zkoumat a experimentovat dál.
_________________
www.FRANTICWARE.com

[mar]

no pokud cache miss trvá na 486ce 2 cykly a mov jeden, jak psal ondrasej, pak určitě cache missy nejsou důvod, proč to běží jak se ti zdá pomalu a žádný z těch nápadů stejně v ničem nepomůže

[OndraSej]

No jo, to bývaly ty zlaté časy, kdy paměť běžela na podobné frekvenci jako procesor a cykly byly tak dlouhé, že round-trip do paměti a zpět proběhl skoro okamžitě

frca: máš někde ten skutečný kód, co optimalizuješ? Jinak v té dobové příručce, co jsem odkazoval, je tabulka latencí většiny instrukcí, takže by nemělo být až tak těžké dopočítat, co tam trvá dlouho.
_________________
http://trionteam.net

[frca]

Kód mám teď rozkopaný, ale mezitím jsem přemýšlel, jestli je nějaká výhoda mít lokální proměnné na stacku vs. statické (v datovém segmentu). Zatím jsem neměl čas to zkoušet.
_________________
www.FRANTICWARE.com

[frca]

Zkoušel jsem všelicos, ale výsledek stále víceméně stejný. Funkce vykresluje jeden řádek voxelů v konstantní vzdálenosti. Assembler je výsledkem kompilace s -O2:

https://franticware.com/files/rcross_opt/cpurenderasm.cpp
https://franticware.com/files/rcross_opt/cpurenderasm.s
_________________
www.FRANTICWARE.com

[mar]

[frca]

Díky za super nápady, hlavně s tím clampem a verzí funkce bez něj. To bude poměrně snadné.

Half-res je taky možnost, hlavně blízko kamery, kde jsou voxely beztak velké přes x pixelů.


Co mi vrtá hlavou: Nejsou 32-bit operace rychlejší než 8-bit? Že bych si vytvořil 32-bit framebuffer, pracoval nad ním a pak zkopíroval každý čtvrtý bajt, na to bude určitě nějaká instrukce

PS: Druhou půlku jsem nepochopil, přečtu si ji znova zítra

PS2: Optimalizaci clampu mám hotovou, testuju počáteční a koncové iCoordX, iCoordY a pokud všechno spadne do 0-1023, volám rychlou verzi bez clampu. Pokud hráč jede po trati a nedělá kraviny, tak se verze s clampem vůbec nezavolá.
Druhá věc je, že se neudálo žádné znatelné zrychlení. Pořád to zarytě jede 17-18 fps.

PS3: Pixel doubling přinesl zrychlení na asi 23 fps. Použil jsem ho jen blízko kamery, kde to je pixelované tak jako tak.
_________________
www.FRANTICWARE.com

[frca]

V další verzi plánuji 3 úrovně detailu:


Pixel doubling je jen u části obrazu při nastavených detailech na úroveň 0. Pak se to liší hlavně počtem z-sliců. Nejvíce se rozdíl projevuje v pohybu, kdy je vidět alias hlavně u výraznějších terénních nerovností.
_________________
www.FRANTICWARE.com