2. Fórumok
  3. Lokál
  4. AMD CPU-k jövője - amit tudni vélünk

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

  • #550 Petykemano veterán Petykemano #549
    Új Válasz #550
    Ú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

    Petykemano

    veterán

    válasz Petykemano #549 üzenetére

    Ugyanakkor persze annyi különbség van, hogy az SE-k mögötti L2 és HBCC mellett az előttük levő Command processor és Workload distributor is közös. De miért ne lehetne ez az IO chipen?

    Fogj meg egy aput, vágd ki belőle a cpu magokat és a CU-kat és kösd hozzá kívülről, skálázd. Voilà.
    Ugyanakkor valamiért Dávid Wang mégiscsak azt mondta, ez nem olyan egyszerű nem compute taskok esetén.
    (A gput folytassuk a radeon találgatósban)

  • #549 Petykemano veterán Cathulhu #548
    Új Válasz #549
    Ú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

    Petykemano

    veterán

    válasz Cathulhu #548 üzenetére

    De és ez a csomó késleltetés ez biztos?
    Mert ha igen, akkor az meg is adja a választ arra, hogy a következőkben miért is lenne indokolt imterposer használata. Lezso azt mondta, az IF nem széles, nem szükséges az IP, de az IP miközben rövidít, aközben szélesebb buszt is lehetővé tesz. Ha az irány az IF javításán vezet, akkor az IP a későbbiekben elkerülhetetlen.

    Mindenesetre az jó hasonlat, hogy mintha csak közvetlen memóriaelérés nélküli TR lapkák lennének. Az biztos kolönbség, hogy az IF órajele magasabb kell legyen, ez máris csökkenthet a késleltetesen.

    Viszont ha ebben igazad van, az megint csak indkolja, hogy az IO lapkán egy bazi nagy cache legyen, hogy egy útvonal minél inkább megúszható legyen. (Eddig: cpu<->ram, most: cpu<->io), amibe a prefetchelést maga az IO lapka végezze. Pont úgy, ahogy a Vega HBCC-nél láttuk. (Lehet, hogy a technológiát ott csak kipróbálták)

    Az, hogy ezt a struktúrát fel lehetne használni gpuknál, nem egyedi gondolat. Sőt, kicsit a 4 Shader engine már eleve ez. De mennyivel jobb lenne minden shader enginet külön gyártani és IF-fel össszekapcsonil? Akár külön célra. Akár válogatva.
    (Via)

  • #548 Cathulhu addikt
    Új Válasz #548
    Ú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

    Cathulhu

    addikt

    Egy erdekes gondolat utotte fel bennem a fejet. A kozponti IO miatt felaldozott az AMD egy csomo kesleltetest, gyakorlatilag olyan az uj proci, mintha a threadripperekben csak azok a magok uzemelnenek, amelyikeknek nincs sajat memoria vezerlojuk, es csak egy kulsol vezerlon keresztul tudjak ezt elerni. De igy viszont egy IO chip tud akar 8 csatornat is kezelni marha nagy sebesseggel. Emellett maradtak a kis chipletek a sajat "kis" cacheikkel, de eleg sokan (8an most, ki tudja mennyien meg). Ez nem CPU emberek, ez egy GPU!
    Egy marha eros es modularis CPUGPU hibrid. Kovetkezo lepesben latok magam elott nehany GCN chipleteket a tokozason belul a marha gyors ion keresztul RAM-ot kezelni, utana viszont mar kulonbseg se lesz koztuk

    Es ez egybe vagna azzal is amt Lisa mondott, hogy meresz dolgokkal kiserleteznek, amelyik evek mulva robbannak.

    Mark my words! Jo ejt :)

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