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

• #173 Abu85 HÁZIGAZDA jacint78 #169

  Új Válasz 2016-04-28 08:57:52 #173

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

  Mi másra fejlesztették volna? Egy dolog, amit meg kell érteni. Egyrészt van a normál VR piac, ami az átlagfelhasználókból áll, és van egy speciális rész, amely a tartalmat készíti. Ugyanúgy, ahogy a normál fejlesztéseknél a legjobb itt sem elég, de nincs nála jobb, így azt kell megvenni. Mivel a VR piac most indul be, így a tartalomkészítők a nulláról indulnak, ergo az első lépés megvenni a szükséges hardvert. Az AMD-nek most szerencséje van azzal, hogy az NV nem hozta ki a saját megoldását, így a Radeon Pro Duo az egyetlen választás. Ez igazából abból a szempontból kedvező, hogy minden tartalom Radeonon készül, ami előnyt jelent a normál piacon is.

• #163 Abu85 HÁZIGAZDA jacint78 #162

  Új Válasz 2016-04-27 19:13:44 #163

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

  Itt nem volt semmiféle taktikázás. Az AMD és az NV a múlt évben meglátott egy olyan piacot, amelyre nem volt megfelelő válaszuk. Nekikezdtek a hardver tervezésének, és az AMD terméke eljutott az üzletekig, míg az NV lelőtte, mert nem sikerült a szoftveres részt annyira jól megcsinálni, hogy célozhatók legyenek az észrevett piac igényei. Csupán ennyiről van szó.

• #161 Abu85 HÁZIGAZDA TTomax #160

  Új Válasz 2016-04-27 18:50:51 #161

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

  Dehogynem ad. Az API-k a garanciák rá.

  Miért? Már a következő hónapban kivezetik?

• #159 Abu85 HÁZIGAZDA jacint78 #157

  Új Válasz 2016-04-27 18:48:18 #159

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

  Kezdjük ott, hogy ahova ezt a kártyát szánják oda nincs más alternatíva.

  Egyébként nyilván a professzionális tábor egy része jól jár azzal, hogy van Autodesk, Maya és DaVinci Resolve certifikáció, hiszen nagyon olcsón kapnak extrémgyors cuccot. De valószínűleg az AMD felmérte azt, hogy ez még belefér a FirePro vonal mellett.

• #156 Abu85 HÁZIGAZDA TTomax #155

  Új Válasz 2016-04-27 18:42:48 #156

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

  Nem feltétlenül. Ez attól függ, hogy szükséges-e az adat betöltése. Alapvetően az a modell, amit az MS kidolgozott a WDDM 2.0-ban lényegében azt a célt szolgálja, hogy a GPU-k kezelése olyan legyen, mint a multiprocesszoros rendszerek kezelése. Gyakorlatilag adódjon össze az adapterekhez tartozó memóriaterület.

• #149 Abu85 HÁZIGAZDA TTomax #148

  Új Válasz 2016-04-27 14:47:12 #149

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

  Az adatok tárolása ennél bonyolultabb kérdés. Még egy adapteren belül is többször van eltárolva ugyanaz az adat, függően attól, hogy milyen a belső buszrendszere a GPU-nak. Ha ilyen formában hasonlítjuk össze a memóriákat, akkor vezérlőnként kell különvenni a memória méretét.

• #147 Abu85 HÁZIGAZDA TTomax #145

  Új Válasz 2016-04-27 14:31:28 #147

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

  Az SFR és a működési mód lényegtelen. Itt a címzési modell a fontos, ami meghatározza, hogy miképp tudod kezelni a több memóriaterületet. Nyilván a gyártók dönthettek volna úgy régebben (~DX11 éra bevezetésénél), hogy építenek az akkori driver modellek fölé egy alternatív címzési módot lehetővé tevő réteget, csak nem tették meg, mert egyrészt bonyolult volt, másrészt nem volt kritikus probléma a memória mérete. Ha megtették volna, akkor ma CF és SLI mellett is össze lehetne adni a VRAM-ot. Ma már mindegy, mert itt a WSI réteg és a WDDM 2.0, ami program oldalról teszi lehetővé a jobb címzési módot.

• #146 Abu85 HÁZIGAZDA #85552128 #144

  Új Válasz 2016-04-27 14:29:01 #146

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

  Ez a lehetőség nincs definiálva az új API-kban. Ez azért ékelődött be a köztudatba, mert régen a rendszer működési modellje szegmentált fizikai címzésre épült. Tehát direkten címezte a rendszer a fizikai memóriát, illetve a többletterhelés miatt még törölni sem lehetett. Az új API-k által használt felületeken, legyen az WSI réteg, vagy direkt WDDM 2.0 csak egy nagy virtuális memória van.
  A közérthetőség kedvéért legyen ez 16 GB, és mondjuk azt, hogy tele van. Ilyenkor a címzés úgy történik, hogy a motor a preload algoritmus alapján jelzi, hogy egy címtérre szüksége lesz a következő frame-ek során, és azt betölti egy olyan adat helyére, amelyet már nem használ. Ez működik több GPU-ra is.

• #143 Abu85 HÁZIGAZDA TTomax #142

  Új Válasz 2016-04-27 14:18:58 #143

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

  Multiadapter módban a fejlesztő menedzseli a memóriát. Ez úgy néz ki, hogy a WDDM 2.0-ban vagy WSI-hez hasonló modellben lesz egy virtuális címtér, amiből mindig betölti a használt címtartományt. A kártyán, illetve a konfiguráción belül logikailag annyi GB-nak veszi a program a VRAM méretét, amennyi van összesen, függetlenül a lapkák számától. Ilyen formában minden multiadaptert támogató játékban összeadódik a VRAM mérete.

  A memóriaelérés programozásfüggő. A legacy API-ban azért nem volt összeadható, mert úgy volt leprogramozva a multi GPU, hogy erre nem adott lehetőséget. Egyébként le lehetett volna másképp is programozni, csak túl sok pénzt raktak a cégek a hackelt AFR-be.

• #140 Abu85 HÁZIGAZDA #85552128 #139

  Új Válasz 2016-04-27 13:33:47 #140

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

  A működés módjától függ. 4+4 GB-osként viselkedik minden DX9/10/11/OGLakárhányas multi GPU-s játékban. 8 GB-osként viselkedik minden DX12/Vulkan/Mantle, illetve az összes VR-t használó multi GPU-s játékban. Röviden így lehet ezt jellemezni.

• #59 Abu85 HÁZIGAZDA gbors #52

  Új Válasz 2016-04-26 19:46:10 #59

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

  Warp, de amúgy jó a wavefront is. Viszont GeForce-on a gond nem ezzel van, mert warpok között sem lehet váltani. Konkrétan meg kell várni, amíg a befutott rajzolási parancshoz kapcsolódó teljes feladat lefut, és utána lehet váltani.

  Elvi síkon a VR multi GPU tényleg nagyon egyszerű, de a gyakorlatban ott van az a probléma, hogy az aktuális szabvány API-k nem tudják megállapítani, hogy a jobb és bal szemnek szánt képhez a rajzolások egy része ugyanaz. Ergo a processzor többletterhelése megduplázódik, mert minden rajzolást kétszer kell kiadni a sztereó 3D miatt. A LiquidVR ott segít, hogy nem a szabvány API van célozva, hanem a Mantle-t, ami kezeli a mögötte lévő API-kat úgy, hogy ugyanazokkal a rajzolásokkal a processzort csak egyszer terheli, de azt kétszer küldi be a szabvány API-kba.

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