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

• #16172 Abu85 HÁZIGAZDA Petykemano #16156

  Új Válasz 2015-06-25 19:22:25 #16172

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

  Nem lehet még beszélni mindenről. Csak a hardvert leplezte le az AMD azt, hogy mit hoznak még a hardverhez nem. De annyit elárulhatok, hogy nem véletlen, hogy júliusban lesz elérhető a sima Fury. Ezzel az a terv, hogy a Windows 10-hez legyen közel a start, hogy ott is le legyen mérve a teljesítmény a 15.200-as csomaggal, amiből egyébként amúgy is kapott a 15.15-os driver a tesztek előtt frissítést. Bár valószínűleg sokan már nem telepítették fel.
  A Nano sem véletlenül jön később, hogy nagyobb legyen a fókusz a DX12-vel.

  Nagyon egyszerű dolog történt amúgy. Az Intel és az NV ugyanúgy látta cirka 7-8 évvel korábban, hogy az API-k a PC-n korlátozók. Rengeteg limittel, és jó lenne, ha ez megváltozna, de nem hittek benne, hogy egy ilyen váltást a PC-n át lehet nyomni egyáltalán. A célja mindig az volt, hogy biztosítsanak egy egyszerűnek tűnő felületet, és a komoly problémát okozó tényezőkkel a háttérben dolgozhat az API és a kernel driver. Ha pedig ez a cél, akkor ehhez kell tervezni a hardvert. Az AMD úgy gondolta 7-8 évvel korábban, hogy egy életük egy haláluk át kell nyomni a változást. És a potenciális változáshoz tervezték a hardvert, gondolva arra, hogy hagyományos szinten hátrányban lesznek, de ha sikerül letolni az ipar torkán a low-level irányt, akkor már a konkurensek lesznek hátrányban. Most történik a váltópont, mert nem kis meglepetésre egyébként, de átnyomták az irányt.
  Többek között a DX12 az AMD-nek nagyon fontos, mert rengeteg olyan dolgot megváltoztat, amely most számukra hátrányos a DX11-ben. Például ma a bekötési modell váltása a legfontosabb és nem véletlen, hogy erről beszélnek a legtöbbet. Ma ez úgy néz ki, hogy a CPU beköt egy puffert az API-val és a kernel driverrel, amelynek az eredménye egy adat lesz a hardver számára. Ezt a driver szimplán elküldi a hardvernek mint erőforrás leírót. Ezt persze minden hardver máshogy csinálja, mert implementálás szintjén lehetnek különbséget, itt arról beszélhetünk, hogy a bekötés hol valósul meg a multiprocesszoron belül, például a legtöbb mai modern GPU-ban a textúra-mintavételezőben történik mindez, de itt is számolni kell azzal, hogy tömbösítve történik a bekötés, vagy különállóan. A GCN viszont teljesen egyedi. Ennek az architektúrának nincs szüksége erre a procedúrára. Egyszerűen a shaderbe bele lehet írni memória elérést és kész, a skalár egység elvégzi a bekötést. A hátránya, hogy ma egyik szabvány API sem működik így, tehát ezt le kell "emulálni" a kompatibilitást egy olyan hardverrel, amit nem hagyományosan terveztek. Az új API-k azonban így működnek, és fordul a kocka, vagyis a többi architektúrának kell "leemulálni" a kompatibilitást.
  Ugyanilyen probléma a queuing. Egy mai API DX11/OpenGL úgy működik, hogy van a hardver felé egy parancslista, és abba lesz betöltve minden, majd a hardver szépen egyesével lekéri a feladatokat, és azokat sorban végre is hajtja. Ma több modern GPU-t erre terveztek. Egy mérnöki csapat felteszi a kezét, hogy tudunk mi hardvert tervezni, de miért is költsük tranzisztorokat a párhuzamos feladatfuttatás kigyúrására, ha a pipeline-ok úgyis sorban jönnek? És ez egy érthető döntés a maga szintjén. Valószínűleg senki sem vonja kétségbe az Intel és az NV vezetőségében, hogy a mérnökeik képesek lennének egy alternatív GCN-t tervezni, csak nem ezt kérték tőlük. Az AMD viszont úgy gondolta, hogy egy ilyen reformot is átnyomnak, mert azért masszívan párhuzamosításra tervezett rendszer a GPU, hogy olyan programok is fussanak rajta. Megtervezték a GCN-t stateless compute-ra, megpakolták regiszterekkel, gyorsítótárakkal, és igen ebből ma egyetlen szabványos API-n sem lehet kihozni semmit, de mit ad az úr a DirectX 12 queuing modellje copy/compute/graphics halmazba van szervezve, így a hardver tetszőleges számú compute és copy parancslistát kezelhet, és ezekről párhuzamosan kérhet le feladatokat, ha persze van rajtuk betölthető. Ezzel lehetőség adódik, hogy a feltöltés és a compute minden más feladattal párhuzamosan végrehajtható legyen, vagyis megszűnt a soros feldolgozásra kényszerítő modell. Itt megint fordul a kocka és a hátrányból előny lesz. És ezekről egyébként fognak beszélni H2-ben, csak megvárják a játékokat, hogy megmutathassák, hogy ez mit is jelent. A 3DMark API Overheadben már láthatjátok egyébként, hogy mi történik az architektúrák hatékonyságával a DX11-DX12 váltásnál.

  [ 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