- Computex 2024: feltárta a Lunar Lake-et az Intel
- Célegyenesben a Yettel TV
- OLED TV topic
- Azonnali informatikai kérdések órája
- Nvidia GPU-k jövője - amit tudni vélünk
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- TCL LCD és LED TV-k
- Milyen billentyűzetet vegyek?
- HiFi műszaki szemmel - sztereó hangrendszerek
- ThinkPad (NEM IdeaPad)
Hirdetés
-
Frissítve! Summer Game Fest 2024 - Az összes bejelentés egy helyen!
gp A show késő este kezdődik, de utána az összes trailert összegyűjtjük egy helyre.
-
Filléres Redmi érkezett
ma Az A3x nem kapott nagy bemutatót, egyszer csak felbukkant.
-
Perelnek a vallásos kripto-piramisjáték miatt
it Két kriptocéget perel New York államügyésze, mert több mint 1 milliárd dollárral károsították meg az áldozatokat.
Új hozzászólás Aktív témák
-
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.[ 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
- MSI GeForce Gaming X Trio RTX 3060 12GB GDDR6 192bit Videokártya
- ASUS GeForce RTX 3060 12GB Dual V2 OC GDDR6 192bit Videokártya!
- MSI GeForce RTX 3060 GAMING X 12GB GDRR6 192bit Videokártya!
- ZOTAC GeForce RTX 3060 Twin Edge OC 12GB GDDR6 Videokártya!
- MSI GeForce RTX 3060 VENTUS 2X OC 12GB GDDR6 192bit Videokártya!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen