Jump to content
adek

AMD i nowa strategia dla profesjonalnych kart graficznych

Recommended Posts

z 2010 wyżej kolejny filmik, jak najbardziej używalne, a do reszty bez problemu trafisz.

ehe, to jest akurat prosty algorytm (tak samo jak prosty jest raytracing) i średnio zaawansowany programista z mojej uczelni implementuje to w ciągu kilku godzin w języku C, jako ćwiczenie, inną sprawą jest optymalizacja i integracja tegoż z całą strukturą danego softu, żeby obsłużyć jak najlepiej najwięcej ustawień, to zajmuje dopiero ogrom czasu...

 

Nie, naprawdę? O matko, dopiero zaczynam rozumieć, że rozmawiam z 20 latkiem. Średnio zaawansowany programista sobie napisze coś, co średnio ogarnięty student miłośnik AMD uzna za dowód na coś.

 

Miłych wakacji, pozdrawiam!

skk.

Share this post


Link to post
Share on other sites
Bredzisz jak typowy śmieszny zielony ujadacz

Spokojnie, za stary jestem zeby takie teksty na mnie dzialaly :D Tylko pokazujesz jak zdesperowany jestes w obronie swojego bozka.

Stan na dzien dzisiejszy - AMD nadal nie ma niczego co mogloby konkurowac z NV. Nie maja zadnej karty ktora by wydajnoscia dorownywala 1080. Przez litosc nie wspomne o TitanX. Jak beda mieli to porozmawiamy - na razie koncze bo ja zyje w realnym swiecie a ty w swiecie zapowiedzi ukochanej firmy. Mozemy do dyskusji wrocic jak slowo stanie sie cialem, tylko niestety czesto okazuje sie, ze chcieli dobrze a wyszlo jak zwykle. Oby nie.

Dzis juz wiadomo ze Vega bedzie dopiero w przyszlym roku (i zgaduje, ze nie chodzi o styczen :D) a z tego co wiemy to X490 ma marne szanse na powalczenie z ta znienawidzona przez ciebie NV. Vega moze cos zmienic ale do tego czasu to ja nasmigam renderow na NV za ktora przeplace bo dziala dobrze z przereklamowanym Cyclesem. Oh, oh, jakie to straszne :D

Share this post


Link to post
Share on other sites

materalia już się tam zagotował od tego jak my tu wszyscy tak bardzo nic nie rozumiemy :D

A te 480tki to rzeczywiście wyprzedzają wszystkich o epokę, dlatego pewnie nie dostały i nie dostaną certyfikatu PCI-Express bo nie spełniają wymagań, aż tak bardzo odskoczyli od peletonu ze swoją kosmiczną konstrukcją :) Nic tylko chylić czoła :D

Share this post


Link to post
Share on other sites

Zdecydowanie brakuje tu wzmianki, że wielu z nas mając wbudowaną kartę graf w procesor intela jest zwyczajnym niebieskim kolaborantem.

Ale ciesze się, że kilka stron pozwoliło mi być tak bardzo na bieżąco z tematem.

Share this post


Link to post
Share on other sites
To jest ślepa uliczka, bo akurat wektoryzacja kodu pod takie długie rejestry jest kosztowna, sam rdzeń jest większy (da może bez spec. opt. +15% w realnych zadaniach), lepiej i taniej dołożyć kolejny rdzeń ze std. 128bit rejestrami - łatwiejsza wektoryzacja, tym bardziej, że to obliczenia wielowątkowe, więc ładnie się też skaluje, i rdzeń mniejszy, także nie wiem czy to ma sens dawać tak długie rejestry, ale ludzie to kupią, tak jak kupują aparaty z większą liczbą mpiksli z oczkiem jak dziurka wysikana w śniegu :)

 

Pewnie nie warto rozmawiać z młodzieńcem, który bierze w tej dyskusji udział chyba tylko po to, żeby popisywać się wiedzą, a nie coś zrozumieć, albo komuś coś wytłumaczyć, ale że wątek czytają także inni...

 

To jest pomieszanie z poplątaniem. Oczywiście, że wektoryzacja nie odbywa się bez kosztów i nie jest rozwiązaniem na wszystko, ale mądrzy ludzie robią coś, co jest możliwe w danej sytuacji (a "sytuacją" jest ograniczony dostęp do pamięci z CPU), a nie opowiadają, co byłoby najlepsze. Wektoryzacja zmniejsza nawet taktowanie procesora..., więc magic bullet to to nie jest, ale reszta argumentu to czysta demagogia...

 

Procesorów z takimi rejestrami nie kupują ludzie, których można przekonać megapixelami, tylko ludzie, którzy stawiają klastry obliczeniowe, robią testy na zoptymalizowanym kodzie i podejmują decyzje zakupowe w oparciu o to, ile gflopów wyciągną per watt i per dolar. I do takich ludzi przemawia Intel poszerzając wektory. Zdaje się, że poszło mu to nieźle, skoro Phi jest sukcesem na rynku HPC, czyli tam, gdzie miał być. Tyle a propos studenckich teoretycznych mądrości.

 

W zadaniach, o których tutaj mowa, czyli renderowaniu, kod zawsze się optymalizuje, nie ma więc sensu porównywać wzrostu wydajności kodu bez optymalizacji. Dlatego zresztą niewątpliwe zalety OpenCL, są dla rendererów wątpliwe. OpenCL nie jest w stanie sam z siebie wyciągnąć maksimum wydajności zarówno pod CPU jak i GPU, właśnie dlatego implementacje rendererów w Cuda są zawsze szybsze od OpenCL (o ile jest dostępne). Cuda wspiera jedną architekturę, więc może być zoptymalizowane pod jedno GPU i wyciąga z niego więcej niż kod OpenCL, który się sprytnie sam optymalizuje (aczkolwiek faktem jest, samo wyrażenie algorytmu w OpenCL, daje wzrost wydajności na CPU w porównaniu do C(++)).

 

Wektoryzacja nie przekłada się automatycznie na znaczny wzrost wydajności w większości aplikacji, ale w generowaniu grafiki, w zoptymalizowanym kodzie, przekłada się bardzo, co najlepiej widać po 20% wzroście wydajności VRaya, kiedy włącza się w nim Embree. A przecież to jest BARDZO zoptymalizowany kod ludzi, którzy zjedli zęby na asemblerze. Tylko tylko, że żaden duży program nie zaryzykuje szerokiego wsparcia na AVX (nie mówiąc o AVX2), bo te programy pracują na starych klastrach SSE4 (albo nawet SSE2), a na ręczną optymalizację dla każdej wersji Intela mało kogo stać. No chyba, że Intel dostarczy Embree, które posiada oddzielne ścieżki dla różnych architektur, więc można się szarpnąć.

 

Reasumując, może Cuda jest z założenia ch**wa (a jest, bo zamknięta, bo niskopoziomowa) , ale była dotąd jedyną REALNĄ alternatywą dla ludzi, którym zależało na kontrpropozycji wobec rendererów CPU. Być może Luxrender może sobie działać na OpenCL, bo z założenia jest powolnym path tracerem unbiasowym.

 

Redshift, którego "selling point" polega własnie na tym, że oferuje A) praktycznie wszystkie ficzery VRaya B) robi to szybciej C) jest płatny i ma działać z minimum ryzyka komplikacji, takiego komfortu nie ma. Podobnie Maxwell. Inaczej trudno byłoby wytłumaczyć decyzje ludzi, którzy je stworzyli. A Redshifta zdaje się napisało 3 gości, którzy wcześniej pisali 15 lat enginy do gier. Chyba się znają na GPU.

Edited by SYmek

Share this post


Link to post
Share on other sites

SYmek a to nie jest tak, że w zastowaniach HPC to daje też tak dobre efekty dlatego, że wektoryzacja nie jest tam opłacalna? Tzn. istnieje tam spore ryzyko, że obliczenia będą nieliniowe i architektura GPU z naciskiem na układy liniowe po prostu się nie sprawdza?

Share this post


Link to post
Share on other sites
więc ten swój 500$ vs 700$ soluszyn mogą sobie w dupe wsadzić. Fajnie że amd się podnosi po ciągłych porażkach ale narazie polaris w niczym nie zaskoczył. Dogonili karty z przed 2 lat czyli 970, teraz pozostaje czekać na vege.

 

Nie dość, że hejterzy NV, to jeszcze ignoranci :)

 

Kilka linków pod rozwagę, dla tych co bredzą jakoby rendering na AMD to piosenka sprzed kilku miesięcy. Jesteście tak żałośni razem, że szkoda gadać.

 

Rok 2013

 

http://ht4u.net/reviews/2013/asus_matrix_hd_7970_platinum_im_test/index37.php

 

Jak widać HD7970 rozwalał TITANA na łopatki, nie mówiąc o GTX 780 itp., baa, HD7870 góruje nad kartami NV włącznie z TITAN'em. I co powiecie zielone fanboje na to. HD7970/7950 oferowały wtedy 3GB RAM, osiągalne dopiero na GTX970 hehe:)

 

http://www.luxrender.net/luxmark/

 

Rok 2016, gdzie się trochę poprawiło, tylko trochę, bo NVIDIA robi szalenie drogi szajs:

http://www.luxmark.info/top_results/LuxBall%20HDR/OpenCL/GPU/1

 

-----

Oczywiście dalej zawzięcie ignorujecie możliwość renderowania na AMD, nie tylko, bo także IntelHD na silnikach np: luxrender, indigo itp. od dawien dawien dawna.

 

2x rx480 to jest 300W

1x 1080 to jest 180W

1x 1070 to jest 150W

 

po co porównujesz 2 do 1, jak to jest odpowiednik GTX970/1060, puknij się w głowę. Myślenie ON!. Jak weźmiesz 2x 1060 to też masz 250W, a jak 1070 to 300W. Puk! puk!.

Share this post


Link to post
Share on other sites
SYmek a to nie jest tak, że w zastowaniach HPC to daje też tak dobre efekty dlatego, że wektoryzacja nie jest tam opłacalna? Tzn. istnieje tam spore ryzyko, że obliczenia będą nieliniowe i architektura GPU z naciskiem na układy liniowe po prostu się nie sprawdza?

 

Pewnie jest tak, jak mówisz. Zdaje się, że HPC kilka lat temu przesiadło się na różnego rodzaju akceleratory, ponieważ wiadomo było, że z standardowe CPU osiągnęło limit możliwości a nowych technologii nie było. Rozwijając klaster na Cuda, niekoniecznie musi chodzić o wiarę w tę technologię, ale raczej o rozpoczęcie długiego procesu transformacji kodu działającego na klastrze na inne technologie. Nie chcę się wymądrzać, bo niewiele na ten temat wiem (ale wiem, czego nie wiem). Pierwszy z brzegu pdf, który fachowo tłumaczy temat - ale te wnioski stosują się tylko do HPC (nie do rendererów):

 

https://verc.enes.org/ISENES2/documents/Talks/WS3HH/session-4-hpc-software-challenges-solutions-for-the-climate-community/markus-rampp-mic-experiences-at-mpg

 

Pada tam ciekawe zdanie, że na marzec 2014, Cuda właściwie nie ma konkurencji jeśli chodzi o programowanie GPU (swoją drogą ciekawe, czy chodzi o stan samego OpenCL, czy o stan sterownika OpenCL Nvidii). Btw z jakiś powodów od pewnego czasu nie kupuje się procesorów AMD na klastrach - chyba chodzi o prąd, ale nie jestem pewien.

 

Są też rzeczowe testy pokazujące, że GPU w zastosowaniach HPC daje realnie x2-x3 wzrost wydajności, czyli niewiele biorąc pod uwagę koszt rozwoju oprogramowania. Jak wspomniałem, wygląda na to, że nakład pracy w klastry na GPU to głównie inwestycja w rozwój oprogramowania, które łatwiej będzie przepisać na nowe architektury (intela i innych).

 

 

DISCLAIMER:

 

Co do kart graficznych AMD, ich możliwości etc., całego tego zamieszania, o którym tu prawicie, nie wypowiadam się, nie znam się, nie chcę się znać. Jeśli AMD robi hurtowo procesory dla producentów konsol i wymagającego Apple, to chyba nie jest tak z nimi źle? Moja wypowiedź z początku tego wątku dotyczyła wyłącznie sterowników OpenGL od AMD, które przez lata wołały o pomstę do nieba i to wiem na pewno. Niestety przy obecnym stanie OGL, pisanie sterowników jest męką i bez gigantycznego nakładu pracy, nie da się tego robić dobrze. Intel jak i AMD przez lata zaniedbywały sprawę oddając miejsce Nvidii w rynku aplikacji profesjonalnych CGI, co niekoniecznie musi mieć znaczenie dla graczy, konsol.

 

 

EDIT:

 

Co do Indigo, Lux: ich istnienie świadczy o tym, że napisanie path tracera na OpenCL jest możliwe, natomiast nie świadczy o tym, że wybór OpenCL, zamiast Cuda, było optymalne dla rozwoju tego oprogramowania. Oba są open source (indigo też zaczynało jako open source tak?), oba są z natury powolne i mówiąc najkrócej technologicznie odstają od komercyjnych aplikacji (znacznie odstają).

Edited by SYmek

Share this post


Link to post
Share on other sites
AMD nadal nie ma niczego co mogloby konkurowac z NV. Nie maja zadnej karty ktora by wydajnoscia dorownywala 1080.

 

Bredzisz. AMD tego GTX1080 to 2x połyka w poprzednich hi-end konstrukcjach 28nm. Nie ma jeszcze odpowiednika w 14nm, bo prawdopodobnie nie będzie to Polaris tylko Vega 10 (RX 490X). AMD ma inną koncepcje rozwoju, nie zapycha większą powierzchnię dokładnie tym samym, tym bardziej, że RX490X ma mieć min. 16GB (będą wersje PRO z 32GB HBM2). GTX1080 to 314mm2, a RX480 to 232mm2, mogliby dodać jeszcze 100mm2 i miałbyś swojego przepłaconego za frajer GTX1080 wydajnościowo w Polarisie, tak jak niektórzy przepłacali za żałosne 4GB w GTX970(3.5 w fullspeed)/980, kiedy można było można kupić taniej R9 390/390X z 8GB (dla mnie karta bez 8GB od 2 lat jest niewarta uwagi, bo to miałem w starym HD7970 3GB). Także płać za swoją ukochaną firmę. Gadanie o życiu w nierealnym świecie jest żałosne. Liczę na GPU AMD od 2011 zupełnie normalnie, a testowo od 2009. To co piszecie o AMD to brednie do kwadratu.

 

Doceniam Cyclesa, ale go nie używam, więc CUDA nie ma dla mnie większej wartości, bo wszystko inne mam w OpenCL, a OpenCL jest o niebo lepszy na AMD. Kumasz ?. Gdybym korzystał z Cyclesa wybrałbym kartę NVIDIA, przecież nigdzie nie przeczę temu!.

Share this post


Link to post
Share on other sites
Bredzisz. AMD tego GTX1080 to 2x połyka w poprzednich hi-end konstrukcjach 28nm..

 

cooo? fanboy mode on xD?

 

przecież jeszcze sam pisałeś w poprzednich postach że AMD nie ma żadnej karty która mogła by konkurować z 1080 a teraz piszesz że poprzednie generacji karty były 2 krotnie szybsze od GTX'a? Jest jakiś w ogóle benchmark w którym AMD jest lepsze xD?

 

Mógłbyś być PR u AMD bez kitu. tak samo jak oni.. paplą jacy to są zajebiści i jacy to mega szybkie karty i wogole oh ah a potem jest tak że nawet kernel się niechce skompilować :(

Share this post


Link to post
Share on other sites

Ten luxmark to jakas wyrocznia? Zawsze jak ktos probuje ratowac karty amd to przedstawia wyniki luxmarka. Ktos wogole tego uzywa? Tu masz dosc dobre porownanie nv vs amd

http://www.phoronix.com/scan.php?page=article&item=amdgpu-pro-rx460&num=6

 

Nie twierdze ze amd to sa zle karty. Nie uwazam sie za jakiegos wybitnego wroga amd. Mialem swego czasu durona, a64 czy r9550. I zawsze dobrze wspominam ale na ta chwile trzeba przyznac ze dla profesjonalisty 1070/1080/titan to jest pierwszy wybor. Zachowujesz sie troche dziecinnie a powinienes na to patrzec chlodnym okiem (jak dorosly). Nazywanie kogos hejterem nv jest dosc niepowazne. To nie jest forum benchmarka czy onetu. To forum raczej skupia ludzi ktorzy z grafiki zyja i w sumie maja w dupie przepychanki miedzy oboma firmami. "puknij sie w glowe" "wlacz myslenie" mam wrazenie ze pisze z jakims licealista ale odpowiem. Na prezentacji amd jakis gosc mowi ze odpowiedzia na gtx1080 ktory kosztuje 700$ sa 2xrx480 sumarycznie 500$. W tescie takie polaczenie daje 2 klatki wiecej od 1080. Tylko nie dodaje ze to polaczenie to 2x wiecej mocy zuzytej. Nie wiem czego tu mozna nie zrozumiec no ale czego wymagac od dzieciaka.

Share this post


Link to post
Share on other sites
Średnio zaawansowany programista sobie napisze coś

 

Nic na to nie poradzę, że studiowałeś rolnictwo ;). Nie bierz tego do siebie. http://www.kevinbeason.com/smallpt/

 

Wektoryzacja zmniejsza nawet taktowanie procesora...

 

ehe, to ciekawe czemu w syntetykach takich jak linx/intelburntest dogrzewa się procki dopiero na AVX, a nie na SSE 128bit ?:)

 

Procesorów z takimi rejestrami nie kupują ludzie, których można przekonać megapixelami, tylko ludzie, którzy stawiają klastry obliczeniowe, robią testy na zoptymalizowanym kodzie i podejmują decyzje zakupowe w oparciu

 

Taki marketingowy bełkot to zostaw sobie jak będziesz musiał kiedyś przebranżowić się na sprzedawcę skarpetek :). Nie bierz też do siebie, ale nie pisz do mnie taką śmieszną nowomową.

 

co najlepiej widać po 20% wzroście wydajności VRaya, kiedy włącza się w nim Embree.

 

Najpierw włącz embree dla SSE4.x (128bit), a potem AVX (256bit), a skok wydajności między 256>512 będzie mniejszy niż 128>256. Zmierz różnicę, zanim wyciągniesz +20%. Okey ?:)

 

Być może Luxrender może sobie działać na OpenCL, bo z założenia jest powolnym path tracerem unbiasowym.

 

Jakie być może sobie działać. Luxrender jest używalny od lat, powiedzmy 5, od lat działa całkiem stabilnie i coraz lepiej, a czy jest powolny, nie sądzę by był powolniejszy od Cyclesa, ale lepsze wyniki czasowe i jakościowe zazwyczaj uzyskuje się na komercyjnych np: Indigo, chyba bardziej lepszych względem Cyclesa, niż Luxa, bo Lux ma niezłe "odszumiacze", tylko za to trzeba bulić razy X node.

k0hhjo.jpg

 

ale była dotąd jedyną REALNĄ alternatywą dla ludzi, którym zależało na kontrpropozycji wobec rendererów CPU

 

Bzdura, że jedyną realną, bo pathtrejsery od dawna śmigają na OCL. NVIDIA bardzo długo trzymała niedopracowane OCL 1.1 (do 2015), a jednocześnie wypuszcza karty do GPGPU only CUDA. Jak to wyjaśnić ?. Niektórym widać takie praktyki korpotech pasują :).

Share this post


Link to post
Share on other sites

luxrender stabilny BUAHAHAHAHAHAHAHAHAHA o jizas. Ile to razy musiałem przenosić cały projekt do cyclesa bo luxrender nie dawał rady i zaczynał się randomowo wysypywać.. a cycles jeszcze nigdy mi się nie wykrzaczył po wystartowaniu renderingu. a luxrender nie raz nie dwa nagle się crashuje :( albo są jakieś dziwne artefakty. Zgłaszałem buga i pracują nad poprawą ale. Lux renderowi jeszcze duzoooo do stabilności cyclesa.

Share this post


Link to post
Share on other sites
przecież jeszcze sam pisałeś w poprzednich postach że AMD nie ma żadnej karty która mogła by konkurować z 1080 a teraz piszesz że poprzednie generacji karty były 2 krotnie szybsze od GTX'a? Jest jakiś w ogóle benchmark w którym AMD jest lepsze xD?

 

Mógłbyś być PR u AMD bez kitu.

 

Mógłbyś naumieć się czytać ze zrozumieniem, a nie połykać wyrazy jak połyka kasę od frajerów kochana NVIDIA :). Napisałem jasno, w Polarisie, później w 14nm, żeby jasne. Czepiasz się tak głupio, że szkoda gadać :)

Share this post


Link to post
Share on other sites
ehe, to ciekawe czemu w syntetykach takich jak linx/intelburntest dogrzewa się procki dopiero na AVX, a nie na SSE 128bit ?:)

Przeczytaj instrukcje Intela.

 

Jakie być może sobie działać. Luxrender jest używalny od lat, powiedzmy 5, od lat działa całkiem stabilnie i coraz lepiej, a czy jest powolny, nie sądzę by był powolniejszy od Cyclesa, ale lepsze wyniki czasowe i jakościowe zazwyczaj uzyskuje się na komercyjnych np: Indigo, chyba bardziej lepszych względem Cyclesa, niż Luxa, bo Lux ma niezłe "odszumiacze", tylko za to trzeba bulić razy X node.

 

Ludzi którzy żyją z renderowania, nie interesuje porównanie z Cycles. Interesują porównania z Maxwellem, Vrayem w trybie PBR, Arnoldem, Mantrą, Rendermanem PBR, 3delightem PBR, Redshiftem. Zarówno pod względem możliwości, jak i wydajności. Rozumiem, że nie masz pojęcia o czym mówię.

 

Bzdura, że jedyną realną, bo pathtrejsery od dawna śmigają na OCL. NVIDIA bardzo długo trzymała niedopracowane OCL 1.1 (do 2015), a jednocześnie wypuszcza karty do GPGPU only CUDA. Jak to wyjaśnić ?. Niektórym widać takie praktyki korpotech pasują :).

 

Jeszcze raz Ci napiszę, że "śmiegają" nic nie znaczy, śmigają dla funboyów. Dla ludzi pracujących w branży nie ma ani jednego rendera OCL, który nadaje się do pracy, jeden pod CUDA, który się nadaje i kilka zabawek, które coś próbują zrobić. Reszta to CPU.

 

I jeszcze raz, na spokojnie. Czy OCL dorównuje CUDA jeśli chodzi o możliwość wdrożenia CAŁEGO renderera może powiedzieć ktoś, kto podjął taką próbę w obu środowiskach. A ponieważ ani Ty ani ja nie zrobiliśmy tego, musimy oprzeć się na opinii innych. Tak się składa, że jedyne profesjonalne renderery GPU obecne TERAZ na rynku, używają CUDA. Stąd moje domniemanie, że CUDA ma (lub miała 3 lata temu), coś czego OpenCL nie ma. Koniec argumentu. Lux niczego nie dowodzi, bo nie mieści się w kategorii profesjonalnych narzędzi w branży CGI. Może CI się to nie podobać, ale zarówno Cycles jak i Lux są narzędziami dla entuzjastów i freelencerów, którzy pracując na Blenderze nie mają zbyt wiele możliwości.

 

 

Nic na to nie poradzę, że studiowałeś rolnictwo ;)

Taki marketingowy bełkot to zostaw sobie jak będziesz musiał kiedyś przebranżowić się na sprzedawcę skarpetek :). Nie bierz też do siebie, ale nie pisz do mnie taką śmieszną nowomową.

 

Uśmieszek na końcu zdania nie zmienia chamskiego wydźwięku całości (i braku argumentu). Jak bardzo chcesz bana, to ja o niego dla Ciebie poproszę. Na razie proszę, żebyś się zachowywał i nie obrażał ludzi na forum.

Edited by SYmek

Share this post


Link to post
Share on other sites

Próba "dyskusji" z materalią jest jak tarzanie się ze świnią w g*wnie, znacie resztę ;) Nie lepiej pozwolić mu gnić we własnej rzeczywistości? Taki piękny słoneczny dzień dzisiaj, szkoda go marnować :)

Share this post


Link to post
Share on other sites
Ludzi którzy żyją z renderowania, nie interesuje porównanie z Cycles. Interesują porównania z Maxwellem, Vrayem w trybie PBR, Arnoldem, Mantrą, Rendermanem PBR, 3delightem PBR, Redshiftem. Zarówno pod względem możliwości, jak i wydajności. Rozumiem, że nie masz pojęcia o czym mówię.

 

dokładnie.. a lux render nawet nie jest na poziomie cyclesa. więc z czym do ludzi... Lux to jest zabawka dla developerów aby wcisnąc najnowsze algorytmy i sposoby renderingu i pobawić się w renderowanie kaustyki for fun.

Share this post


Link to post
Share on other sites
Z miejsca widać, że stronnicze po doborze kolorów. Wyniki to tylko zmyślone dane..

M A N I P U L A C J A

 

Manipulacja, nie :). MD5 jest tu zupełnie niewiarygodny, ale widać ciut lepiej realizuje hardware NV, ale to działa na całkowitoliczbowych, to już lepiej liczenie PI z syntetyków. Równie dobrze mógłbyś dać testy z koparek bitcoinów, też na całkowitoliczbowych simd, akurat lepiej na hardware AMD, no tak, to byś nie dał, nie pasowałoby do zielonego obrazu świata hehe:). Widzisz z GPU to jest tak, że różne operacje podstawowe (takie najbardziej prymitywne) lepiej działają na hard AMD, a inne na hard NVIDIA lub hard Intel itd., a ponieważ są to relatywnie proste algorytmy (same loopy) więc wyciskają z prymitywów absolutne maksimum, więc jak widzisz, nie może to być jakokolwiek obiektywne. Nas jednak interesują głównie pathtracery oraz inne przetawarzania związane z grafiką np: kodowanie dekodowanie - tutaj moim zdaniem AMD gniecie NV, algo. kompozycji na GPU itp.

 

Tu jest test GPUPI, chociaż nie przywiązywałbym wagi do tego syntetyka:

http://www.hardwareluxx.de/index.php/artikel/hardware/grafikkarten/39889-powercolor-radeon-rx-480-red-devil-im-test.html?start=7

 

Tu Luxmark 3.0:

http://www.hardwareluxx.de/index.php/artikel/hardware/grafikkarten/39889-powercolor-radeon-rx-480-red-devil-im-test.html?start=6

 

Jak widać RX480 miażdzy nadal o wiele droższe karty NVIDIA, podobnie jak w czasach HD7xxx, HD5xxx itd. :). Dodam, że NVIDIA dodała spec. poprawki dla GTX980/Ti i szału nie ma w lux.

 

luxrender stabilny BUAHAHAHAHAHAHAHAHAHA o jizas. Ile to razy musiałem przenosić cały projekt do cyclesa

 

Jest stabilny i wydajny, nie widzę jakiejś różnicy między cyclesem, poza tym, że cycles jest ubogi w wybór algorytmów renderowania (only one pathtracer), a luxrender wspiera kilka (nawet x2). W przypadku OCL na AMD GPU o wiele stabilniejszy niż na IntelHD, a OCL od Intela jest chyba już ciut lepszy od tego z NVIDIA, mi na NVIDIA OCL wykrzaczały się proste sceny, które ciągnął IntelHD!?. W przypadku CPU działa zawsze, zarówno natywnie CPU i OCL, stabilniej natywne imho... Należy wybierać algorytmy luxcore, żeby mieć najwyższą wydajność. Integracja z Blenderem jest moim zdaniem na 3/4 gwizdka. Trzeba wiedzieć co przechodzi z Blendera do luxa i tyle.

 

SYmek:

 

Przeczytaj instrukcje Intela.

 

po co miałbym czytać foldery reklamowe ? :)

 

Ludzi którzy żyją z renderowania, nie interesuje porównanie z Cycles. Interesują porównania z Maxwellem, Vrayem w trybie PBR, Arnoldem, Mantrą, Rendermanem PBR, 3delightem PBR, Redshiftem.

 

Tak często użyłeś słowa PBR, że aż zastanawiam się, czy wiesz co to jest i w zasadzie w jakim celu powstało, bo bynajmniej nie po to żeby lepiej renderować w klasycznych silnikach renderujących - tu nie daje nowej jakości ponad to czego nie było od dawien dawna, pozwala tylko lepiej pracować z viewportem :). Dodanie PBR do nazwy renderera oznacza ni mniej, ni więcej, to samo co w świecie składu tekstu WYSIWIG, czyli tak jak widzisz materiały w viewport (nie jakiś fake OGLowy lub na GLSL) powinineś widzieć niemal tak samo przy renderowaniu. Jakie korzyści to przynosi to już każdy chyba wie np: zmniejsza konieczność zapuszczania renderingu w czasie pracy ze sceną ?:). Na ile gdzie jak może wydać się użyteczne, to już każdy sam sobie oceni. PBRy są też pewnym drogowskazem jak uzyskać "wydajne" shadery tzn. lepiej używające zasobów szczególnie GPU, opierając się na wszystkich klasycznych silnikach renderujących CPU/GPU (z dodatkiem PBR czy bez).

 

Jeszcze raz Ci napiszę, że "śmiegają" nic nie znaczy, śmigają dla funboyów. Dla ludzi pracujących w branży nie ma ani jednego rendera OCL, który nadaje się do pracy, jeden pod CUDA, który się nadaje i kilka zabawek, które coś próbują zrobić. Reszta to CPU.

 

Ależ ja wiem, że CPU rządzi, u mnie też rządzi CPU, nie na OCL tylko natywnie najlepiej :). Nie musisz mnie przekonywać, bo już to wcześniej napisałem.

 

OCL dorównuje CUDA jeśli chodzi o możliwość wdrożenia CAŁEGO renderera może powiedzieć ktoś, kto podjął taką próbę w obu środowiskach.

 

W OpenCL zaimplementowano wszystkie takie same algorytmy co w CUDA. OCL ma od niedawna przewagę jaką dają SVM, ACE (async, mmu..) itd. Na wykorzystanie przyjdzie trochę poczekać. Natomiast same budowanie kerneli w OCL i CUDA daje dokładnie takie same możliwości implementacji tych samych algo praktycznie z maks. wydajnością GPU (opt. na niskim poziomie). Wybór CUDA częściej w komercyjnych projektów wynika tylko z popularności hardware, a NVIDIA wykorzystuje to lansując swoją CUDA, kompletnie degradując swoją implementację OCL. Praktyka której nie należy pochwalać, bo wracamy mentalnie niemal do lat 80 i programów konkretnie pod jedną maszynę jednego producenta... API itp. powinny i mogą być multiplatform. NVIDIA nie była takim dziadostwem jakim jest gdyby od początku lansowali CUDA w miejsce OCL. Myślę, że widząc obecnie jak rozwija się OCL zaczynają pukać się w głowę, oczywiście mogą teraz przystąpić do lepszego wsparcia OCL, ale stracili miano lidera, bo są zarówno za AMD/Intel, a nawet ARM, dlatego będą muszą brnąć w ślepą uliczkę CUDA, produkując jako jedyni sprzęt do tego, a to nigdy nic pewnego... :)

 

Jak bardzo chcesz bana

 

Ja tylko proszę byś nie praktykował na mnie języka z marketingowego rynsztoku. Mówiąc krótko, nie gadał do mnie jak sprzedawca, nawet marzeń. Nie obraziłem w żaden sposób. Nie używam słów obraźliwych w odróżnieniu od niektórych tutaj fanbojów zielonego, którzy weszli już do obory :).

 

Imperator:

 

Próba "dyskusji" z materalią jest jak tarzanie się ze świnią w g*wnie, znacie resztę ;) Nie lepiej pozwolić mu gnić we własnej rzeczywistości? Taki piękny słoneczny dzień dzisiaj, szkoda go marnować :)

 

NVIDIA płaci za hejterostwo i fanbojstwo, tak pytam z ciekawości ?:), bo na razie nie masz nic obiektywnie do dodania w temacie, poza ad personam. Erystyka to trudna sztuka, a z takimi prostackimi odzywkami to możesz brylować najwyżej nie powiem gdzie, żebyś się nie obraził :).

 

Jutrzenka:

 

Lux to jest zabawka dla developerów aby wcisnąc najnowsze algorytmy i sposoby renderingu i pobawić się w renderowanie kaustyki for fun.

 

Mitsuba to jest eksperyment, natomiast nie Lux, chociaż obok stabilnych ma eksperymentalne algorytmy CPU/GPU itp. Cycles to jest jeden algorytm, dobra integracja z Blenderem, chociaż na GPU zarówno SSS i Volume można uznać za eksperymentalne, bo tak często wieszają stery.

 

No cóż. Można pokusić się o porównanie cykli cyclesa z cyklami lux, na CPU i GPU. Na CPU sprawa jasna, chociaż luxcore moim zdaniem rozwala cyclesa na amen w przypadku unbias (innego nie wspiera cycles) pathtracera CPU, możliwościami i wydajnością. Na GPU to porównanie kart z tej samej półki cenowej oczywiście (Cycles działa na Pascalu?). W zasadzie wykonalne co do milisekundy, tylko pewnie zawsze znajdzie się maruder, że scena za słaba itp., bo wiele zależy od rodzaju sceny i ustawień.

Edited by materalia

Share this post


Link to post
Share on other sites

SYmek:

po co miałbym czytać foldery reklamowe ? :)

 

Nie foldery reklamowe, tylko instrukcję procesora napisaną dla twórców kompilatorów. Jest w niej oficjalnie mowa o zwolnieniu procesora w przypadku dużego użycia instrukcji wektorowych, a do tego odniosłeś się a propos wektoryzacji.

 

Tak często użyłeś słowa PBR, że aż zastanawiam się, czy wiesz co to jest i w zasadzie w jakim celu powstało,

 

Nie chce mi się z Tobą wykłócać i biorę w tej dyskusji udział w dobrej wierze, więc najkrócej mówiąc użyłem "PBR" przy niektórych nazwach, żeby zaznaczyć, że te silniki mogą lub mogły do niedawna pracować w trybie, który nie nadaje się do bezpośredniego porównywania z Lux. Dopiero kiedy włączy w nich tryb PBR, takie porównanie ma sens. I w takim porównaniu ani Lux, ani Cycles, ani Indigo nie wypadają korzystnie - dla ludzi w mojej branży, czyli robiących filmy w komputerach. Obawiam się, że są to subtelności, które uchodzą Twojej uwadze, bo a) nie używasz zawodowo rendererów b) zbyt krótko się zajmujesz tematem. Potwierdzałoby to zresztą to, co napisałeś o PBR.

 

Dzięki za wyjaśnienie, to ciekawa perspektywa, ale obawiam się, że wynikająca z bardzo ograniczonego doświadczenia kogoś kto bawi się trochę marmo toolbag czy czymś podobnym... PBR jest rewolucją w grafice komputerowej, która wywróciła go góry nogami życie niejednej firmy. Zabawne, że podejrzewasz mnie o ignorancję w temacie, z którego żyję, po czym wykładasz się na podstawowym temacie...

 

Prawdę mówiąc szkoda mi czasu na walczenie z Twoją arogancją. Wiesz, interesujesz się, tylko podejście masz ch**we, zamiast spokojnie rozmawiać, walisz tutaj farmazony do ludzi, którzy 15 lat pracują zawodowo na tych narzędziach... Życzliwie radzę, znajdź sobie w internecie kursy z Siggraphu o PBR na przykład.

 

W OpenCL zaimplementowano wszystkie takie same algorytmy co w CUDA. OCL ma od niedawna przewagę jaką dają SVM, ACE (async, mmu..)

 

Sam piszesz, że od niedawna, a ja od początku podkreślam, że mówimy o stanie na dzisiaj, co w świecie rozwoju oprogramowania znaczy, że mówimy o stanie sprzed kilku lat. Inna sprawa, że możliwość implementacji algorytmu, a środowisko, stabilność sterowników, debugger, narzędzia do optymalizacji etc, zarządzanie pamięcią, no i w końcu wsparcie OCL od głównego gracza, Nvidii, to insza inszość.

 

 

itd. Na wykorzystanie przyjdzie trochę poczekać. Natomiast same budowanie kerneli w OCL i CUDA daje dokładnie takie same możliwości implementacji tych samych algo praktycznie z maks. wydajnością GPU (opt. na niskim poziomie).

 

To by ucieszyło wielu ludzi, bo woleliby pracować w OCL, choć podejrzewam, że kernel OCL, który ma tę samą wydajność co CUDA, będzie miał kiepską wydajność na CPU.

 

Wybór CUDA częściej w komercyjnych projektów wynika tylko z popularności hardware, a NVIDIA wykorzystuje to lansując swoją CUDA, kompletnie degradując swoją implementację OCL. Praktyka której nie należy pochwalać, bo wracamy mentalnie niemal do lat 80 i programów konkretnie pod jedną maszynę jednego producenta... API itp. powinny i mogą być multiplatform. NVIDIA nie była takim dziadostwem jakim jest gdyby od początku lansowali CUDA w miejsce OCL. Myślę, że widząc obecnie jak rozwija się OCL zaczynają pukać się w głowę, oczywiście mogą teraz przystąpić do lepszego wsparcia OCL, ale stracili miano lidera, bo są zarówno za AMD/Intel, a nawet ARM, dlatego będą muszą brnąć w ślepą uliczkę CUDA, produkując jako jedyni sprzęt do tego, a to nigdy nic pewnego... :)

 

Zgadzam się i również mi się to nie podoba, co nie zmienia faktu, że jak mój szef mówi, żebym zrobił coś, żebyśmy mogli pracować szybciej, to po długich rozważaniach, testach, rozmowach z ludźmi z innych studiów moje oczy padają na Redshifta, dla którego alternatywny nie ma. I taką decyzję podejmuje 99% wszystkich ludzi na moim miejscu. Nie siedzę w głowie ludzi od Redshifta, ale idiotami nie są sądząc po efektach. Dlaczego wybrali Cuda? Bo wiedzieli, że mam w studio, jak inni, +50 GPU Nvidii i Cuda da najlepsze efekty, przy najmniejszych problemach. Ale mam te GPU nie dlatego, że nie lubię AMD czy OCL, tylko dlatego, że od wielu lat sterowniki OpenGL dla kart ATI nie nadawały się do użytku pod Linuksem.

 

A potem otwieram pdf, który zamieściłem wyżej i patrzę na liczby, jak to klaster isnt. Maxa-Plancka ma 600 K20, i martwię się, bo wiem, że skoro klastry jadą na Cuda, choć wolałyby nie, to cały programistyczny bajzel, debuggery, biblioteki etc, wszystko ma boost za pieniądze z grantów i to dlatego Cuda jest dopracowana a OCL będzie się nadal wolno rozwijał. A dlaczego Max-Plank liczy na Cuda? Bo Nvidia olewa swoje OCL? Tylko dlatego? No dobrze, ale dlaczego nie ma tam kart AMD? A bo AMD nie robi akceleratorów... ale dlaczego nie ma tam procesorów, dlaczego AMD straciło rynek HPC? A, bo zjadają za dużo prądu, nie są szybsi, za to mniej kompatybilni etc. I w ten sposób dochodzimy (nieco oczywiście upraszczając) do wniosku, że nie wszystko jest winą złej Nvidii, tylko istnieją realne problemy technologiczne, które utrudniają AMD konkurowanie z Intelem i NV. A efekt jest taki, że jak chce się kupić profesjonalne oprogramowanie korzystające z GPU, to jego twórcy kilka lat temu wybrali prawdopodobnie Cuda. No ch**owe, ale co zrobisz.

 

 

Ja tylko proszę byś nie praktykował na mnie języka z marketingowego rynsztoku. Mówiąc krótko, nie gadał do mnie jak sprzedawca, nawet marzeń. Nie obraziłem w żaden sposób

 

O nic mnie dotąd nie prosiłeś. Ten rynsztok, to normalna analiza, który musi wykonać stojący na ziemi szef technologii (czyli taki, co nie bierze w łapę, tylko ocenia co dla niego dobre) - odsyłam do pdfa. Panowie po prostu optymalizują, mierzą i wiedzą czy wektoryzacja i szerokie rejestry są opłacalne czy nie - dla niech. To jednak różnica niż analiza typu: "ludzie kupią bo są idiotami, i myślą, że jak więcej to lepiej, a w ogóle Intel marnuje czas na ślepą uliczkę, bo wystarczy dodać rdzenie, a nie poszerzać rejestry, a wiem to, bo kolega napisał path tracer i mu wyszło, że lepiej dodać wątek, niż użyć AVX zamiast SSE4".

 

Chociaż zgadzam się, że dla aplikacji, której wąskim gardłem jest znajdywanie intersekcji, skok z SEE4 do AVX (i dalej) wiele nie wnosi, tyle tylko, że jeśli mowa o rendererze, to ten obok śledzenia promieni, filtruje tekstury, integruje sample, ewaluuje shadery na wirtualnej maszynie SIMD i robi parę innych rzeczy, które idealnie nadają się do wektoryzacji.

Edited by SYmek

Share this post


Link to post
Share on other sites
Jest stabilny i wydajny, nie widzę jakiejś różnicy między cyclesem, poza tym, że cycles jest ubogi w wybór algorytmów renderowania (only one pathtracer), a luxrender wspiera kilka (nawet x2). W przypadku OCL na AMD GPU o wiele stabilniejszy niż na IntelHD, a OCL od Intela jest chyba już ciut lepszy od tego z NVIDIA, mi na NVIDIA OCL wykrzaczały się proste sceny, które ciągnął IntelHD!?. W przypadku CPU działa zawsze, zarówno natywnie CPU i OCL, stabilniej natywne imho... Należy wybierać algorytmy luxcore, żeby mieć najwyższą wydajność. Integracja z Blenderem jest moim zdaniem na 3/4 gwizdka. Trzeba wiedzieć co przechodzi z Blendera do luxa i tyle.

 

yyy tylko dlaczego developerzy luxrendera przyznali mi racje :X? że pracują nad rozwiązaniem tego problemu bo wiedzą że lux nie jest jakoś bardzo stabilny. jak cycles i generalnie przyznali mi rację :) Lux napewno jest stabilniutki na prostych scenach ale jak masz kilkaset świateł i tak dalej robią się schody niestety ;( renderowałem na CPU. bo akceleracja GPU jest mega niestabilna.

Share this post


Link to post
Share on other sites
Nie foldery reklamowe, tylko instrukcję procesora napisaną dla twórców kompilatorów. Jest w niej oficjalnie mowa o zwolnieniu procesora w przypadku dużego użycia instrukcji wektorowych, a do tego odniosłeś się a propos wektoryzacji.

 

Czyli potwierdzają oczywistość :). Nie trzeba czytać instrukcji Intela żeby też to odkryć, bo jest to znane też od dawien dawna, a Intel nie jest tu ani pionierem, ani prekursorem. Krótko mówiąc. Mam rację, że jest pewna granica poszerzenia tych rejestrów na dziś dzień.

 

Życzliwie radzę, znajdź sobie w internecie kursy z Siggraphu o PBR na przykład.

 

Doskonale wiem czym jest PBR i po co powstało. Rewolucji w tym nie widzę, raczej pewną standaryzację, którą można wszczepić do każdego silnika renderującego (nawet takiego przed PBR), a standaryzacja na pewno ułatwia pracę w dużych grupach. Natomiast czy ma z tego jakąś korzyść przeciętny Kowalski lub kilku Kowalskich trzaskający vizki lub animki na zamówienia to bym polemizował, bo trochę narobi się na około żeby trzymać fason tj. standard.

 

oczy padają na Redshifta, dla którego alternatywny nie ma

 

TINA nie jednemu założyła klapki na oczy :).

 

Dlaczego wybrali Cuda? Bo wiedzieli, że mam w studio, jak inni, +50 GPU Nvidii i Cuda da najlepsze efekty, przy najmniejszych problemach. Ale mam te GPU nie dlatego, że nie lubię AMD czy OCL, tylko dlatego, że od wielu lat sterowniki OpenGL dla kart ATI nie nadawały się do użytku pod Linuksem.

 

Potwierdzasz tylko to co napisałem o wyborze zakupu NVIDIA. Wybrano NVIDIA to teraz brną w CUDA, bo NVIDIA nie potrafi lub nie chce zając się OCL. Galimatias ze sterownikami AMD na Linuxie na pewno przyczynił się do tego stanu. Oczywiście można krytykować posunięcia AMD, jest w tym wiele racji, ale z drugiej strony wynikły z tego pozytywne zmiany... Wydajność miała mniejsze przełożenie na OCL i użytkowe programy OGL, które same w sobie nie korzystają zbyt wydajnie z OGL, a raczej na same gry wykorzystujące najdrobniejsze fiuczerki plus słaba jakość zamkniętych frameworków do gier dla linuxa.

 

ak to klaster isnt. Maxa-Plancka ma 600 K20

 

Ehe, ale co to ma do rzeczy ?. Pojechałeś z większym poborem energii w ślepą uliczkę, bo w top green hpc na 1 miejscu (4 właściwie, ale 1 z GPU) jest AMD FirePro S9150 :), a na 1 miejscu już w top500 nie są ani Intele, ani AMD, tylko chiński Sunway oparty o arch. DEC Alpha (Alpha powróciła, jest PPC i SPARC, szykuje się powrót MIPS - też Chiny, bo Chińczycy wygaszają Tianhe-2, w ogóle rezygnują z amerykańskich procków, podobnie jak w Rosji itd... Rozbawił mnie superkomputer w Arabii poz. 10, do czego, do liczenia przydziału dziewic dla wahabistów :D. Nas grafików to nie dotyczy, więc prawdę mówiąc to już bujanie w obłokach! :). Jedno jest pewne, jak wyjdzie AMD Zen, w połączeniu z AMD RX4xx będzie w top green cash, jeżeli AMD Zen 8 core będzie faktycznie za ok. 1000 zł :).

 

Panowie po prostu optymalizują, mierzą i wiedzą czy wektoryzacja i szerokie rejestry są opłacalne czy nie - dla niech. To jednak różnica niż analiza typu: "ludzie kupią bo są idiotami

 

Ehe, według mnie analiza kończy się na tym właśnie "ludzie kupią itd., i od kiedy pamiętam tak jest z tymi panami; "kasa misiu, kasa... :).

Wąskim gardłem procesorów to są opóźnienia, poszerzyć rejestry można zawsze, pakować 2x tyle danych, ale 2x dłużej, więc co to da ?. Nie bez powodu najbardziej optymalne są jednak rejestry 128bit na AMD64 i Intelx86. Przyspieszać można na wiele sposobów, niekoniecznie poszerzając rejestr i na nowo przepisując kod programu. Poszerzanie rejestru nie jest panaceum, choć w syntetykach na pewno pokazałoby pazur ku pokrzepieniu serc zwolenników takiej drogi. Pamiętaj jedno!, podkreślam to, bo wielu wpada w pułapkę, a z Twoją wiedzą inżynieryjną jest wg. mnie bardzo krucho, że to co widzisz jako rejestr AMD64 x86 nie jest fizycznym rejestrem procesora!, bo fizycznie procesor operuje na zupełnie innych rejestrach.

 

Maciek Jutrzenka:

 

yyy tylko dlaczego developerzy luxrendera przyznali mi racje

 

Przyznali rację, bo może wykryłeś buga, ale lepsze to niż usłyszeć, że czepiam się, bo przecież nie może być lepiej, a poza tym darowanemu koniowi to się w zęby nie zagląda tylko bierze i nie marudzi itd. :). Akceleracja GPU na lux jest stabilna, albo stabilniejsza, na karcie AMD. Osobiście używam dwóch GPU, na laptopie mam IntelHD, na stacjonarce AMD GCN. Na IntelHD miewam dużo większe problemy i zostaje CPU, choć to samo na AMD GPU rusza bez zająknięcia, a problemem nie jest brak pamięci.

Edited by materalia

Share this post


Link to post
Share on other sites

człowieku. Luxrender nie jest stabilny, ile razy mam ci to pisać sami developerzy potwierdzili me słowa. a ty piszesz jakieś głupoty. Ty mi piszesz że akceleracja jest stabilna. Jak ja na samym CPU miałem problemy a na akceleracji to już w ogóle... Luxrender to jest eksperymentalny render w pełni i kazdy o tym wie.

 

luxrender nie dawał rady gdy zrobiłem jakieś 30% sceny. a cycles jednak bez zająknięcia wszystko bez problemu renderuje zarówno na CPU jak i GPU nie miałem problemów. dill with it.

Share this post


Link to post
Share on other sites

A karty AMD nadal slabsze... XD

 

Ale za to zblizajacy sie procek Zen wydaje sie ciekawa alternatywa dla prockow intela - moze cos o tym napisza znawcy tematu, bo zapowiada sie interesujaco a przy tym, znajac AMDka nie bedzie kosztowal 1k+.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

We are using cookies. Read about our Privacy Policy