SLI, inaczej Scalable Link Interface to technologia firmy nVidia, która pozwala łączyć dwie lub więcej kart graficznych, w celu szybszego renderowania obrazu. Technologia została zaprezentowana w 2004 roku, jednakże pierwszy raz zastosowana została przez nieistniejącą już firmę 3dfx w 1998 roku. Połączono ze sobą dwie karty Voodoo 2, które pracowały w trybie przeplatania linii obrazu. Pierwsza karta generowała obraz składający się tylko z linii nieparzystych, druga zaś – z linii parzystych. Wygenerowane pół-obrazy łączone były w jedną klatkę.
Sposób działania
Dwie karty graficzne GeForce wspólnie generują obraz, który jest dzielony na dwie części – górną i dolną. Za rendering górnej połowy odpowiada pierwsza karta, dolnej – karta druga. Obie części obrazu nie są jednak sobie równe, przez co robiona jest analiza, aby stwierdzić która wymaga mniej, a która więcej obliczeń. Potem ustawiana jest linia podziału i obraz jest wysyłany do procesorów graficznych.
SLI, czy Multi-GPU
Technologia SLI kojarzona jest także z Multi-GPU, które działa na podobnej zasadzie. SLI jest używane głównie do rozłożenia mocy obliczeniowej, pomiędzy dwiema (lub więcej) kartami graficznymi z jednym rdzeniem. Multi-GPU natomiast rozdziela obliczenia pomiędzy dwa rdzenie, umieszczone na jednej płytce PCB.
Zatem, jeżeli mamy dwie karty graficzne, to używamy SLI, jeżeli mamy dwuprocesorową kartę graficzną włączamy Multi-GPU.
Tryby renderowania
SLI posiada kilka trybów pracy:
- Auto: wybiera automatycznie poniższe tryby
- AFR – Alternate Frame Rendering: każda z kart renderuje osobną ramkę
- SFR – Split Frame Rendering: każda z kart renderuje pewną część ekranu
- AA – Antialiasing: jedna z kart zajmuje się antyaliasingiem, a druga generuje ramki
- AFRofAA – Alternate Frame Rendering of Anti Aliasing: moc obliczeniowa jest dzielona na obie karty graficzne
- Mosaic: extend a single X screen transparently across all of the available display outputs on the Quadro Plex VCS
Uruchamianie odpowiedniego trybu
Jeżeli wiemy już, jakiego typu będziemy mieli połączenie, czas je uruchomić. Warto przy tym zapoznać się z dostępnymi opcjami wykonując polecenie:
[bash]nvidia-xconfig –advanced-help[/bash]
SLI
Tryb SLI uruchamiamy wydając polecenie:
[bash]nvidia-xconfig –sli=SLI[/bash]
gdzie pod SLI wstawiamy opcję: Auto, On, Off, AFR, SFR, AA, AFRofAA, Mosaic. Domyślnie SLI działa w trybie Auto, ale podczas testowania można zauważyć migotanie ekranu, zatem należy użyć konkretnego trybu.
Multi-GPU
Tryb Multi-GPU uruchamiamy wydając polecenie:
[bash]nvidia-xconfig –multigpu=MULTIGPU[/bash]
gdzie pod MULTIGPU wstawiamy opcję: Auto, On, AFR, SFR, AA. Domyślnie Multi-GPU działa w trybie Auto, ale podczas testowania można zauważyć migotanie ekranu, zatem należy użyć konkretnego trybu.
Sprzęt
Serdecznie dziękujemy tutaj firmom Gigabyte i Zalman za wypożyczenie potrzebnego na testy sprzętu. Nasze badania oparliśmy o systemy: Xubuntu 12.10 i Windows 8, z wykorzystaniem benchmarków: Unigine Heaven 3.0, GpuTest 0.2.0 i Luxmark 2.0.
Unigine Heaven 3.0 ustawiliśmy:
- API: OpenGL
- Tesselation: Extreme
- Shaders: High
- Anisotropy: x16
- Antyaliasing: wyłączony
- Resolution: 1280 x 1024
Sterowniki graficzne:
- Linux: nVidia Linux Display Driver 313.18
- Windows: nVidia ForceWare 306.97
Płyta główna
Abyśmy mogli w ogóle posiadać tryb SLI potrzebujemy do tego odpowiedniej płyty głównej. Aktualnie tryby SLI wspierają starsze modele z chipsetami nForce oraz niektóre chipsety Intela. Warto przed zakupem dokładnie zapoznać się ze specyfikacją danego modelu producenta. Dodatkowo potrzebna nam będą specjalne mostki, w zależności od ilości zamontowanych GPU.
Do naszych potrzeb wybraliśmy model Gigabyte GA-Z77X-UP5 TH, który pozwala na podłączenie do trzech kart graficznych. Mamy na niej dostępne 3 sloty PCI Express Gen.3, ale dodana złączka pozwala nam na połączenie jedynie dwóch grafik.
Warto tutaj wspomnieć o dodatkowej bezprzewodowej karcie sieciowej Atheros Communications Inc. AR9462, która działa bezproblemowo. Próbowaliśmy uruchomić adapter Bluetooth, ale nie zadziałał.
Procesor
Wybraliśmy model Intel Core i5-2400 z taktowaniem 3 GHz, który posiada tryb Turbo Boost. Wyłączyliśmy obniżanie taktowania, natomiast zostawiliśmy zwiększanie szybkości.
Karty graficzne
Aby zadziałało SLI, potrzebne są dwa identyczne chipsety graficzne. Nie jest wymagane, ale zaleca się posiadanie kart graficznych o podobnych parametrach i producentach. W naszym teście wykorzystaliśmy modele taktowane pod 750 MHz na każdy rdzeń:
Zasilacz
Im mocniejsze karty graficzne, tym większej mocy zasilacza potrzebujemy. Do naszego testu potrzebna była moc około 1000W, jednakże nie mieliśmy takiego zasilacza pod ręką. Użyliśmy pewnego obejścia w postaci dwóch osobnych:
Corsair podłączamy do komputera, płyty głównej i karty graficznej w 1 slocie PCI-Express. Zalmana natomiast podłączamy jedynie do drugiej karty graficznej, na wyłączonym przełączniku w zasilaczu. W tym momencie musimy bardzo uważać, aby nie uszkodzić sprzętu i siebie. Bierzemy wtyczkę do gniazda płyty głównej i odszukujemy zielony kabel. Patrząc od siebie, bierzemy czarny kabel z lewej strony i oba zwieramy pinezką lub czymkolwiek innym, odpowiednio zabezpieczonym.
Włączenie całego zestawu odbywa się poprzez puszczenie prądu przez zasilacz Zalman, a następnie uruchomienie całego komputera. Po chwili powinniśmy usłyszeć standardowy dźwięk poprawnego sprawdzenia sprzętu.
Wyniki testów
Na początku wspomnieliśmy o kilku trybach, w jakich mogą pracować nasze karty graficzne. O ile pod Linuksem łatwo było wybrać, o tyle pod Windows nie było napisane bezpośrednio. Po kilku dniach prób, zdecydowaliśmy się na: SFR pod Linuksem oraz druga opcja w menu wyboru pod Windows.
Unigine Heaven
Pierwszy wykres przedstawia ogólną wydajność Xubuntu 12.10. Drugi natomiast to system Windows 8. Widzimy wyraźnie, że wyniki potrafią być diametralnie różne. Ciekawostką jest, że pod Linuksem minimalna liczba klatek w trybie SLI była 4 razy większa, aniżeli miało to miejsce pod Windowsem. Test był powtórzony kilkukrotnie i uzyskiwaliśmy te same wyniki.
GpuTest
Jest to nowość u nas, aczkolwiek postanowiliśmy go wykorzystać, ze względu na dobre zobrazowanie sytuacji. W testach FurMark oraz TessMark wygrywa za każdym razem system Windows. Jednakże widać tutaj doskonale przyrosty wydajności, jaki uzyskujemy w SLI.
Luxmark
Na koniec postanowiliśmy sprawdzić moc obliczeniową technologii OpenCL. Okazało się, że zastosowanie dwóch kart graficznych daje dwukrotny przyrost mocy obliczeniowej. Na obu systemach uzyskaliśmy praktycznie takie same wartości. Nawet zmiana trybu na AFR nie dała żadnych odchyleń.
Gry
Niestety, ale musimy tutaj zawiadomić, iż praktycznie żadna gra pod Linuksem, nie potrafiła wykorzystać mocy obliczeniowej dwóch kart graficznych. Czasami nawet zdarzało się, że wyniki były gorsze od pojedynczego trybu.
Podsumowanie
Nasze ponad 3 tygodniowe testy uznajemy za naprawdę udane. Do tej pory nie mieliśmy styczności z tą technologią pod Linuksem, co tym bardziej nas zastanawiało. Nie robiliśmy masy testów, tylko skupiliśmy się na kilku najważniejszych aspektach, aby móc przeprowadzić więcej prób.
Okazało się także, iż wyniki ogólne wydajności pod Linuksem, są dwa razy mniejsze aniżeli te pod Windows.
Wnioski nasuwają się następujące:
- Sterowniki pod Linuksa są gorszej jakości, aniżeli te pod Windows
- Uruchamianie SLI jest gorzej dopracowane, aniżeli to pod Windows, szczególnie że musimy za każdym razem restartować system operacyjny. Korzystanie z konsoli też nie każdemu musi się podobać
- Brak gier, które potrafiłyby wykorzystać moc dwóch kart graficznych. Oby w przypadku Steam się to zmieniło
- Obliczenia OpenCL są wyraźnie szybsze, ale nie lepsze, aniżeli pod Windows. Niestety, ale nie dane nam było przetestować technologii CUDA.
- Nie działa lub nie widać dokładnego taktowania kart graficznych, szczególnie tych, co posiadają technologię dynamicznego zwiększania mocy obliczeniowej. Pod Windowsem i Linuksem mieliśmy zgoła odmienne odczyty taktowania rdzeni graficznych
Artykuł planujemy jeszcze rozszerzyć, jak tylko nadarzy się kolejna okazja z kartami graficznymi, szczególnie jeżeli chodzi o dwa rdzenie na jednym PCB, czyli Multi-GPU.
Pierwsza rzecz do rozszerzenia do opis testów w Unigine. Jakie ustawienia, jakie API wybrane, jaka wersja sterowników, jakie taktowanie GPU (Unigine teraz sam podaje), czy __GL_THREADED_OPTIMIZATIONS było włączone?
Podejrzewam, że porównanie było DX11 vs OpenGL, a nie OpenGL vs OpenGL? Jeśli tak to wniosek "Sterowniki pod Linuksa są gorszej jakości, aniżeli te pod Windows" jest bezpodstawny. Problem leży podobno w kompilatorze Nvidii shaderów w GLSL, gdzie kod wynikowy jest znacznie mniej zoptymalizowany niż w przypadku D3D. No, ale też to nie tyle problem jakości sterowników co tego, że shadery w GLSL są kompilowane "on-line" i kompilator nie ma to tyle czasu co w przypadku prekompilowanych shaderów w HLSL (D3D). [Mam nadzieję, że za wiele nie namieszałem. Mam tylko wiedzę przeciętnego gracza;-]
"Nie działa lub nie widać dokładnego taktowania kart graficznych, szczególnie tych, co posiadają technologię dynamicznego zwiększania mocy obliczeniowej. Pod Windowsem i Linuksem mieliśmy zgoła odmienne odczyty taktowania rdzeni graficznych"
A może były to prawidłowe odczyty? Kepler miał (ma?) buga z taktowaniem pod Linuksem. To też może wpływać na wydajność. http://www.phoronix.com/scan.php?page=news_item&a…
No bug nie był, bo jak widzisz na załączonych zrzutach z GPU-Z pod Windows taktowanie jest dobre. Pod Linuksem pokazywało maksymalnie 750 MHz na każdy rdzeń i nie mogłem tego zmienić.
Czyli bug był, skoro pod Linuksem zostawał na 750, zamiast iść na ~1100.
Ayup, pod Windows istotnie OpenGL działa wolniej, także wyniki powinny się w miarę zrównać.
Porównanie było OpenGL na obu systemach. Nie ruszałem DX11 z wiadomych względów.
__GL_THREADED_OPTIMIZATIONS nie widziałem, aby ktoś to w ogóle ruszał w jakichkolwiek testach kart graficznych. Użyłem po prostu domyślnych ustawień i tyle. Jeżeli możesz podpowiedzieć, jak to włączyć, to z miłą chęcią postaramy się tego użyć w przyszłych testach.
LD_PRELOAD="libpthread.so.0 libGL.so.1" __GL_THREADED_OPTIMIZATIONS=1 ./heaven
Dla gier ze Steama, w parametrach startowych:
LD_PRELOAD="libpthread.so.0 libGL.so.1" __GL_THREADED_OPTIMIZATIONS=1 %command%
PROTIP: Bluetooth Atheros wymaga dostarczenia firmware ;) (just guessing)
To, co jest opisane w tym artykule, w pewnym sensie nie istnieje. Wykorzystanie takich zaawansowanych funkcyj kart NVIDII wymaga niewolnego sterownika. Jeśli spośród wszystkich programów wykosić niewolne i uznać, że z praktycznego punktu widzenia nie istnieją, a tak należy czynić, to karty NVIDII istnieją w takim stopniu, w jakim jest w stanie obsłużyć je nouveau. Jak wiadomo, nie jest on w stanie w pełni obsłużyć tego sprzętu, więc po formalnym zaprzeczeniu istnienia niewolnego oprogramowania z punktu widzenia użyteczności dla użytkownika komputera, dochodzi się do wniosku, że produkty NVIDII to buble i niedorobione niedziałające atrapy. I tak też jest w rzeczywistości. Jeśli jakiś obszar działania komputera jest zaimplementowany za pomocą niewolnego programu, to znaczy, że obszar ten jest jeszcze niezagospodarowany przez ludzkość. Tu np. niby wszystkie funkcje kart NVIDIA siedzą w niewolnym programie, więc jest tak, jakby nikt dotąd nie wymyślił, jak wykorzystać w pełni te karty i jakby tych niektórych funkcyj nie było. Równoważnie można sformułować to tak, że NVIDIA produkuje dziwaczne niedoróby. Inny przykład. Istnieje sobie program Mathematica, ale tak naprawdę go nie ma. Ludzkość wcale nie jest w dziedzinie programów CAS na etapie Mathematici, tylko na tym etapie, który reprezentuje najlepszy wolny program z tej dziedziny. Mathematica to złudzenie. NVIDIA to złudzenie.
Zaprzestań waść tych "funkcyj", boś nie Hugo Steinhaus.
A poza tym, to czyta się Ciebie trochę jak P. K. Dicka na ostrym tripie. On też kiedyś twierdził, że S. Lem to mistyfikacja :).
Ciekawe, bo z tego co ja widzę, Łukasz prezentuje konsekwentne podejście zgodne z filozofią linuksa, choć może w trochę niecodziennej formie. Ale może ja się mylę i bardziej "linuksowe" jest narzekanie, że jakieś "bloby" nie działają z każdym wydaniem np. X.org, czy kernela, albo że dystrybucji jest za dużo i gierki ze Steama mogą nie działać na każdej. Cóż, gdyby w/w wymienione były Open Source, nie byłoby takich problemów…
Trochę Ciebie rozumiem.
Stłuczmy termometry…
Twierdzenie że coś nie istnieje tylko dlatego że jest poza twoim zasięgiem to jednak trochę nadużycie twierdzenia nieistnienia, tym tokiem rozumowania to nie istnieje Australia – nie widać jej, nie stać mnie na bilet do Australii, nie znam nikogo z Australii – czyli Australia nie istnieje…
Damian Wlazeł liked this on Facebook.
Jakub Szukała liked this on Facebook.
Michał Olber liked this on Facebook.
C GB Spender liked this on Facebook.