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

• #35 Abu85 HÁZIGAZDA Oliverda #34

  Új Válasz 2018-12-11 13:37:23 #35

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz Oliverda #34 üzenetére

  A PCI Expresst nem kell kukázni. Annak semmi baja. Persze nem memóriakoherens, de ez egyáltalán nem ér meglepetésként senkit, hiszen a PCI Express specifikációja évek óta ismert. Ha a GPU továbbra is a CPU szolgája marad, akkor nem is kell amúgy memóriakoherensnek lennie. Ellenben a HPC-piacon már eléggé alakul át ez a terület. A Linux esetében elég sokat módosítottak már a kernelen ahhoz, hogy ha a gyorsítót akarod célozni, akkor ott már van arra is lehetőség, hogy a GPGPU-s API-k a kerneleket közvetlenül futtassák, ehhez persze implementációtól függően ma még kellhet a PCI Express 3.0 AtomicOp, de működik, és ezáltal a kerneleknek már nem kell tartalmaznia az OS rendszerhívást is, vagyis amikor egy GPGPU-s program elindít egy kernelt, akkor nem kell megkérni az OS-t, ezen belül is egy erre vonatkozó szervizfolyamatot, hogy indítsa el azt a programot futtató felhasználónak, az adott API implementációjának kernel driverén. Gyakorlatilag az AMD IF GMI-je és az NVIDIA NVLinkje ennek a továbbgondolása a teljes memóriakoherenciával. Ha nem lenne ugye erre szükség, akkor ki se fejlesztették volna. Ugyanez igaz a Xilinx saját megoldására, csak ők ugye a CCIX-et fogják használni erre a célra. Mondjuk mást igazából nem tehetnek, az az egyetlen szabványos memóriakoherens interfész. A CAPI, illetve az OpenCAPI esetleg még opció lehetett, de valószínűleg jobbnak látták, ha az x86/AMD64-es hosthoz igazodnak, és nem a Powerhöz. Ez tisztán üzleti döntés lehetett, ők minden bizonnyal több FPGA-t adnak el x86/AMD64-hez, tehát nincs okuk abban kételkedni, hogy az ACAP-pal ez nem így lesz.

  [ 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