Nadszedł dzień, długo wyczekiwanej premiery najnowszych kart od Nvidia. Czy karty te zasługują na miano rewolucji, czy jest to tylko marketingowy chwyt? Ile będą pobierać mocy i jak się sprawdzą w grach? Na te pytania dziś możemy zacząć odpowiadać.
Podczas telekonferencji w której braliśmy udział, Nvidia zaprezentowała dwie zupełnie nowe karty graficzne: GeForce GTX480 oraz jej zubożoną wersję GTX470. Są to pierwsze karty oparte o nową architekturę Fermi i otwierają nową serię kart oznaczonych jako GeForce 400. Tym samym Nvidia zaczęła wspierać Direct X 11.
Nie dość, że radeon HD5870 jest równie wydajny (jak nie wydajniejszy) to jeszcze jest tańszy. Cieniutko nVidia.
Jeszcze autor może dodać, że te karty będą też wspierać OpenGL 4.0!
Hmm znając, życie nawet jak będą słabsze od AMD to i tak stery pod Linuksa będą lepsze :).
Nie obsługuje OGL v.4.0 tylko 3.2.
Vide [ http://www.nvidia.pl/object/product_geforce_gtx_4… ]
Tak się kończą szumne zapowiedzi (czytaj brednie) nVidii i zaczyna to w czym ta Firma jest najlepsza, robienie potencjalnych klientów w balona.
Akurat z tym OpenGL-em, to wynika to raczej z tego, że 4.0 maja jeszcze niegotowe. Nie wierzę, że karta, która obsługuje DX11 miała by problem z OpenGL 4.0, które w zasadzie jest tożsame jeśli chodzi o funkcjonalność.
Choć może też coś być na rzeczy, bo OpenGL 4.0 wymaga 64-bitowej precyzji obliczeń w shaderach. stąd np. Radeon 5770 i słabsze nie są oficjalnie z nią zgodne (w każdym razie ZTCW nie do końca), tylko Cypress (5870 i 5970). NVIDIA może mieć podobny problem, choć było by to dziwne, w sytuacji gdy tak podkreślają wagę GPGPU w swoim produkcie, a przecież wszyscy wiedzą, że obliczenia naukowe to w większości przypadków podwójna precyzja FP.
zalezy w jakich obliczeniach. Bardzo czesto pojedyncza precyzja jest wystarczajaca.
Bardzo często jest właśnie niewystarczająca, szczególnie przy większej ilości operacji gdzie błędy zaokrągleń wyników cząstkowych mają wymierny wpływ na dokładność ostatecznego wyniku.
Z 5770 w ogóle jest cyrk. Niby nie mają DP, ale w OpenGL 4.0 podobno "mają mieć DP". Czyżby sztuczna blokada? Na oko niczym się nie 5770 różni od połowy 5870…
Ok, tylko NVIDIA ma CUDA które jest o niebo lepsze od Stream no i wsparcie dla fizyki NVIDIA PhysX. NVIDIA jest warta swojej ceny.
Rozwiązania własnościowe przepadną. Wcześniej czy później. Szczególnie jak jest OpenCL.
W Polsce są tylko dwie sztuki do testów: 480 na PCLab, 470 na Benchmark.
+wydajna teselacja
+wydajne OpenCL/DirectCompute
+odrobinę szybsze od HD 5850 i 5870
-astronomiczny pobór mocy
–hałas
-wysoka temperatura pracy
-dużo droższe od 5850 i 5870
Testy na pclab to jakaś porażka. W testach zagranicznych portali wyniki się pokrywają i plasują GTX470 pomiędzy 5850 i 5870, a GTX480 pomiędzy 5870 i 5970, gdzie w większości testów bliżej mu do 5970. Co do poboru prądu, i związanych z tym temperatur i hałasu się zgodzę.
W testach wszystkich portali są sytuacje gdzie GTX480 ma problemy z pokonaniem nawet HD5870. Z HD5790 radzi sobie tylko w przypadku teselacji.
Natomiast co do OpenCL to nigdzie nie widziałem osobnych testów mimo, że jest już odpowiedni benchmark (SiSoft Sandra 2010), więc "czyste" GPGPU jest dla mnie póki co zagadką.
W gruncie rzeczy to porównanie mówi wszystko. Średnio z wielu portali i gier: GTX 480 szybszy od 5870 o 9,3%, GTX 470 szybszy od 5850 o 9,49%.
Testy OpenCL są na Anandtech.
Popsułem linka http://pclab.pl/kom52324-32-100.html#c363377
To co jest na Anandtechu w kwestii OpenCL to jest śmiech na sali. wynik w N-body jest silnie zależny od rozłożenia obliczeń "worker threads" pomiędzy "compute units" (terminologia z OpenCL), a PostFX to jest specjalny nvidiowy przykład, który chodzi dobrze tylko na geforce'ach (złe wykorzystanie local memory na czym Radeony mocno tracą). Jeśli chcieli by czegoś obiektywaniego trzeba było użyć SiSoft Sandra. Swoją drogą w GPU CapsViewier jest jeszcze więcej przykładów OpenCL np. liczenie fraktala 3D ze zbioru Julii – czemu tego nie pokazali?
Są wyniki z sandry GPGPU http://hothardware.com/Articles/NVIDIA-GeForce-GT…
Znacznie szybsze od 5870 w pojedynczej precyzji, bardzo wolne w podwójnej…
Ewidentnie coś z tym wsparciem dla DP jest nie tak, swoją drogą w łamaniu haseł Radeon HD5870 jest dwa razy szybszy: http://www.brightsideofnews.com/news/2010/3/26/nv…
przy czym tutaj mamy czysty integer. Jak widać obie platformy mają swoje mocne strony.
Już wiadomo, że rzeczywiście DP na GTX 480 jest poważnie ograniczone: http://www.geeks3d.com/20100329/geforce-gtx-480-a…
I jeszcze coś, ze stron NV http://www.nvidia.com/object/product_geforce_gtx_…
3.2?
Jesli chodzi o uzytek domowy w grach, to szczegolnie biorac pod uwage szumne zapowiedzi i w porownaniu do radeonow ktore sa juz chyba z 6 miesiecy na rynku, nowe karty nv to FAIL.
6 wersów – to ma być nius? Nic się sensownego z niego nie dowiedziałem.
Sam zauważyłeś news, a nie artykuł.
Mimo wszystko jakaś specyfikacja kart by się przydała. ;P
Kupować kartę, dla której uzysk z wafla krzemowego wynosi kilka procent, a temp. pracy oscyluje w pobliżu 85 stopni, to skrajna głupota. Jeśli większość chipów nie nadaje się do pracy, to jak długo popracują te, które rzekomo się do niej nadają? To w ogóle nie jest tak naprawdę karta graficzna, tylko porzucony projekt do obliczeń numerycznych, który na tempo został wyciągnięty z szafy i lekko przerobiony, żeby wypuścić cokolwiek w odpowiedzi na ATI 58xx. A najlepsze jest to, że nvidia nie ma żadnego pola manewru żeby poprawić choć trochę jego pracę. Zwykle o takich projektach mówi się "strzał w stopę", ale tym razem nvidia strzeliła sobie w głowę. Oby znalazł się jakiś dr. House, który ją poskłada do kupy. Bo na razie jedyna część mózgu, która jeszcze działa, to marketing.
Może wyniki testów nie wypadły powalająco, ale będą one bardziej miarodajne jak nvidia wypuści dopracowane sterowniki. Geforcy mają jedynie wyraźniejszą przewagę w aplikacjach masowo wykorzystujących teselację, których puki co jest niewiele.
Swoją drogą sporo osób twierdzi, że teselacja stanowi przyszłość gier i w tym przypadku tylko karty radzące sobie z nią najlepiej będą dominować. Zastanawia mnie na ile ma szansę się to urzeczywistnić, bo jednak spadek wydajności z użyciem tej techniki jest wyraźny. Przecież w wielu przypadkach doskonale sprawdza się stosowanie map normalnych, które dobrze "udają" efekty nierówności. Czy zatem jest potrzeba generowania faktycznych nierówności poprzez drastyczne zwiększenie ilości wielokątów(bo tylko wtedy ma to sens)? Ile osób zauważy/będzie chciało zauważyć jakąkolwiek wyraźną różnicę? Grając w grę pełną szybkiej akcji nawet nie zwraca się uwagi na wiele innych rzeczy, uwaga jest skupiona na czym innym.
Bardzo fajnie wygląda generowanie rzeźby terenu z użyciem teselacji i mapowania przemieszczeń, chociaż to drugie jest już stosowane od dawna. Również przekonująco wyglądają postacie zdeformowane przy użyciu mapy. Co ciekawe już wcześniej próbowano to zastosować, ale rezultaty były nie najlepsze i sprzęt za słaby. Poza tym ciekawi mnie czy stosowanie takiej metody jest np. równie wygodne i dające taką samą kontrolę nad siarką jak ręczne rzeźbienie w podstawowym modelu. Przetwarzanie uproszczonego obiektu i zagęszczenie go w locie na pewno wymaga mniej pamięci ale ostatecznie liczba wielokątów do odrysowania jest ogromna i wymaga czasu. Trochę sceptycznie jestem do tego nastawiony, ale czas wszystko niebawem zweryfikuje.
Szkoda tylko, że w tym całej euforii sztucznie nakręcanej przez producentów, gdzieś zaginęła idea, którą powinni się kierować twórcy gier i gracze, czyli ogólny poziom i mechanika gry w pierwszej kolejności a bajery na końcu, eh 🙁
puki!=póki
Czasu na napisanie sterowników mieli bardzo dużo. No chyba, że wypuszczą takie "zoptymalizowane" sterowniki jak w przypadku FX 5800…
Return to Castle Wolfenstein i masz teselację ;]
Mein Gott! Dzięki za przypomnienie. Ostatni raz grałem w RTCW na Radeonie 7500, który jeszcze nie miał teselacji (od 8500). Teraz sobie odpalę i nie będzie już TruForm zacienione:)
ZTCP w sterownikach ATI rozszerzenie GL_ATI_pn_triangles (stara teselacja) nie jest widoczne od cholery czasu. Nie wydaje mi się, żeby RTCW kojarzył GL_ATI_vertex_shader_tessellator…
Na Pclabie jest napisane ze Fermii wspiera c++. Jak mam to rozumiec?
Ze nvidia dostarcza oprogramowanie, ktorym sobie skompiluje kod w c++ bez zadnych przerobek?
I ze program wynikowy bedzie wykonywany przez karte graficzna? Czy tak?
Masz to rozumieć tak, że póki co jest to marketingowy bełkot, wprowadzili możliwość tworzenia klas i template'ów w CUDA i kompilację do ELF-a. Takie to C++.
To nie jest marketingowy bełkot, wojtku m. Programowanie kart GPU do zastosowań numerycznych wymaga bardzo rozważnego posługiwania się operacjami na pamięci operacyjnej karty. Mimo że przepustowość pamięci przekracza 100GB/s, a więc jest o rząd wielkosci lepsza niz w CPU, jest to wąskie gardło wszystkich GPU w większości normalnych zastosowań, bo przecież te układy mają teoretyczną moc obliczeniową liczoną w teraflopach na sekundę i trudno nadążyć z dostarczaniem danych do takiego potwora. W procesorach NVidii programista ma do wyboru przechowywanie danych w rejestrach karty (zmienne), pamięci dzielonej (zmienne lub tablice), pamięci stałej (zmienne lub tablice), pamięci głównej karty (zmienne lub tablice) i w ostateczności w pamięci RAM komputera (dramatycznie nieefektywny sposób). Fermi jest pierwszym GPU, w którym możliwe jest utworzenie wskaźnika do danych i wstawienie go do funkcji, której autor nie musiał wiedzieć, w jakim obszarze pamięci te dane są przechowywane. To oznacza możliwość jednolitego traktowania wskaźników (jak w C lub C++ na CPU), a w perspektywie oznacza możliwość użycia w kodzie źródłowym pisanym na GPU całego arsenału C++ łącznie z funkcjami wirtualnymi, które zwykle implementowane są przez wskaźniki vtable. W ten sposób powinno też dać się zaimplementować dynamiczne struktury danych. W tym sensie Fermi potencjalnie obsługuje cały C++ – dotychczas GPU NVidii programowało się w języku C, do którego z C++ dołączono obsługę szablonów i polimorfizm nazw funkcji, ale z którego wyłączono dynamiczne struktury danych, rekurencję, zmienne statyczne.
Reasumując: Dotychczasowe programowanie w CUDA pod względem formalnym przypominało programowanie w C z kilkoma elementami C++ (szablony!), pod względem struktur danych był to fortran 77 (w arsenale tylko zmienne i tablice), pod względem algorytmiki jest to terra icognita. Teraz programy powinny zacząć przypominać "normalny" kod w C++ pod względem używanych technik programistycznych i struktur danych (ale algorytmika to wciąż niemal dziewicze pole), co oznacza większe pole manewru dla programistów i ułatwienie tworzenia bibliotek.
Programy na GPU trzeba pisać w specjalny sposób i kompilować specjalnym kompilatorem. Ten kompilator rozróżnia kod wykonywany na cpu (i kompiulje go zwykłym kompilatorem c++, np. gcc) od kodu dla GPU (i kompiluje go do specjalnego języka pośredniego PTX za pomocą opensorcowego Open64). PTX może być skompilowany do kodu binarnego obsługiwanego przez konkretną kartę przez kompilator lub – on the fly – przez sterownik karty graficznej. W ten sposób PTX zapewnia zgodność kodów "binarnych" z rożnymi modelami kart NVidii.
Z tym całym wskaźnikiem to jest dla mnie spawa nie do końca jasna, bo na dobrą sprawę ma on sens tylko na poziomie pamięci globalnej karty (VRAM), a przecież całe to masywne zrównoleglanie na poziomie danych właśnie możliwe jest dzięki temu, że nikt na sztywno nie ustawia struktur danych i można je na bieżąco przydzielać do wolnych jednostek obliczeniowych i ich lokalnych zasobów.
Wprowadzenie tego wskaźnika jest tak naprawdę krokiem wstecz z dotychczasowego bardzo efektywnego modelu "data parallel" do dużo mniej efektywnego i znanego z CPU "task parallel".
Ta funkcjonalność jest może wygodna z punktu widzenia programisty C++, który jest przyzwyczajony myśleć za pomocą pojęć OOP, ale jak już od dłuższego czasu się wykazuje jest dużo mniej efektywne od podejścia "data driven programming" (DDP).
Jak dużo może być różnica pokazują ekskluzywne tytuły na PS3 takie jak choćby hit ostatnich dni God of War III, w całości zrealizowany w metodologii DDP.
Polecam ten link: http://www.insomniacgames.com/blogcast/blog/mike_…
Stąd uważam, że jest to "łata na łacie" i bardziej ukłon w stronę wygody programistów niż rzeczywistej troski o wydajność.
Można jeszcze dla jakiegoś tam przypomnienia/uzupełnienia rzucić "białym papierkiem": NVIDIA's Next Generation CUDA™ Compute Architecture: Fermi™.
Nie do końca jest prawdą, że w C/C++ można jednolicie traktować wskaźniki. Może na X86 ale na architekturach harwardzkich (uC) wskaźniki są rozdzielone względem funkcji (a mimo to f. wirtualne istnieją).
W rzeczy samej. Nie wierzę, że w Fermim, można zrobić operację „(*wskaznik_funkcji)();”, a to w C/C++ podstawowa sprawa.
Mowa jest jedynie o wskaźnikach do danych, a to jeszcze za mało aby mówić o pełnej implementacji C/C++.
Z drugiej strony jak już wcześniej pisałem nie widzę sensu w udostępnianiu takich możliwości, bo zwyczajnie ograniczają możliwości skalowania. Im bardziej niezależne zadania tym większa równoległość, a jak tylko wprowadzimy wskaźnik to od razu pozbawiamy się całej klasy optymalizacji opartych na statycznej analizie kodu i przepływie sterowania.
W ostatecznym rozrachunku nikt na tym nie zyskuje, bo programista i tak musi się wysilić pisząc bardziej optymalny kod, prędzej czy później „ręcznie” implementując założenia „data parallel computing”, bo tak jest najefektywniej na GPU.
W C to podstawowa sprawa, w C++ używa się funktorów i szablonów dla których kompilator ma większe szanse na auto-zrównoleglenie i rozwijanie (inline). Wskaźniki na funkcję bez porządnego PGO psują wydajność.