Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Az Apple M1 modellje más. Ott a két mag nagyon hasonlít egymásra, emiatt nem kell külön szoftveres háttér rá. Szóval az Apple ezt nagyon másképp csinálja, mint a többiek.
A szerverplatformok egyáltalán nem ilyenek. Jó okkal, ott ez annyira nem lenne hasznos, mert throughput optimalizáltak. A hibrid dizájn mobil szinten hasznos, és onnan beszivároghat az asztaliba.A szoftveres probléma abban nyilvánul meg, hogy Androidon is úgy működnek az alkalmazások, hogy kiválasztanak egy klasztert aztán a többi magot érintetlenül hagyják. Nagyon kevés program használja ténylegesen az összes magot. Túl bonyolult.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13
Abu85
HÁZIGAZDA
Petykemano
#9
Abu85
HÁZIGAZDA
válasz
Petykemano
#9
üzenetére
Az AMD megoldása az az Apple-ét másolja. Alapvetően lesznek eltérő családból származó magok egy lapkán belül, de úgy, hogy az optimalizálásukra vonatkozó követelmények megegyeznek majd, tehát a szoftver felé nem kell hibridként kezelni őket. A programozók felé így ez az egész transzparens lesz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Írtam, hogy az AMD is ugyanezt csinálja, csak azzal a különbséggel, hogy ők nem akarják azt, hogy a programozóknak törődni kelljen az eltérő optimalizálásokkal a magtípusokra, így az AMD megoldás a programozók felé transzparens lesz.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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
Androidon is probléma ez. Csak azért nem látszik annak, mert a fejlesztők többsége szarik rá, és hozzá sem ér az alkalmazás az egyik magcsoporthoz. A hardver itt nem tud csodát tenni. Képes az OS kiosztani a feladatokat, de nem tudja ezt megtenni optimálisan, így a program oldaláról ezt "hint-ekkel" irányítani kell. Ebből a szempontból nem különbözik az, amit mondjuk a Hitman 3 csinál az Alder Lake-S-re attól, amit egyébként meg lehetne tenni Androidon is, ha nem szarnának bele a fejlesztők. Egyértelmű eseteket egyébként már az OS el tud dönteni a hardverből származó adatok alapján, de sajnos van nem kevés kevésbé egyértelmű helyzet is. Ahhoz mindig is programoldali segítség fog kelleni.
[ 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
És ezért csinál nagy hülyeséget az Android, hogy ezt alapból nem engedik flagelni, hanem szükségesek hozzá a gyártói segítség. Az Intel nem véletlenül rakta bele az új procijaiba a CPUID Hybrid Function Table-t. Ez két flaget jelent: Hybrid Flag és Core Type. Tehát a fejlesztőnek konkrét látképe lesz arról, hogy mit tartalmaz a hardver. Ez az extra adat azért fontos, mert előre meg tudják majd határozni, hogy az adott processzorra érdemes-e irányítani a szálkiosztást. A SetThreadIdealProcessorral ez kijelölhető, noha az Intel is mondja, hogy garancia arra nincs, hogy tényleg arra osztja rá az OS a szálat, amit a program kijelöl, de megpróbálja, és azért sokszor sikerül is jó helyre kiosztani a feladatot, ami nagyon fontos annak érdekében, hogy ne legyen az egész játékélmény dadogós.
Az ARM esetében is meg lehetne ugyanezt csinálni gyárilag (a flagek ott vannak), mert nem véletlenül van benne az Intel dizájnjában. Ha nem lenne szükség rá, akkor nyilván nem lenne az Intelnél sem használható, de sajnos szükség van rá, mert az OS ütemezője az nem jósgömb és nem is csodatevő. Az, hogy az Android azt hiszi, hogy az, elég nagy gond az egész ökoszisztémára nézve. Nyilván nem véletlenül van ennyire lemaradva az iOS mögött a high performance címek tekintetében.
[ 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.
Ú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.
- Amazon Kindle
- Kamionok, fuvarozás, logisztika topik
- Amlogic S905, S912 processzoros készülékek
- Nyíregyháza és környéke adok-veszek-beszélgetek
- A régi node-okra koncentrál a szankciók miatt Kína
- Magga: PLEX: multimédia az egész lakásban
- Azonnali VGA-s kérdések órája
- Windows 11
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Facebook és Messenger
- További aktív témák...