Új hozzászólás Aktív témák
-
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.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
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.