Hirdetés

Új hozzászólás Aktív témák

  • lenox
    veterán

    é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.

    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.

  • HalasKYO
    aktív tag

    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!

  • Pikari
    veterán

    é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.

  • lenox
    veterán

    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.

  • mzso
    veterán

    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)

  • lenox
    veterán

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

    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.

  • d3tto
    csendes tag

    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.

    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.

  • d3tto
    csendes tag

    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.

  • d3tto
    csendes tag

    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.

  • d3tto
    csendes tag

    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.

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

  • d3tto
    csendes tag

    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? :N

    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. :D 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ő. :D )

    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.

  • lenox
    veterán

    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?

    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.

  • dezz
    nagyúr

    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.

    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?

  • lenox
    veterán

    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)

    Nincs opencl kompatibilis gpu-d...

  • mrgg
    tag

    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...

    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)

  • lenox
    veterán

    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 :D 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.

    Igen, azota betettek a driverbe is...

  • lenox
    veterán

    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! :)

    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...

  • lenox
    veterán

    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? :N

    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. :D 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ő. :D )

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

  • mrgg
    tag

    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! :)

  • sekli
    addikt

    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 :D 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.

    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.

  • dezz
    nagyúr

    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 :D 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.

  • dezz
    nagyúr

    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? :N

    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. :D 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ő. :D )

Új hozzászólás Aktív témák