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

• #57629 Abu85 HÁZIGAZDA huskydog17 #57625

  Új Válasz 2022-06-16 23:03:40 #57629

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

  Évek óta ismert problémát írtam le. Ez végezte ki az OpenGL-t.

  #57626 Hellwhatever : Leginkább úgy, hogy amikor az OpenGL-t specifikálták, akkor már a fejlesztésébe bele volt kódolva, hogy el lehet szarni.
  Rich elég sok előadást tartott anno, amikor a Valve motorját portolta natívan OpenGL-re. A lényege ezeknek mindig az volt, hogy hiába beszélünk egy API-ról, a gyártók az egyes függvényeket másképp implementálják. Egyszerűen a specifikációban leírtak nem egyértelműek.
  Többször utalt rá, hogy az NV-vel gyorsan működhetnek a dolgok, de a kód, amit így megírsz nem lesz szabványos, és az NV-nek a fejlesztőeszközei pontosan ezért használhatatlanok, mert a debug eszközökkel összevesznek, ugyanis a debug nem azt várja, amit kap, egy nem szabványos kódot. A fejlesztéshez tehát nem tudott a Valve mást használni, csak AMD hardvert, mivel a GPU PerfStudio és a CodeXL eléggé szabványos eszközök voltak, és kompatibilisek szabványos debug eszközökkel is, illetve az AMD workstation drivere is szabványosan kezeli az API-t, de ha erre megírsz egy kódot az nem jó az NV-nek, mert az meg más kódot vár. Olyat, ahogyan az NV értelmezte a szabványt. Emellett az AMD workstation drivere pont azért workstation driver, mert arra van kigyúrva, hogy a specifikációknak megfelelően kezelje az API-t, és ilyenkor nem csinál olyat, amitől az alkalmazás összeomolhatna, nem értelmezi szabadon a függvények specifikációit, hogy kihagyjon teljesítményigényes ellenőrzéseket. Utóbbitól lesz egy performance driver gyors, egyszerűen a nagyon lassú munkafolyamatokat koncepció szintjén kihagyja, még akkor is, ha a specifikáció előírja az erőforrások ellenőrzését, annak érdekében, hogy ne alakulhassanak ki hazardok. Viszont ilyenkor nagyon sok múlik a játékra szabott meghajtón, mert ott kell olyan ellenőrzési rutinokat beépíteni, ami ezt megakadályozza, ha már az API működését nem követik. És ez az, amiért a performance driverekkel lehetetlen a nagy OpenGL alkalmazások debugolása és profilozása. Egyszerűen a meghajtó még nem ismeri az alkalmazást, és az ellenőrzések kihagyásával tele lesz az egész munkafolyamat hazarddal.

  Ezen túlmenően nagy gond volt még a shader fordítás. Az OpenGL programban magát a shader forrást kellett szállítani, és azt a meghajtó fordította le a GPU-nak. De az egyes meghajtók más kódokat igényeltek, attól függően, hogy miképpen értelmezték a specifikációt, ezért kellett külön shader az összes gyártónak, sőt, az egyes architektúrák sem mindig fogadták el a gyártóspecifikus shadert, így hiába beszéltél szabványról, akkor is egy gyártóra két-három kódutat szállítottál OpenGL-ben, vagyis mindent kb. 7-9-szer kellett megírni. És mivel más megoldás nem volt, ez egy leülős-gépelős feladat volt.

  Nem véletlen, hogy a Vulkan API már sokkal egyértelműbben fogalmaz a specifikációk tekintetében. Kevésbé félreérthető. Alapvetően a dokumentációját az AMD-től emelték át, és azt módosították, tehát helyből már egy olyan alap állt rendelkezésre, amit hozzáértők írtak meg. És így már jól lehetett építeni erre az alapra. A shader fordítást is megváltoztatták, mostantól nem lehet forrást szállítani, hanem IR-t kell, és az IR-re gyári fordító van, vagyis nincs olyan, hogy az NV/AMD/Intel "véletlenül" máshogy értelmezte a specifikációt. Az IR-ig hozzá sem tudnak szagolni a fordításhoz, tehát ők már csak az IR után dolgozhatnak, és ez a köztes nyelv nem magas szintű, így sokkal-sokkal egyértelműbb, mint magas szintű nyelvről gépi kódot fordítani.

  Röviden, az volt a gond, hogy OpenGL-re nagy applikációkat lehetetlen volt írni egy kódútból. Egyszerűen több kellett. Emiatt meg is pusztult az API. A Valve is áttért később a Vulkan API-ra, mert igazából nagyon-nagyon drágává tette az OpenGL mód karbantartását az, hogy 7-8-szor volt megírva minden.

  #57628 morgyi : Igazából a gyártóspecifikus kiterjesztések egyszerre voltak hasznosak és katasztrofálisak. Az egyik előadáson Rich meg is említette, hogy ARB kiterjesztésekkel lehetetlen gyors kódot írni, egyszerűen azok túl rosszak. Emiatt a Valve is a lehető legtöbb dologra gyártóspecifikus kiterjesztéseket használt. Ha ezek nem lettek volna, akkor az OpenGL a DirectX leképező teljesítményének a huszadát sem szedte volna össze, annyira el van szarva az egész. A kiterjesztésekkel lehet hozni bele teljesítményt.

  Nincs azon mit csodálkozni, hogy manapság nem igazán jön OpenGL-re semmi. Néhányan a régi kódutakat még karbantartják, de a Vulkan akkora átütő siker, és a Khronos annyira leállt az OpenGL fejlesztésével, hogy ez a kérdés már rég eldőlt.

  [ 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