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

• #42184 Abu85 HÁZIGAZDA Petykemano #42171

  Új Válasz 2019-06-29 14:58:17 #42184

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

  Reflektálok rá:

  "- állítása szerint a gcnben a tesszeláció azért volt gyenge, mert kevés volt a puffer/regiszter és az eredményeket kénytelen volt a lassú és energiaigényes memóriába írni"

  A tesszelláció a TeraScale-ban volt gyenge a GCN-ben már erős. Emellett ennek nincs igazán köze a regiszterhez. Van egy puffer ideiglenes tárolásra, de az nem nagy. A memóriába is lehet írni, de annak csupán az a haszna, hogy ha egy mesh tesszelálva van, akkor azt el lehet úgy menteni, és a következő frame-ben csak be kell tölteni. A tesszelláció azért gyenge teljesítményű egy ponton túl, mert a háromszögek kisebbek lesznek 16 pixelnél, és mivel a hardvereket még ma is quad raszterre tervezik, így amint alámész ennek a határnak, rögtön összeomlik a raszter hatékonysága. 8 pixel/háromszöggel már csak 50%-os a raszterizáció, ami gyakorlatilag azt jelenti, hogy hiába viseli el a hardver a munkát a geometria szempontjából, a raszter motorok a munka felét feleslegesen gyakorlatilag csinálják meg. Az RDNA-nak az automatikus prim culling pipeline-ja ugyan tényleg sokat jelent, többet bármilyen korábbi trükknél, de az alapproblémát nem kezeli, vagyis az RDNA-nál is ugyanúgy a raszterizálással kapcsolatos munka fele felesleges 8 pixel/háromszög mellett. Ez minden GPU-n így van és így is marad, amíg nem jön rá valami quad-fragment merging szerű megoldás az API-ban. Hiába trükközik szét a gyártók a pipeline elejét, a raszterizáláson bukik minden.

  "- ezen az rdna új cache hierarciája segít"

  Ha a tesszellációra gondolt, akkor azon nem igazán. Sokat ér máshol, de pont a tesszelációnál nem lényeges.

  "- a Turing és az rdna egymáshoz közelítő architektúrák"

  Inkább távolodók. A GCN és a Turing hasonlít nagyon. Az RDNA valamivel másabb. SIMT-nek SIMT persze, csak amíg a GCN és a Turing csak TLP-re van optimalizálva, addig az RDNA ILP-re és TLP-re is.

  "- akkor viszont az mvidia bajban van, mert a fejlesztők valójában a gcnre optimalizáltak eddig is,.mert azt ismerik. Az egy tévedés, hogy a játékokat nvidiára optümalizálják,.kivéve persze a szponzortáltakat."

  Ez addig igaz, hogy a fejlesztők GCN-re dolgoznak, de a GCN és a Turing optimalizálási iránymutatásai azért eléggé hasonlók. Nem minden szempontból, de úgy jellemzően elmondható, hogy a shaderek megírása tekintetében, ami jó a GCN-nek, az tulajdonképpen jó a Turingnak is, és fordítva. Ergo olyan különösen nagy hátrány az NV-t ezen a ponton nem éri. A Pascalnál lehet, hogy ez gond, de a Turingnál már nem.

  "- a valóság az, hogy a fejlesztők nem tudják és ráhatásuk sincs, hogy működik az nvidia vga. ..."

  Nagy részleteiben nem tudják, ezért is történik az R&D GCN-en, de azt azért meg tudják nézni az NV profilozóján is, hogy egy adott shader mennyi erőforrást emészt fel, azzal mennyi konkurens warpot tudnak futtatni, mit kell tenniük, hogy több fusson, ha az adott warp mennyisége nem lenne elég, stb. Amikor eljutnak oda a fejlesztők, hogy GeForce-on is tesztelnek, akkor már a GCN-re van egy olyan kód, ami úgy nagyjából hozza azt a teljesítményt, amit céloztak. Innen már nem kell ahhoz nagyon-nagyon részletesen ismerniük a Turingot, hogy további optimalizálást hajtsanak végre. A GCN leginkább az R&D szintjén nagy segítség, mert az sokkal nehezebb lenne nélküle, de amint van egy bizonyos architektúrán már működő kódod, akkor azzal már sokkal könnyebb dolgozni más architektúrán is.

  "... A zártság oka pedig az, hogy az nvidia eddig is olyan techmikákat alkalmazott, driverből vagy hardverből, amelyek alig észrevehető módon és mértékben rontottak a minőségen. A.gcn akkor és ott is dolgozott, ahol az nvidia kártya már legyintett a részletekre. Emiatt hatékonyabb volt az nvidia"

  Igazából egy túrót rontottak. A driverek alkalmaznak bizonyos optimalizálásokat, amikkel teszem azt kicserélnek bizonyos formátumokat másikra, de nem csak azért, mert ebből teljesítményt lehet nyerni, hanem azért is, mert esetlegesen arra a formátumra írták a programot konzolhoz, csak éppen PC-n annak nincs API szinten támogatottsága, stb. Arról sokat lehetne vitázni, hogy ez csalás vagy sem, de mivel tulajdonképpen mindenki ezt csinálja, így kb. nem érdekes. Emellett az efféle optimalizálások a játékok kis részét érintik, és tényleg nagyító kell az észrevételükhöz. Szóval olyan nem igazán van, hogy a GCN számol valamit, az NV meg csak legyint rá, ha van, akkor az maximum valami driverbug.

  Amire itt szerintem próbál utalni, az a DX11 vs. DX12/Vulkan. DX11-ben valóban hatékonyabb az NV, és ennek az oka leginkább az, hogy vannak bizonyos speciális pathok a hardverben, hogy gyorsítsák az egyes DX11-es parancsokat. A DX12/Vulkan ezt ugye kizárja, mert már nem a kernel driverben van a parancslista (nincs is ugye kernel driver), hanem az OS-ben. A Microsoft és a Khronos pedig nem fogja hardverfüggően flaggelni ezeket, hogy ki milyen speciális path-okkal rendelkezik. Vagyis minden grafikai parancs és compute egységes, a driver számára maximum a compute parancsok kezelése megengedett, de a grafikait el kell fogadniuk úgy, ahogy az OS-től jön. Emiatt van az, hogy az NV-nek a DX11-hez szabott speciális path-ok nem működnek már a hardverben DX12/Vulkan alatt. Emellett persze nyilván az is számít, hogy az AMD 2014 elején adott ki explicit API-ra hivatalos implementációt, míg az NV 2016 elején, azt is újraírták nemrég. Ennyi év plusz tapasztalattal persze, hogy valamivel jobban működik DX12/Vulkan API-val az AMD. De ennek aztán tényleg semmi köze ahhoz, hogy az NV valamit nem számol, vagy hasonló. Ha ők csinálták volna meg a Mantle-t, és nekik lenne nagyobb tapasztalatuk az irányból, akkor most az NV drivere lenne ott, ahol az AMD-é van. Ennyire egyszerű.

  Ami pedig a játékokat illeti, alapvetően két lényeges különbség van az AMD és az NV között az DX12 implementációk tekintetében. Az egyik, hogy a Turing előtt az NV nem volt minden buffer viewre vonatkozóan bindless, de a Turing már az, ahogy a GCN is. Ezzel a Turingnak és a GCN-nek jobb, ha a buffer viewek nem direkten a Root Signature-be kerülnek, hanem egy memóriahalmazba, míg a korábbi GPU-knak pont ennek az ellentéte az ideális. Csak ugye utóbbival az volt a gond, hogy bármennyire is akartak régebben kedvezni a Pascalnak, nem minden buffer view köthető be direkten a Root Signature-be, tehát a memóriahalmazok használata elkerülhetetlen. Ezért tervezte át ilyenre az NV a Turingot. Ebből a szempontból tehát már lényegében ugyanazok az ajánlások a Turing és a GCN esetében, csak a Pascal miatt tartja magát az NV a régi ajánlásai mellett.

  A nagyobb különbség a memóriatípusok kezelése, amely még ma is fontos, mert az AMD és az NV nagyon eltérő itt:
  
  
  Az NV-nek a memóriafelosztását nagyon nehéz optimálisan kezelni a program oldalán. És ezt valóban nem mindegyik DX12/Vulkan címnek sikerül jól abszolválnia. De ez nem azt jelenti, hogy az NV-nek a felosztása rossz, csak nagyon nehezen lehet rá optimalizálni.

• #42174 Tyrel őstag Petykemano #42171

  Új Válasz 2019-06-29 11:10:56 #42174

  Ú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

  

  Tyrel

  őstag

  válasz Petykemano #42171 üzenetére

  Én végignéztem este, de kár volt, leginkább egy alaptalan és elfogult nézőpontot közöl, azt is szükségesnél 3x hosszabb videóban. Nagyjából AdoredTV szint, össze-vissza beszél meg elmélkedik, a saját rózsaszín szemüvegén keresztül.
  Ja meg persze védi a korábbi találgatásait, kimagyarázza hogy az ő úgy gondolta ám hogy most igaza van. AdoredTV csapó 2.
  A "játékokat alapvetően GCN-re optimalizálják" résznél már kb. csak röhögtem...

  Bocs ha megbántok valakit de eddig az egyetlen egy olyan YouTube csatorna ami kellően tényszerű, objektív, naprakész és informatív is, az a Gamer's Nexus. Éljen Tech Jesus!

  Visszatérve erre a videóra az egyetlen érdekes pontja az volt (25:15), amikor azt taglalta hogy az AMD kártyák esetenként jobb képminőséget adnak, azzal indokolva ezt, hogy az nVidiánál sokkal nagyobb a driver fejlesztő csapat és megengedhetik maguknak hogy DX11-re és külön az egyes játékokra is olyan "optimalizálásokat" csináljanak, amik miatt alapvetően kevesebbet kell számolnia a kártyáinak, érzékelhető minőségromlás nélkül. Úgy értve hogy ha fut egy játék 60+ fps-el akkor tökre nem veszed észre hogy a kép bizonyos részein valamit alacsonyabb részletességgel renderelt vagy kihagyott egy shader lépcsőt vagy akármi, inkább csak örülsz a magas fps-nek.
  Aztán ha ki screenshotolsz egyetlen képkockát és abba még bele is zoom-olsz akkor látod a turpiszságot, de valós időben nem.

  Ez kb. azért érdekes mert hasonló városi legendák már évtizedek óta keringenek az nVidiáról, még anno a 3dfx-el vívott harcuk kapcsán is felmerült, majd az első ATi Radeon szériás kártyákról is válltig állították egyesek, hogy szebb a képe. Bizonyos időközönként ez azóta is elő-előjön... Itt a fórumon is vannak páran akik írogatták már, ogy nekik volt mostanában mindkét gyártótól videokártyájuk és a Radeonok képe szebb.

  Én nagyon megnéznék egy független, objektív tesztet erről, hogy tényleg igaz-e, és ha igen akkor általánosan, vagy csak egyes játékokban amikben az nVidia kiemelt figyelmet fordított az "optimalizálásra"...

• #42173 Pécsi gyerek addikt Petykemano #42171

  Új Válasz 2019-06-29 10:04:02 #42173

  Ú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

  

  Pécsi gyerek

  addikt

  válasz Petykemano #42171 üzenetére

  

• #42172 smc addikt Petykemano #42171

  Új Válasz 2019-06-29 09:48:31 #42172

  Ú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

  

  smc

  addikt

  válasz Petykemano #42171 üzenetére

  Köszi!

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