Radeon HD5750 Passive (700 MHz GPU/1150 MHz mem): ~40 fps
De lehet, hogy procilimit van (Athlon64@2.5 GHz), mert az 100%-on megy közben.

Real-time ray-tracing (még ha csak egy gömb+talaj+ég is), és 0 hozzászólás? Hát hogy van ez?

Nem teszed be aláírásba? Pl.: "OpenCL real-time ray-tracing - blogom - eredményeket várunk a topikban!", vagy ilyesmi.

Nagyon komoly ez az egész... Fél-egy-két TFLOPS at hand... Nem olyan rég szuperszámítógépek tudtak ennyit... Meg néztem pár forrást az AMD developer csomagban... Ezzel akár hobbiból is össze lehet hozni érdekes dolgokat...!

(Kár, hogy a mai fiatalok többsége csak játszik egész nap... Régebben azért jobban kiéltük a kreativitást...)

Apropó, '87 körül én is írtam egy ilyen gömbös ray-tracert, de nem ám C-ben, hanem 68k FPU ASM-ben (A500+030+882 ), úgy akkori mércével egész gyors volt, néhány gömbbel pár perc alatt végzett -- 320x256-ban. Ja, előbb tudott textúrákat, mint az akkori ismert ray-tracerek. Animokat is tudtam menteni vele, a klubban ("Csoki") kicsit néztek, hogy ezt meg mivel csináltam... Valahol itt eszi az enyészet egy 3.5"-es floppyn... 24 éve... Basszus! (Azért most engem nem úgy kell elképzelni, mint egy ősz aggastyánt, tizenéves koromban csináltam, meg rajtam amúgy is kevésbé fog az idő. )

[ Szerkesztve ]

Ezt nézted már?: smallpt
Van már OpenCL port is: SmallptCPU/GPU
Érdekessége, hogy nem visszafelé követi a fényt, hanem a lámpától indítja a sugarakat. Így kicsit lassú, de úgy 10 óra alatt meglehetősen élethű eredményt ad.

Talán ennek továbbfejlesztése a SmallLuxGPU v1.5 (OpenCL). YouTube
(Érdemes 720p-ben nézni!)

ps. egyébként már az AMD-től is tölthető olyan videokártyadriver-csomag, amiben benne van az OpenCL driver is.

[ Szerkesztve ]

az elég elborult dolog azért, hogy a fényforrásból indítja a sugarakat, én nem lennék ennyire türelmes... szvsz a kétirányú sugárkövetés nem lenne sokkal rosszabb, de nagyságrendekkel gyorsabb.

Ez egészen jól néz ki, ráadásul realtime? Ez tetszik, gratulálok a kódjaidhoz! Az ilyen pillanatokban szoktam elgondolkodni azon, hogy összegyűjtöm a pénzt egy OpenCL-t támogató videókártyára és a körítésére nézelődési célokra, de azon kívül hogy nézem a demókat sokat nem tudnék vele kezdeni, programozásból elég gyökér vagyok.

dezz: Én azt a floppy-t minimum páncélszekrénybe zárnám. Mindenesetre gratulálok a te programozási tudományodhoz is!

[ Szerkesztve ]

Hat igen, nem nagyon erolkodtem a kepkirakassal, ugyhogy alapvetoen 2 magos procira lett irva, ugy erdemes futtatni.

Elvileg megy cpu-n is, ha kodot akarsz irni, igaz, lassabb, de az amd driverrel nekem 4 magos intelen is ment... Mondjuk joval lassabban, mint grafkartyan, az igaz...

Igen, azota betettek a driverbe is...

Hm, kipróbáltam, és tényleg van ilyen! Köszönöm a tájékoztatást!
Viszont próbáltam a te benchmark-jaidat, és mindegyiknél hasonló jelenség lép fel:

User-error lesz ez, vagy más lesz a probléma? ("Ezek a régi cuccok, mindig csak a baj van velük!" )
CPU: Pentium M 735
GPU: ATi Mobility Radeon 7500 (Omega driverrel)

[ Szerkesztve ]

Nincs opencl kompatibilis gpu-d...

Okés, köszönöm, én kérek elnézést!

Ezt elfelejtettem linkelni: smallluxGPU
Ez is úgy működik, de algoritmikailag valahogy megoptimalizálva. Ez egy bizonyos -- több elterjedt 3D-animációs programcsomag rendererjeként alkalmazható -- LuxRender "kódmag-kivonata", aminek egyes legszámításigényesebb részeit már átírták OpenCL-re. Valamilyen előnye bizonyára van, a gyorsabb módszerekkel szemben... Pl. a videóban olyan minőségű és élethűségű animációk vannak, amit én máshol még nem láttam...

(#4) mrgg: Ma már nem biztos, hogy menne... Jópár éve már csak kisebb mikrokontrollereket programozom, szintén ASM-ben, de nincs benne sok matek. (Legutóbb úgy 5 éve kellett egy kicsit C-ben melóznom, PC-n.) Szóval, csak nosztalgiából elevenítettem fel...

(A "még ha csak egy gömb+talaj+ég is" semmi esetre sem Lenox munkáját minősítette -- én sem éppen egy nap alatt írtam meg a sajátomat --, hanem arra vonatkozott, hogy ez kevesebb számítás igényel, mint ha sok-sok poligonból állna. De így sem semmi, hogy ilyen 60 fps-ekkel fut!)

mrgg: OpenCL driver fent van? Gondolom, az ahhoz is kell, hogy CPU-n fusson. Vagy nem, Lenox?

[ Szerkesztve ]

Mindenkepp gpu device-t ker, ugyhogy nem menne cpu-n driverrel sem. Nyilvan at lehetne irni, hogy ha nincs gpu, akkor menjen, de ez inkabb olyan teszt volt csak, most inkabb fizikazok egyelore.

Egy gömbtől manapság nem ájul el senki.
Én egy kombinált voxel enginnel több tízezeer gömböt tudok realtime egymásba tükröztetni. És nem holmi opencl vagy cuda, hanem hullaprimitív CG shaderrel.

És nem azért írtam, hogy elvegyem a kedved, hanem hogy felnyissam a szemed.

Ha már erre jártam, adot néhány használható ötletet, ami később jól jöhet.

Sokszor nem a CUDA tesz gyorsabbá egy programot, hanem néhány utasítás. Sokan nem ismerik a step(a,b)-t, ahol attól függően, hogy melyik paraméter a nagyobb 1 vagy 0 kerül a vektor komponensébe.
Ezzel az egyszerű utasítással egyszerre 3 IF-et lehet helyettesíteni.

Egy bounding box ellenőrzés, ami ennyi lenne:
if(pont.x >=bbox.min.x)
if(pont.y >=bbox.min.y)
if(pont.z >=bbox.min.z)
if(pont.x <=bbox.max.x)
if(pont.y <=bbox.max.y)
if(pont.z <=bbox.max.z) OKE

ennyire redukálódik:
float3 e=step(bbox.min, pont) + step(pont,bbox.max)
e.x=e.x+e.y+e.z
if(e==6) OKE

A futási idő sokkal rövidebb.

Egy raytracelt sugár és egy bounding box metszéspontját pedig így kapjuk meg a legrövidebben:
bbox.minmax=lerp(bbox.min,bbox.max,ray_orientation)
float3 e=(bbox.minmax-eye)/ray
float u=max(e.x,max(e.y,e.z))

Az első sor meghatározza, hogy a sugár a boxot melyik oldalról fogja eltalálni. A második EGYSZERRE számolja a box eye felé eső 3 oldalának a távolságát. Mivel mind egyenként egy-egy skalárművelet lenne, így egy időben elvégezhető a három egyszerre. A harmadik sor meghatározza, hogy melyik metszéspont van a legtávolabb. Ez kell nekünk, ebből kiszámítható az a pont, ahol a sugár metszi a boxot.

float3 pont=eye+ray*u
Ezután már csak az elején leírt ellenőrzést kell végrehajtani.
Ez így sokkal rövidebb, mint amit a neten általában találsz.

Kérdezhetnéd, minek a bounding box, ahhoz rekurzió is kellene. Egy ilyen boxokból álló fával már elég érdekes dolgokat lehet művelni.

Nos, megoldható a rekurzió is egyszerű shaderrel.
A kulcs, az ugrás, a faág levágása. A megoldás pedig annyi, hogy ezt az ugrást egyszerű textúra koordinátával oldjuk meg.

A CPU-n lefuttatod a rekurziót, és minden ág bounding boxát felsorolod lineárisan, tehát sorba egy textúrába. A lényeg az, hogy minden boxhoz tartozik egy ugrási "cím", vagyis egy textúra koordináta, ami a faág levágása esetén elő kell venni.

A shadernek már csak végig kell futnia a textúra pixelein sorba, és a sugár nem metszi a boxot, akkor elővenni az ugrási koordinátát, és onnan folytatni.

Az eredmény teljes mértékben megegyezik azzal, mintha rekúrzió történne a shaderben. Több százezer ágból álló fát 300-500 lépésben végignézi a shader.

A voxel raytracing már egy másik történet.

A ray_orientation komponense 1, ha a ray adott komponense negatív, 0 ha pozitív.
Nyilván a negatív irányultságú sugár a boxot a pozitív lapján találja el.

Kicsit felreertetted a dolgot, ezekkel nem a vilagot valtom meg, csak kiprobaltam az opencl-t. Koszi a tippeket, valakinek biztos hasznos, cg-t 2003-ban probaltam eloszor, ezeken mar tul vagyok.

Helló!
Én kíváncsiságból kipróbálnám ezeket a benchmarkokat de már egyik sem elérhető.

Ismét csak kíváncsiságból érdekelne, hogy is működik ez? A megjelenítés opengl-lel történik vagy mivel? Vagy csak simán egy pixel tömböt akármilyen rajzolással amit az os biztosít?
Másik kérdésem (ami számomra még érdeksesebb) az lenne, hogy hogyan viszonyul ez sebességben/praktikumban ahhoz mintha OpenGL-ben renderelnél? (ami ugye amúgy grafikára van kihegyezve)

Hat sajna mar torlodtek. Altalaban opengl-t szoktam megjelenitesre hasznalni, de ennel csak siman a windows apival kirajzoltam bitmapkent. Azota masik progiban mar hasznalom az opencl/opengl interop funkciot, szoval grafkartyan belul atmegy opengl-be a pixel adat, ennel meg visszajott cpu mem-be, es onnan rajzolodott ki.

Ezt valoszinuleg meg lehetne csinalni opengl-lel is hasonlo sebesseggel. Marmint shaderekkel, ugy ertem. Meg amugy ha csak az lenne a cel, hogy hasonloan kinezo kepet rendereljunk, azt sokkal gyorsabbra is meg lehet csinalni, opencl-le, vagy opengl-lel, vagy mashogy, de nem az volt a celja. Pl. perlin-noise szamolas szamitasigenyes, ki lehet rakni texturaba, csak akkor a sebessegbol nem derul ki, hogy milyen lenne, ha ezt is szamolna.

és, van azóta valamilyen előrelépés?

elszomorító azt látni, hogy még az opencl nagy evangelizátorai sem tudják működésre bírni ezt a szutyok platformot.

[ Szerkesztve ]

A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

Heló!

Engem is érdekelne ez az OpenCL- anno még direkt ezért vettem GTX470 et, VrayRThez.

Viszont a mai napig nem tudtak elérni olyan minőséget, hogy azt final rendernek lehessen használni.
Rengeteg dolgot nem támogatnak, átlátszóság, reflexiók, ezek mapolva, normal map stb.
Így eléggé lecsökken a használhatósága.

Azt szeretném megkérdezni, hogy tudtok e olyan render motort , lehetőleg 3ds-kompatibilist, de minden más is érdekel, akár Blender akár más; ami érdemben használható a gyakorlatban.

Az elmúlt kb 1 évben nem próbálkoztam vele, maradtam a CPU-n renderelésnél.
Nemsokára ahogy időm engedi csinálok megint egy összefüggő tesztet pl Octane render stb.

De ha valakinek hasonló infója van szívesen fogadom!

Halas - http://www.flickr.com/photos/halaskyo

Mar milyen ertelemben? Azota is foleg cudazok, kicsit opencl-ezek, de az uj mac pro miatt nemsokara tobbet kell majd opencl-ezni. Ezzel a kis teszttel nem foglalkoztam tobbet azota.

#22: Nem foglalkozom sajna raytrace-szel.