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

• #26 Abu85 HÁZIGAZDA Petykemano #19

  Új Válasz 2019-01-02 11:02:13 #26

  Ú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 Petykemano #19 üzenetére

  Mert GDDR6-ból nem tudsz 1+ TB/s-ot építeni, ami baromira kell a DirectX Raytracingnek, illetve a DirectML-nek. Igazából az optimális a 2 TB/s, amit még úgy sem tudsz GDDR6-ból megcsinálni. A GDDR6 körülbelül képes lehet 700 GB/s-ra optimális energiaigénnyel. Efölött már a fogyasztása a HBM 10-15-szöröse, ami a GPU TDP-keretéből zabálja el a kraftot. Nem mindegy, hogy egy 300 wattos TDP-jű VGA-n olyan 280 watt jut a GPU-ra, vagy csak 180-200, mert a GDDR6 memóriának kell a többi.

  [ Szerkesztve ]

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

• #31 Abu85 HÁZIGAZDA Cifu #16

  Új Válasz 2019-01-02 11:10:05 #31

  Ú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 Cifu #16 üzenetére

  Az a helyzet, hogy jelenleg ez a HBCC-hez kötődik. Tehát akkor lehet hardveresen megoldani a két GPU egyként való működését, ha a HBCC aktív. Ha ezt kikapcsolod, akkor rögtön ott lesz újra az a probléma, hogy van két GPU-d különálló memóriaterülettel, és bár a memóriakoherens összeköttetés ezen segít, mégis sokkal lassabb átnyúlni a másik GPU memóriájába az adatért, mint szimplán cache-nek használni a VRAM-ot. Ugye magát a menedzsmentet bonyolítja jelentősen, hogy képes vagy egy memóriaterületként visszaadni a VRAM-ot, de az egyik GPU csak az egyik, míg a másik csak a másik felét éri el gyorsan. És ezt megint alkalmazásoldalon kellene kezelni. A HBCC-vel ezt a problémát automatikusan kezeli a hardver.

  Na most a HBCC nem igazán megvalósítható a WDDM 2 alatti szinteken, tehát mindegy, hogy milyen API-n fut a program, maga a WDDM 2.0 legalább szükséges a működéshez. Ez pedig csak Windows 10-től van.

  A Linux megoldható lenne, mert az újabb kerneleknél a HBCC-t rá lehet mappelni, de megszokhattuk már, hogy nem azért nem csinálnak meg dolgokat Linuxra a gyártók, mert nem lehet, hanem mert nem éri meg erőforrást fektetni bele.

  [ Szerkesztve ]

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

• #39 Abu85 HÁZIGAZDA Cifu #35

  Új Válasz 2019-01-02 11:25:30 #39

  Ú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 Cifu #35 üzenetére

  Az inkluzívhoz program oldali támogatás kell egy API-n keresztül. Működik ezzel is, de ha a program nem támogatja, akkor csak az exkluzív módot tudja az AMD rákapcsolni. Az inkluzívhoz egyébként megoldható lehetne a régebbi Windows operációs rendszereken is, de erősen kétlem, hogy az AMD leportolná azokra ezt.

  Hosszabb távon szerintem ez az egész úgy lesz szabványba emelve, hogy az API megköveteli majd a hardvertől a bájtszintű adatelérést, és akkor onnantól kezdve lehet egy NAND flash a VGA-n, vagy akár a lapkán is 3D-s tokozással, a memória pedig annak a gyorsítótára lesz.

  [ Szerkesztve ]

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

• #48 Abu85 HÁZIGAZDA Cifu #44

  Új Válasz 2019-01-02 11:43:20 #48

  Ú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 Cifu #44 üzenetére

  Akár. De oda lehet rakni a NAND flash-t a lapka mellé is, a tokozáson belülre. A lényeg az, hogy legyen a GPU/GPU-k mellett. Ennek a megoldásnak az az előnye, hogy ilyen módon például az NV-re is szabványosítható ez a fajta hardveres menedzsment, mert nem követel meg x86/AMD64 licencet. Persze oda lehet rakni egy kiterjesztést az API-kba, hogy Intel és AMD GPU-n még a rendszermemória is szabad préda, de szabvány szinten ez az NV-nek tabu, tehát olyan általános megoldás kell, ami a rendszermemóriát nem célozza ilyen módon.

  [ Szerkesztve ]

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

• #70 Abu85 HÁZIGAZDA b. #62

  Új Válasz 2019-01-02 12:17:00 #70

  Ú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 b. #62 üzenetére

  Ilyennel még sose próbálkozott senki. Az a baj, hogy a másik megoldás a 700+ mm2-es lapka, ami mondjuk 7 nm-en 2500 dolláros VGA-kat eredményezne. Sokkal olcsóbb két 350 mm2-es lapka hardveres vezérléssel összekapcsolva. Vagy felviszed az árakat a 7 nm-es waferekhez igazodva, vagy megpróbálsz valamit csinálni, hogy ne 2000 dollár fölött legyen jövőre a csúcs-VGA.

  [ 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