KD-tree mono-tracer

[Vilem Otte]

Malé oživení tématu polopřímek ... chtěl bych poprosit zdejší majitele linux-64 zda by mohli otestovat http://www.otte.cz/forgottenlib-test-lnx64.tar.gz?

Potřebuje knihovny OpenGL a DevIL (bývalé OpenIL), DevIL však toto demo nepoužívá (ale já byl línej někde v půlce vývoje ho odstranit a teď se mi nechtělo).

Možná si to bude chtít trochu pohrát s ini souborem (informace v něm by měly být jasné). Mě by hlavně zajímalo, jak vám vše běží (případně vaše konfigurace - CPU + rychlost RAM především, GPU nehraje roli).

Jedná se o celkem rychlý ray tracer (není ještě úplně vypilovaný), ale používá:
- vysoce optimalizovaný ray-triangle intersection (silně překopaný a modifikovaný barycentrický test, až 2x rychlejší než Moellerův, ale něco předpočítá).
- modifikovaný KD-Tree (postavený v N-log-N čase, teoreticky jej lze použít pro menší dynamické scény)
- dlaždicový rendering (po 32x32 blocích), jedná se však o mono-tracer
- vláknování (jen pozor u ini, počet vláken = 1, nebo násobek 2)
- a pár dalších vychytávek... i když trocha magie s pointery by ještě šla předvést, abych získal nějakou rychlost navíc

Žádné stínování v demu neprovádím (úmyslně), jedná se mi čistě o výkon, jaký můžu vytáhnout z procesorů (nejde o žádný hybridní výpočet, ale čistý mono-tracer).

Zvolil jsem (vzhledem k velikosti souboru) relativně jednoduchý model pro výpočet...

Uvidíme co vymyslím u většího dema (dalšího) ... tam to bude chtít lepší model i nějaké stínování (path tracing? );

32-bit binárka zatím nebude... ani Win32 binárka.

EDIT: Scéna začíná uprostřed scény (implicitně uprostřed koně ), WSAD (pohyb) a šipky (rozhled) by měli kameře trošku pomoct

EDIT2: http://openil.sourceforge.net/ Stránky DevIL - deb balíky by měly být v repozitářích (Ubuntu i Debian je tam mají), rpm balíky si nejsem jistý, ale asi také budou (Suse je myslím má, Fedora, Red hat asi také) ... jinak asi kompilace ze zdrojáků na stránkách, na které odkazuji.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[Quiark]

Core i5 2,53 GHz
Kubuntu linux 64b běžící ve VirtualBoxu pod Windows 7

V tom defaultním okně, na 1 vlákno, to dává kolem 2 MRay/s
_________________
Mám strach

[franz]

[Vilem Otte]

[nou]

Phenom II 955 3.2GHz to dava 7-8MRays/s
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[Marek]

64-bit Linux nevedu z praktických důvodů.
_________________
AMD Open Source Graphics Driver Developer

[Vilem Otte]

Díky za testy...

Mimochodem Eosie - můžu se zeptat proč přesně?
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[rezna]

ja budu mit urypanou otazku - ve vedlejsim vlakne se prudi VODA ze mu release pro widle nejede poradne ve wine, ale na druhou stranu ty se s releasem pro windows ani nenamahas

[Icek]

Ubuntu 11.04 AMD QL-60 (2x 1,9 Ghz), 4GB Ram 800 Mhz - 1,5 az 2.1 MRays/s

[frca]

rezna: Všechno nemusí mít widlácký release. A něco třeba ani nemůže... Teď si rýpnu zase já: Vodovo vlákno není ve správné sekci a tobě je to jedno.
_________________
www.FRANTICWARE.com

[Vilem Otte]

[nou]

a tu GPU cast chces tahat cez OpenGL alebo zapriahnes nove OpenCL?
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[Marek]

[Vilem Otte]

Upřímně, zkušenosti mám s GLSL gpgpu - třeba takový path tracer v GLSL je docela sranda psát, navíc to vypadá, že GLSL si o něco lépe poradí s kompilací programu (než OpenCL)... na druhou stranu pokoušet se o správu paměti v GLSL je docela sebevražda (jednoduše to je nemožné, takže GLSL asi vypadne).

Další možností je CUDA, s tou ale zkušenosti nemám (ale afaik se od OpenCL tolik neliší). Jenže uzavřít si možnost pro AMD, mého oblíbeného výrobce GPU, si rozhodně nehodlám - takže CUDA také padá.

DirectCompute možnost není (pro mě je podpora linuxu kritická).

OpenCL je tedy asi jedinou možností ... pokud se nepokusím o sebevraždu se správou paměti v GLSL - kde byly docela úspěchy s short-stack KD-restart algoritmem, ale to je u Radeonu X1900 - což je trošku něco jiného než moderní stream procesory - které s short-stackem zase problémy mají...
Prozatím jsem docela drtil výkon z CPU, kde z takového 8-core Xeonu s rychlou 2 GHz RAM, dokážu vytáhnout nějakých 32 MRays/s (což je imho docela dost), tady pro koníka.
Uvidím jak budu úspěšný s GPU (prakticky vezmu program co mám pro CPU a přepíšu jej pod OpenCL pro GPU, dodělám správu paměti a bude hotovo).

Snažím se tak ale dimenzovat svoji technologii do "APU" tedy ať se bude jednat o fyzikální, grafický či herní výpočet, kernel enginu ho přiřadí na zařízení, kde bude momentálně více volno.

Problém je dneska s pamětí, pro statické scény je relativně jednoduché držet v paměti vše vícekrát (1x pro GPU, 1x pro CPU), ale pro dynamické scény je třeba vše updatovat a posílat (buď GPU-CPU, nebo naopak)... a zde jsou zatím problémy (resp. nejsou, ono těch výpočtů zase není tolik). Obecně je ale lepší to spočítat na CPU a poslat na GPU (než to dělat naopak), opačná cesta je však někdy lepší.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[Marek]