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

• #15 Fiery veterán con_di_B #14

  Új Válasz 2015-11-24 20:34:17 #15

  Ú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

  

  Fiery

  veterán

  válasz con_di_B #14 üzenetére

  Nem azt mondtam, hogy OpenCL 2.0 = SVM, hanem hogy az az egesznek az apropoja, az indokolta a major verzio ugrast kapasbol. Vannak mas ujdonsagok is, amiket tamogathat egy dGPU is. Es nyilvan az SVM bizonyos funkcioit tamogatni lehet dGPU-val is, mint ahogy az nVIDIA oldalan, a CUDA-ban is van megosztott memoria, de a legtobb esetben ez inkabb csak potcselekves, mint valoban hasznos feature. Ha ezzel egy adott dGPU meg tud felelni az OpenCL 2.0-nak (amihez valoban nem kell SVM, rosszul emlekeztem, lasd lentebb), az tok jo, de en me'g nem lattam olyan AMD dGPU-t, ami SVM-et tamogatna, ill. ami a device kapcsan OpenCL 2.0 verziot riportolna magarol. Es egyik sem tamogatja a cl_amd_svm egyedi OpenCL kiterjesztest sem. Nyilvan meg lehetne oldani, takolassal meg trukkozessel egy dGPU kapcsan is az SVM tamogatast, de ez SZVSZ inkabb egy felesleges marketing huzas lenne, mint valoban hasznos feature. Kulonosen mivel ha valakinek pont az SVM-re van igenye, akkor remek SVM-képes APU-t vasarolhat mar most is (pl. Carrizo).

  Szerk.: Sz'al utananeztem, es elvileg ezek a kiterjesztesek szuksegesek az OpenCL 2.0-hoz:

  cl_khr_3d_image_writes
  cl_khr_byte_addressable_store
  cl_khr_depth_images
  cl_khr_global_int32_base_atomics
  cl_khr_global_int32_extended_atomics
  cl_khr_image2d_from_buffer
  cl_khr_local_int32_base_atomics
  cl_khr_local_int32_extended_atomics

  Ezek kozul a cl_khr_depth_images-et nem tamogatja az R9 380 (Antigua), a tobbit tamogatja.

• #14 con_di_B tag con_di_B #13

  Új Válasz 2015-11-24 19:16:35 #14

  Ú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

  

  con_di_B

  tag

  válasz con_di_B #13 üzenetére

  Peldaul igy: CL_MEM_USE_PERSISTENT_MEM_AMD.

  Sosem hasznaltam, de ha jol ertettem, ezt tudja azt, hogy a buffer mindig ugyanoda pinnelodik.

  Ha jol ertem, ha ezt tudod, plusz meg annyit megcsinalsz, hogy a kernel launch automatikusan szinkron esemeny legyen, akkor gyakorlatilag kesz van a coarse grained SVM implementaciod. Nem teljesited betu szerint, hogy ugyanazt a virtualis pointert hasznalja a ket eszkoz, de osszesen egyszer tortenik cimforditas, a host oldalon nyugodtan rogzitheted a mutatoidat, ervenyesek fognak maradni, az meg, hogy a GPU valojaban mivel cimez az inkabb filozofiai problema. Ezen kivul az is problema, hogy rohadt sok pinned memory-t fogsz lefoglalni host oldalon, es jo esellyel ki is fogysz belole, dehat nem is azt mondtam, h ez egy jo megoldas, csak azt, hogy meg lehet csinalni.

  De javitsd ki ha tevedek, mert az uj 2.0-s feature-oket sajnos meg nem volt alkalmam kiprobalni a gyakorlatban, szoval lehet olyan scenario, amit ez nem fed le.

  A Fine grained SVM az nyilvan tok eselytelen, de az amugy is csak egy APU/SoC szeru allaton lehet erdekes, ennek megfeleloen, az eleve opcionalis feature.

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