Új hozzászólás Aktív témák
-
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.
Ú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.