Hirdetés

  2. Fórumok
  3. Processzorok, tuning
  4. Az Intel visszahozza az önálló OpenCL SDK-t
Keresés

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

  • #20 con_di_B tag Fiery #15
    Új Válasz #20
    Ú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 Fiery #15 üzenetére

    "OpenCL maintains memory consistency in a coarse-grained fashion in regions of buffers. We
    call this coarse-grained sharing. Many platforms such as those with integrated CPU-GPU
    processors and ones using the SVM-related PCI-SIG IOMMU services can do better, and can
    support sharing at a granularity smaller than a buffer. We call this fine-grained sharing. OpenCL
    2.0 requires that the host and all OpenCL 2.0 devices support coarse-grained sharing at a
    minimum." - OpenCL 2.0 Specification 5.6.1

    Szoval jah, az IOMMU csak egy pelda, hogy azzal pl lehet fine-grained-et csinalni. Viszont a coarse-grained meg kotelezo, ezert magyaraztam rola, hogy hogyan lehet rapatkolni IOMMU nelkuli, meg gyakorlatilag barmilyen hardverra. Csak ilyen szempontbol vizsgaltam a kerdest, maga a feature engem mindig is relative hidegen hagyott, es inkabb veszelyt latok benne, mert lehetove teszi a portolas "felgyorsitasat" legacy C/C++ kodokrol.

    Az OpenCL 1.x az annyira kotott memoriamodellel jott ki, hogy igy is ugy is at kellett varialni az adatszerkezeteidet, hogy egyaltalan futtathato programot kapjal (amibol nem mellesleg az ezutan elert speed-up nem kis resze szarmazott), ezzel szemben ha rafogod, hogy te marpedig fine-grained APU-kat tamogatsz kizarolag, onnantol kezdve barmennyire kokany meglevo adatszerkezetet radobhatsz a GPU-ra a meglevo (90%, hogy mar eleve optimalizalatlan, trehany) kodbazisodbol, aztan meg majd lehet csodalkozni, hogy miert sokkal lassabb, mint CPU-n volt.

    Aztan persze mondhatod, hogy ott van az az <1% az eseteknek, amikor valaki tenyleg valami ertelmes CPU-GPU ko-op funkciot irt, de mivel minimum ket kernel launchrol beszelunk, meg ket kulon device-rol, es a szinkronizacios primitivek meg nem lettek erosebbek a 2.x-ben sem, ezert a biztos mukodesert ugyanugy kenytelen leszel buffer-level szinkronizalni, ha van fine-grained support, ha nincs.

    Ennel rosszabb mar csak az lesz, amikor jonnek a szemaforok meg a felteteles valtozok, hogy a multi-threaded sracok is ugy erezzek, hogy ertenek valamihez... (bocs-bocs-bocs :R )

  • #16 DRB senior tag Fiery #15
    Új Válasz #16
    Ú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

    DRB

    senior tag

    válasz Fiery #15 üzenetére

    Úgy nézem a 290X(ergo a 390X) is ezeket támogatja, kivéve a cl_khr_depth_images-t. Gondolom driver kérdése az egész, bár esküt most így erre nem tennék. :) Mondjuk azt azért hozzátenném, hogy mindez az aida szerint, de hát az aida szerint a hardveres dx támogatás is csak 11.1, egy másik fülön meg már 11.2, valóságban meg tudjuk, hogy 12. Ne értsd félre, mindezektől függetlenül az aida egy remek kis progi, talán a műfajában a legjobb, de azért nem tökéletes, persze ilyen nincs is ;)

    ”Kulonosen mivel ha valakinek pont az SVM-re van igenye, akkor remek SVM-képes APU-t vasarolhat mar most is (pl. Carrizo).„
    Ez lehet, de Carizzo igpu-ja köszönőviszonyban sincs, teljesítményben értem, mondjuk egy 390X-hez.

    Hadd kérdezzem már meg, te szándékosan írsz ékezet nélkül? Rohadt idegesítő. ;]

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