Intel opisuje pierwsze szczegóły architektury GPU X^e i oneAPI

Superkomputer Aurora zostanie zbudowany przez Intela i Cray (część Hewlett Packard Enterprise) z procesorów i akceleratorów obliczeniowych Intela. Jak zapowiedziano, będzie się składał z segmentów wyposażonych w 2 procesory i 6 akceleratorów każdy. Rolę procesorów będą pełniły układy z rodziny Sapphire Rapids – wykonane w litografii klasy 10 nm i wykorzystujące mikroarchitekturę Willow Cove, następną po obecnie najnowszej Sunny Cove. Te procesory mają być wyposażone w kontroler pamięci DDR5 i PCI Express 5.0.

Akceleratorami obliczeniowymi będą GPU o nazwie roboczej Ponte Vecchio (wł. „stary most” – od słynnego mostu we Florencji). Będą zbudowane w zapowiadanej od dawna architekturze Xe i wykonane w litografii klasy 7 nm. Poszczególne akceleratory Ponte Vecchio w ramach jednego segmentu będą połączone między sobą oraz z procesorami za pomocą łącz CXL, czyli PCI-E 5.0 z dodatkowymi elementami protokołu pozwalającymi na zachowanie spójności pamięci. Cały komputer z dwoma procesorami i sześcioma akceleratorami będzie mógł dzięki temu operować na jednolitej przestrzeni adresowej.

Ilustracja poglądowa jednego segmentu superkomputera Aurora. W rzeczywistości procesory i akceleratory będą zapewne wymienne.

Xe – architektura i mikroarchitektury

Intel podtrzymuje swoje plany wprowadzenia na rynek procesorów graficznych w nowej architekturze w 2020 roku. Jak wyjaśniono, architektura Xe – podobnie jak Graphics Core Next albo x86 – określa zachowanie i sposoby programowania sprzętu, a można ją zrealizować za pomocą różnych mikroarchitektur. Ponte Vecchio będzie używać innnej mikroarchitektury, niż desktopowe karty graficzne Intela. Nie wiemy jak daleko będą sięgać różnice, ale zapewne będą dotyczyć precyzji obliczeń (niektóre formaty – BFLOAT16, INT8 – nie są przydatne w grafice 3D) oraz zasobów nie-obliczeniowych GPU, które pozwalają mu wyświetlać obraz i zarządzać pamięcią. 

Akceleratory Ponte Vecchio nie będą monolityczne, ale złożone z wielu jąder. Intel wymienia technikę Foveros, ale to tylko nazwa marketingowa, a na pytania o dokładną budowę nie odpowiedziano. W przypadku Ponte Vecchio najpewniej nie chodzi o aktywną przekładkę, zamontowaną aktywną stroną w kierunku aktywnej strony jadra obliczeniowego, ale o pasywną przekładkę łączącą dwa lub więcej jąder obliczeniowych oraz  pamięć typu HBM – podobnie jak w akceleratorze SI Huawei Ascend 910. 

oneAPI – jeden kod na wiele platform, nie tylko Intela

Sądzimy, że sukces Xe będzie zależał w głównej mierze nie od szczegółów budowy pierwszych implementacji tej architektury, ale od środowiska programistycznego jakie Intel stworzy wokół swoich produktów. Jego podstawą będzie oneAPI – interfejs programowania, który ma pozwolić oddzielić kod programu od architektury, a nawet rodzaju urządzenia, na którym program ma zostać uruchomiony. W wizji Intela programiści będą przygotowywać programy w opracowywanym przez Intela języku DPC++ lub używając innych języków i funkcji udostępnianych przez API dostarczane przez Intela. Ten kod będzie mógł być skompilowany do postaci zgodnej z przygotowywaną przez Intela specyfikacja Level Zero.

Można w uproszczeniu powiedzieć, że Level Zero ma być meta-zestawem instrukcji, uniwersalnym zestawem funkcji obliczeniowych, które moga być zrealizowane przez różne rodzaje sprzętu. W zamyśle Intela programiści będą pracować w znanych obecnie językach lub w Data Parallel C++ (oparty na C++ oraz specyfikacji SYCL). Programy będą kompilowane do postaci zgodnej z Level Zero, która będzie przekazywana sterownikowi dowolnego akceleratora. Producent tego akceleratora ma zadbać o to, żeby jego sprzęt wykonywał programy zgodne z Level Zero jak najlepiej wykorzystując swoje atuty.

Obecna rozwojowa wersja oneAPI jest dostępna przez Intel Devcloud, usługę sieciową pozwalającą wypróbować techniki programowania oraz sprzęt Intela korzystając z połączenia z demonstracyjnymi komputerami z procesorami, akceleratorami oraz FPGA Intela. Intel udostępnia m. in. narzędzie do konwertowania kodu CUDA na DPC++. Większa część konwersji ma być automatyczna; do uruchomienia programu mają być potrzebne tylko niewielkie ręcznie wprowadzone zmiany, a do osiągnięcia optymalnej wydajności – szczegółowa analiza i optymalizacja przeprowadzona ręcznie.

Na przekór Nvidii, ale czy w zgodzie z resztą?

oneAPI, Level Zero i Data Parallel C++ przypominają kilka istniejących lub porzuconych inicjatyw:

• OpenCL – wysokopoziomowe API do obliczeń równoległych, ograniczone do nielicznych typów urządzeń, dalszy rozwój nie jest pewny.
• C++ AMP – próba przestosowania C++ do łatwego i wydajnego wykonywania obliczeń równoległych, rozwijana przez Microsoft, obecnie porzucona.
• SPIR oraz SPIR-V (Standard Portable Intermediate Representation) – postać kodu wymagająca kompilacji JIT, pozwalająca wykonywać obliczenia równoległe na sprzecie zgodnym z OpenCL i Vulkan. Opracowana przez konsorcjum Khronos i wspierana m. in. przez Intela i firmy należące do fundacji HSA.
• HIP (Heterogeneous-compute Interface for Portability) – standard umożliwiający programowanie GPU różnych producentów w C++. Rozwijany przez AMD, obsługuje GPU AMD i Nvidii.

Intel zamierza otwarcie udostępnić interfejs oneAPI oraz Level Zero – każdy dostawca oprogramowania i producent sprzętu będzie mógł go wykorzystać. Bez wątpienia to szczytny zamiar i warunek konieczny, żeby oneAPI miało szanse się rozpowszechnić (być może był to również warunek otrzymania lukratywnych kontraktów superkomputerowych od organizacji rządowych USA). Jednak pozostałe wymienione inicjatywy też są w głównej mierze otwartoźródłowe i dostępne dla każdego, a mimo to nie wyłonił się spośród nich jeden powszechny standard.

oneAPI warto porównać do standardu CUDA oraz zestawu oprogramowania ROCm. Ten pierwszy jest przywiązany do GPU Nvidii, i ma również przywiązywać dostawców oprogramowania do sprzętu Nvidii. CUDA jest przytłaczającym – dla niektórych zapewne jedynym – argumentem przekonującym do wybrania sprzętu Nvidii. CUDA nie jest tak ambitnym przedsięwzięciem, jak oneAPI, bo jest ograniczone do procesorów graficznych; Nvidia nie ma zamiaru produkować innego rodzaju maszyn obliczeniowych. Z tego samego powodu zapewne nie będzie w najmniejszym stopniu zainteresowana przyjęciem żadnego uniwersalnego, otwartego standardu, który mógłby zastąpić CUDA.

ROCm – zestaw technik i oprogramowania opracowywany przez AMD – jest jeszcze mniej dojrzały od CUDA i podobnie jest ograniczony do procesorów graficznych. AMD prezentuje jednak zupełnie odwrotną politykę niż Nvidia: tworzy i promuje otwarte standardy. Nie wiadomo, czy zechce porzucić kontrolowane przez konsorcja (Khronos, HSA), ale wolniej rozwijające się i ciągnione jednocześnie w wielu kierunkach rozwiązania na rzecz omijającego te standardy, ale również otwartego rozwiązania, któremu kierunek przynajmniej początkowo będzie wyznaczał Intel. Co ciekawe, jedna z pierwszych części oneAPI Intela jest coś, co AMD oferuje od dawna: półautomatyczny konwerter kodu z CUDA na przenośny C++ (hipify).

Wydaje się, że do osiągnięcia jakiegoś konsensusu w dziedzinie technik programowania wielkich obliczeń jest bardzo daleko, ale oneAPI spełnia wiele warunków koniecznych, żeby zająć taką pozycję. Wiele może zależeć od tego, jaką dojrzałość osiągną narzędzia programistyczne AMD i Intela, kiedy już zostaną udoskonalone na potrzeby nadchodzących superkomputerów w USA. Poza Aurorą o mocy 1 eksaflops w budowie są również Frontier (procesory i GPU AMD, moc ponad 1,5 eksaflops) oraz El Capitan (nieznany dostawca mocy obliczeniowej). Z kolei budowniczowie superkomputerów poza USA będą z pewnością zainteresowani wyłącznie otwartymi standardami (o ile nie wykorzystają własnych technik, jak np. programiści chińskich superkomputerów).

Superkomputer Aurora ma być gotowy do użytku w 2021 roku. Ponieważ poprzednie inwestycje superkomputerowe w USA bywały często opóźnione, a Intel ciągle jeszcze pracuje nad litografią klasy 7 nm, sądzimy, że opóźnienie liczone w miesiącach nie jest wykluczone.