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

• #57635 Abu85 HÁZIGAZDA Yutani #57631

  Új Válasz 2022-06-17 11:30:32 #57635

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

  Igen, bele van rakva egy rakás munka. A Valve előadásai nagyon jól mutatták ezt. Ők ugye kényszerűen AMD hardveren fejlesztettek, mert akkora kódmennyiséget az NV debug eszköze nem tudott kezelni. Szétfagyott az egész a picsába.

  Itt van a dia, ami azt írja le, hogy miért az AMD fejlesztőeszközét használták:
  
  Ezt az előadást láttam is, és Rich azt is hozzátette, hogy ha nincs a GPU PerfStudio 2, akkor sose lett volna OpenGL módja az említett két játéknak. Egyszerűen kivitelezhetetlen lett volna egy ekkora kódbázisra az egész, mert egyénileg kellett volna minden egyes függvényt ellenőrizni, hogy az hogyan fordul le xy hardverre, és ott pontosan mit csinál. Az pedig akár 5-6 évnyi munka is lett volna, és olyan időtávban felesleges dolgozni, mert mire ellenőrzik xy hardverre, addigra két-három generációval későbbi hardverek jönnek, amelyekre szintén ellenőrizni kell, vagyis ismét jöhet a munka, bár nem 5-6 évnyi, de folyamatosan patch-ek kellenének, amelyek az érkező hardvereket 1-2 év csúszással támogatják csak.

  Ezen túlmenően a szabványos kódjuk, meg se moccant az NV hardvereken. Egyszerűen sűrűn szétfagyott, illetve kaptak egy rakás stallt. Ezt úgy oldották meg, hogy a kódot mindig elküldték az NV-nek, amely cég egy új driverrel együtt visszaküldte a kívánt módosítást. Tehát nem csak egy másik kódút kellett, hanem egy specializált driver is, amit mindig használtak, mert ha nem, akkor a módosított kódút is szétfagyott a picsába, és a teljesítménye is kb. a tizede volt annak, amire szükség volt.

  Alapvetően ezek voltak az OpenGL bajai, és évek óta ismertek, csak a Khronos egyszerűen nem fordított erőforrást a kijavításukra, mert feltettek mindent a Vulkan API-ra. Ezzel együtt pedig a Valve is befejezte az OpenGL mód supportját. A Vulkan mellett nem volt értelme.

  Tehát amikor valaki OpenGL-re dolgozik egy igen nagy programot, akkor igazából gyártói segítség nélkül azt nem fogják összehozni. És a gyártók is egyedi kódokat javasolnak, gyártói kiterjesztésekkel, amit a Valve szintén említett, hogy használják is bőven, mert az ARB-vel sokkal lassabb a program. Ilyen szintű együttműködés ugyan megoldható, de végül lesz gyártónként két-három kódút, és specializált driverek, és a kódutakat úgy kell karbantartani, hogy új driver kell a módosításokhoz. Ma már ezzel nem éri meg foglalkozni. Az egyetlen működő OpenGL debugert sem fejleszti már az AMD. Persze a forráskódját kiadták, hogy aki szeretne dolgozni, az elmaszatolhat vele, de sokkal-sokkal könnyebb Vulkan API-ra váltani.

  #57632 b. : Ami ugye Linux alatt megint úgy sikerült, hogy a Valve a saját programjaihoz módosította a meghajtót, vagyis ez sem szabványos teljesen.
  A szabványhitelesítés lényegtelen OpenGL alatt, mert az a gond, hogy maga a dokumentáció nem fogalmaz egyértelműen, hogy mik a követelmények. Egy-egy dolog implementációjára több út is van, és a gyártók ezt ki is használják. Itt változott nagyon sokat a Vulkan. Amikor átvették a Mantle API-t, akkor vele átvették az AMD dokumentációját is, és az nagyon szigorúan fogalmazza meg, hogy mit hogyan lehet implementálni. Ezt a Vulkan vitte tovább, tehát alig van olyan tényező, hogy valamiben kérdés merülne fel. Ha van is, azt is nagyon gyorsan egyértelműsítik, hogy ne álljon be az a helyzet, ami az OpenGL-nél.
  Az OpenGL dokumentációjával simán lehet olyan meghajtókat írni, amelyek mind átmennek a hitelesítésen, de eközben ugyanazokat a kódokat nem úgy értelmezik. És ez az API hibája, nem egyértelmű a specifikáció, és ezt a gyártók szándékosan félreértelmezik, hogy gyorsabb legyen a meghajtó, csak nem eszi meg a szabványos kódot.
  Érdekes módon a workstation piacon mindenki tudja, hogy mi a szabványos és mi nem. Ott eléggé egységesen van kezelve minden, akármilyen gyártói drivert dobsz fel, megeszi a szabványos kódot. Tehát nem hülyék a gyártók sem, csak tetetik, hogy hülyék, mert csak az AMD hozza át a workstation meghajtóját Windows alatt a gaming driverbe. Ez változik meg a következő nagy batch-csel, de ezzel együtt már az AMD meghajtója sem lesz szabványos.

  #57633 Petykemano : Igen jól érted. Az új meghajtóval a régi játékok OpenGL módja problémás lehet, de mivel alig van OpenGL program, így nagyon egyszerű per alkalmazás szintjén leprofilozni az egészet, és akkor az új meghajtó problémáit célirányosan lekezelni úgy, hogy az AMD még a fordítás előtt kicseréli a programkódot egy olyanra, amit a nem szabványos meghajtó megeszik. Ezt csinálja az NV is. Csak ugye az ilyen modell megöli az API-t, mert így fejleszteni lehetetlen rá, lásd fentebb Valve.

• #57632 b. félisten Yutani #57631

  Új Válasz 2022-06-17 09:03:45 #57632

  Ú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

  

  b.

  félisten

  válasz Yutani #57631 üzenetére

  Linux alatt amúgy egyáltalán nem rossz az AMD OGL futasa Nvidiához nézve,sőt.De ott nyílt forráskód ugye.Tehat szinte csak driveren mulik a sebesseg.Ott megoldjak a fuggetlen fejlesztők.
  Igen valószínűleg ez van mögötte.Évek óta az első szabványhitelesítéseket pont az Nvidia szerzî meg,tehát annyira nem mennek ők szembe ezzel a dologgal se driveresen se fejlesztői eszközök terén.

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