SYmek Napisano 18 Sierpień 2016 Napisano 18 Sierpień 2016 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.
Nezumi Napisano 18 Sierpień 2016 Napisano 18 Sierpień 2016 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
Imperator Napisano 18 Sierpień 2016 Napisano 18 Sierpień 2016 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
olaf Napisano 18 Sierpień 2016 Napisano 18 Sierpień 2016 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.
SYmek Napisano 18 Sierpień 2016 Napisano 18 Sierpień 2016 (edytowane) 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. Edytowane 18 Sierpień 2016 przez SYmek
rice Napisano 18 Sierpień 2016 Napisano 18 Sierpień 2016 https://mobile.twitter.com/tonroosendaal/status/765580276974153729 Zaraz bedziemy mieli pelne wsparcie w cyclesie ;)
legomir Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 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?
materalia Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 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!.
SYmek Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 (edytowane) 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ą). Edytowane 19 Sierpień 2016 przez SYmek
materalia Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 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!.
Maciek Jutrzenka Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 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ć :(
rice Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 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.
materalia Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 Ś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. 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ą :).
michalo Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 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 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
Maciek Jutrzenka Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 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.
materalia Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 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ć :)
SYmek Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 (edytowane) 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. Edytowane 19 Sierpień 2016 przez SYmek
Imperator Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 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ć :)
Maciek Jutrzenka Napisano 19 Sierpień 2016 Napisano 19 Sierpień 2016 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.
materalia Napisano 20 Sierpień 2016 Napisano 20 Sierpień 2016 (edytowane) 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ń. Edytowane 20 Sierpień 2016 przez materalia
SYmek Napisano 20 Sierpień 2016 Napisano 20 Sierpień 2016 (edytowane) 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. Edytowane 20 Sierpień 2016 przez SYmek
Maciek Jutrzenka Napisano 20 Sierpień 2016 Napisano 20 Sierpień 2016 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.
materalia Napisano 20 Sierpień 2016 Napisano 20 Sierpień 2016 (edytowane) 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. Edytowane 20 Sierpień 2016 przez materalia
Maciek Jutrzenka Napisano 20 Sierpień 2016 Napisano 20 Sierpień 2016 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.
Nezumi Napisano 20 Sierpień 2016 Napisano 20 Sierpień 2016 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+.
SYmek Napisano 20 Sierpień 2016 Napisano 20 Sierpień 2016 (edytowane) Czyli potwierdzają oczywistość :). Nie trzeba czytać instrukcji Intela żeby też to odkryć Sam wcześniej temu przeczyłeś, rozumiem, że dla sportu... połowa Twojej wypowiedzi to trywialne fakty (co jest wąskim gardłem procesora na przykład), które nijak mają się do moich argumentów. Wkładasz mi też w usta rzeczy, których nie powiedziałem a potem z nimi polemizujesz. Rozumiem, że jakoś niedawno dowiedziałeś się, że wektoryzacja nie jest jedyną metodą optymalizacji i chciałeś się tą wiedzą podzielić. No dziękuję, jakoś do mnie dotarło wcześniej. No i nadal nie rozumiesz co to jest i co zmienia PBR. Gdybyś rozumiał, wiedziałbyś, co daje Kowalskiemu, ba nawet Tobie, i dlaczego nie dało się tego robić praktycznie jeszcze kilka lat temu. Zachęcam jednak do lektury. Za informację o top green dziękuję, przeczytam, choć to jeszcze gorsza wiadomość dla AMD, bo jeśli nie chodzi o prąd, to dlaczego tak sobie słabo radzą w HPC.. TINA nie jednemu założyła klapki na oczy :). Proszę, podaj mi alternatywę. Stawiam butelkę dobrego wina (albo co tam sobie chcesz). Ale jeśli jej nie znajdziesz, to zachowaj się jak dorosły człowiek i przyznaj, że alternatywy nie ma. Edytowane 20 Sierpień 2016 przez SYmek
materalia Napisano 20 Sierpień 2016 Napisano 20 Sierpień 2016 (edytowane) Maciek Jutrzenka: Cycles nie jest eksperymentalny i nigdy się nie wiesza, tak jak Blender ? hehe:). Dla mnie najstabilniejszym programem w jakim pracowałem i nadal jeszcze czasami pracuje jest Cinema4D, o Blenderze tego nie powiem, o Cyclesie tym bardziej, bo wywalał mi stery na GPU NVIDIA, albo tak zamulał, że nic nie dało rady zrobić. Nie wiem jaką scenę tam robiłeś w lux, bo to trzeba na konkretnym przykładzie pokazać, bo jednak sceny do luxa nie robi się tak jak do cyclesa. Osobiście nie mam takich problemów trzymając się zasad... Nie mam na tym forum zaufania do fanbojów NVIDI psioczących na AMD od kiedy ktoś mi tu wmawiał jakieś bugi w Mayce na Radeonie (TeraScale 3), bugów tych nie dało się powtórzyć dokładnie na tym samym sprzęcie, bo specjalnie sprawdziłem w praktyce na Mayce, choć Mayki nie używam, dokładnie wg. podanej instrukcji. Twoja opowieść jest równie bardzo wzruszająca, jak to próbowałeś, nie wyszło, więc jest bee. Na marginesie, to żaden developer nie nazwie swojego programu w pełni stabilnym, będąc uczciwym, co innego sprzedawca:). Nezumi: A karty AMD nadal slabsze... XD Silniejsze znaczy słabsze ;). http://www.hardwareluxx.de/index.php/artikel/hardware/grafikkarten/39889-powercolor-radeon-rx-480-red-devil-im-test.html?start=6 luxmarki 3.0 - im więcej tym lepiej: RX 480 - 14643 GTX 970 - 10971 GTX 1060 - 11093 cenowo odpowiadające modele;) cenowo 2x droższy GTX 980Ti - 15311 hehe:), ogólnie lepiej z NVIDIA niż w czasach HD7970, ale kasku nie zrywa. procek Zen wydaje sie ciekawa alternatywa dla prockow intela AMD Zen raczej nie dorówna Skylake w pojedyńczym wątku, przynajmniej Zen gen1, zakładając tak jak podaje AMD +40% na IPC, ale będzie miał na podstawowej podstawce AM4 maks. 8 rdzeni (16wątków), podstawce dla kilku generacji Zen!, podczas gdy Intele mają maks. 4 rdzenie (8wątków) na podstawce 1151, więc w wielowątkowych aplikacjach będzie o niebo wydajniejszy, także w grach powinien (8rdzeni nie jest równe 8 wątkom, gry optymalizuje się teraz na 8 >konsole wyznaczają trend), oczywiście DDR4 itd. Testowane już są, a niedługo dostępne w sklepach, może nawet pod koniec roku, chociaż ceny ustabilizują się dopiero po kilku miesiącach. Intel pewnie zostanie zmuszony wydać kolejną podstawkę, ale będzie płacz, znów zmiana prawie całego kompa hehe:) SYmek: które nijak mają się do moich argumentów Ale jakich argumentów, o 512bit rejestrach ?. Kręcisz się w koło tych rejestrów jak kołowrotek, jakby to było cudowne rozwiązanie, święty cudowny graal do nieskończonego wzrostu wydajności CPU, nic tylko poszerzać rejestry i wektoryzować kod he:) . Przypomniałem tylko, że procesor to nie tylko rejestry, zresztą nawet owe rejestry AMD64/Intelx86 są jedynie wirtualne, o czym pewnie nie wiedziałeś, bo byś tak kurczowo nie trzymał tych argumentów. Wiele lat temu pojawił się AVX potem AVX2.0, a liczba programów używających tego zbioru jest nadal znikoma. Z rendererów najlepiej robi to Embree, wiem, bo używam Embree, to nawet wtedy słychać na wiatrakach :) przeczytam, choć to jeszcze gorsza wiadomość dla AMD, bo jeśli nie chodzi o prąd, to dlaczego tak sobie słabo radzą w HPC HPC to naprawdę bujanie w obłokach i nie ma sensu o tym tu dyskutować, bo to czystej wody demagogia. Top supercomputer to zupełnie inny świat. No i nadal nie rozumiesz co to jest i co zmienia PBR. Gdybyś rozumiał, wiedziałbyś, co daje Kowalskiemu, ba nawet Tobie, i dlaczego nie dało się tego robić praktycznie jeszcze kilka lat temu. Zachęcam jednak do lektury. Nie będę powtarzał się kolejny raz, więc krótko. PBR to taki nowy krzykliwy termin, jest to nowa jakość, ale głównie w RT (tzw. silnikach czasu rzeczywistego), bo sprzęt (GPU) ma już taką moc przerobową... i można pokusić się o dokładniejsze przybliżenie do fotorealizmu, ale w std. silnikach renderujących zewnętrznych i wbudowanych w popularne softy (nawet b. starych wersjach), nie wprowadza niczego takiego co nie było już wcześniej używane, bo w tym przypadku nie jest to nic nowego, tylko inne spojrzenie na to co jest od dawna. Proszę, podaj mi alternatywę. Stawiam butelkę dobrego wina (albo co tam sobie chcesz). Ale jeśli jej nie znajdziesz, to zachowaj się jak dorosły człowiek i przyznaj, że alternatywy nie ma. Nie używam tego Redshita, nie wiem nawet do czego miałby być dla mnie alternatywą i w czym miałby być alternatywą, od tego zacznijmy, więc nie pomogę. Mamy inne potrzeby, nie znaczy gorsze lub lepsze, po prostu inne, a jak wiesz, nie ma rozwiązań idealnie uniwersalnych. Silników renderujących jest tyle teraz, że już od dawna tego wszystkiego nie śledzę, bo mi się nawet nie chce, a większość zdecydowana to właściwie ten sam model, tylko lepiej lub gorzej zrobiony itp. Edytowane 20 Sierpień 2016 przez materalia
SYmek Napisano 21 Sierpień 2016 Napisano 21 Sierpień 2016 (edytowane) Ale jakich argumentów, o 512bit rejestrach ?. Kręcisz się w koło tych rejestrów jak kołowrotek, jakby to było cudowne rozwiązanie, (...) Chodzi właśnie o to, że nigdzie tego nie powiedziałem. Ty zaprzeczyłeś, że użycie AVX zwalnia taktowanie procesora, a kiedy powołałem się na źródło, powiedziałeś że to oczywiste, żeby chwilę później zarzucić mi braki w wiedzy inżynierskiej (które zresztą posiadam, jako że nie jestem inżynierem). Brawo, zajebista logika. Nie będę powtarzał się kolejny raz, więc krótko. PBR to taki nowy krzykliwy termin, jest to nowa jakość, ale głównie w RT *...( Nie masz pojęcia o renderowaniu. I dobrze, nikt nie wie wszystkiego, ja na pewno, ale jak ktoś prowadzi wśród grafików rozmową w sposób taki, że argumentów strony przeciwnej nie chce mu się nawet zrozumieć, tylko wali k*** nad klawiaturą, to oczekiwałoby się większego rozeznania w temacie. PBR nie ma nic wspólnego z silnikami realtime. Termin został przez nie zapożyczony ze świata offlinowego renderingu (nie real-time). Jest raczej nieostrym określeniem zmiany paradygmatu w algorytmach, w którym fizyczne zachowanie światła i powierzchni stanowi podstawę modelowania algorytmu. Koniec. Staramy się liczyć całkę równania renderowania w taki sposób, żeby energia nie ginęła ani nie pojawiała się znikąd, używamy terminów z radiometrii, oraz staramy się poprawnie modelować właściwości powierzchni, co w większości przypadków oznacza rezygnację z analitycznych modeli cieniowania na rzecz modeli empirycznych lub fenomenologicznych (stąd przejście ze starego dobrego Phonga na BBX w większości nowoczesnych rendererów, pojawienie się prawa Fresnela w każdej interakcji, a nie tylko refrakcji itd itd, zabawy z polaryzacją, modelem spektralnym etc). Krótko mówiąc staramy się, żeby algorytm był motywowany fizyką światła. Nie znaczy to nic konkretnego, ale kiedy w literaturze pojawia się termin PBR po Arnoldzie, Rendermanie, Mantrze, znaczy to właśnie to. A kiedy pojawia się w kontekście silników realtime, znaczy to, że silniki te aspirują w ramach swoich możliwości do podobnych rozwiązań (czyli zamiast chamskiej pętli lamberta i phonga po światłach, samplują otoczenie wewnątrz jakiegoś modelu micro-faced). Jak się rozumie, co PBR znaczy i skąd się wziął, wie się że kilka lat temu nie było to możliwe, bo wie się, co jest potrzebne, żeby zsamplować światło na umotywowanym fizycznie modelu powierzchni), Nie używam tego Redshita, nie wiem nawet do czego miałby być dla mnie alternatywą i w czym miałby być alternatywą, od tego zacznijmy, więc nie pomogę. Mamy inne potrzeby, nie znaczy gorsze lub lepsze, po prostu inne, a jak wiesz, nie ma rozwiązań idealnie uniwersalnych. Silników renderujących jest tyle teraz, że już od dawna tego wszystkiego nie śledzę, bo mi się nawet nie chce, a większość zdecydowana to właściwie ten sam model, tylko lepiej lub gorzej zrobiony itp Jasne, że nie pomożesz, ale zdanie masz, i tupet, żeby w publicznej dyskusji gadać głupoty na tematy, o których nie masz pojęcia. Zamiast zapytać, dlaczego Redshift jest dla ludzi w mojej branży jedynym rendererem GPU wartym uwagi, wolisz napisać, że jestem zaślepiony, bo Redshift jest na wrednym Cuda. Wychodzi na to, że nie masz pojęcia, jakie zalety lub wady OpenCL może mieć dla rendererów, bo za mało o nich wiesz. Ot gównarzeria. Edytowane 21 Sierpień 2016 przez SYmek
Nezumi Napisano 21 Sierpień 2016 Napisano 21 Sierpień 2016 @materalia - kiedy mowie ze AMD ma slabsze karty mam na mysli ze nie ma na rynku niczego co pobiloby flagowe karty NV. 480ka przegrywa z 1070,1080 i TitanX. Pomijam specjalistyczne Quadro za grube tysiace dolcow. Wygrywa z najslabsza karta NV z serii 10... Ciezko to uznac za sukces niestety. Na dzien dzisiejszy nie znajdziesz niczego od AMDka co moznaby juz kupic i co byloby lepsze od flagowcow NV. Zwyczajnie nie wyprodukowali jeszcze takich kart i nie wiem po co dyskutowac z faktami. Jest jak jest - oby bylo lepiej. Cena zawsze byla mocna strona AMD, licze na to ze ZEN pokaze pazur bo nawet jesli nie bedzie lepszy od najlepszego procka intela to niemal na pewno bedzie duzo tanszy oferujac mimo wszystko swietna wydajnosc. Na najlepszy procek intela nie wywale tyle kasy, na niemal rownie dobry AMDka juz moglbym uzbierac. I tak bylby sporo lepszy od tego co mam :D Zen raczej w tym roku nie wyjdzie - cos slyszalem o poczatku nastepnego (mowie o dostepnosci w sklepach). Na procek AMDka moge poczekac, ale karte niebawem kupie z NV. Nawet jesli pokaze sie cos sensownego to wciaz bede potrzebowal CUDA do Cyclesa. Moze jak ogarna OpenCL w Blenderze ale to za rok dopiero. Szmat czasu i jedna wielka niewiadoma. A NV przez ten rok tez nie bedzie siedziec i nic nie robic.
materalia Napisano 22 Sierpień 2016 Napisano 22 Sierpień 2016 (edytowane) @Nezumi Do PRO są karty AMD FirePro, mimo wszystko R9 390X/Fury (4GB/8GB) nie ustępuje GTX980Ti 6GB, będąc tańszą, w porównaniu do niedawna najmocniejszej "nieprofesjonalnej karcie" NV. Można więc domyśleć się, że Polaris w wersji FirePro zostawi kiszowatego Maxwella w tyle w PRO zastosowaniach (sama możliwość dodawania pamięci to też jest niezła myśl, AMD znów pierwsze), a w PRO liczy się nie tylko single, ale także double itd. Inna sprawa, że NVIDIA jest 2 lata do tyłu w kwestii HBM, nie wspomnę o jednostkach ACE, czy wspomnianym łączeniu wielu kart lub chipów. Porównanie najsłabszych: RX460 500zł odpowiada GTX950 650zł, chociaż przy dobrej opt. na AMD, gra Hitman, miażdzy GTX950 :). Najtańszy RX480 4GB kosztuje 1000 zł (z 3x wydajniejsza, 2x więcej RAM). Wynik o tyle ciekawy, że RX460 jest także przeznaczony w niezmienionej postaci do mocnych laptopów z średniej półki :) I jeszcze ciekawostka dt. AMD Zen; Zen w teście Blender wygrywa nieznacznie z Broadwel-E, ten sam zegar. http://www.purepc.pl/procesory/amd_zen_wygrywa_z_intelem_w_wielowatkowym_tescie_blender Najzabawniejsze w tym wszystko jest jedno, że AMD jest naprawdę malutką firmą, robi tak wiele; udane CPU, APU, GPU..., tyle innowacji wprowadziła, ale hejterzy zielonych i niebieskich nie mogą tego przeżyć hehe... Cóż, AMD nawet u szczytu nie mogłaby skoczyć Intelowi w posiadaniu rynku: http://www.dailytech.com/Intel+Wipes+Out+AMDs+2006+Marketshare+Gains+in+One+Quarter/article7051.htm SYmek: Chodzi właśnie o to, że nigdzie tego nie powiedziałem. Ty zaprzeczyłeś, że użycie AVX zwalnia taktowanie procesora ja zaprzeczałem, chyba nie umiesz czytać ze zrozumieniem, albo mój polski wymaga poprawy, co nie jest wykluczone :) Nie masz pojęcia o renderowaniu. I dobrze, nikt nie wie wszystkiego ehe, a Ty nie masz pojęcia o algorytmach grafiki, co dowiodłeś przy okazji pathtracera kilka postów temu, jak napisałem, że to prosty alg. i średni student to napisze z mojej uczelni, mojego kierunku..., jednak dla Ciebie ten prosty jest zbyt skomplikowany, a rzucasz teraz takimi terminami, chcesz udawać mądrzejszego niż jesteś hehe:), a ja myślę, że nie masz o tym pojęcia w tym kontekście jak próbujesz błyszczeć, masz oczywiście pojęcie o renderowaniu jako grafik, w sensie użycia, bo grafik to jednak artysta ma być, a nie technik, i do tego nie jest potrzebna taka wiedza, ale od strony matematycznej lub programistycznej praktycznie nie masz. Wszystkie terminy wcale nie są takie nowe, niektóre bardzo stare, czyli jak tam napisałeś na początku; PBR jest to paradygmat. Mówiąc krótko. Mając język opisu materiału oparty na np: prostych węzłach, plus niezbędne cegiełki...(niezbędne są od dawna) uzyskasz PBR, a renderujesz na czymkolwiek dowolną metodą. Czy da to zawsze lepszy od oczekiwanego rezultat, zależy co robisz... bo w gruncie rzeczy jest to tylko przybliżenie. Najbardziej korzysta na tym RT dzięki wykorzystaniu mocy przerobowej współczesnych GPU (jednostki shader) pozwala uzyskać o wiele lepsze efekty niż wcześniej (brak jednostek shader lub dużo słabsze jednostki shader na których realizowane zazwyczaj bardzo krótkie programy dodające pojedynczą lub kilka prostych właściwości). Zamiast zapytać, dlaczego Redshift jest dla ludzi w mojej branży jedynym rendererem GPU wartym uwagi, wolisz napisać, że jestem zaślepiony, bo Redshift jest na wrednym Cuda. Co mnie interesuje branża. Dla mnie Redshit z pierwszych dwóch powodów jest niewarty uwagi. Pierwszy. Cena, zbyt zaporowa. Drugi. NV CUDA. Trzeci. Nie integruje się chyba z żadnym używanym przeze mnie softem. Czwarte. Pathtracera już mam za friko :). Piąte. Ma ponoć być dla OCL, ale z uwagi na kilka pkt. wcześniej, jakoś nie widzę potrzeby. Pisanie o tym, że się nie da w OCL to idiotyzmy tych co nie mają zielonego pojęcia o programowaniu GPGPU. Karty AMD i NV oferują obecnie dokładnie takie same możliwości implementacji tych samych algorytmów liczących na poziomie GPU - wybór API CUDA to wynik badań marketingu (pomijając praktyki NV dt. rozwoju OCL), przy czym OCL oferuje większe możliwości od 2.x, dzięki zgodności z modelem HSA, który jednak jest bardzo przyszłościowym podejściem. O tym jak dziwaczne i beznadziejne jest CUDA pokazują przypadki nie funkcjonowania starszych silników na kolejnych kartach NV vide Cycles i GTX Pascal... Wiesz lub nie wiesz, prędzej nie wiesz produkując swoje farmazony o OCL, ale na OCL zrealizujesz każdy nawet najbardziej skomplikowany algorytm liczący, tylko może nie ruszyć na obecnej gen. GPU czy FPGA, może na przyszłej..., a jedynie samym CPU lub tylko w ogr. zakresie na GPU, wybór następuje w momencie uruchomienia, a nawet już automatycznie na etapie wykonywania w OCL >2. Mówiąc krótko, na OCL możesz napisać wszystko, bo wszystko ruszy na CPU. Edytowane 22 Sierpień 2016 przez materalia
SYmek Napisano 23 Sierpień 2016 Napisano 23 Sierpień 2016 (edytowane) a Ty nie masz pojęcia o algorytmach grafiki, co dowiodłeś przy okazji pathtracera kilka postów temu, jak napisałem, że to prosty alg. i średni student to napisze z mojej uczelni, mojego kierunku..., Argument o tyle nietrafiony, że kilka postów wyżej od Ciebie sam napisałem, że path tracing można zaimplementować w 100 linijkach kodu, sam to zrobiłem 10 lat temu, jak większość moich kolegów napaleńców. Z tego, co piszesz wnioskuję że znasz się na hardwarze, masz masę ciekawych informacji, ale nie masz pojęcia, co to jest nowoczesny renderer, nie wiem, po co się wymądrzasz. Brzmisz, jak człowiek, który twierdzi, że zna się a programowaniu, ale nie wie, co to jest kompilator. Odpuść sobie. Twoja ocena mojej wiedzy jest mało umotywowana, ani się na tym znasz, ani nie pokazałeś mi, gdzie się mylę (a nawet jeśli gdzieś się mylę, wezmę to na klatę, a nie, Twoim zwyczajem, zmienię temat). Edytowane 23 Sierpień 2016 przez SYmek
Kroopson Napisano 23 Sierpień 2016 Napisano 23 Sierpień 2016 Symek - coś czuję że jesteś na urlopie skoro chce Ci się o tym dyskutować :D
deshu Napisano 23 Sierpień 2016 Napisano 23 Sierpień 2016 Skoro już gadamy o mitach, to gdzie można kupić RX480 za 1200zł?
wujek_kane Napisano 23 Sierpień 2016 Napisano 23 Sierpień 2016 Skoro już gadamy o mitach, to gdzie można kupić RX480 za 1200zł? Wszędzie, tylko nie w Polsce.
SYmek Napisano 23 Sierpień 2016 Napisano 23 Sierpień 2016 Symek - coś czuję że jesteś na urlopie skoro chce Ci się o tym dyskutować :D Nie wakacje, ale faktycznie siedzę przy grubiej sprawie i prokrastynuję :)
ptaszek Napisano 24 Sierpień 2016 Napisano 24 Sierpień 2016 Chyba nie było :)) [video=youtube_share;u5YJsMaT_AE]
deshu Napisano 24 Sierpień 2016 Napisano 24 Sierpień 2016 Właśnie sprzedałem swoją starą gtx580, mniej wiecej tak brzmiała gdy odpaliłem octane:P
materalia Napisano 24 Sierpień 2016 Napisano 24 Sierpień 2016 Skoro już gadamy o mitach, to gdzie można kupić RX480 za 1200zł? RX480 4GB - od 999 zł http://www.ceneo.pl/45277277 RX480 8GB - od 1229 zł http://www.ceneo.pl/45277254 5 sekund szukania, skoro mowa o mitach. Vulkan DOOM, to jest nowość :) A GTX 1070 kosztuje uuuu, dużoooo, blisko 2x więcej niż RX 480, nawet GTX1060 jest wyraźnie droższy hehe:). I kto tu jest frajerem. Nie mówiąc o tym, że CUDA nie działa w renderowaniu, jeszcze do 2017 nie podziała hehe, renderujecie na CPU, czy wcale vide Octane hehe, u bo u mnie na OCL w RX480 no problem od pierwszego rozruchu. Ciekaowstką jest popatrzeć na obciążenie CPU, a ponoć na AMD miało się zatykać CPU hehe, kolejne mity fachmanów od testów sponsorowanych przez niebieskich i zielonych.
Nezumi Napisano 24 Sierpień 2016 Napisano 24 Sierpień 2016 I kto tu jest frajerem. Nie mówiąc o tym, że CUDA nie działa w renderowaniu, jeszcze do 2017 nie podziała hehe Ups... :
rice Napisano 24 Sierpień 2016 Napisano 24 Sierpień 2016 oba linki co podałeś "Aktualnie brak ofert tego produktu"
materalia Napisano 24 Sierpień 2016 Napisano 24 Sierpień 2016 To jest właśnie hejterstwo, robić z kogoś kto wybiera AMD frustrata itp., rozumiem, że ten obrazek z materiałów opłacanego hejtera i fanboya NV :), a jeszcze jak ktoś pokaże, że AMD jest lepsze i jeszcze tańsze, to dopiero straszne, wtedy trzeba atakować ad personam itp. Akurat NVIDIA robi słabsze GPU od AMD, od wielu lat, to NVIDIA goni AMD, dok. goni GCN, ale nadrabia zamkniętą technologią CUDA, to tak jak z DX/OGL i Mantle, kto by chciał żeby taką popularność zdobyło Mantle, bo ja nie, chociaż uzyskuje się lepsze rezultaty, nie byłoby DX12 i Vulkana, tylko byłoby Mantle only AMD, tak jak CUDA only NV. Kto byłby górą pokazują testy, ale chyba nie o takie górowanie w tym chodzi. Na szczęście AMD to nie kiszkowate NVIDIA, które należy fakować za to zamykanie wszystkiego. Vulkan to właśnie takie otwarte Mantle dla wszystkich, podobnie jak DX12. https://en.wikipedia.org/wiki/Vulkan_(API)
Maciek Jutrzenka Napisano 24 Sierpień 2016 Napisano 24 Sierpień 2016 oh stary... zrozum w końcu że... liczy się to czego można użyć.. a nie to co jest na papierze... :) Co z tego że dajmy na to karty AMD są szybsze lepsze i wogóle awesome. skoro niemogę jej użyć. bo aplikacje są napisane na Cude... Liczy się użyteczność a nie specyfikacja.
Monio Napisano 24 Sierpień 2016 Napisano 24 Sierpień 2016 oba linki co podałeś "Aktualnie brak ofert tego produktu" Ty hejterze! :D
materalia Napisano 25 Sierpień 2016 Napisano 25 Sierpień 2016 @Maciek Jutrzenka Co z tego że dajmy na to karty AMD są szybsze lepsze i wogóle awesome. skoro niemogę jej użyć. bo aplikacje są napisane na Cude... Dlatego takie aplikacje wrzucam do kosza, dla zasady, co to za pisanie aplikacji pod jeden sprzęt jednego producenta. Dziwi mnie trwała integracja Blendera z Cycles GPU only NV, a właściwie to zniechęca bardziej niż cokolwiek. Nie powinno mieć to miejsca. Co by było gdyby viewport Blendera chodził tylko na Mantle, wyobrażasz takie coś sobie w otwartym sofcie, bo ja nie. Co do softów własnościowych to sprawa producentów, widocznie mają takie umowy z NVIDIA. bo aplikacje są napisane na Cude... Kiedyś liczyłem aplikacje CUDA, wiele tego nie wyszło, użytecznych lub niezastąpionych jeszcze mniej, dla używających, bo całe to GPGPU jest jednak nieco przereklamowane. Oczywiście jak ktoś związał się na stałe z Octane lub Cycles GPU to siłą rzeczy kupi NVIDIA dla świętego spokoju, ale w pozostałych przypadkach to jakoś nie widzę sensu przepłacać za logo NVIDIA GeForce, bo użyteczność jest taka sama na AMD Radeon i innych tj. OGL (bez jakiś spec. wymagań). Tak jak w moim przypadku. Czy są alternatywy, były i są zawsze. Nie jestem specjalnie związany z silnikami renderującymi GPU, są tylko kolejną opcją, niekoniecznie najlepszą. Blender nie jest też jeszcze moim podstawowym softem, dopiero go poznaje, a Luxrender podstawowym silnikiem renderującym. W życiu używa się tego co zna się najlepiej, a nie od wczoraj, roku i lat tym się zajmuje. Prawdę powiedziawszy to Cycles nie bardzo podoba mi się plastycznie, choćby z tego powodu nie jestem zainteresowany tym silnikiem. @rice oba linki co podałeś "Aktualnie brak ofert tego produktu" Były i znikły, proste. Obecnie najtańsza 8GB jest za 1299, a wersji 4GB to nie ma już chyba żadnej w sklepie. Poczekaj chwilę jak się nasycą rynki ważniejsze i wrócą do Polski.
deshu Napisano 27 Sierpień 2016 Napisano 27 Sierpień 2016 Były i znikły, proste. Obecnie najtańsza 8GB jest za 1299, a wersji 4GB to nie ma już chyba żadnej w sklepie. Poczekaj chwilę jak się nasycą rynki ważniejsze i wrócą do Polski. Nie, nie proste. Nie było momentu w którym dało się te karty kupić w Polsce, a ceny które tu widzisz to przewidywania sprzed premiery. Nie wierze, że te ceny się utrzymają po faktycznej premierze.
materalia Napisano 28 Sierpień 2016 Napisano 28 Sierpień 2016 Nie, nie proste. Nie było momentu w którym dało się te karty kupić w Polsce, a ceny które tu widzisz to przewidywania sprzed premiery. Nie wierze, że te ceny się utrzymają po faktycznej premierze. Ja kupiłem RX480 8GB za 1219 zł od sztuki, ale kupiłem od razu 15 sztuk do renderfarm. Obecnie najtańszą kartą 8GB nie jest RX 480 tylko RX 470, kompletnie zapomniałem o RX 470, który jest niemal tym samym co RX480 (ma mniejsze taktowanie, wyłączony jeden unit, ale nadal 8GB!), a kosztuje poniżej 1200 zł, teraz 1176 zł, tu moim zdaniem jest mniejsza przebitka niż na RX480 np: http://proline.pl/?p=MSI+RX+470+GAMING+X+8G&utm_source=ceneo.pl&utm_medium=cpc&utm_campaign=ceneo_polecane https://www.net-s.pl/index.php?id=3&c=608&g=653984&n=Karta-graficzna-MSI-Radeon-RX-470-Gaming-X-8G-8192-MB-GDDR5&w=c Z doświadczenia wiem, że lepiej kupić kartę RX 470 8GB niż troszkę wydajniejszą RX 480 lecz 4GB do GPGPU. Pamięć jest naprawdę kluczową sprawą, bo najczęściej jej brak powoduje przerzucenie obliczeń na wolniejsze zazwyczaj CPU w pathtracingu, dlatego dziwi mnie jak ktoś poleca np: GTX970 4GB (3.5GB w real speed) jeszcze pół roku temu, kartę droższą o dziwo, takie wymagania do GPGPU to były dobre w czasach HD7970 3GB, czyli kilka lat temu.
rice Napisano 28 Sierpień 2016 Napisano 28 Sierpień 2016 "Ja kupiłem RX480 8GB za 1219 zł od sztuki, ale kupiłem od razu 15 sztuk " masz rozmach ;) gadasz jak dzieciak a tu proszę 15 kart. Daj jakiegoś linka do swoich prac, jestem ciekaw czym Ty się tak właściwie zajmujesz. Rx480 faktycznie pod vulcanem to bardzo dobra karta. Chociaz z tego co kojarze nvidia zablokowala asynchroniczne obliczenia wiec nie do konca mozna uczciwie porownac radeony z geforcami.
Nezumi Napisano 28 Sierpień 2016 Napisano 28 Sierpień 2016 No i juz wiadomo dlaczego nie ma tych kart - materalia wykupil.
Rekomendowane odpowiedzi
Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto
Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.
Zarejestruj nowe konto
Załóż nowe konto. To bardzo proste!
Zarejestruj sięZaloguj się
Posiadasz już konto? Zaloguj się poniżej.
Zaloguj się