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

• #56389 Abu85 HÁZIGAZDA TTomax #56368

  Új Válasz 2017-01-08 11:29:35 #56389

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

  Leírom én. Induljunk ki a most elérhető architektúrákból, vagyis a Pascalból és a GCN4/Polarisból, hogy mik azok, amiken lehetne rajta javítani általánosan és API specifikusan zárójellel jelölve:

  GCN4/Polaris:
  - a fix wavefront hossz nem a legjobb egy olyan rendszernél, ahol a wavefrontméret 64 szál, persze ezt nehéz hibának írni, mert kisebb wavefrontokkal rosszabb lenne a skálázhatóság
  - a geometry shader lépcsőt kifejezetten lassan hajtja végre az architektúra az etalonnak számító Intel dizájnhoz képest eléggé, de a Pascalhoz képest is érezhető a hátrány, persze az AMD-nek szerencséje, hogy alig használnak a játékok geometry shadert
  - relatíve sok memória-sávszélesség kell a működéséhez, mert nagyon az IMR elv felé húz. Sokat segített a primitive discard accelerator, de több mozaikos optimalizálás kellene, hogy a munka több része maradjon GPU-n belül
  - aránylag sokat vesz ki a rendszerből, ha nem látható geometriákat kell tesszellálnia, amelyek végül nem mennek át a raszterizációs lépcsőn (pl. Crysis 2-ben a rejtett óceán, Fallout 4-ben a lens flare maximum beállítás)
  - (D3D11) az architektúrában nagyon kevés a fast path a jellemző műveletekre, így minden az általános utakon keresztül lesz végrehajtva, amelyek emiatt ki vannak gyúrva, de akkor sem olyan gyorsak, mint a dedikált fast pathok
  - (D3D12) nincs támogatás a konzervatív raszterizációra
  - (D3D12) nincs támogatás a ROVs-ra
  - (D3D12) nincs támogatás a Tiled Texture3D-re

  Pascal:
  - a warpméret csak 32 szál, ami skálázási nehézségeket okoz, de hasonlóan az AMD wavefrontméretéhez nehéz hibának írni, mert nagyobb warpmérettel nőne a kihasználtságlimit (itt megjegyzem, hogy nagyon ironikus az egész, hogy az AMD-nél a nagyobb méret okoz problémákat, míg az NV-nél a kisebb, az optimális a variálható hossz lenne mindkét gyártónál)
  - sajnos itt sem gyors geometry shader lépcső, az Intel dizájnjához képest lényeges a hátrány, de az NV-nek is szerencséje, hogy a játékok kevés geometry shadert használnak
  - aránylag fáj a rendszernek a komplex, raszterizációs lépcsőn keresztülhaladó geometriák megjelenítése (pl. Deus Ex: Mankind Divided, Hitman geometriai komplexitása)
  - (D3D12) nincs támogatás a konzervatív raszterizációra leghasznosabb szintjére, a TIER_3-ra
  - (D3D12) nincs támogatás a kevert pontosságra a GeForce-okon (pontosabban le van tiltva a mikrokódban)
  - (D3D12) elég rossz hatékonysággal működik ez a hidas "SLI" összeköttetés a Microsoft szabványos AFR-jével, amíg a Radeonok XDMA-s megoldása gyakorlatilag ténylegesen duplázza a sebességet, addig a GeForce-ok még a legjobb híddal sem képesek erre és a szabványos frame pacing is dadogósan megy
  - (D3D12) nincs támogatás a legjobb bekötési modellre, ezért a processzor oldalán többletterhelés keletkezik
  - (D3D12) nincs támogatás a GS emuláció nélküli VP/RT tömbindexre
  - (D3D12) nincs támogatás a pixel shader stencil referenciaértékre
  - (D3D12) nincs támogatás az összes Typed UAV loads formátumra
  - (D3D12) a Microsoft által kialakított és ajánlott Root Signature modell egyáltalán nem illik a hardverhez, és az így strukturált programokban csökken a pixel shader teljesítmény, az NV ajánlásaival ez kivédhető, viszont úgy meg számos sűrűn használt formátum egyszerűen nem is tölthető be a Root Signature-be
  - (D3D12/Vulkan) az architektúrába épített nagyon sok, D3D11-re szabott fast path miatt relatíve gyengék az általános utak, amiket viszont használni kell, mert a D3D12 és a Vulkan nem támogatja a fast pathokat
  - (D3D12/Vulkan) elég rossz a kevert feladatfuttatás hatékonysága és nincs támogatása konkurens folyamatokra a parancsmotorokban
  - (Vulkan) a hardver picit rosszul mapelhető a Vulkan memóriaallokációs modelljéhez, így a hatékony működéshez egy gyártóspecifikus kiterjesztést érdemes használni (NV_dedicated_allocation)

  [ 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