GTX 1080 SLI - Testy wydajności najpotężniejszej konfiguracji dwukartowej

Listując zalety DirectX 12, Microsoft obiecywał wyeliminowanie wszystkich wcześniejszych bolączek Multi-GPU, co miało zostać osiągnięte poprzez migrację z modelu AFR na SFR. Twórcy Windowsa nie wspomnieli jednak, że afiszowany dookoła SFR nie jest żadną technologiczną nowinką, ale rozwiązaniem znanym od dawna, nieużywanym przez wzgląd na problemy natury implementacyjnej, których źródło leży u podstaw zasady działania tego algorytmu. Właśnie dlatego przez całe lata programiści tkwili (i tkwią) przy AFR, a tylko sporadycznie wskazać możemy jakieś wyjątki od tej reguły, np. Civilization: Beyond Earth w środowisku Mantle.

AFR kontra SFR - slajd autorstwa AMD (kliknij, aby powiększyć)

Pierwszą i nadrzędną zaletą AFR jest, jak zdążyłem zasugerować, prostota implementacji. Niestety ceną bezproblemowości na etapie deweloperskim jest szereg problemów użytkowych. Kiedy GPU współpracują poprzez technikę AFR, jednostki wchodzące w skład baterii muszą otrzymać od procesora te same dane binarne, co przekłada się na powielenie informacji zapisanych w komórkach ich pamięci, a tym samym ograniczenie VRAM-u do poziomu pojedynczego akceleratora. Idąc dalej, AFR często bywa sprawcą mikro przycięć, bo wygenerowane sceny muszą oczekiwać na wyświetlenie w kolejce, by zachować sztywny podział na klatki parzyste i nieparzyste, leżący u podstaw tej techniki. Wreszcie problemem okazuje się także samo wyświetlenie gotowego obrazu, a precyzując – przesłanie zawartości bufora ramki karty podrzędnej do karty głównej, która bezpośrednio odpowiada za przekazanie sygnału do monitora.

Technika SFR pozwala ukniknąć mikro przycięć, ale z uwagi na trudności przy implementacji, jest niechętnie stosowana przez developerów.

SFR teoretycznie wypada lepiej, bo spięte GPU pracują wspólnie nad każdą kolejną klatką, dzieląc się zadaniami. Efektem tego jest pełne wykorzystanie pamięci VRAM. Tutaj pojawia się jednak problem programistyczny: Jak podzielić obraz, aby obydwa procesory graficzne zostały w pełni wykorzystane? Symetryczne przecięcie sceny na pół nie jest rozwiązaniem. Aby się o tym przekonać, wystarczy zobrazować sytuację, w której jedna karta musi liczyć zaawansowane efekty przezroczystości na szybach budynków, a praca drugiej ogranicza się do wypełnienia teksturami podłoża. Właśnie dlatego zastosowanie algorytmu SFR wymaga wytężonej pracy developera, a przy tym nie gwarantuje tak wysokiego skalowania jak prostszy konkurent. Doskonałym przykładem jest gra Civilization: Beyond Earth, która w środowisku DirectX używa AFR, a w Mantle – SFR. Skalowanie w tym drugim przypadku jest do kilku procent słabsze, ale dzięki niższemu frametime’owi rozgrywka okazuje się płynniejsza.

Konkluzja jest oczywista: SFR zapewnia lepsze efekty, ale rzadko kiedy możemy zobaczyć go w akcji. Nawet pomimo obietnic Microsoftu, dotyczących ograniczenia Multi-GPU w środowisku DirectX 12 do tego rozwiązania. A jak to wszystko przekłada się na sytuację Pascala? Nijak, bo programiści nadal forsują prostszy z ich punktu widzenia AFR. W rezultacie SLI dalej może nie działać jak należy, powodując niepożądane zjawiska typu stuttering, które pomimo ogromnej liczby generowanych klatek, skutecznie uprzykrzają zabawę.