Leírás

3D grafikával kapcsolatos bejegyzések és cikkek. A Quadron Virtual Particle nevű game engine fejlesztése.

Stuff

Anything related to game development.

Contact: darthasylum at gmail dot com

Nemlineáris cikkek

Mi ezeknek a célja?

Leginkább az, hogy magyarul is elérhető legyen programozási anyag, olvasmányos formában.

A cikkek kódja GitHub-ról is elérhető. (*)-al jelölöm azt a cikket ami nemrégiben frissült.

A színek a nehézséget próbálják jelezni, de az, hogy egy cikk piros nem azt jelenti, hogy csak a profiknak szól!

 

 

 

 

 

 

 

 

Hörcsög (Adobe Flash szükséges)

The Asylum

3D grafikával kapcsolatos bejegyzések és cikkek. A Quadron Virtual Particle nevű game engine fejlesztése.

Friss topikok

Címkék

HTML

OpenCL: jobb vagy rosszabb?

2013.01.05. 20:48 | darthasylum | 1 komment

Kísérletképpen megcsináltam a causticot OpenCL-el is, mert gondoltam hogy ez majd milyen jó lesz és talán lehetőséget ad olyan adaptív finomításra, mint amit geometry shaderrel csinált meg Wyman.

Először is: a használata baromira fapados, dehát ezt az ilyen OpenXX cuccoktól már megszokhattam volna. Nincs egyértelműen definiálva, hogy mit lehet átadni egy adott kernelnek, tipikusan minden bizbaszhoz memory objectet kell csinálni. Az se mindegy, hogy kernel argumentumnak mit adsz meg, például struktúrákkal baromira nem tud mit kezdeni (gondolok itt a vertex adatra). Konstansként működnek a structok is.

Egy kicsit a koncepcióról. Egy OpenCL képes eszköznek van n db compute unit-ja, ami alatt egy sokmagos processzort kell érteni. Pl. az én videókártyámnak van 16 db 8 magos procija. Tipikusan azt szeretnéd, hogy egy compute uniton több száz kernel példány fusson egyszerre, mert akkor használja ki megfelelően. Persze ez függ attól, hogy milyen kernelről van szó, és itt a legnagyobb probléma. OpenCL oldalon ugyanis a compute unitokra nincs egyértelmű leképezés.

Két fogalom van, amivel szabályozni lehet a teljesítményt: az egyik a global worksize, ami gyakorlatilag a munkaterület elemeinek számát kell, hogy megmondja (pl. egy 512x512-es kép feldolgozásához 512x512). Persze lehet kisebb, de akkor értelemszerűen többször kell lefuttatni a programot. Ez pongyolán mondva ennyi darab work item-et jelent (kernel példányt). A globális terület fel lesz osztva work group-okra, de egy ilyen csoport nem teljes egészében fed le egy compute unit-ot (és ez baj...). A másik logikai csoport így nyilván a local worksize, ami azt mondja meg, hogy egy csoport hány work itemet fog össze.

A probléma még nem lenne akkora, mert a compute unitok számát el lehet kérni. Azt viszont, hogy egy compute unitnak hány végrehajtási egysége van, azt már marhára nem, és nekem ezen a ponton halt meg az egész koncepció. Pontosabban ott, hogy a shaderes megoldás kenterbe veri az OpenCL-est (pedig sokféle variációt kipróbáltam). A másik dolog ami baromira zavart, hogy ez csak és kizárólag párhuzamos programozási problémákra használható, és szekvenciális outputot az életbe nem tud magából kiszenvedni (pedig pont ez kéne, mert geometry shaderrel ezt meg lehet csinálni).

Szóval senki ne rohanjon OpenCL-t tanulni, ez még nagyon messze áll a general purpose-től...

A bejegyzés trackback címe:

http://darthasylum.blog.hu/api/trackback/id/tr725000287

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.