Keresés

Hirdetés

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

  • Abu85

    HÁZIGAZDA

    válasz lenox #2 üzenetére

    Tom Malloy összegzése:

    Ott van, hogy a teljesítmény portolhatóságán segít.

    A tradicionális accelerator kártyák esetében nagyon függ a sebesség a feladattól. Nem felelnek meg minden igénynek. Az igaz, hogy baromi gyorsan végeznek a végrehajtással, de a data transfer sok időt elvehet.

    Például az offload memcached technikánál a szervereknél. Látható, hogy az accelerator szerepét betöltő Radeon HD 5870 baromira gyorsan végez a feldolgozással, de a data transfer megöli a sebességet.
    Hasonló következtetést vont le az NVIDIA is a jövővel az Ecehlon projekt tanulmányában. [link]
    ... CPUs and GPUs will be integrated on the same die with a unified memory architecture. Such a system eliminates some of accelerator architectures historical challenges, including requiring the programmer to manage multiple memory spaces, suffering from bandwidth limitations from an interface such as PCI Express for transfers between CPUs and GPUs, and the system-level energy overheads for both chip crossings and replicated chip infrastructure.
    Van ahol nem számít annyira a data transfer büntetése, de jellemzően jelentős probléma, így Tom Malloy nyugodtan beszélhet erről általánosan.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz wetomi #3 üzenetére

    A HSA nem függ az OS-től, szóval nem lehet gond a Linux disztribúciók támogatása sem. Persze önmagában nem akkora fókusz, mint az elterjedt OS-ek. Erről a HSA alapítvány gondoskodik. Ennek résztvevői lényegében azok a vállalatok, amelyek beléptek. Mindegyik cégnek van egy képviselője. [link]
    Önmagában az AMD hatalma a draft specifikációk megalkotásával véget ért. Az alapítvány azt a célt szolgálja, hogy minden cég egyenrangú legyen a HSA támogatása szempontjából. Ennek megfelelően a további fejlesztéseket nem csak az AMD, hanem résztvevők végzik egységesen.

    Nem, a közösség kezébe nem adják a HSA fejlesztését. Ez az alapítvány feladata. A gyártók feladata, hogy a saját finalizert és a kernel drivert megírják. Mivel ezek a fizikai hardverhez kötődnek, így erről mindenkinek gondoskodni kell.
    A fejlesztésbe viszont be lehet lépni, de csak úgy kívülállóként a közösség ezt nem fejlesztheti.
    Nyílt forrású sosem lesz. Az alapítványon belül a tagok ingyenes jogot kapnak a használatára, de minden fejlesztést meg kell osztani mindenkivel az alapítványon belül.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz vanhalen #7 üzenetére

    Az OpenCL problémája nem a rendszer hibájából ered, hanem abból, hogy a mainstream programozók nem fognak hozzá, mert nem szeretik a "pöcsölést". A HSA nem az OpenCL ellenfele. Kiegészíti azt. Lehet rá OpenCL-ben programozni. Amit a HSA eliminál az a "pöcsölés".

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz lenox #15 üzenetére

    Nem tudom, hogy más mit írt, én megnéztem az előadást. Egyértelműen a teljesítmény portolhatósága volt a téma, és Tom Malloy szerint ezen javíthat az egységes címtér.

    Az előadás ilyen ömlesztett volt, jöttek az emberek, és mondták a magukét. A data transfer problémája jelentős. Azt mondták, hogy nagyon függ a feladattól, de a helyzet az, hogy van ahol ez elkerülhetetlen. Lényegtelen, hogy a HD 5870 mikor volt. Ettől még a teljesítményt a data transfer fogja vissza. Rakhatsz akármilyen erős gyorsítót oda, ha az adatokat másolgatni kell. Pont ezért mondja az NV is egy ideje, hogy a tradicionális accelerator kártyáknak nincs jövőjük.

    Az AFDS programozóknak szóló rendezvény. A problémákat vázolták a vezető szoftvermérnökök. Nekik nem céljuk a marketing. Azért lettek meghívva, hogy tanítsák a fiatal generációt.

    Nem. Ahogy látom az AMD/Intel/AMD/ARM ... hosszútávú roadmapját mindenhol a teljesen koherens megosztott memória szerepel, mint killer fícsőr. Persze elképzelhető, hogy tévednek, de annyira egységesen látják a jövőt, hogy kicsi a valószínűsége.
    A stacked memory pedig sokféle lehet, de inkább cache szempontból van értelme ilyen jövőképek mellett.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz vanhalen #17 üzenetére

    Hardver szempontjából az AMD Vision APU-k támogatják a HSA-t. A Trinity a HSA MMU kiterjesztést is. Az ImgTec esetében a PowerVR 5 család SGX 545 IP-je támogatja, illetve a készülő Rogue, az majd támogathat extrákat is. Az ARM esetében az új generációs Mali T család támogatja a HSA-t, egyelőre nem tudom, hogy milyen kiterjesztésekkel.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz vanhalen #22 üzenetére

    Az AFDS-en lehet jelentkezni a publikus bétatesztre. Szerintem majd az alapítvány oldalán is meg lesz ez hirdetve. Gondolom, aki kiadott egy rakás pénz, hogy ott legyen az AFDS-en, annak annyi előny jár, hogy hamarabb kapják meg a toolokat.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz dezz #24 üzenetére

    Többségüknek közvetlenül nem, de a HSAIL teszi lehetővé nekik, hogy ne kelljen hardverre optimalizálni. Közvetve tehát az előnyiből profitálnak. De hogy egyértelműbb legyen átírtam. :)

    (#25) DRB: A legegyszerűbb felfogása ennek a Java. A Java bytecode is egy vISA. Ez is hasonlóan működik, csak más szempontok szerint fejlesztették.
    API-nak semmiképp sem nevezhető.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz DRB #29 üzenetére

    Az API-t azt tényleg hagyjuk most mert ez nem az. Ez az API és a hardver között lehet. De elsősorban a GPU compute a cél. A DX-szel nem akar mit kezdeni, egyelőre.
    A működés le van írva a cikkben. Megírsz egy programot OpenCL-ben mondjuk, de úgy, hogy csak az algoritmussal és a futtatással törődsz. A HSA Runtime lesz az a köztes réteg, mely helyetted elvégzi a párhuzamosítást. Ezután jönnek a gyártóspecifikus dolgok, amik a HSAIL kódot a fizikai hardverre fordítják.

    (#34) DRB: A konzoloknak van low-level API-juk, de mivel a hardver adott, így érdemes kézzel optimalizálni a kritikus részeket. Ezzel még így is sokat lehet nyerni. Persze nem kötelező, de az exkluzív címek azért néznek baromira jól ki, mert a fejlesztők megteszik.

    (#33) juzer78: Leegyszerűsítve ez lenne a lényeg, de nem API a HSA, hanem vISA. Illetve a finalizer felel a HSAIL hardverre való fordításáért. Külön optimalizáció pedig itt is kelleni fog. A HSA ad egy nagyon jó alapot, de a legjobb teljesítményhez szükséges a specifikus optimalizálás. A funkcionalitás persze nem szenved csorbát optimalizálás nélkül.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    Letöltöttem Norm Rubin előadását, ha valakit érdekel vázlatosan a HSAIL, akkor küldjön privátot, és elküldöm az e-mail címére, vagy amilyen mail címre akarja.
    Az anyag egyébként pár hét múlva elérhető lesz publikus formában is.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz kisza25 #40 üzenetére

    Igen. De a Llano nem tudja a HSA MMU kiterjesztést. Persze ettől még működni fog.

    (#41) DRB: Nem API, hanem vISA.
    Mondjuk rá, hogy ez a két mód létezik, bár szerintem több is. A HSA a Java-hoz hasonlítható, de inkább a két mód közé raknám, ha most mindenképpen erre akarod helyezni a gondolatmeneted.
    A HSAIL és a Java bytecode hasonló vISA csak más szempontok szerint fejlesztették, így a teljesítmény is eltérő lesz.
    Az API egy alkalmazásprogramozási interfész. Ilyen mondjuk az OpenCL, ami eléggé low-level, de API. A HSA az OpenCL alatti szinten helyezkedik el.

    (#43) DRB: A cikkben a Java az Aparapi miatt került elő. Erre az AMD nagyon gyúr, és egyelőre az Aparapi OpenCL-en keresztül valósul meg, de hosszútávon az a terv, hogy a HSA része legyen a JVM-nek. Ez lehetséges, és a fejlődés irányát tekintve az Oracle is értékesnek találhatja.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz huskydog17 #42 üzenetére

    Nem számít, hogy lassul egy picit, ha töredékmunkát kell belefektetned. [link]
    Nincs baj azzal, ha valaki imádja az OpenCL-t, és szeret végletekig dolgozni a programkódon, hogy a lehető leggyorsabb legyen. Az viszont baj, hogy kevés programozó tartozik ide. Kell tehát valami megoldás erre. A HSA egy megoldás. Ez a mainstream programozóknak szól főleg. A hardcore programozók maradhatnak a megszokott terepükön, bár kérdés, hogy megéri-e, de a választás szabad.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz huskydog17 #51 üzenetére

    Nem kötelező OpenCL, jó a C++ AMP is, de ott a BOLT is, illetve más nyelv is támogatható.
    Az OpenCL és a C++ AMP annyiban előnyös, hogy ha megírod a programot, akkor a HSA-t nem támogató hardvereken is menni fog csak lassan.
    Manapság már nem gond az OpenCL kompatibilis IGP/GPU. Mindenki ilyet tervez. Nagyon sok cégnek már van is. C++ AMP szintén nem probléma. Ha a GPU/IGP DX11-es, akkor csak egy driver kérdése az egész.

    A serial CPU az egy szálú programkód. A TBB az az Intel Threading Building Blocks, ami több szálra optimalizálásért felel. Intrinsics+TBB szintén. Az OpenCL-C az lényegében az OpenCL C99-re épül, számos megkötéssel. Az OpenCL-C++ az az 1.2-es verzió C++ Wrapper. A C++ AMP egyértelmű.
    Túl nagy gondot a HSA nem jelent sebességvesztés szempontjából. Főleg, úgy, hogy mennyire kevés a befektetett munka. Az OpenCL is driveren keresztül működik, illetve van AMDIL is. Az AMD is sok különböző GPU ISA-t támogat. Ezt legegyszerűbb vISA-val megoldani. A HSAIL kiváltja az AMDIL-t.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz huskydog17 #54 üzenetére

    A HSA nincs kiterjesztve dGPU-ra. Nem lenne értelme. Főleg az APU-nak szól ez az egész, illetve a partnereknél a SoC-ról. A dGPU-k hozzáadása később megtörténhet, de kérdés, hogy mennyi értelme van.
    Benne van a cikkben, hogy a HSA MMU-val a teljes rendszermemória elérhetővé válik a CPU és az IGP számára. A memory copy minimalizálható. A sebességvesztés függ az adott programtól.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz huskydog17 #56 üzenetére

    Gondolom azért, mert külön memóriával rendelkeznek. A HSA legnagyobb előnye az lesz, hogy közös lesz a memória. De egyébként elméletben kiterjeszthető, szóval ez inkább egy döntés miatt alakult, így, mintsem valami hardveres limitáció miatt. Azért nem nehéz észrevenni, hogy a VGA-piac nem egy jövőbiztos terület. A mobil irányt látva meg pláne nem az.
    Programtól függ a sebesség. Szóval általánosítani nem lehet.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Taragas #59 üzenetére

    A roadmapon is szerepelt, de nem 2012-re volt ígérve, és nem az első verzióra. Dolgozni kell még ezen. A HSA útiterv ezt 2014-re tette az elmúlt évben. Mára ez eltűnt. Nyilván felmerült a kérdés, hogy megéri-e. Ha megéri megcsinálják. Ez csak attól függ, hogy a VGA-k eladása mennyivel nő az elkövetkező hónapokban.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Taragas #61 üzenetére

    Lehetőség rengeteg dologban van, de kérdés, hogy pénz van-e benne. Az AMD és az NV nem akarja ezt lelőni, de el kell gondolkodni azon, hogy esik az eladás, ami egyértelmű üzenetként jelzi a tömeg igényét. Ennél fontosabb pedig nincs, mert a tömegben van a pénz. Ettől függetlenül ott a lehetőség támogatásra. Ez döntés kérdése. Gondolom tartható az eredeti 2014-es útiterv a dGPU-kra.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Löncsi #66 üzenetére

    Nincs bejelentve, csak valaki a hasára ütött és leírta. Egyébként nem az lesz benne. Az MS külön fejlesztésű hardvert kért. Vannak speckó igényeik. Mivel ők adják a fejlesztésre a pénzt, így természetesen ez nem gond.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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