Na podobný mezikrok nedošlo poprvé a ačkoli takové řešení není ničím velkým (v kontextu integrovaných grafik to platí opravdu doslova), jde o drobné pozitivu pro výrobce i zákazníka. AMD si tím může ověřit funkčnost některých novinek v praxi (křemík s RDNA 3.5 má k dispozici podstatně dříve než první vzorky RDNA 4) a uživatel tím dostane mírně pokročilejší hardware.

O RDNA 3.5 se čas od času objevují informace od minulého roku - tentokrát se však zaměříme na tři novinky, které jsou potvrzeny kódem LLVM.

Skalární jednotka nově s FPU

Architektura GCN uvedená v roce 2011 byla postavena na výpočetním bloku vybaveném jednou skalární jednotkou a šestnácti vektorovými jednotkami. Účel skalární jednotky byl takový, aby některé jednodušší výpočty (často režijního ražení) mohly běžet na ní a neblokovaly vektorové jednotky. Rámcově podobná filozofie fungovala i u četných starších grafických architektur ATi / AMD, kdy vec4 jednotku doprovázela jednotka skalární (fungující také jako SFU) nebo později (R6xx-R7xx) superskalární VLIW o pěti jednotkách, z nichž jedna byla opět vybavena jako SFU. Později (byť jen na jednu generaci) AMD pátou jednotku odstranila a jí zpracovávané výpočty byly rozloženy na čtveřici základních jednotek.

Tyto změny nejsou ničím jiným, než přizpůsobování se aktuálním potřebám, které jsou dané jak požadavky soudobého softwaru, tak konkrétní hardwarovou konfigurací grafické architektury. Vrátíme-li se k GCN a RDNA, je zjevné, že poměr instrukcí, které by bylo možné zpracovávat na SFU (např. trigonometrické operace) není takový, aby se vyplatilo mít pro ně samostatný hardware. GCN / RDNA tudíž SFU nemá. Na druhé straně některé standardní celočíselné instrukce se stále vyplácelo provozovat na zvláštní skalární jednotce, protože jich už bylo tolik, že by zbytečně brzdily vektorové jednotky.

S RDNA 3.5 AMD usoudila, že nastal čas vybavit skalární jednotku FPU obvody, jinými slovy naučit skalární jednotku výpočty v plovoucí desetinné čárce. To GCN ani první tři generace RDNA neuměly. Skalární jednotka bude nově podporovat výpočty FP16 i FP32. AMD zjevně cítí nárůst jejich poměru oproti ostatním, v důsledku čehož upravila hardware tak, aby nemusely běžet na vektorových jednotkách, ale mohly být prováděny paralelně s vektorovými výpočty na skalární jednotce. V situacích, kdy dochází na FP16 / FP32 výpočty, kterým dostačuje výbava nově rozšířené skalární jednotky, nebudou na RDNA 3.5 muset ostatní výpočty čekat, ale budou prováděny paralelně.

V FP16 i FP32 jsou podporovány instrukce typu Add, Subtract, Multiply, Fused Multiply-Add, Minimum, Maximum, Ceiling, Floor, Compare (less than, greater than, not less than, equal/not, aj.). V FP32 pak s_fmamk_f32 a FP32 vstup → FP16 výstup s_cvt_pk_rtz_f16_f32 (slouží ke zkonvertování dvou FP32 hodnot do dvou FP16 hodnot a uložení do 32bit skalárního registru).

V praxi to může znamenat mírně zvýšenou efektivitu architektury (jak výpočetní, tak energetickou), ale u většiny typů zátěže bych neočekával nějak zásadní rozdíl.

Instrukce pro VGPR

VGPR znamená Vector General Purpose Register. Pokud jde o registry, liší se poměrně výrazně přístup AMD a přístup Nvidie. AMD dlouhodobě tíhne k hardwarovému řešení, Nvidia k výraznějšímu využití softwaru. Obojí má své. AMD až do RDNA 3 do registru ukládá všechny vstupy, u Nvidia umožňuje kompilátor pro každou pozici operandu označit, zda bude opětovně využita a má ji smysl ukládat do register cache. Tato úspora register cache si ovšem vybírá daň v podobě velmi dlouhých instrukcí, které od generace Turing dosahují délky 128 bitů. AMD naproti tomu do RDNA 3 včetně dosahuje typické délky instrukcí 32-64 bitů s volitelným rozšířením o 32bit immediate (přímý operand). RDNA 3.5 umožňuje volitelné rozšíření o instrukci s_singleuse_vdst, která říká, že vstupy následné instrukce již nebudou využity, takže ukládání příslušných operandů do registru není potřeba.

Byť jde o jednoduché řešení, podstatně zvyšuje flexibilitu, neboť umožňuje balancovat mezi délkou instrukcí (na to byly cíleny dosavadní architektury AMD) a využitím registru (na to byly cíleny dosavadní architektury Nvidie).

s_singleuse_vdst bude podporována i u RDNA 4.

Instrukce DPP

Instrukce DPP (Data Parallel Processing) budou nově podporovat dva skalární vstupy (až do RDNA 3 byl podporován jen jeden skalární vstup). Je známo, že tato změna se bude týkat jak RDNA 3.5, tak RDNA 4.

Vydání APU Strix Point (Zen 5 + RDNA 3.5 pro notebooky) se očekává někdy koncem letošního léta. Vydání velkého APU Sarlak (Zen 5 + RDNA 3.5 pro herní notebooky) někdy v zimě 2024 / 2025, snad v lednu na CES 2025.

• APU Kraken Point (menší Strix) je stále ve hře, přinese 4× Zen 5 + 4× Zen 5c

Krom toho se očekává ještě menší APU Kraken Point, které rovněž bude vybaveno grafikou RDNA 3.5 (nedávno jsme se dozvěděli, že původně zvažovaná konfigurace s dvěma velkými jádry Zen 5 byla rozšířena na čtyři velká jádra Zen 5, která doplňují čtyři kompaktní jádra Zen 5c).