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

• #40 Abu85 HÁZIGAZDA vicze #39

  Új Válasz 2023-10-16 23:11:02 #40

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

  Itt nem optimalizált kódról van szó, hanem egyfajta leképező technológiáról. Az androidos mobil játékok szinte mindegyike valamilyen tradicionális CPU-based renderinget alkalmaz, ami azért van így, mert a mai ultramobil GPU-k többsége UBO-ra van optimalizálva, vagyis nem igazán szeretik, ha a hozzáférési minták túl dinamikusak. Ez régen egy koncepció volt, mert az ultramobil architektúrák nagyban építenek egy kis beépített pufferre a vertex attribútumokhoz, de ez manapság már nagyon elavult megközelítés. Már csak azért is, mert az Unreal Engine 5 működése masszívan a GPU-driven pipeline-ra épít. És alapvetően az alkalmazott leképezőhöz elég lenne egy Adreno 740 teljesítménye, de hiába a beépített GFLOPS, ha a hardver UBO-ra optimalizált működése miatt minden vertex shader háromszor fut per pixel, és a texture fetch optimális sebességéhez 20-nál is több memóriabetöltésre van szükség egy pixel shaderben. Egyszerűen egy rakás tök haszontalan munkára van kényszerítve a hardver az elavult felépítése miatt. És ez a Vulkan API-tól sem függ igazán, mert GPU-driven pipeline OpenGL alatt is írható. A Vulkan inkább csak ahhoz kell, hogy meglegyen a tízezer rajzolás, mert ennyi például kell az Xbox 360-ra kiadott címek portolásához. És itt óriási a különbség az egyes dizájnok között. tízezer rajzolási parancs egy RDNA 2 architektúrájú IGP-n ~1 ms-nyi processzoridő, de egy Adreno 600 architektúrájú IGP-n ~15 ms. Tehát hiába vagy GFLOPS-ban hasonló vagy jobb szinten a Qualcomm dizájnjában a Samsung-féle Xclipsével, akkora büntetést kapsz a processzorterhelésen az alaparchitektúra rég elavult működése miatt, hogy brutális CPU-limited lesz egy GPU-driven pipeline játékban.

  Ez az a gond, amit az Apple korábban észrevett, és most a Samsung is. Egyszerűen se a Qualcomm, se az ARM nem foglalkozik ezzel a gonddal, mert abban élnek, hogy Androidra jóvan ez így, de a Samsung számára fontos az is, hogy az Apple-t elkapja, és ehhez már nem elég a Qualcomm és az ARM, mert azokkal az IGP-kkel csak brutális többletterhelést kapnak, ami az Apple dizájnjait nem bünteti. Ezért váltottak az Xclipsére, mert ebben a többletterhelést gyakorlatilag a tizenötöd részére csökkentették, tehát ugyanahhoz a GPU-driven pipeline kódhoz egy RDNA 2 dizájnnal 15-ször kevesebb processzoridő kell a rajzolások szempontjából, és ez lehetővé teszi azt, hogy az Xbox 360-nál alkalmazott leképezők elérhetők legyenek Androidon is. Qualcomm és ARM IGP-vel ehhez 15-ször erősebb processzorrész kell, az meg már nem fér bele a fogyasztási keretbe, okostelefonoknál sajnos nagyon nem.

  Azért elég nagy különbség van a Xenos és a Z430 között. Az egyik legnagyobb a memóriamodellje, ugyanis a Z430-at ultramobil szintre tervezték arcade felhasználásra. És emiatt a Xenos memóriamodellje csak lecsupaszítva került bele, ráadásul az EDRAM is sokkal-sokkal kevesebb volt, ami a Xenosnál nagyon fontos tényező, mert abból nyeri az SSBO modell hatékony feldolgozását. Erre a Z430 képtelen lett volna, mert aprócska tárral rendelkezett volna. Ezt végül a Qualcomm nem is építette bele az utódba, mert hasztalan volt arra a szintre, amire lőttek. Szóval tök nyolc, hogy egy ultramobil IGP tudja GFLOPS-ban az Xbox 360-at, ha nem tudja hatékonyan futtatni azt a feldolgozási modellt, ami a Xenos működését hatékonnyá tette. Lásd Unreal Engine 5 problémái az ultramobil dizájnokon.

  [ 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