2017. november 24., péntek

Vélemény: mennyire tervezhet saját IGP-t az Apple?

  • (f)
  • (p)
Írta: | | Forrás: PROHARDVER!

A vállalat már most is módosítja az Imaginationtől licencelt IP-ket, de hol az ideális határ?

Az Apple kapcsán rendre felmerülnek azok a híresztelések, miszerint saját IGP-t terveznek. Ezeket a pletykákat számos tényező erősíti, többek között az idei év első felében az Imaginationtől elbocsátott szakemberek egy része pont az Apple-nél talált otthonra, de vannak ellenérvek is, leginkább az, hogy GPU-t tervezni nagyságrendekkel nehezebb, mint CPU-t.

Az viszont látszik, hogy az Apple egyre több részegységet tervez házon belül. Az A6-os SoC óta saját processzormagokkal dolgoznak, míg az A7-es rendszerchiptől kezdődően már az Imaginationtől licencelt IP-ket is módosítják. Az IGP-be ráadásul egyre jobban belenyúlnak. Az elején még csak a részegységek számával játszadoztak, így olyan dizájnt is létrehoztak, amilyet az Imagination nem is kínált, míg az új A10-es lapka esetében már konkrétan kicserélik a shader motort, ami a Rogue architektúrában az USC nevet viseli. Erről a Real World Tech írt pár hete egy részletesebb beszámolót, amely részben az Imagination és az Apple publikus dokumentációinak eltéréseire alapoz.

A Real World Tech szerint az A10 Fusion SoC IGP-je az Imagination PowerVR Series7XT Plus dizájnba annyiban nyúl bele, hogy az eredeti, 32 bites lebegőpontos feldolgozásra tervezett multiprocesszorokat 16 bites lebegőpontos feldolgozásra tervezett opciókra cseréli, azaz 16 bitesek lettek a regiszterek és 16 bitesek az adatutak. A 32 bites lebegőpontos feldolgozás persze továbbra is megoldható a regiszterterületek duplázott felhasználásával, ám ennél nagyobb vívmány, hogy a 16 és 32 bites adattípusok közötti konverzió ingyenes.

Az eredeti PowerVR Series7XT Plus dizájn működését figyelembe véve látszatra ennek a változásnak nincs hatása, a valóságban azonban nagyon is sokat jelent, ugyanis az Imagination a 32 bites lebegőpontos feldolgozásra tervezett dizájnt egészítette ki teljes sebességű 16 bitessel, míg az Apple fordítva dolgozott, vagyis 16 bites lebegőpontos feldolgozásra gyúrták ki a rendszert, ami képes a 32 bites operációk végrehajtására is, de felezett sebességgel. Ha csak nyers elméleti számokat értékeljük, akkor az eredmény ugyanaz, viszont ha figyelembe vesszük az energiahatékonyságot is, akkor az Apple dizájnja 16 bites, míg az Imaginationé 32 bites lebegőpontos végrehajtás mellett optimális. Tekintve, hogy az ultramobil piacon az előbbi célszerűbb, az Apple ezzel fogyasztást spórol.

Persze az almás cég helyzete egyszerű a Metal API miatt, illetve a hardverükhöz saját maguk írják a shader fordítót, valamint a meghajtót is. Ez adta tulajdonképpen a lehetőséget a cégnek, hogy a hardver módosítását is elővegyék, mivel képesek profitálni belőle. Ugyanakkor a fentebb leírt optimalizálás biztonságosnak számít, mivel készen kapták az utasításarchitektúrát, illetve az egész hardverdizájnt, amiben a multiprocesszorokat kicserélni alternatív megoldásokra nem komoly munka.

Az igazi kérdés, hogy az Apple meddig lépdel tovább. Saját fixfunkciós blokkok tervezése jóval nehezebb, és nincs is megfelelő tapasztalata ebben a cégnek. Egy teljesen saját grafikus vezérlő még nehezebb, és még több tapasztalatot igényel. A pénz pedig nem minden, láthattuk ezt az Intelnél is a Larrabee esetében, amelyet a gyenge teljesítménye miatt törölni kellett.

A legvalószínűbb opció, hogy az Apple továbbra is Imaginationtől licencelt alapokat fog felhasználni, és a multiprocesszor erejéig azokat módosítják, hogy kedvezőbben tudják kiszolgálni a célpiacot. Emellett bőven elképzelhető, hogy a teljes iOS platform uralásával, és most már egy saját grafikus API-val bevezetnek bizonyos újításokat, amelyekhez saját IP blokkokat fognak tervezni az Imagination fejlesztéseibe. A lényeg továbbra is az lehet, hogy minden olyan, aránylag biztonságosan és gyorsan kivitelezhető módosításba belefognak, amely számottevő előnyöket biztosít az ultramobil eszközök piacán.

H​ir​d​eté​s

Gyártók, szolgáltatók

H​irde​té​s

Copyright © 2000-2017 PROHARDVER Informatikai Kft.