artykuły

AMD Radeon RX Vega 64 – test wydajności

Powrót króla?

350
14 sierpnia 2017, 15:00 Piotr Gołąb
Po długim oczekiwaniu w końcu są: nowe karty graficzne AMD. Czy warto było na nie czekać? Oto test modelu AMD RX Vega 64.

Spis treści

AMD Radeon RX Vega 64 jest najbardziej wyczekiwaną kartą graficzną od prawie 2 lat. Oczekiwania były bardzo duże. Spekulowano, czy nowość będzie wydajniejsza od GeForce'a GTX-a 1080. Wówczas Nvidia wyciągnęła z szuflady kartę, której nikt się nie spodziewał, model GeForce GTX 1080 Ti. Spekulacje na temat wydajności Vegi rozpoczęły się zatem na nowo: czy Vega będzie szybsza od najszybszego GTX-a, czy może zadowoli się tylko pokonaniem podstawowej tysiącosiemdziesiątki.

 GTX 1080 TiGTX 1080Vega 10Fury X
Architektura Pascal Pascal Vega 10 GCN
Jednostki cieniujące 3584 2560 4096 4096
ROP

88

64 64 64
Jednostki teksturujące 224 160 256 256
Taktowanie rdzenia

1481 MHz

1746 MHz (Boost)

1607 MHz

1733 MHz (Boost)

1274 MHz

1546 MHz (Boost)

1050 MHz

Szybkość wypełniania teksturami ~331,5 Gt/s ~269,6 Gt/s ~395,8 Gt/s ~281,9 Gt/s
Zegar pamięci 1376 MHz 1250 MHz 945 MHz 500 MHz
Szyna pamięci 352 b 256 b 2048 b 4096 b
Rodzaj pamięci 11 264 MB GDDR5X 8192 MB GDDR5X 8192 MB HBM2 4096 MB HBM
Przepustowość pamięci 484,0 GB/s 320,0 GB/s 483,8 GB/s 512,0 GB/s
Obsługiwane API DirectX 12 DirectX 12 DirectX 12 DirectX 12
Złącze graficzne PCI-E 3.0 PCI-E 3.0 PCI-E 3.0 PCI-E 3.0

 

W modelu AMD Radeon RX Vega 64 użyto pierwszego procesora graficznego zbudowanego w architekturze Vega, o nazwie Vega 10. To stosunkowo duży układ scalony, przeznaczony do wielu zadań. Będzie wykorzystywany w różnych produktach AMD, nie tylko w kartach graficznych dla domowych użytkowników, ale również w kartach do zaawansowanych obliczeń czy nauki sztucznej inteligencji.

Radeon RX Vega 64

Vega 10 jest wytwarzany w procesie produkcyjnym klasy 14 nm LPP FinFET. Układ składa się z 12,5 mld tranzystorów, które upakowano na płytce krzemowej o wielkości 486 mm2. Został zoptymalizowany pod kątem lepszego wykorzystania tranzystorów FinFET, które mają większą sprawność energetyczną, a więc mogą pracować przy większej częstotliwości taktowania układu graficznego niż starsze Radeony. Procesor Vega 64 może więc być taktowany z częstotliwością aż 1670 MHz. Porównanie z układem AMD Fury X, który był produkowany w procesie klasy 28 nm i taktowany z częstotliwością 1 GHz, doskonale pokazuje postęp w tej dziedzinie.

Radeon RX Vega 64

Rdzeń Vega 10 składa się z 64 bloków next-generation compute units (NCUs), co daje w sumie 4096 jednostek cieniujących. Moc obliczeniowa to 12,7 teraflopa w obliczeniach pojedynczej precyzji i 25,3 teraflopa w obliczeniach połowicznej precyzji. Reszta parametrów jest nie mniej spektakularna: 256 jednostek teksturujących umie przetwarzać tekstury z prędkością do 395 gigatekseli na sekundę, 64 jednostki ROP wypełniają zaś scenę pikselami z prędkością niemal 99 gigapikseli na sekundę.

Radeon RX Vega 64

Opracowany przez AMD podsystem pamięci HBCC (High-Bandwitch Cache Controller) jest rozwiązaniem całkowicie unikatowym. W jego skład wchodzą: pamięć podręczna pierwszego poziomu, L1, drugiego poziomu, L2 (4 MB), i 8 GB pamięci HBM2, która tutaj została nazwana HBC, od High Bandwidth Cache. W dużym skrócie: w sterownikach można włączyć funkcję HBCC, która przypisze część pamięci operacyjnej zainstalowanej w komputerze do podsystemu pamięci karty graficznej. To, ile tej pamięci zostanie przypisane, można regulować za pomocą suwaka. Kontroler może zaadresować do 512 TB. W takiej pamięci będą przechowywane duże tekstury oraz inne dane, do których nie będzie wymagany najszybszy dostęp. Często wykorzystywane dane będą dostępne w pamięci HBC. Pamięć HBM2 komunikuje się z rdzeniem graficznym poprzez magistralę Infinity Fabric o szerokości 2048 b, osiągającą przepustowość na poziomie 483 GB/s.

Infinity Fabric jest również wykorzystywane do komunikowania się rdzenia z poszczególnymi blokami logicznymi, takimi jak: kontroler PCI Express, kontroler wyświetlania obrazu (display engine), kontroler sprzętowej akceleracji wideo (video acceleration blocks).

 

Przygotowywane aktualizacje

W najbliższych dniach opublikujemy bardzo dokładną analizę architektury Vega 10 oraz testy w narzędziach profesjonalnych, z obliczeniami fraktali i renderowaniem obrazu w programie 3Ds Max 2017 przy użyciu silnika renderującego V-RAY RT. Niestety, na razie nie udało się nam się zmusić karty do prawidłowej współpracy z tym programem. Próba renderowania zawieszała całą platformę.

Strona:
matekmzZobacz profil
Poziom ostrzeżenia: 0%
matekmz2017.09.05, 17:36
lolotron @ 2017.08.29 05:00  Post: 1091449
Wiadomo coś o testach Vegi 56 kiedy będą ?

Jeszcze nie mogę przekazać bardzo dokładnych informacji, ale pojawią się jeszcze we wrześniu.
lolotronZobacz profil
Poziom ostrzeżenia: 0%
lolotron2017.08.29, 05:00
Wiadomo coś o testach Vegi 56 kiedy będą ?
*Konto usunięte*2017.08.24, 20:10
No i ?
Przecież wzrosła niewspólmiernie do przyrostu ALU... gdzie NV daje podobny wzrost ALU/fillrate....
AssassinZobacz profil
Poziom ostrzeżenia: 0%
Assassin2017.08.23, 20:32
To jakby dwie osobne kwestie. Faktycznie AMD od GCN 3.0 wzwyż daje dziwnie mało jednostek ROP w stosunku do TPU i SPU. Jednak w przypadku Vegi teoretyczna wydajność względem Polarisa wzrosła zarówno w zakresie mocy obliczeniowej ALU, jak i pixel fillrate oraz texel fillrate.Gdyby np. Polaris miał wąskie gardło fillrate to podwojenie tej wartości w Vedze tym bardziej powinno zapewnić dobre skalowanie, dążące do 100%. Jest inaczej.
*Konto usunięte*2017.08.23, 13:36
@up
U NV większość rzeczy ulega zdublowaniu więc i moc jest 2x większa.
AMD zwiększa ALU. Więc jakim cudem miałoby wzrosnąć skalowanie tak jak u NV. AMD postawiło na inny bilans, który od wielu lat się nie sprawdza.
AssassinZobacz profil
Poziom ostrzeżenia: 0%
Assassin2017.08.22, 12:40
Ułomność Vegi najlepiej pokazuje ta tabelka:

Przy czym chodzi mi bardziej o relacje między RX580 a Vegą i GTX1060 a 1080. W obu przypadkach wyższy model ma 2x wyższą moc obliczeniową i prawie 2x wyższą przepustowość pamięci. Skalowanie na Nvidii jest jednak o ok. 25% lepsze, choć układy dzielą dokładnie tę samą architekturę. Vega jest usprawnionym Polarisem, a jej efektywność jest w zasadzie gorsza. Obecnie można jedynie czekać(tm) na poprawione sterowniki i wykorzystanie 'ficzerów' DX12 w grach. Wg wiedzy na dziś wykorzystanie architektury VEGA do budowy energooszczędnych układów mobilnych i IGP wydaje się błędne.
cjb2017.08.20, 23:03
vibovit @ 2017.08.18 22:55  Post: 1089384

Primitive Shaders czy HBCC wyłączone? czyli nie wiesz co to jest tak naprawdę, żeby skorzystać z obu rozwiązań, soft musi być pod to specjalnie pisany, dlatego obecnie nic to nie daje, bo nic tego nie wykorzystuje, nic tu się nie da włączyć/wyłączyć.


Otóż nie. Zarówno Primitive Shaders i HBCC działają tylko w oparciu o sterownik.
HBCC jest domyślnie wyłączony, bo jak pisze ComputerBase, wyniki są 'niekonsekwetne' - czyli w 1 grze min fps idzie w górę, a w innej w dół.
Przeczytasz o tym wszystkim już na 1. stronie ich testu:
https://www.computerbase.de/2017-08/radeon...ega-64-56-test/
Pentium DZobacz profil
Poziom ostrzeżenia: 0%
Pentium D2017.08.20, 00:30
Gamers Nexus wykrył jakiegoś buga z raportowaniem taktu rdzenia

https://www.youtube.com/watch?v=SBx73n-fgdE
*Konto usunięte*2017.08.19, 12:46
Pytałeś się kto mnie okłamał. Grzecznie odpowiedziałem. Więc jak wspomniałem oklamał mnie nie wymienione przez ciebie github, octane. Więcej po prostu miejsc gdzie mnie okłamano nie pamiętam.

Minusem to może być brak wsparcia danej aplikacji dla OpenCL,

Może ale nie musi.

który jest standardem przemysłowym ze znacznie, znacznie szerszą liczbą obsługiwanych platform niż CUDA.

Oczywiście. Jest szerzej obsługiwany.

Podwójna precyzja (czyli typ double) jest dosyć standardowo wykorzystywanym typem w C++ zatem wszelakie sztuczne ograniczenia skutkują dla mnie jednym prostym wnioskiem - karty dla graczy nie są do obliczeń. Dlatego w serwerach HPC się stosuje Tesle, a nie GeForce (nie do przecenienia są dodatkowe technologie jak ECC). A jeśli chodzi o renderfarmy na GF to jakby nie patrzeć, nawet jeśli są składane przez profesjonalistów i firmy z wyrobioną renomą na tym rynku to i tak jest to zwykła proteza. Karty dla graczy zostawmy graczom, w renderfarmach nie potrzebne jest w ogóle wyjście cyfrowe, nie jest potrzebny dekoder wideo, jakieś dsp true audio, nie są potrzebne ROPy i TMU. Potrzebne są SP, cache i pamięć. I od ilu lat CUDA w tych blenderach itp. występuje od tyle oprócz Tesli (która jest dobra, ale droga) nic dedykowanego mniej profesjonalnym obliczeniom się nie pojawiło.
Co do Freesync - czemu wada? NV nie musi wspierać standardu konkurencji, który raz, że jest sam w sobie dla jej interesów zły, a dwa - wcale nie zdobył dużego uznania, jest słabo widoczny na rynku i nie jest czymś za czym dużo ludzi się rozgląda podczas zakupu grafiki. Innymi słowy o ile nie stanie się naprawdę szeroko stosowanym standardem przemysłowym nie ma co minusować nvidii za brak wsparcia.

Mam nadzieję, że osób w NV/AMD myślących jak ty będzie jak najdłużej. Dzięki temu np. przemysł graficzny czy wolni strzelcy będą zadowoleni.

Co do freesync. Widać dośc wybitnie wybiórczo go przeczytałeś, polecam popatrzeć na temat planów HDMI.
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842017.08.18, 23:24
Okłamał mnie github, octane, nvidia, skoti też kłamał.

http://www.anandtech.com/show/5238/nvidia-...-source-kind-of
Ostatni akapit. Nic od tamtego czasu się nie zmieniło. Zupełnie nic. To nie jest 'otwarty' standard. I skoti też to doskonale wie zatem nie rozumiem po co go w to chcesz wciągać.
Ja nie proponuję żeby wspierali... ja proponuję by uznać brak wsparcia, słabe wsparcie za wadę, minus

Ale dlaczego miałby to być minus? Minusem to może być brak wsparcia danej aplikacji dla OpenCL, który jest standardem przemysłowym ze znacznie, znacznie szerszą liczbą obsługiwanych platform niż CUDA. Tak, bo OpenCL masz na SoC z PowerVR, masz na FPGA altery (intel) i xilinx, masz na IGP Intela, masz na GPU AMD i NV, masz na CPU AMD, Intela, IGP PowerVR, procesorach ARM, procesorach IBM POWER. A CUDA masz dla NV, z niczym innym nie działa lepiej niż OpenCL.

Oboje wspierają w podobnym stopniu FP64.

Podwójna precyzja (czyli typ double) jest dosyć standardowo wykorzystywanym typem w C++ zatem wszelakie sztuczne ograniczenia skutkują dla mnie jednym prostym wnioskiem - karty dla graczy nie są do obliczeń. Dlatego w serwerach HPC się stosuje Tesle, a nie GeForce (nie do przecenienia są dodatkowe technologie jak ECC). A jeśli chodzi o renderfarmy na GF to jakby nie patrzeć, nawet jeśli są składane przez profesjonalistów i firmy z wyrobioną renomą na tym rynku to i tak jest to zwykła proteza. Karty dla graczy zostawmy graczom, w renderfarmach nie potrzebne jest w ogóle wyjście cyfrowe, nie jest potrzebny dekoder wideo, jakieś dsp true audio, nie są potrzebne ROPy i TMU. Potrzebne są SP, cache i pamięć. I od ilu lat CUDA w tych blenderach itp. występuje od tyle oprócz Tesli (która jest dobra, ale droga) nic dedykowanego mniej profesjonalnym obliczeniom się nie pojawiło.
Co do Freesync - czemu wada? NV nie musi wspierać standardu konkurencji, który raz, że jest sam w sobie dla jej interesów zły, a dwa - wcale nie zdobył dużego uznania, jest słabo widoczny na rynku i nie jest czymś za czym dużo ludzi się rozgląda podczas zakupu grafiki. Innymi słowy o ile nie stanie się naprawdę szeroko stosowanym standardem przemysłowym nie ma co minusować nvidii za brak wsparcia.
Funkcja komentowania została wyłączona. Do dyskusji zapraszamy na forum.
1