Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Ez nem ennyire egyszerű. Itt nem csak a feladatok kiosztása a lényeg, hanem az, hogy egy feladat milyen magra illik. Erre vannak különböző programozási technikák az ARM részéről, illetve az Intelnél is. Az Intel kapcsán például a Hitman 3 ilyen, bizonyos kódolási feladatokat dedikáltan a kisebb magokon végez, és erre a programozó figyel a programkódban, hogy oda is kerüljön a feladat.
Az Android esetében ennyire nincs ez elterjedve, de nem azért, mert az ARM-nak nincs rá megoldása, hanem azért, mert szarik rá a fejlesztő. Kiválaszt egy klasztert aztán a többi magot elengedi.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az Android is csak egy OS. És nem is az Android választja ki ezt, hanem a programban van lehetőség arra, hogy ezt megtedd. Képzeld mennyire zord világ lenne, ha nem tudnád megcsinálni. A grafikus parancskezelés random mehetne a leggyorsabb és a leglassabb mag között bármin. Durván méretes lagokat produkálnának ezek az állapotváltások. Ergo van lehetőség arra, hogy egy feladattal dedikáltan lehessen célozni egy kijelölt magot, vagy akár egy klasztert.
A Snapdragon esetében ezt a HetCompute SDK szolgálja, amit natív Android appba lehet integrálni. De van az ARM-nak is ilyenje, tehát nem kell ám gyártóspecifikust használni, csak nyilván a gyártóspecifikus valamivel hatékonyabb lehet. Ezzel az SDK-val úgynevezett "hint-eket" adhatsz az OS-nek arra, hogy melyik feladatot hova helyezze, és ebbe beletartozik az is, hogy mindent megpróbálsz egy kiválasztott klaszterre rakni, mert marhára nincs pénzed azt leoptimalizálni, hogy minden mag jól működjön az alkalmazásod alatt. Ezért választják a fejlesztők jellemzően ezt a módszert. Egyszerű, olcsó kivitelezhető, és a tesztelhetősége hasonló a PC-s dizájnokhoz.
A Power Optimization SDK az más, ugyanis az nem biztosít lehetőséget arra, hogy megpróbáld kontrollálni azt, hogy melyik feladat melyik magon fusson le.
Az alap Android API-ban nincs is. Ez a baj. Erre vannak a kiegészítő SDK-t, például a HetCompute, ha mindenképpen a Snapdragont szeretnéd példának. Egyébként maga a HetCompute is jóval több annál, mint pusztán a heterogén többmagos dizájnt kezelhetővé tenni a programozó számára, mert hozzá lehet nyúlni a Snapdragon egyéb részegységeihez is, de ez most mellékes.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Csak egy picit gondolj bele, hogy mi történne, ha nem lehetne "hint-ekkel" rábírni a rendszert, hogy egy célzott magra rakja rá az adott feladatot. Például a játékoknál ott a parancsfeldolgozás, ami OpenGL ES alatt egyszálú. Tehát elindítod a játékot, az OS pedig kiválasztja neki a leglassabb magot. olyan CPU-limited lenne, mint a ház, mert neked a leggyorsabb mag kellene erre a feladatra. De állításod szerint ezt nem tudod megtenni, az OS feletted dönt. A te leírásoddal random dobálná az OS az alkalmazás teljesítményét indításonként.
A Vulkan ugye explicit párhuzamos, tehát ott még nagyobb gond lenne az, hogy a fejlesztőnek nincs beleszólása, hiszen egyrészt a parancsok nem fix hosszúságúak, az OS nem tudja előre, hogy melyik parancs mekkora batch-et tartalmaz. Ezt még maga a program sem feltétlenül tudja, akkor lesz róla tudomása, miután kiosztásra került a feladat a magra. Ellenben tud következtetni abból, hogy egy adott munkafolyamatra a múltban milyen batch-méretek voltak alkalmazva, és eszerint van az optimalizálás is. Ha úgy működne az Android, ahogy te vázolod fel, akkor egy Vulkan program tele lenne akadással, mert a magok eltérő teljesítményét folyamatosan megfogná a shader újrafordítás, ugyanis ez kiosztásra kerülhet a leggyorsabb magokra, illetve a leglassabbakra is. Gyakorlatilag másodperces lagok lennének az alkalmazásokban, attól függően, hogy a szerencsefaktor mit intézett a sorstól.
Szerencsére van mód a kontrollra, az más kérdés, hogy a többség így is leszarja, mert nehéz eldönteni, hogy minek lesz rossza kis mag, és minek lesz jó. Ennek az egyszerű megoldása az, hogy a kis magokhoz ne is nyúljon hozzá az alkalmazás. Akkor nagy baj nem lehet. Mély tisztelet a kivételnek, aki jól megcsinálja.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az OS-nek fogalma sincs arról, hogy egy grafikai parancs milyen igényű. Ez csak akkor derül ki, amikor a batch látszik, de akkor meg már késő. Arról sincs fogalma, hogy kell-e shader újrafordítás, ez ugyanis a folyamat elindítása után derül ki, nem pedig előtte.
Mármint papíron megfelelő teljesítményt, de vannak olyan problémák, amik csak akkor derülnek ki, amikor már elindult a munkamenet. Akkor ez a módszer nem elég jó, tehát a programnak jó lenne megmondania előre, hogy kellhet-e nagyobb teljesítmény.
Nem az a gond, hogy nem lehet dinamikus magkiosztást csinálni, hanem az, hogy nem egy feladat van, főleg grafikus motoroknál, ahol túl későn derül ki, hogy mekkora teljesítményigénye van egy feladatnak. Ha ez nem lenne gond, akkor a Hitman 3 sem lenne úgy optimalizálva, hogy a motor dedikáltan célozza az egyes munkafolyamatokkal az egyes magokat (például úgy van megírva a grafikus parancskreálás, hogy grafikai parancsot csak nagy mag dolgozhat fel, ezzel szemben tartalomkódolást csak kis mag, stb.), és ugyanígy kellene eljárni az ARM-os rendszerek esetében is, csak Androidon nincs akkor pénz, hogy erre időt szakítson bárki is. Androidon például az is megoldhatatlan feladatnak, hogy tök szabványos textúraszűrést hiba nélkül megcsináljon az IGP. Tiszta bugok a gyártói Vulkan implementációk, ezernyi sebből vérzik a teljes szoftveres háttér, szóval kb. pont leszarják, hogy egy valami rossz magon fut, mert legalább fut, ezernyi más hibával szemben, amelyek nem is futnak jól/hibátlanul.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
A Big.Little esetében is hintekkel dolgoztak a fejlesztők, és ugyanúgy lehet hintet alkalmazni bármilyen rendszerre. Nagyon is hasznos dolog ez, mert ugye borzasztó akadásokat kapnának a játékosok, ha az OS csak úgy rárakná a parancskreálást a kis magra úgy, hogy közben legalább tíz parancsot batch-el az adott csomag. Gyakorlatilag fél másodpercig megállna a feldolgozás. Aztán hiába korrigálja magát, hogy megy vissza a nagy magra a szál, a baj már megtörtént. Az Intel nem véletlenül vezette be a flagelést, mert nyilván ez náluk is ugyanolyan probléma, mint az ARM-nál, és ezt az okozza, hogy az egyik mag látványosan kisebb teljesítményű a másiknál.
Ha ezt pusztán az OS-re bíznák, akkor az elég nagy gondokat okozna, mert az OS-nek se jósgömbje nincs, hogy pontosan lássa mi lesz, és időgépe sincs, hogy a rossz döntéseket visszacsinálja. Egyedül és kizárólag a fejlesztők tudnak tenni azért, hogy ne legyen egy lagfest a program. Persze az Android már önmagában egy akkora szarlavina, hogy komoly játék nem érkezik rá, de technológiailag lehetséges lenne.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ugyanilyen hintekkel dolgozik a Qualcomm HetCompute SDK.
Próbáld ki mekkora akadást eredményez egy tíz parancsból álló batch, ami nem a nagy magon fut le. Az Unreal Engine Vulkan leképezőjével sok ilyen szituációt tudsz majd tesztelni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A HetCompute a hint-ekre egészen egyszerű módszert használt. Annak megvan az utódja.
Most belinkeltél egy 2017 májusában írt dokumentumot miközben maga a motor Androidon a Vulkan API-t 2018-ban véglegesítette. Szó sem volt akkoriban arról a problémáról, hogy az explicit parancsgenerálása a Vulkan API-nak rossz magra rakhat a parancskreálást, mert akkoriban az OpenGL ES egy szem magon futott, és nem volt skálázható. A skálázás nagyjából másfél éve jelent gondot, mivel elég sokat fejlődött ahhoz az UE4, hogy default explicit párhuzamos legyen ultramobilon a leképező skálázása (töltsd le a legújabb motorverziót, és nézd meg, hogy így van már beállítva). Mert ugye 2020 előtt hiába volt maga az API explicit párhuzamos, a default működés egy szálra volt korlátozva Androidon a motorban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Reggie0
félisten
Pont az ellenkezoje van leirva:
"You can set Android N to permanently run the processor at lower clock speeds, reducing battery drain.
Android N has a sustained performance mode API that is guaranteed to run indefinitely at a lower performance level. While a fast peak performance is attainable on mobile, you cannot sustain it indefinitely due to heat and battery drain concerns."Amugy logikus, ha ki tudja a fejleszto optimalizalni a kodot alacsony fogyasztashoz, akkor a proci teljesitmeny ingadozas sem fog problemat okozni, mert onnan csak felfele tud ingadozni. Egy atlag telo meg a waze-tol is elizzik, nagyobb teljesitmenyt igenylo jateknal garantalt a trottyling, legfeljebb nehany gamingre optimalizalt es nem is tul szeles korben elterjedt telefont vagy tablet leszamitva.
[ Szerkesztve ]
Új hozzászólás Aktív témák
ph A Meteor Lake már három eltérő teljesítményű magot is bevet, de ez még csak a kezdet.
- TCL LCD és LED TV-k
- Kerékpárosok, bringások ide!
- HBO Max & OD topic
- Otthoni hálózat és internet megosztás
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- OpenMediaVault
- Amazon Fire TV stick/box
- Autós topik
- További aktív témák...