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

• #209 Abu85 HÁZIGAZDA Ren Hoek #195

  Új Válasz 2015-06-06 12:48:46 #209

  Ú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 Ren Hoek #195 üzenetére

  Valójában az kisebb mértékben számít, hogy mi mit emulál, és ez mennyi többletterheléssel jár. Úgy néz ki, hogy sokkal nagyobb szerepe van annak, hogy egy cég mennyire nyitott az adott architektúráról, mennyire rendezkedett be úgy, hogy a fejlesztők képesek önálló munkavégzésre, mert mostantól a fejlesztő szállítja a korábban driverben lévő funkciókat a programon belül. Ha nem mondják el nekik, hogy hogyan kell dolgozni az architektúrákra, akkor nem tudnak hatékony optimalizálást szállítani.
  Aki dolgozik DX12-vel, vagy bármilyen low-level API-val, az egyértelműen a toolokra és a dokumentációkra, vagy ezek hiányára panaszkodik. Hiába van az Intelnek kétharmados részesedése a fejlesztő nem tudja lekérni azt az assembly szintű kódot, ami megmutatja, hogy a magas szintű forrás hogyan fut magán az architektúrán. NV-n dettó ugyanez. Ha ezt nem látja a fejlesztő, akkor nem tudja hol a szűk keresztmetszet és nem tudja javítani azt forráskódban. Emellett szintén nem ismert, hogy bizonyos hardverek mit szeretnek és mit nem, például az NV nem mondja meg. Pedig aszerint kellene meghozni a különböző döntéseket, hogy milyen erőforrás-formátumokat használjanak, de nem tudják meghozni, mert csak azt ismerik, hogy a konzolból a GCN mit szeret. Persze valaki úgy áll hozzá, hogy ha xy cég hallgat, akkor áthozzák a kódot a konzolból és majd ha belassulnak a hardvereik, akkor megered a nyelvük, és elkezdik készíteni a dokumentációkat. De ez nem megoldás, mert ez csak a DX12 gyengeségeit mutatná meg a világnak, vagyis azt, hogy nagyrészt a fejlesztőn múlik a program sebessége, és abba a gyártóknak gyakorlatilag nincs közvetlen beleszólása.
  A Vulkan esetében például már gondol erre a Khronos és készítenek olyan conformance tesztet, aminek az eredményét a Vulkan tagságot igénylő fejlesztők megkapják. Ez ugyan nem dokumentáció, de alapvetően ad egy támpontot, hogy nagyjából mi hogyan fut a különböző architektúrákon, és ez így segít meghozni bizonyos döntéseket. Nem fog segíteni komolyabban optimalizálni, de legalább irányt mutat. Készül SPIR-V disassembler is, ami ugyan nem ISA disassembler, de a fejlesztők azért jóval többet láthatnak majd abból, hogy a magas szintű kód legalább a közbülső rétegre hogyan fordul le, és ott tudnak kísérletezni, hogy az adott hardvert esetleg mi gyorsíthatná be.
  Az, hogy több gyártó sem low-level barát a kialakított ökoszisztémát tekintve jóval nagyobb baj most, mint azt nézegetni, hogy mennyi extra többletterhelés a binding TIER_2 a TIER_3-hoz viszonyítva.

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