XFX Radeon RX 5700 XT THICC II Ultra - Test karty graficznej

Radeon NAVI - Charakterystyka architektury RDNA

Architekturę RDNA niektórzy ochrzcili zawczasu jako zupełnie nowe rozdanie, aczkolwiek bezpieczniej będzie ją nazywać pochodną Graphics Core Next, bowiem wykorzystuje określony zestaw instrukcji spełniających założenia GCN, czyniąc to jednak w odmienny sposób. Skutkiem tego zachowuje kompatybilność z poprzednikami oraz gotowymi kompilatorami, devkitami czy wszelkimi optymalizacjami, jakie latami dokonywało AMD. Wprowadza też zupełnie nowe techniki. Mówimy zatem o solidnej ewolucji GCN 5.0 będącego podstawą Radeona Vega i Radeona VII. Kolejne usprawnienia w sterownikach powinny przynosić korzyści również wcześniejszym architekturom, więc przynajmniej czysto teoretycznie, taka decyzja była najbardziej opłacalna dla użytkowników Radeonów. RDNA to natomiast nowa architektura w takim sensie, że inaczej (efektywniej) przeprowadza obliczenia, potrafiąc korzystać z nowszych rozwiązań, niedostępnych w starszych generacjach. Upraszczając rzeczy jeszcze bardziej - RDNA wygląda na optymalizowaną pod granie, odchodząc od uniwersalności architektury GCN.

RDNA będzie elastyczną architekturą tzn. zagości zarówno w desktopowych kartach graficznych, układach montowanych w procesorach oraz urządzeniach mobilnych, docelowo pokrywając całą przestrzeń rynkową. Popularyzacji tego rozwiązania powinna pomóc współpraca z Samsungiem, który zamierza licencjonować technologię AMD, umieszczając GPU bazujące na RDNA w swoich jednostkach obliczeniowych. Nowe konsole SONY i Microsoftu również otrzymają układy graficzne będące zmodyfikowaną wersją Navi. Warto zatem przyjrzeć się fizycznym zmianom poczynionym w strukturze krzemowego jądra, ponieważ sporo poprawiono względem niedawno pokazanego Radeona VII, dokonując szeregu męskich decyzji. Przede wszystkim, AMD zmieniło w architekturze RDNA strukturę jednostek wykonawczych. Bloki obliczeniowe zestawiono w parach (Dual Compute Unit), zawierających dwa zamiast czterech klastrów SIMD. Każdy otrzymał 32 procesory strumieniowe, własny scheduler, jednostkę skalarną oraz rejestr wektorowy.

16 bloków RB oznacza 64 jednostki rasteryzujące, będąc rozwiązaniem zapożyczonym z poprzednich architektur. Względem GCN wymiana danych między CU uległa jednak przyspieszeniu, jednostek skalarnych jest dwukrotnie więcej, natomiast TMU otrzymały 64-bitowe rejestry zapewniające szybsze wypełnianie pikselami. Szerokość tzw. wavefrontu ograniczono do wartości odpowiadającej ilości procesów strumieniowych w pojedynczym SIMD (32). Zatem pomimo iż jednostka CU nadal zawiera 64 procesory strumieniowe, wyniki są otrzymywane po jednym cyklu zegara zamiast po czterech, co znacznie skraca czas wykonywania wszelkiej maści instrukcji. Szybsze jest również przechodzenie do kolejnych etapów potoku obliczeniowego oraz zapełnianie bloków SIMD odpowiednimi danymi.

Wszystkie procesory strumieniowe w obrębie jednego Compute Unit współdzielą teraz pamięć podobną w założeniach do podręcznej. LDS (Local Data Storage) wyodrębniono poza CU żeby przechowywała ulotne dane, których późniejsze wykorzystanie możliwe jest dopiero po zapisaniu przez jednostkę obliczeń skalarnych albo procesor strumieniowy w pamięci podręcznej. Obok LDS znajdują się jeszcze pamięć podręczna dla instrukcji oraz jednostek skalarnych. Pamięć podręczna L0 odpowiada L1 w architekturze GCN, współdzielona jest pomiędzy dwa CU w ramach jednego WGP, a dane do rejestrów migrują z dwukrotnie większą przepustowością. Każdy CU dysponuje 16 KB SRAM, podczas gdy zestaw pięciu DCU otrzymał 128 KB L1 zdolnej wykonać 16 operacji w cyklu zegara. Pamięci Cache L2 jest sumarycznie 4 MB (256 x 16 na kanał). Jak widać na diagramie - całość tworzy dwa Shader Engine, pomiędzy którymi umieszczono m.in. cztery jednostki ACE, procesor geometryczny oraz rozdzielacz komend, spojone magistralą Infinity Fabric. Ciekawostką jest również nowa metoda przeplatania obliczeń - Priority Tunneling - skupiona na realizacji przez CU rozkazów o najwyższym priorytecie, aby uniknąć zapychania schedulera.

Zamiast pamięci HBM / HBM2 stosowanej w Radeon Fury / Vega / VII, producent wykonał zwrot w kierunku GDDR6, przy okazji usprawniając mechanizm bezstratnej kompresji tekstur. Zachodzi tutaj również bezpośrednie podobieństwo do architektury Vega, ponieważ GPU łącznie z rasteryzatorem może korzystać z całości dostępnej pamięci podręcznej. Nowa architektura potrafi też sprzętowo dekodować wideo w formacie VP9, natomiast przepustowość kodera wzrosła o około 40%. Kwestia obsługi PlayReady 3.0 pozwalającej odtwarzać materiały 4K HDR od Netflixa albo Blu-Ray pozostaje otwarta - udostępniona mediom prezentacja nie zawierała konkretnych danych. Wprowadzono także natomiast trzy kompresory DSC połączone z trzema DisplayPort 1.4. Warto jeszcze wspomnieć, że Radeony NAVI wykorzystują PCI-Express 4.0, chociaż przepustowość jaką zapewnia ten interfejs nie będzie im raczej potrzebna.

• « pierwsza
• ‹ poprzednia
• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• …
• następna ›
• ostatnia »