2. Fórumok
  3. Processzorok, tuning
  4. Az Intel visszahozza az önálló OpenCL SDK-t
Legfrissebb anyagok
PROHARDVER! témák
Mobilarena témák
IT café témák
GAMEPOD témák
Keresés

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

  • #21 DRB senior tag Fiery #19
    Új Válasz #21
    Ú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 #19 üzenetére

    A billentyűzetes dolgot ne vedd zokon, csak ugratlak. :D Természetes el tudom olvasni, megerőltetés nélkül, az ékezet nélküli magyar szöveget, főleg, ha egy értelmes ember írja. Egyébként csak az tűnt fel, hogy mindig így írod az „é”-t: e', de most van egy ilyen mondatod: ...akkor remek SVM-képes APU-t vasarolhat mar most is (pl. Carrizo)., ezt nem bemásoltad.

    „Es a csajozas nalam mar nem jatszik, iden immar 15 eve”
    Ja az más, akkor ezért nem tudod mivel lehet hanyatt vágni egy 20 éves bringát, nem érti miről beszélsz, de az a lényeg hogy okosnak tűnj, manapság az IT téma tökéletesen megfelel erre a célra, ez a menő, sőt az sem baj ha te sem érted mit beszélsz, csak akkor nehogy egy IT spinét próbál oltogatni a dumával. :DDD

    Tényleg nem érdemes iGPU vs. dGPU-ról vitatkozni, mert nyilván úgy kell megírni a kódot, hogy ne kelljen sokszor hozzápiszkálnija a dGPU-nak a ram-hoz, kb. csak programozói hozzáállás kérdése.

  • #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 )

  • #18 DRB senior tag Fiery #17
    Új Válasz #18
    Ú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 #17 üzenetére

    Ha jól értem, akkor a DirectX-et nem jól detektálja valamiért az AIDA? Az OpenCL-re akad másik szoftver, az is 1.2-t ír egyébként. :D Amúgy azért kérdeztem a 290X/390X-et, mert azt hittem támogatja az OpenCL 2.0-át(SVM-et, meg úgy egyébként az ezzel kapcsolatos dolgokat), úgy rémlik az AMD zagyvált erről valamit, de ezek szerint nem jól rémlik, vagy valamelyik FirePro-ra írták és ezzel keverem. De igazából mindegy, csak kíváncsi voltam, hogy az AIDA64 hibázik, vagy tényleg az AMD beszél ződségeket.

    Erről az iGPU sebességről meg felesleges szerintem vitázni, ha valamelyik emlegetett dGPU támogatná az SVM-et, akkor lenyelné keresztbe a Carizzo gpu-ját, még úgy is, hogy hozzászámoljuk a PCIe késleltetését. De amióta a prociban van a vezérlő, és nem az alaplapi chipsetben, azóta sokat csökkent késleltetés. Bár tény, hogy még így is sokkal lassabban éri(vagy érné) el a dGPU a rammot, mint egy mostani APU(iGPU + CPU).

    Az ékezetekről sejtettem, hogy ezt fogod írni, mégis akad néha itt-ott egy „é”, talán „á” is, szóval valami nem stimmel. :F ;] :DDD Van egy programozó haverom, még a suliból marad rajtam, na ő is mindig azt mondja amit te(gondolom ez valami Hi tech csajozós duma lehet), de ehhez képest magyar a billentyűje, sőt még az oprendszerben is magyar van beállítva(esetleg ha dolgozik akkor nem), csak ő direkt ékezet nélkül hirdeti az igét. :DDD

    Szerk: Közben megtaláltam egy részét annak amit lehet félreértetem: [link]

  • #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ő. ;]

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

    Device-side kernel launch? Annak elvi szinten pont, hogy dGPU-n van tobb ertelme, ha tenylegesen gyorsabb mint a host-side kernel launch.

    Az SVM-hez meg a kotelezoen tamogatott szint az lenyegeben nem szigorubb, mint amit eddig is lehetett tudni egy normalis map/unmap implementacioval cimforditas mellett, nem?

  • #11 DRB senior tag Fiery #10
    Új Válasz #11
    Ú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 #10 üzenetére

    És PH!-val mi van, itt is 2.0-át írnak, vagy tpu-n is, meg a úgy a fél interneten.

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

Hirdetés