Czy AMD rzeczywiście wykastrowało GCN 1.0 z Async Compute? Weryfikujemy doniesienia

Pamiętacie wczorajszy donos z forum reddit o możliwości programowego usunięcia wsparcia dla obliczeń asynchronicznych z kart graficznych AMD w architekturze Graphics Core Next 1. generacji? Jako, iż materiał ten wywołał spore poruszenie na facebookowym profilu, wspólnie zdecydowaliśmy się na zbadanie całej sprawy. Przypadkiem pojawiła się też świetna okazja do ponownego przeanalizowania poszczególnych iteracji GCN i różnic między nimi, co jest notabene niezbędne do wskazania potencjalnych przyczyn blokady. Zakładając oczywiście faktyczne wystąpienie takowej, ale już teraz mogę zdradzić, że spostrzeżenia z reddita się potwierdzają. Główne pytanie brzmi zatem: po co kasować działającą funkcję? I to taką, która zapewnia handicap względem konkurencji?

Zacznijmy od tego, czym właściwie jest Async Compute. W najprostszych słowach: technika ta pozwala akceleratorowi na równoległe i płynne wykonywanie kolejnych poleceń, tak, by zadania nie musiały oczekiwać w kolejce. Teoretycznie gwarantuje to optymalne wykorzystanie dostępnych zasobów obliczeniowych, bowiem żadna z ich części nie leży odłogiem. Operacje asynchroniczne prym wiodą zwłaszcza na współczesnych konsolach, PS4 i Xbox One, gdzie osiągnięcie dobrego efektu wymaga wyciśnięcia ostatnich soków z relatywnie słabych komponentów. Jeśli chodzi o komputery osobiste - Async pojawił się dopiero wraz z bibliotekami DX 12, skądinąd przy ogromnym wsparciu AMD, które znalazło dla niego miejsce także w autorskim API Vulkan. Konkurencyjna Nvidia tradycyjnie usadowiła się po drugiej stronie barykady bagatelizując temat. Ten wrócił na wokandę dopiero przy okazji Pascala, wciąż w zdecydowanie bardziej prymitywnym stopniu niż u Czerwonych - ale o tym za moment. Skupmy się najpierw na AMDowskiej implementacji, bo to ona jest kluczowa z uwagi na wiodący temat niniejszej publikacji.

Wszystkie akceleratory zrealizowane w architekturze GCN posiadają wyspecjalizowane Asynchronous Compute Engine (ACE), sparowane z procesorem rozkazów poprzez kontrolery Direct Memory Access (DMA). Silniki ACE oraz procesor rozkazów rozdzielają zadania pomiędzy dostępne zasoby, odpowiednio obliczeniowe oraz graficzne. Z kolei DMA czuwają nad wymianą danych (kopiowaniem). W przeciwieństwie do funkcjonującego globalnie procesora rozkazów, ACE mają dostęp tylko do bloków CU - ale dzięki compute shader i tak wspierają generowanie grafiki na potrzeby gier. Sama zasada działania asynchronizmu jest więc niezależna od wersji GCN... drastyczne różnice dotyczą za to liczby i efektywności poszczególnych elementów układanki. Najstarsze konstrukcje, takie jak HD 7970 czy stworzony później drogą rebrandu R9 280X, posiadają zaledwie po dwa ACE, podczas gdy dla GCN 1.1 oraz 1.2 wartość ta jest czterokrotnie większa. Co jednak ciekawsze, najnowszy GCN 1.3 aka Polaris oferuje tylko cztery ACE, jednak wsparte parą dyspozytorów, które buforują zadania i określają priorytet - zwalniając tym samym procesor centralny komputera i sterownik.

Wracając do Nvidii, Zieloni w ogóle nie stosują sprzętowych ACE, tylko niesprecyzowaną technikę programową. Stąd też często raptem marginalne przyrosty w DX 12 - albo nawet spadki w tytułach napisanych typowo pod asynchronizm, np. Deus Ex: Rozłam Ludzkości.