1) Čím složitější řešení, tím lepší potřebuješ inženýry a programátory. Proto taky AMD architekturu HSA opustilo. Bez spolupráce od OS a vývojářů aplikací by přínos nebyl takový, aby ospravedlnil tu makačku. Neříkám, že je to špatně - akorát uznávám práci Apple, že se snaží vyždímat každý skrytý kousek výkonu, aby byl konkurenceschopný (koneckonců Zen 3 je i jako CPU obecné architektury výkonnější než M1; ale takhle Apple překonal Zen 2 a Intel, což pro přechod na vlastní CPU není vůbec špatný).
2) Sdílená paměť neznamená HSA. VRAM na Android SoC, Rhapsbery Pi a Intel/AMD iGPU se chová jako samostatná (logická) RAM, jen je fyzicky namapovaná do prostoru systémové fyzické RAM (jde ale měnit její velikost za běhu). U primitivnějších řešení se data do ní musí kopírovat, tj. načtu z disku JPG, dekomprimuju na bitmapu, zkopíruju její bajty do VRAM (fyzicky na další místo ve fyzické RAM). U lepších řešení se označí paměťové stránky dekomprimované bitmapy jako grafická paměť, tj. zero-copy (myslím, že to takhle má nějakej rok AMD; nejde to použít vždy - někdy si aplikace chce ponechat bitmapu pro další práci). Nicméně ani u toho lepšího řešení nemůže s bajty bitmapy ve VRAM pracovat současně CPU a GPU (stránky paměti jsou buď RAM, nebo VRAM - ne obojí).
Tohle řeší HSA (Heterogeneous System Architecture): ačkoli s daty pracuje současně CPU (načtení bajtů JPG z disku), ISP (image signal processor; dekomprese JPG na bitmapu) a GPU (použití bitmapy ve vykreslení stránky), tak bitmapa je ve fyzické RAM jen 1x (a současně na ní mohou přistupovat všechny procesory a koprocesory, včetně funkčnosti cache).