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

• #48 LordX veterán Abu85 #21

  Új Válasz 2015-12-31 22:07:12 #48

  Ú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

  

  LordX

  veterán

  válasz Abu85 #21 üzenetére

  Egy példát mondj, amiről vita van. Max valami iszonyatosan speciális eset, amivel csak minden február 30.-án találkozik a programozó.

  OpenCL-ben programoztam, ami majdnem az összes létező CPU-n és GPU-n futott: AMD GCN, nVidia Fermi+Maxwell, Intel Haswell+Skylake, Qualcomm Adreno 330, Mali T624, Mali T760 GPU-kon és x86 (Intel és AMD runtime-al), ARM CPU-kon teszteltem. Kizárólag PowerVR és FPGA-k alatt nem. Soha semmi olyan problémába nem futottam bele, hogy valamit egyik gyártó így értelmezett, a másik úgy. Ami szabványos kód, amit a Khronos SPIR fordító megevett, az mindenhol lefordult, ha nem számítom azt, ami nyilvánvalóan bug.

  És mivel a legtöbb OpenCL implementáció frontendje CLang alapú, még a bugok is többnyire ugyanazok. Nem véletlenül az LLVM-IL volt az alapja a SPIR 1.2-nek.

  A SPIR-nek meg marhára nem az volt a célja eredetileg, hogy a nem egyértelmű dolgokat megoldja, arra elég lett volna az, hogy módosítják a szabványt (ahogy egyébként ezt csinálják is, az OpenCL 1.2-nek van vagy 10 revíziója, némelyik az után jött, hogy már megvolt a nem-draft 2.0), hanem hogy ne kelljen forráskódot szállítani, ha nem akarsz binárist (és nem akarsz, mert az még gyártón belül se kompatibilis). Teljesen életszerűtlen és logikátlan az, amit mondasz, hogy van egy szabvány, ami itt meg ott nem egyértelmű, és a szabvány testülete ezeket nem javítja ki annak ellenére, hogy gőzerővel dolgoznak folyamatosan új verziókon, hanem behoznak egy teljesen új szabványt, hogy majd az megoldja.

• #14 LordX veterán #32839680 #9

  Új Válasz 2015-12-30 23:59:58 #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

  

  LordX

  veterán

  válasz #32839680 #9 üzenetére

  Hát, véleményem szerint az aktuális OpenCL-hez képest az aktuális CUDA szar.. 1.2-nél persze jobb a 3 éves CUDA is, csak azt már mindenki (lassan including mobil GPU) meghaladta az nVidiát kivéve.

  Azért használja mindenki a CUDA-t, mert mindenki CUDA-t használ. Arra vannak hülyére optimalizált libek.

• #4 LordX veterán

  Új Válasz 2015-12-30 20:27:11 #4

  Ú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

  

  LordX

  veterán

  Az OpenCL forditók közötti eltérés nem értelmezésbeli eltérés... Vagy szabványban megengedett implementációs különbségekről van szó, vagy bugról.

  Bugok a SPIR-V finalizerek közt is fognak eltéréseket hozni, úgyhogy ezt a szálat most hagyjuk.

  Az implementációs különbség meg olyan, hogy egyik esetben 64 szál lehet egy workgroupban, a másikban 256, a harmadiknál a legszélesebb használt adattipustól függően 4/8/16, hogy az egyikben 4k __local memory van, a másikban 32k, stb. Itt vagy megirod a kódod a legkisebb közös többszörösre, és mindenhol lassú leszel, vagy #ifdef __AMD__ #elif __INTEL__ #else #endif (vagy dinamikusan kéred le, effektive ugyanaz). És ezen a SPIR-V se segit semmit.

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