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

• #6 Meteorhead aktív tag LordX #5

  Új Válasz 2014-08-27 08:52:38 #6

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz LordX #5 üzenetére

  Én nyílván nem látok bele a működésébe, de úgy tippelem, hogy a libcxxamp.so nem csinál sokkal többet, mint a libopencl.so, ami csak az ICD-t tartalmazza, azaz csak az implementációk futásidejű betöltéséért felelős (amit OpenGL alatt kvázi pl. a GLEW pótol). Ettől még a runtime, ami a munka kemény részét végzi, az a libamdocl64.so és társai libekben vannak.

  Lehet ez csak szőrszál hasogatás.

  Arra egyébként kíváncsi lennék, hogy OpenCL 2.0 hogyan is fogja AMP esetében automatikusan eltűntetni a másolásokat? Az addig ok, hogy a concurrency::array az std::vector-hoz hasonlóan tartalmaz egy host oldali pointert is, de számomra sosem volt tiszta, hogy milyen kapcsolatban van a concurrency::array, az std::vector, és a cl:uffer egymással. A cl:uffer csak egy handle, ha lemásolom nem történik semmi. A concurrency::array esetében a spec szerint deepcopy történik, ahogy az std::vectornál is.

  Mennyiben állja meg a helyét az a hasonlat, hogy a concurrency::array a vectorhoz hasonlóan konkrétan tárolja is az adatot (minden szempont szerint)? Engem a host oldali pointer része zavar, mert ha egyszer visszakértem az adatot host oldalra, akkor lefoglal magában egy akkora területet. De ez mikor szabadul fel? Ki vagyok vele segítve, ha OpenCL 2.0 megtehetné, hogy ne másolgasson, de cserébe adatduplikál (és evvel tulajdonképpen másolnia is kell, még ha nem is BUS-on keresztül).

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