materalia

Nic na to nie poradzę, że studiowałeś rolnictwo ;). Nie bierz tego do siebie. http://www.kevinbeason.com/smallpt/ ehe, to ciekawe czemu w syntetykach takich jak linx/intelburntest dogrzewa się procki dopiero na AVX, a nie na SSE 128bit ?:) 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ą. 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 ?:) 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. 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ą :).

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!.

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. 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!.

Bredzisz jak typowy śmieszny zielony ujadacz na AMD gdzie tylko pojawi się jakikolwiek news AMD, odmawiając nawet prawa AMD od podkręcania marketingu, podczas gdy NVIDIA ściemnia na maksa..., zupełnie ignorujesz fakt, że jednak AMD wyprzedza już o epokę NVIDIA w konstrukcji GPU > kolejne gen. (już 4) GCN vide Fermi,Kepler,Maxwell,Pascal prawie na jedno kopyto. Jeżeli AMD już coś tam pokazało to tylko to, że gra zoptymalizowana pod Crossfire/SLI (DX12) uzyskuje widoczny wzrost fps, biorąc pod uwagę fakt, że niezoptymalizowane gry nad dwóch kartach często mogą działać nawet wolniej niż na jednej karcie to jest bez wątpienia jakiś krok do przodu :). Wniosków rozumnych nie nauczyłeś się wyciągać, bo masz zielone bryle na ślepiach i wszystko widzisz w kategoriach NVIDIA vs AMD, a AMD tylko próbuje popchnąć temat łączenia kart w DX/OGL do przodu, w odróżeniu od NV, dla nich temat prawie nie istnieje!, potem go odkryją jak AMD już przetrze drogę, tak jak z HBM, choć nie są na to gotowi itp. hehe... Powtórzę raz jeszcze, że RX480 8GB nie jest odpowiednikiem GTX1080 8GB, a fanbojem jesteś NV, choć się tego wypierasz, a ja przynajmniej nie ukrywam swojej sympatii do AMD, bo firma wniosła ogromny wkład do świata PC, w stosunku do swojej wartości rynkowej itp... AMD od dawna wydaje godne uwagi karty bijące na głowę jakością do ceny produkty NVIDIA i nie bawi się w ściemy jak zapowiedzi dt. Pascala co miał być 10x wydajniejszy od Maxwella i w ogóle GCN miało leżeć na łopatkach, a nie są nawet na poziomie gen.1, a jak pisałem, że NVIDIA nie stać na zaprojektowanie czegoś nowego, skoro marketingiem wcisną każdy złom, a CUDA pokaże +10% więcej w czymś tam, fan boje polecą do sklepu żeby dalej przepłacać za to samo hehe:) Mi taki komfort oferuje AMD, jakby się nie pukać, zawsze wychodzi, że jednak wybieram AMD, bo akurat niczego z CUDA nie używam, bo nie ma czego, a przepłacać nie mam zamiaru, skoro za 1200 zł mam kartę z 8GB, a nie za 3000 zł hehe:)

Nezumi: Śmieszne to są Twoje wnioski. Ty masz jakiekolwiek pojęcie, więc pokrótce wyjaśnię. 1. Połączenie dwóch kart w grach nie podwaja fpsów, to tylko GPGPU faktycznie podwaja wydajność obliczeń, ale nie DirectX i OGL, więc porównywanie tutaj dwóch kart do jednej jest akurat czystej wody idiotyzmem, powstałym chyba na potrzeby zgnilizny zielonych, którzy są w szoku jakim cienkim i drogim okazał się Pascal w stosunku do zapowiedzi, bo to tylko mały lifting Maxwella, więc łączą sobie dwa AMD (akurat udane i zgodne z tym co AMD zapowiadało, chociaż z obcięciem zasilania chyba przesadzili) do DX żeby poczuć się mniej oszukanymi przez cwaniaków marketingowych z NVIDIA. 2. RX 480 kosztujący 1200zł nie jest odpowiednikiem GTX 1080 kosztującego 3200 zł hehe :). Puknij się w głowę. 3. RX 480 jest odpowiednikiem GTX 1060. AMD idzie raczej najpierw w dół tj. RX 470 i bardzo dobry RX 460 (cena do wydajności w grach). Polaris nie ma w tej chwili nawet odpowiednika dla GTX1070 i GTX1080. Jeżeli patrzeć nawet na numerologię to 480 jest jak poprzednie R9 380/380X, to jest właśnie ten przedział, więc odpowiednikiem GTX 1080 będzie raczej RX 490 lub RX 490X z 16GB (raczej RX 490X, RX 490 to GTX 1070). AMD jest firmą o wiele bardziej nowatorską od NVIDIA, nie dość, że GCN wiele lat temu już wprowadził GPU na wyższy poziom, podczas gdy NVIDIA nadal tłucze kolejne wersje Fermi, to jeszcze jako jedyni mają karty z HBM (marketing NV też zapowiadał, i co, i nic). To jeszcze do wszystkiego mają dobre ceny. To są fakty :).

Ty to chyba zajmujesz się renderowaniem od wczoraj skoro wymyślasz takie dyrdymały. Na GPU to renderuje się co najmniej od 2009/10, przynajmniej ja pamiętam to jeszcze na stareńkiej AMD Radeon HD48xx, a Ty piszesz dzisiaj, że pojawiła się konkurencja w GPU, żal czytać takie głupoty :D . Lux jest akurat jakościowo powyżej Cyclesa. Tu masz filmik z 2010 roku, wtedy nawet Cycles jeszcze nie był w Blenderze, resztę sobie chyba sam znajdziesz; SYmek: I co z tego, że dodali później, to znaczy wcześniej nie było możliwe, było, tylko im się nie chciało, nie było opłacalne, zapłacono najpierw za wersje only CUDA na NV itp.itp. VrayRT to akurat nie jest jakaś tam specjalnie mocna sprawa, bo Vray to raczej only cpu. 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... Akurat to nie jest prawda, tylko widzimisię hejtera NV :). Jakoś nie dodali AVX512 w Skylake itd., jest tylko eksperymentalnie w Xeon Phi. Poszerzanie rejestrów nie ma sensu, jeżeli np: cykl pobrania i zapisania jest znacznie dłuższy od cyklu wykonania, na to cierpiał już PowerPC G4/5 ze swoim doskonałym Altivec/VMX, tylko w bardzo syntetycznych testach dawał VMX kopa lub operacjach nie wymagających zbyt częstego load/store, więc co by tam dało poszerzenie rejestru, niewiele... a za to znacznie skomplikowało (uczyniło kosztowniejszą) wektoryzację kodu pod to. Od kiedy to ludzie w korpo podejmują decyzję na czym pracują ?:). Decyzyjni w korpo to najczęściej bardzo wąska klika nie mająca pojęcia o tym i nie bardzo lubiąca zmiany. Windowsa jednak używało się na długo przed Linuxem w korpo biurach, szkołąch itp. DOSa w wielu firmach na np: stanowiskach księgowych używano jeszcze długo po roku 2000 itd., a stanowiskach diagnostycznych na produkcji stoją do dzisiaj, baa, niedawno w Polsce wyłączono jakąś Odrę w jakiejś tam nastawni na kolei :). Największym zarzutem wobec Linuxa była zbyt mała wciąż windowsowatość, choć oferuje znacznie lepsze rozwiązania, tak to niestety działa :). Pod jednym wszakże warunkiem, że nie wyskoczy to poza wersje 1.2 :). Co oferują wersje >2.x to można sobie odszukać w necie, bo to wprowadza nową jakość jaką daje HSA, czyli w końcu normalność korzystania z GPU, bo obecnie to jeszcze epoka DOSa, oczywiście epoka DOSa miała też z początku znaczną przewagę nad OSami jak Win, szczególnie w wydajności, ale to minęło i se ne wrati... CUDA też ma być dostępna na AMD, ale pod warunkiem ponownej kompilacji, z powodu braku zgodności binarnej, z tego co tam kiedyś czytałem, tylko nie wiem czy to ma jeszcze sens :)

VrayRT akurat jest OCL, ale mniejsza z tym, i tak nie używam produkcyjnie żadnego z tych, prędzej wybrałbym Indigo z komercyjnych... Wybór CUDA i optymalizacji na NVIDIA (optymalizują niskopoziomowe, grzebią w asemblerze, często pod konkretny model np: 980Ti w Octane) wynika tylko z większej popularności tych kart wśród grafików kupujących sprzęt, powód jest czysto rynkowy, a nie dlatego, że OpenCL jest złe lub się nie da itp., bo już ze 7 lat temu śmigały takie pathtracery na radkach hd48xx . OCL 2.x jest obecnie dużo lepsze od CUDA, a że NVIDIA olewa OpenCL to insza inszość, dlatego chcąc mieć odbiorców wśród grafików trzeba kopać się z CUDA, taką politykę ma NVIDIA i dlatego dostała faka od Torvaldsa, a ja bym dołożył im kolejnego faka za drożynę tego ich badziewia pod nazwą Maxwell czy Pascal (Fermi było lepsze), bo karty są wyjątkowo cienkie do GPGPU, tylko nadrabiają lepiej opt. softem komercyjnym przez producentów :) dla mnie to akurat nic nie znaczy, ale wielu ludzi posługuje się takimi "drogowskazami", mi to akurat wisi czy Octane będzie wspierał OCL czy nie, bo nie używam, ale wątpię żeby implementowali powyżej CUDA, prędzej zrobią jakiś wrapper na OCL i na tym się skończy. OpenCL pozwala kompilować kod równie wydajny dla CPU i GPU, przy czym jak ktoś wejdzie w jednym i drugim przypadku w optymalizacje niskopoziomowe uzyska wydajniejszy kod dla CPU i GPU, co w przypadku tak prostych algorytmów jak np: pathtracing przynosi korzyści widoczne, a w przypadku złożonych zabawa jest już niewarta czasu na to poświęconego. Sprawę świetnie rozwiązuje https://github.com/GPUOpen-LibrariesAndSDKs/RadeonRays_SDK , podobnie jak Intel Embree dla CPU, z Embree korzysta Vray, Cinema4d, Luxrender i pewnie inne mi nieznane... W kierunku tych frameworków powinno to iść jak AMD FireRays i Intel Embree, a nie wybór OCL czy CUDA czy x86_64 ;) 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 :) Windows nadaje się tylko do zabawy w gierki. 98% gra w gierki to jest na 1 miejscu :) Jutrzenka: to nie bzdura, to fakt, nie możesz tej samej animki, nie mówiąc o pojedyńczej klatce renderować trochę CPU trochę GPU w Cycles, nie mówiąc o tym, że Cycles GPU nie jest pełnowartościowym Cyclesem, jak włączy się experimental w Blender to coś tam więcej obsługuje, ale stabilność woła o pomstę do nieba, mi na prostych scenach z Volume i SSS resetowało driver grafiki nv... Co nie zmienia mojego zdania, że Cycles GPU na CUDA powinien być osobnym pluginem do Blendera, dla zasady :) HubertP: To dt. użytkowników NVIDIA, bo są skazani na używanie kart NV w CUDA :). Pewnie zapłacą za niewypały takie jak Pascal nawet 10x więcej niż są warte niż przejdą na OCL i obozu czerwonych. OCL nie ma takiego problemu, bo działa na CPU/GPU/FPGA:) itd., sam używam OCL jeszcze na GPU IntelHD, oprócz GPU AMD, nie wspomnę o CPU.

Z tego co wymieniłeś jest tylko Octane i Cycles GPU (Cycles GPU to nie to samo co Cycles - w domyśle CPU, nawet nie można renderować naprzemiennie klatek, bo różnice są widoczne gołym okiem), vray RT to też nie to samo co vray. Maxwell ???, działa tylko cpu. Arnold dla CUDA ???, na razie działa tylko cpu. Nadal są 2 pathtrejsery only cuda warte uwagi, które już wymieniłem, tylko to już trwa od lat, zmian wielkich tam nie ma, bo CUDA nakłada duże ograniczenia, więc nie należy spodziewać się rewolucji. Reszta operacji jednak najczęściej w OpenCL. OpenCL wspiera Intel, AMD i także MS.., a CUDA działa na coraz słabszych karcinach NVIDI, przecież Pascal to jest porażka, też przypominam niektórym hejterom NV, że NVIDIA zapowiadała cuda w Pascalu, a wyszła strasznie droga lipa, także NVIDIA nie lepsza, jak każda normalna firma naciąga na zakup, bo tak działa rynek, ja ich za to nie winię, ale niektórzy wieszają psy na AMD za podobną praktykę, bo rządzą nimi podwójne standardy :) ps. Octane v3 ma być też na OCL. SYmek: Ma znaczenie jak renderujesz na renderfarmie. Jeszcze większe będzie miało znaczenie jak w końcu zerwą ze zgodnością OCL 1.2 (bo nie musi ruszyć na NV), całkowicie przejdą na 2.x, gdzie można już implementować bardziej złożone algorytmy korzystając ze wspomagania GPU. Większość obecnych developerów też wybiera naukę jednak OCL jako bardziej przyszłościowe, choćby też z uwagi na dostępność sprzętu OCL, skoro nawet w smarkfonach jest już OCL, w Web itp... To fakt. Linux rządzi na renderfarmach, a coraz częściej na stacjach roboczych :). Rok Linuksa trwa od dawna. Rok CUDA, może już ostatni, schyłek jak z tym imperium, co to słońce nie zachodziło, a dziś gasną ostatnie promienie ;). PS. po prawdzie, ogólnie moim zdaniem GPGPU jest często przereklamowane.

Teza to jest tylko, a praktyka jest taka, że dzisiaj większość programistów wybiera OpenCL lub inne frameworki korzystające pośrednio z funkcjonalności OpenCL. Nie potrafię wymienić cokolwiek od lat co stawiałoby tylko na CUDA. Opiera się być może jeszcze w większości na kartach NV, ale niekoniecznie CUDA, tylko raczej już OpenCL. Przyszłość właśnie nadeszła, skoro lista programów only CUDA maleje, a OpenCL rośnie, a w nauce CUDA jest zupełnie nieopłacalny z uwagi na brak wsparcia CPU i bardzo niską wydajność kart NVIDIA w double precision już od dłuższego czasu np: RX 480 (1200zl) - Double 323 GFlops (OpenCL 2.2), Geforce 1060 (1400zl) - Double 120 Gflops (staruteńki OpenCL 1.2) . Przepaść!. Karta NV nadaje się tylko do specjalnie zoptymalizowanego kodu CUDA w single precision, na większą wydajność w duble lub half nie ma co liczyć, bo CUDA jest tylko na NV, nawet nie działa na CPU (który ma już zwyczajnie większą wydajność w double i half od kart NVIDIA). W sumie dla kogo NV, dla gracza tak jak AMD, dla użytkownika Octane lub Cycles, ale to tylko z winy developerów, szczególnie w przypadku przereklamowanego Cycles GPU (nie to samo co CPU). Jakiegoś większego specjalnie zastosowania dla CUDA nie widzę obecnie w grafice. Do tego jak sam też potwierdzasz, nie nadaje się CUDA na renderfarmę, a OpenCL daję radę angażując w miarę możliwości wszystkie zasoby obliczeniowe CPU i GPU - wystarczy luxrender, żeby się o tym przekonać. Jedynie na początku tej drogi GPGPU. OpenCL trochę czerpał.

Jak jakiś hejter NV zaczyna od słów, "nie masz pojęcia", to prawdę mówiąc nie widzę sensu dalszej dyskusji :). A NVIDI są zgodne, jak tam cały czas OCL 1.1 i może 90% 1.2, sypie się na prostych procedurach :D, a gdzie 2.x ?. OpenCL od NV jest słabszy od wersji AMD, ale to AMD jest złe :). OpenCL to wszelkie CPU/GPU/AMD/INTEL/NV itd. - razem i osobno cpu/gpu, ale oczywiście wg. Ciebie problem był tylko na AMD, więc wybrano przestarzałe własnościowe CUDA (wymaga specjalnego programowania i działa tylko na jednym urządzeniu, bez sensu), dobre, tłumaczysz rzeczy zupełnie nielogicznie. Dziwne, że inne procedury OCL o wiele bardziej złożone od pathtracingu śmigają no problem od lat, tylko ten Cycles GPU jest problemem, dowód na złe AMD, super NV :). Tak czy owak, Cycles GPU na CUDA powinien być wywalony z Blendera na zewnątrz jako plugin. SYmek: Wspomniałem, czemu przestarzały, bo tu się dąży do unifikacji coś jak C++ Amp, żeby nie pisać osobno kodu na cpu, osobno na gpu, wykonywane może być na wszystkim, zależnie tylko od zasobów. OCL jest o wiele bliższy tej idei i dużo bardziej nadaje się do renderfarm, chociaż nie jest idealny. Czytasz czasami co piszesz, najpierw zaczynasz, że otworzyli, a potem "(właściwie nie otworzyła)" :D . CUDA nie jest otwartym standardem i na tym koniec, nie dość, że jest zamknięte to jeszcze wymaga do działania tylko jednego rodzaju sprzętu, co jest samo w sobie zaprzeczeniem idei otwartości.

O ile wiem to inż AMD napisali to zupełnie niedawno i dopiero zaczęło coś cokolwiek działać, przynajmniej u mnie (bo wcześniej ni w cholerę), a developerom Cyclesa nie bardzo chciało się od samego początku. Przykładem lepszego renderera niż cycles jest choćby luxrender czy indigo (ten płatny), jak widać można, można, tylko trzeba umieć, a nie amatorzyć jak blender developerzy na żołdzie NV. Wybór CUDA jest cokolwiek poroniony jak na otwarto żródłowy soft, bo co to za otwartość, kiedy korzysta się z zamkniętych i własnościowych rozwiązań, po prostu śmieszne nabijanie środowiska free w butelke. Moim zdaniem Cycels GPU (to jest słabsze od wersji CPU) powinien być już dawno oddzielony od głównego repozytorium Blendera i dostępny jako plugin, ale to moje zdanie, kogoś kto używa gnu/linuxa/openbsd od 20 lat. Lepiej jakby to Luxrender GPU lub inny OpenCL render zastąpił Cyclesa GPU w Blenderze. Bzdura, działa od dawna o wiele lepiej niż zabugowany po sufit Windows, którego nie da się używać na dłuższą metę, bo się sam sypie i uciążliwy z tym swoim instalowaniem, zarządzaniem itp. o świrusach nie wspomnę. Ten system to zawsze była pomyłka. Path tracing od dawna na OCL działa bardzo ładnie, a nawet lepiej niż na CUDA, bo nie jest ograniczony zasobami tylko GPU. Model programowania CUDA jest już dawno przestarzały. Tkwienie przy tym wynika tylko z lenistwa developerów.

Właśnie mam taki BIOS update (Asus) sprzed może 4 miesięcy i kręci bez problemu na B85. To samo jest na innej płycie, to nawet nie z B85, tylko jeszcze tańszym MSI z H61 (płyta nowa bodaj za 150 zł, kręci bez problemu i5 z K i Pentiuma G3258 - tego do 4.5Ghz, najprostsze i7 bez K można katować).

Cycles GPU nie wspiera w pełni OCL, od niedawna działa jakkolwiek na OCL, co jak na soft otwarto źródłowy jest raczej deprymujące, żeby używać własnościowego i zamkniętego API Cuda. Analogicznie to tak jakby widok w tym Blenderze był w DirectX, a potem ktoś przerabiał na OpenGL, narzekał, jakie to OpenGL jest złe, a DirectX cudowne.

Bez problemu kręcę na B85 za 250 zł (również na najnowszych BIOS!), nie wiem jak na B150. Natomiast na B85 mam wykręconego Pentium G3258 do 4.7Ghz (chociaż zostawiam na 4.5Ghz) :). Gdyby nie za krótki i ubogi blok zasilania akurat w tej płycie co mam to i5 też można byłoby wykręcić stabilnie >4.5Ghz - zwykłe i7 non K działa no problem. Kręcenie i7-4790K nie ma sensu, bo to procesor fabrycznie OC, nie ma zapasu, podkręcenie o 100-200Mhz jest bez sensu, moim zdaniem, więc po co przepłacać za płytę, lepiej tańszą tylko musi być nieubogi blok zasilania (mieć radiator i ze 4 fazy) ?. Zapas sensowny dla mnie >500Mhz, a lawinowy wzrost poboru energii jest dużo bardziej odczuwalny niż przyrost wydajności. Nie ma co się nabijać, że to Pentium za 200 zł, płyta za 250 zł. Wydajność rdzenia porównywalna z i7-6700K/i7-4790K, tylko wydajność wielowątkowa to mocne i3 (i3-4330/i3-4170) (G3258 to 2 rdzenie bez HT, bez AVX, tylko SSE w ostatniej wersji). Subiektywnie mogę powiedzieć, że praca z programem zazwyczaj nie odbiega od i7, bo większość operacji to jednak 1 wątek. Rendering odsłania prawdę, tylko akurat używam zazwyczaj GPU na tej maszynie do renderingu, więc w sumie to bez większego znaczenia, bo zależy głównie od GPU:). GPU renderuje szybciej od i7 z socketa 2011.

Może tylko uruchamiłeś CATIE, bo jakoś wszystko inne działają, na tyle na ile zostało przewidziane w samym programie. Nie wiem po co ten hejt.

Zawsze jest bardziej opłacalne w stosunku wydajność do ceny sprzętu, oraz dostępności, oczywiście mowa o nowym. jaką halę, 15 komputerów w obudowach microATX, układasz w konfiguracji poziom pion 5x3 lub 3x5 na zwykłej szafce, bez kombinowania z obudowami, to jest hala ?, na 120 renderujących wątków CPU, 15x GPU (30x w opcji maks.) ? :cool: . Ile to kosztuje, poniżej to jest jedyny mankament w pewnych wariantach, tylko u mnie pracują głównie silniki open source, CPU i CPU/GPU, specjalnie kompilowane na AMD FX, system gnu/linux. Owszem, testuje komercyjne np: LightWave - sam rendering (pod wine), testuje Maxwella i Indigo, jest nawet okej, działa:). U mnie w grę wchodzą silniki współgrające tylko z LW, C4D, Blender. Ostatnio tylko LW i Blender, z C4D żegnam się na rzecz Blendera. Renderfarma nie tylko jest do renderingu 3D, także montaż, a w zasadzie głównie końcowy rendering do formatu wynikowego itp.

Nie ma szans zwykły. 2U to 2x 44,45mm(1U) = 88.90mm. Typowe wentylatory mają >100mm. Musisz kupić >80mm. Do 2U pasują zwykłe ATX zasilacze z wentylatorem na tył - przy wyłączniku. Karty PCIx niskoprofilowe lub przez riser. Oczywiście tylko rack uniwersalny. --------------- vandam: Jest nawet niższe >40mm, ale ten będzie okej https://www.morele.net/chlodzenie-cpu-cryorig-universal-c1-cr-c1a-705814/ https://www.morele.net/chlodzenie-cpu-thermalright-axp-200r-100700542-733419/ https://www.morele.net/chlodzenie-cpu-be-quiet-shadow-rock-bk002-732070/ tylko pamięci nie mogą być za wysokie - radiatory. Aaa i jeszcze, o OC i7 należy zapomnieć :) A może wodne ?. Z wentylatorem i chłodnicą 80mm.

Jeżeli docelowo to 20 nodów to szkoda kasy i zabawy w rack. Zaoszczędzone miejsce i tak pójdzie na konieczne miejsce dla wentylacji. Proponuje pooglądać w sieci różne propozycje budowy klasterów. Najprościej to wepchnąć w zwykłe obudowy, postawić na stelażach, wstawić do wentylowanego pokoju, postawić dmuchawy i wio.

Jeżeli na AMD nikt nie mieli to chyba urodziłeś się bardzo niedawno, można rzecz wczoraj, ja to mieliłem jeszcze na Motorolach :). Na AMD mieliłem już w czasach Athlonów i nie byłem odosobnionym przypadkiem... Cinebench R15 jest mało miarodajny, bo każdy silnik to jednak zupełnie co innego. Pobaw się eksperymentalnie kiedyś sceną z Cinebencha 11/15 w ustawieniach na zwykłej Cinemce, a poza tym to bench dla handlarzy i portalowych testerów, swego czasu nawet podejrzewany o ukryte faworyzowanie Intela, bo Cinebench jest jednak inny od zwykłej Cinemki. Oczywiście Intele od czasów Haswell są wyraźnie lepsze i wyraźnie droższe od AMD FX-8, ale to było kilka szczebli ewolucji o +10% tej samej architektury, kiedy cały czas używałem tego samego AMD FX-8, który dzisiaj kosztuje nieduże pieniądze, jest dostępny ze wszystkim nowy fabrycznie od ręki, nadal w ilości każdej. Intele są dobre, dla tych co podniecają się byle pierdułką co pół roku wieszcząc wielkie rewolucje +10%. Żeby rewolucja była faktem Intel zmienia wszystko, poczynając od chipsetu, kończąc na gniazdku, a nawet ostatnio pamięciach. Zmusza do tego samego swoich klientów. Dla mnie polityka tej ogromnej korporacji to jedno wielkie oszustwo. Ewoluować o +10% co 2 lata, czy dopiero dokonać wielkiego skoku o +100% za 6-7 lat, ekonomia daje odpowiedź, a intelowskie +10% załatwiam na amen dokupieniem kolejnego noda na AMD FX-8 za 1000 zł do pozostałych takich samych nodów AMD FX-8, a wszystko zupełnie nowiutkie fabrycznie, bez bujania się po różnych alibabach itp. AMD Zen przejdę już całościowo powiedzmy za 1.5 roku. AMD zagwarantują dostępność AM4 i Zenów minimum 5 lat to biorę w ciemno i mam w nosie, że Intel za rok pokaże lepszy procek +10%, porzucając całkowicie poprzednie i wymieniając znów wszystko, ja wolę za rok dokupić do reszty nowego tego samego noda AMD Zen, już taniej, a nawet jak się jakiś node po gwarancji rozkraczy to 1000 zł mniej boli w kieszeni niż 2000 zł lub więcej, bo są tacy co budują kilka nodów na Xeonach, wow hehe:) Dodam jeszcze, że rozwiązanie Rack jakie proponujesz to absolutna LIPA w grafice. Nody na std. płytach można rozbudować o GPU, masz w jednym nodzie AMD FX-8320E + np: 2x AMD Radeon RX480 w maks. wariancie, ja daje na razie 1 sztukę, mam płyty na 2. Długo stały PCIx nieużywane. Obecnie w tym kierunku rozbudowuje swoje nody. Ta propozycja racka za 499zł jest dobra dla serwerowni sieciowej, bazodanowej etc.

Nic nie poleciałem. My tu piszemy o nowym sprzęcie, a nie, jak sobie poszukasz, jak sobie pokombinujesz, jak sobie sprowadzisz itp. to znajdziesz to itd., sorry, ale tu nie chodzi o kombinowaniem z kupowaniem za oceanem itp. Wiesz, jak ja pokombinowałem to kupiłem 10 sztuk AMD FX-8320E za 3000 zł, a płyty po 120 zł, pamięci 2x8GB po 200 zł itd. (wszystko nowe z GW producenta) Nie o to chodzi, chodzi o to żeby sprzęt był nowy, miał z 24-36mcy gwarancji minimum, dostępny wszystko od zaraz w sklepie, teraz i w najbliższym czasie pod dostatkiem. Nie kombinuj z C4D R15, bo ja tego nie używam, mam inne wyniki w swoich benchach. :)

Za 6000 zł to jeszcze można pokusić się o AMD, ot takie 2 zestawy lub 3 zestawy (3 z dopłatą powiedzmy 600zł). Dla kogo. Dla kogoś kto renderuje CPU & GPU np: Luxmark (RX 480 daje power GTX980Ti, jest 2x tańszy, wspiera kodowanie H.265 dwuprzebiegowe), Indigo, Cycles, RenderMan itp. Centralny do pracy wystarcza, raczej po OC, tylko OC na AMD jest normą, łatwe, nie ma blokad. Bez problemu 4.4Ghz, a można więcej, tylko nie wiem czy jest sens z powodu nagłego zwiększenia poboru energii. Na nodach tak jak jest (3.3Ghz, Turbo 4.2Ghz). Łącznie, 24 wątki (w 3 zestawach), mocne GPU. Trochę powiedzmy ponad 6000 zł. Tania, łatwa rozbudowa o kolejne nody. Centralny do pracy Nody: ----------------------------------------------------------------- Ja wiem, nie znam adamczyka :), raczej gorszy nie jest od Pearl Harbour (szmira totalna), Enemy at the Gates (chociaż ten nie jest zły, tylko zbyt zachodni, pasowałby może do obrony Berlina, pokazane od strony Niemców:) ) itp. Sam film nawiązuje trochę do historii domu Pawłowa - Niemcy stracili tylko tam więcej żołnierzy niż w czasie okupacji nie jednego kraju.... Oceniam jednak średnio sam film, robiony za bardzo pod widza... Efekty, miło słyszeć, że się podobały, bo znam osobiście parę osób z ekipy :) Stalingrad (1993) reż. Vilsmajera nie jest zły, choć zbyt niemiecki, oczami Niemców. PS. nie buczcie mi na AMD, zwracam tylko uwagę, że jeszcze istnieje i działa:)

Jakiej czkawki, przecież to tylko odpowiada za transfer danych z pamięci RAM komputera do pamięci VRAM GPU i vice versa. Każda linia pozwala transferować teoretycznie do 1GB/s (licząc w obie strony), co daje dla 16 linii teoretyczne 16GB/s. Zestaw to sobie z przepustowością RAM w dual-chanel (rzędu ok. 20GB/s), więcej linii nie miałoby zwyczajnie sensu, bo w najbardziej stresującej sytuacji kilka GB/s lepiej żeby zostało dla CPU:). W przypadku i7-5820 itd. masz quad-chanel, więc tu jeszcze ma sens 28 linii, 40 to już jest takie mocno wyśrubowane, to dla profesjonalnych konfiguracji 4xGPU. Dwie karty PCIx16 v3 w konfiguracji 2x8lini, każda ma dla siebie po 8GB/s, czyli dokładnie tyle ile ma PCIx16 v2 w konfiguracji 1x16 linii. Kto używał kart PCIx16 v2 wie, że nic się nie tnie jakoś specjalnie. Pomijam, że uzyskanie takich transferów w liczeniu CUDA to byłby prawdziwy cud :). Silniki najpierw wszystko wrzucają do VRAM, co trwa momentów ileś set milisekundowych, potem transfery są już znikome. Inaczej jest w OCL, dopiero od wersji >2.0, tylko przy przekroczeniu limitów i hybrydach, gdzie może być to w skrajnym przypadku odczuwalne. Oczywiście w grach ma to znaczenie, tylko wtedy kiedy brakuje VRAM, co biorąc pod uwagę jaka jest różnica między przepustowością linii PCIx i pamięci VRAM (DDR5 itp.) będzie zawsze odczuwalne :eek:

Co za problem, chodzą wtedy w konfigu 2x8. Jak widać ruszą nawet 3, to już za dużo na ten procek:) "Wersja PCI Express 3.0 Liczba konfiguracji PCI Express ‡ Up to 1x16, 2x8, 1x8+2x4 Maksymalna liczba linii PCI Express 16"

Naionel: No, na to samo wychodzi, Unity czy UE4, to silniki renderujące bazujące na silniku gier :). Wymienione kalkulacji fx (fizyka, cząstki etc.) działa zazwyczaj na OpenCL (poza jakimiś PhysX), a to załatwia praktycznie każde obecne GPU od NVIDIA, AMD, Intel. Maciek Jutrzenka: True!, RenderMan to nawet nie tylko silnik CPU, to klasyczny silnik sieciowy do postawienia na renderfarmie, dopiero na tym jest power, bo inaczej to power reduction ;).

Tu chodzi tylko o rendering GPU na Unity, no więc dlatego warto dołożyć do GTX1070/8GB, zamiast GTX970/4GB. Unity chyba nie używa CUDA, bo tu chodzi tylko o silniki CUDA. i7-6700K nie warto, skoro za 1249 można dostać i7-6700. Różnice nie będą jakieś powalające, a 3 i pół stówki w kieszeni mieć lub nie mieć, to co innego :). i5-6600K w zupełności wystarcza ze swoimi pełnymi 4 rdzeniami w Zbrush, natomiast do renderingu lepiej i7-6700, dlatego jest bardziej pożądany, opcja i5 to sensowne minimum tj. 4 pełne rdzenie (i3 też ma 4, ale wątki). Zasadniczo i5-6600K jest lepszy od i7-6700, ale to jak ktoś zabawi się w OC, bo uzyska lepszą wydajność na 1 rdzeniu. i7-5820K to już znacznie wyższy wydatek, ale bez zabawy w OC jest zupełnie nieopłacalny.