Skoti

@mookie: wydajność standalone powinna być identyczna lub lepsza. Czytaj standalone nie sili się na renderowanie ze struktur dostosowanych do modelowania (niektóre zintegrowane z softem renderery tak robią), a nie do renderingu. Ofc standalone wymaga dodatkowej pamięci ram (chyba, że wyłączysz program z którego renderujesz, to powinien mieć mniejsze wymagania od pamięci), ale przykładowo Cycles w Blenderze i tak przed renderingiem przetwarza sobie siatkę i robi kopię (aby szybciej renderować) więc wydajność powinna być identyczna.

Tylko autor/autorzy danego kodu mogą to zrobić. Jeśli jakikolwiek współautor nie zgodzi się na wypuszczenie jego kodu na innej licencji używając tego kodu musisz się liczyć z tym, że zmusza Cię to do umieszczania wszystkiego co Ty napiszesz na licencji GPL.

Cycles jest wydawany na licencji liberalnej (podobnej do BSD z obrazka podanego przez Le_chu). Czytaj licencja jest taka, że można kodowi zmieniać licencje... czytaj można użyć kodu BSD w GPL (jak jest zlinkowany z blenderem to jest GPL, ale jak ktoś zrobi standalone to jest już na jakiejkolwiek). BSD wirusologiczne nie jest i można tego kodu użyć w aplikacji GPL, ale w drugą stronę już to nie zadziała (kod GPL nie może być użyty w BSD). Można by, tylko aby był faktycznie sens trzeba by nie UI przepisać, a całego blendera, bo wystarczy linijka, aby kod był GPL. Każdy kto cokolwiek w kodzie blendera zrobił na przestrzeni rozwoju w ramach GPL musiałby się na to zgodzić (zapewne dodatkowo pisemnie, aby była podkładka dla fundacji), bo bez zgody każdego (a są osoby w tym gronie, które się cieszą z braku zamkniętych pluginów i że wszystko jest otwarte). Sankcje byłyby takie, że fundacja praktycznie przestałaby istnieć finansowo zniszczona, a kod na innej licencji byłby nielegalny (jak i pluginy do niego, przez co dalej by ich nikt nie pisał). A kto może dochodzić praw? Każdy kto postawił przecinek w kodzie i nie chciał tego przecinka na inną licencję zmieniać ;p. Free Software Foundation już takie osoby niezadowolone by znalazła (nawet jeśli komuś wisi licencja przekonałaby ich, żeby dociekać swoich praw) i przekonała do tego, aby pozwoliły ich prawnikom się reprezentować w sądach.

Hmm powtórzę swoje słowa: "GPL jest wirusologiczna... czyli jeśli program blender będzie linkowany z kodem ich to ten kod też musi być na licencji GPL" Nie da się napisać API dla pluginów komercyjnych, bo pluginy dynamicznie są linkowane do blendera... a nawet dynamiczne linkowanie oznacza w wypadku GPL, że plugin też musi być na GPL (gdyby blender był na LGPL to problemu by nie było). Blender nie może obecnie już zmienić licencji na inną niż GPL (musiałby się zgodzić każdy kto literówkę w kodzie poprawił na to, a to jest niemożliwe). Można by zrobić API przez sieć czyli z blendera uczynić serwer sieciowy (lokalny), a API dać takie, aby program (uruchomiony przez blendera) łączył się z tym serwerem i komunikował się z nim przez tcp/ip... jednak to oznacza kopie danych - przykładowo jeśli siatka zajmuje Ci 600 MB w blenderze, to musi być przesłana przez protokół internetowy do tego "pluginoprogramu", on robi swoją kopię, przetwarza siatkę i siatkę przesyła przez tcp/ip spowrotem... jest to po prostu bardzo kiepskie rozwiązanie, ale jedyne na jakie GPL pozwoli... innymi słowy blender ma przesrane przez wybór takiej a nie innej licencji (a mogli wybrać LGPL która nie pozwoli zamknąć*kodu, każda zmiana w kodzie blendera musi być wydana na LGPL... ale można dynamicznie linkować (czytaj pozwala wykorzystać zamknięte pluginy), ale teraz już jest za późno).

Nie ma komercyjnych pluginów... bo nie ma pluginów wcale (blender ich nie obsługuje bo nie było sensu ze względu na licencje). Nie ma komercyjnych skryptów, bo one też muszą być na GPL... są komercyjne programy zewnętrzne, które mają skrypt integracyjny (plugin) na licencji GPL. W wypadku renderera jeszcze się opłaca (osobny program + warstwa komunikacji) - renderer standalone i skrypt eksportujący do niego dane. W wypadku rozszerzeń do samego blendera, które mają robić coś więcej niż wypluć dane, ewentualnie odebrać obrazek jest to zupełnie nieopłacalne (w wypadku pluginu do programu nie ma wielkiego sensu tworzyć infrastruktury rozmów z programem, pisząc inny program, dodatkowe skrypty które obsługą ten dodatkowy program i marnować dużo pamięci ram i czasu na kopiowane (nie można skorzystać z tej pamięci blendera, a trzeba wszystkie dane przesłać do aplikacji numer 2 i dopiero ona odeśle wynik obliczeń spowrotem, aby skrypt zmodyfikował oryginalne dane - w wypadku pluginów normalnych plugin po prostu działa na orginalnych danych co oszczędza dużo czasu)) i z tego powodu poza renderingiem praktycznie nie istnieją takie pluginy (już pomijam, że ze względu na licencje, twórcy blendera odpuścili sobie możliwość pisania pluginów i są tylko skrypty). Twórcy blendera niestety wiedzą już czym GPL pachnie (od kilku lat zastanawiają się jak to zrobić, aby zamknięte pluginy były dostępne) i że obejść go ciężko (sztuczka z serwerem to taki bardzo kiepski półśrodek, który w większości przypadków się nie sprawdzi), przez co nowe rzeczy jak Cycles już na GPL nie są pisane, a na liberalnej licencji Apache.

GPL jest wirusologiczna... czyli jeśli program blender będzie linkowany z kodem ich to ten kod też musi być na licencji GPL (czyli muszą udostępnić kod, który każdy może później za darmo rozdawać (wystarczy, aby jedna osoba kupiła) - jest to zapisane w licencji GPL). Wszytko zależy jak to zrobią... jeśli zrobią przykładowo serwer lokalny, który będzie gadał z blenderem za pomocą skryptów (czytaj osobny program z ich kodem w żaden sposób nie linkowany z blenderem, a blender będzie z niego wyświetlał jedynie dane - ofc nie mogą ścigać za używanie blendera czy skryptu, ale ze względu na osobny program ich na ich licencji mogą ścigać za niego) to będzie to legalnie - jeśli będzie jednak kod linkowany statycznie/dynamicznie to będzie problem. Ogólnie dużo zachodu jest z pluginami i licencją blendera i trzeba się mocno namęczyć (dlatego prawdopodobnie wyjdzie blender + skrypt + ich program, który steruje skryptem, zamiast po prostu plugin). Pod Linuksem i Windowsem też wystarczy dodać zmienną środowiskową CYCLES_OPENCL_TEST=all aby włączyć test opencl, ale daleko mu do Cycles CPU czy CUDA (jeśli dobrze pamiętam jest to kod jeszcze z czasów wyrzucenia OpenCL z oficjalnych buildów - jednak jest nadzieja dla OpenCL, bo Khronos wydał SPIR (kompilacja kodu do kodu pośredniego przez programistę, a nie sterownik, przez co sterowniki AMD na większych kernelach nie powinny już się wywalać)). PS. dzięki za info o postępach z bake - ściągam źródła i sprawdzam.

@Laylot: Zależy czy bardziej zależy Ci na wydajnej pracy z masywnymi scenami, czy na renderingu na GPU. GeForce są najlepsze, ze względu Wydajność/Cena (obcięte są względem Quadro/Tesla możliwości obliczania liczb zmiennoprzecinkowych podwójnej precyzji... na szczęście w renderingu i w viewportach używa się jedynie pojedynczej precyzji i GeForce będą tak samo dobre, a tańsze). Jednak co do rdzeni CUDA to nie masz racji. Nie jest ważna ilość rdzeni sama w sobie... ważna jest wypadkowa ilości rdzeni, architektury GPU i częstotliwości działania rdzeni. Przykładowo rodzina Fermi (karty z serii 400 i 500) mają inną architekturę niż rodzina Kepler (serie 600 i 700) i wydajność tych różnych serii nie da się porównywać względem ilości rdzeni... chociażby dlatego, że Keplery mają zazwyczaj rdzenie o częstotliwości 900MHz do 1GHz, a rdzenie Fermi mają 1.5 do 1.6 GHz, rdzenie w Kepler są umieszczone w grupach po 32 lub 64 rdzenie, a w Fermi są umieszczone w grupach wykonawczych po 16 rdzeni (wszystkie 16 muszą w danym momencie wykonywać tą samą instrukcję, lub czekać aż się skończy, dlatego im mniejsza grupa tym lepsza wydajność). Keplery trochę nadrabiają z wydajnością na rdzeń, dzięki Hyper-Q i Dynamic Parallelism... ale wsiększość kart z serii 600 i 700 nie ma ich (te technologie ma tylko kilka modeli). Ogólnie rzecz biorąc To jest naturalne... nie wyobrażałem sobie, że ktoś to musi sprawdzać. Zawsze jeśli mamy sytuację z obliczaniem na wielu węzłach (nie ważne czy jest to klaster z wieloma CPU czy wiele GPU) z lokalną pamięcią (nie współdzieloną, a odrębną dla każdego węzła), program nie może wykorzystywać więcej pamięci niż ma najsłabszy węzeł (bo pamięć w tych węzłach się nie sumuje, tylko jest wiele kopii tych samych danych i wszędzie muszą się te dane do obliczeń zmieścić, więc i na tym najsłabszym węźle)

Najśmieszniejsze jest to, że rozwiązanie gotowe było przez lata, ale przejście z 2.4x na 2.5+ poświęciło wiele narzędzi, w tym Flip Triangle Edges (ctrl+shift+f) i teraz trzeba ręcznie triangulować, zaznaczać, obracać, i konwertować na quad od nowa, zamiast skorzystać ze skrótu i po kłopocie.

LOL... zmieńmy nazwy matematyczne/fizyczne, bo Andrew ich nie rozumie ;p. Wątpię jednak czy nawet opisowe "wektor prostopadły do powierzchni w danym punkcie" by zrozumiał (a innej nazwy sobie nie wyobrażam... każda inna byłaby niezrozumiała nie tylko dla laików, ale też dla osób przechodzących z innego programu, jak i po prostu znających geometrię czy po prostu uczyli się optyki na fizyce w szkole podstawowej (w której też używa się pojęcia normalnej, przy odbiciu promienia od powierzchni pod tym samym kontem w stosunku do normalnej)).

Nie chodzi o granicę krytyczną silników (na scenie w grze może być miliony poly). Ogólnie do gier te poprzednie 25k było już wystarczające - modele do gier zazwyczaj więcej nie mają. OFC można było pracować z więcej poly (importować/otwierać siatki nawet z milionami poly) i wypiekać normalne/textury na siatkę do gry. Export ograniczony do 25k był po prostu ograniczeniem do innych zadań. Do gier nie potrzeba więcej niż 25k na model, a skutecznie blokowało to eksport do zewnętrznych rendererów i korzystanie z tej wersji do innych celów. 65k to odpowiedź na społeczność ("macie więcej, ale i tak nie na tyle, aby nadawało się to do większości innych zastosowań"). Możesz mi wytłumaczyć co ma do ilości eksportowanych wielokątów, do animacji postaci? Ograniczenie to 65k na siatkę postaci, ale animacja (zarówno kości jak i morphing) nie jest w żaden sposób ograniczana i nie była. 65k nie jest wielkim ograniczeniem dla jednego modelu, ale już dla całej sceny owszem.

Ten obrazek akurat pokazuje, że jeśli dopłacać do droższego do i7 3770 to lepiej dodać jeszcze 50zł i mieć i7 4770 (prawie 30s i 20% wydajniej - bez K bo i tak podkręcać nikt nie bedzie)... Ofc bardziej mnie śmieszy to, że dopiero co mówił, że pokazywanie tego obrazka nie ma sensu bo to Mental Ray, a większość korzysta z Vray... ale test z Vraya po prostu jeszcze bardziej mu nie pasuje do koncepcji. [ATTACH=CONFIG]91787[/ATTACH] 3770K to dalej świetny procesor, ale bzdurą jest, że tanieją bo wyszła nowa generacja, Intel ma od lat zasadę, że nowe i5 wydajnościowo porównywalne ze starymi i7 są w niższej cenie, aby nie zaszkodzić magii marki i7 jako tej droższej i lepszej (jak widać działa). Wracając do tematu: W tym budżecie polecam i7 4770 i trochę lepsze GPU niż GF 650

Jeśli to komentarz do tego slajdu to mam nadzieje to, że są tam wymienione gry nie oznacza, że nie do Hi Performance Computing jak rendering. Do gier się ofc nadaje, bo głównie w grach ograniczająca jest fizyka... a fizyka to te same struktury akceleracyjne, te same działania na macierzach i wektorach i ten sam raytracing co w rendererach więc nic dziwnego, że jest dobry i do gier. Znowu gadasz bzdury - od i5 Haswell są lepsze i7 Haswell czy Xeony Haswell... ba 6x/8x/10x rdzeniowe (podkreślam rdzeniowe - nie wątkowe) Xeony starszych generacji też są znacznie - tylko się nie mieszczą w budżecie. Problem w tym, że nawet jeśli soft nie dorósł to w takim Vray ten i5 jest lepszy od podawanego przez Ciebie i7 starszej generacji i dużo lepszy niż Xeon (masz wyżej testy, którymi niestety nas ty nie uraczyłeś tylko dalej opierasz się o "mi się wydaje"). Wybór jest raczej pomiędzy porównywalna wydajność w niższej cenie teraz i lepsza wydajność w przyszłości (tu nie mowa o przyszłości tylko już dziś Haswell i5 jest bardziej opłacalny). Co do FX to ktoś Ci bajki mówił o tym, że jego możliwości są niewykorzystywane. Do wykorzystania nowych AVX2 nie będziesz długo czekał w wypadku rendererów - rok max, a kompilatory już obsługują, renderery OpenCL wykorzystujące OpenCL do CPU (jak LuxRender) już dodatkowe możliwości wektorowe obsługują... bo AVX2 to nic innego jak po prostu 16 rdzeni FMA (2x operacje na raz) takich jak GPU w każdym rdzeniu procesora tylko o częstotliwości procesora czyli ten i5 ma 64x rdzenie FMA po 3.4 GHz pakowane po 16 w SIMD. Nikt nie mówił o przyszłych możliwościach wymiany procesora... bo to, że Intel wymienia podstawki co chwilę i w 2017/18 pewnie znowu zobaczymy zmianę nikogo dziwić nie powinno. Ale skoro już podejmujesz ten temat to i7 o którym mówiłeś ma starą podstawkę, a Haswellowa i5 ma najnowszą i będzie stosowana jeszcze przez kilka lat (więc jeśli komuś przyjdzie ochota to będzie miał na co wymienić, a tego i7 nie)

To co piszesz zakrawa już o absurd. Na merytoryczne testy i dane dotyczące działania w Viewporcie, MentalRay, Maxwell, Vray nie podajesz nic metorycznego poza twoim tak mi się wydaje, danymi z sufitu czy też syntetykami nie mającymi nic wspólnego z tematem (sorry w testach które podałeś użyli benchmark Cinema 4D... bardzo na temat musisz przyznać, ale bezpośrednio do niego i tak się nie odwołujesz, bo nie jest dla ciebie tak optymistyczny jak wyobrażenia). Znowu gadasz bzdury. Mówię, że powinno się pracować na wielordzeniowych procesorach o jak najbardziej rozbudowanych dekoderach instrukcji i wielu superskalarnych ALU (Haswell ma więcej alu i więcej potoków niż poprzednie generacje). Wiele wątków Hyper-threading nic/niewiele daje, dają za to poprawione dekodery instrukcji, dodatkowe ALU do liczb całkowitych, dodatkowe możliwości jednostek wektorowych i nowa generacja jednostek MADD.... i najważniejsze ILOŚĆ FIZYCZNYCH RDZENI OBLICZENIOWYCH, a nie "wirtualnych wątków", które działają i tak na pojedynczym rdzeniu jeden czekając aż drugi skończy. Wielowątkowość jest super, ale na wielordzeniowych po 1x wątek na rdzeń. Tego nawet nie wiem jak skomentować. Wielowątkowość wykorzystuje większość programów - renderery czy fizyka radzą sobie z tym bardzo dobrze. Jedyna różnica jest taka, że wielowątkowość skaluje się ładnie względem ilości rdzeni fizycznych, a ilość wątków sprzętowych nie ma tu wiele do rzeczy. HT to nie jest magia która z jednego rdzenia robi Ci 2x. HT to po prostu dodatkowy wątek... i mamy 2x wątki pracujące jednocześnie na tych samych ALU (liczyć w jednym momencie może tylko jeden wątek, a drugi musi czekać). Ogólnie jeśli program nie wykorzystuje dobrze architektury superskalarnych to HT przyspiesza maksymalnie o 30% (dane od Intela), a w praktyce kilka % (patrz wszystkie, łącznie z Twoimi podanymi tu testami), jeśli kompilator dobrze zoptymalizował kod do wielu potoków to dodatkowe wątki nie tylko nic nie dają, a zwiększają wykorzystanie cache o ponad 40% (cache thrashing), przez co z HT jest niższa wydajność*na 8x wątkach niż na 4x wątkach (oba na 4x rdzeniach) - patrz przykład z Lightwave właśnie. Ogólnie nie gloryfikuj HT bo to wielka lipa i 2x więcej wątków wygląda ładnie tylko na slajdach. Najważniejsza jest architektura rdzenia - Haswell z tego i5 ma większą wydajność w liczbach całkowitych przy tej samej częstotliwości niż poprzednicy dzięki dodatkowemu ALU. Haswell ma 2x większą wydajność wektorową/zmiennoprzecinkową dzięki nowym jednostkom: Na wszelki wypadek powiem Ci co tu jest napisane - AVX2 + FMA przetwarzają 32 operację zmiennoprzecinkowe na cykl, podczas gdy poprzedniej generacji 16. Wydajność obliczeniowa AVX2+FMA w tym i5 wynosi teoretycznie 108.8 GLOPS na rdzeń czyli 435,2 GLOPS na ten i5... wydajność obliczeniowa i7 poprzedniej generacji który podawałeś jest równo 2x słabsza... teraz tego nie odczuwasz, bo programy dopiero będą wykorzystywać nowe rdzenie wektorowe, dlatego i7 jest porównywalny w testach. a dzięki HT o kilka % potrafi być szybszy (w Vray wręcz przeciwnie). Nie pisz bajek już na tamat cudownych właściwości większej ilości wątków (HT) na wydajność, bo takich właściwości zazwyczaj nie ma, a jeśli już ma to na poziomie kilku %. Ja nigdzie nie mówiłem, że tak nie jest, ale Ty, żeby nie robić z gęby cholewy powinieneś podać skąd podajesz takie dokładne procentowe dane i jeśli źródło własne to metodologię - bo tak to tylko się ośmieszasz rzucając z głowy liczby bez potwierdzenia.

Coś Ci się pomieszało. Nie proszę o radę, a jak ktoś radzi bzdury to uważam, że obowiązkiem jest poprawianie złych rad, które komuś mogą wyrządzić krzywdę. Może nie jestem zwolennikiem przywiązania do marki, ale proponowanie starego powolnego xeona... tylko dlatego, że nazywa się xeon to idiotyzm.

Zrób - to ty podajesz dane z sufitu więc jeśli chcesz uwiarygodnić się to zrób przynajmniej ankietę (bo do tego, że podajesz te % z czapy w tej chwili praktycznie się przyznałeś). To z tym krztuszeniem się to żart mam nadzieje? Za mała ilość pamięci na karcie graficznej nie powoduje "krztuszenia się". Po prostu jak się nie będzie za mało miejsca na GPU to program się wywali bez ostrzeżenia/niektóre poinformują że brakuje miejsca. O ile w Viewporcie raczej Ci się to nie zdarzy, to przy renderingu na GPU masz to jak w banku, że 1GB będzie za mało (i nie będzie Ci się krztusić, tylko po prostu nie wyrenderujesz tego co chcesz).

AMD nadaje się tylko do renderingu i to nie lepiej niż procesory Intela, dlatego do komputera na którym pracujemy i większość czasu spędzamy na operacjach jednowatkowych się nie nadaje do niczego. Na małych farmach się nadaje, bo platforma jest tania, a różnica w poborze prądu nie szybko odrobi, na dużych farmach komercyjnych cena pożeranego prądu bierze jednak górę i AMD są nieopłacalne (smutne, że tego nie rozumiesz). AMD wziął się z tego, że analizowałem twój post głośno i wykluczałem możliwości co radzisz - to ty jednak z kilku słów rozpocząłeś rozwijać temat AMD. Podaje testy Maxa (lightwave był przy okazji na stronie z testami HT maxa pokazującymi, że w przy pracy nie ma żadnego znaczenia HT, a przy renderingu minimalne i minimalne w Mentalu). Znowu dane z sufitu na które nie masz żadnego potwierdzenia poza "tak mi się wydaje". Ale niech Ci będzie, bo o ile chciałem podawać bardziej reprezentatywny Mental w stosunku do reszty rendererów to jeśli bardzo chcesz Vraya (on bardziej nie lubi HT niż Mental) to proszę: http://www.hardware.fr/medias/photos_news/00/41/IMG0041493.png W Vray akurat i5 4670 wypada lepiej od i7 3770 już teraz nie mówiąc o przyszłości. Zabawne jest to, że im bardziej próbujesz uratować mit starych i7 jako lepszych niż nowe i5 tym gorzej wypada to dla i7. Pisałem ogólnie o architekturze AMD FX - ten i5 ma 170% wydajności 8350 przy 20% niższym zegarze - przemnóż sobie 170 przez 1.2x to dowiesz się czy nie wychodzi Ci z matematyki 2x większa wydajność na zegar.

Nie - wielu zainwestowało w bardzo dobry procesor, ale teraz pojawiła się nowa seria i już nie jest taki przekonujący jaki był wcześniej - dziś ten i5 może swobodnie walczyć z tym i7. Nie ma co się obruszać, że świat idzie do przodu. Mówi o wydajności w liczbach całkowitych. W liczbach zmiennoprzecinkowych według Intela wsrosła wydajność o 8% w instrukcjach wektorowych AVX (w wersji 1, a więcej w 2). Wiem jak wygląda budowa procesorów AMD. Mają 4x moduły, każdy z nich ma 2 rdzenie po 1x wątek na rdzeń. Mimo, że jest to 4x moduły, to jest to 8x rdzeni i 8x wątków, a nie jak u Intela w niektórych 4x rdzenie, a 8x wątków. Dać się pracować da i na Pentium 4, ale z wygodną pracą nie ma to nic wspólnego. To, że źle wyciągasz wnioski/nie rozumiesz tego co czytasz nie oznacza, że wszyscy tak mają. Ten procesor AMD wypada nieźle w testach wielowątkowych - do Intelów mu daleko (i7 4770 jest daleko), ale przy swojej wydajności wielowątkowej i cenie może iść do faremek (ofc nie za wielkich, bo w dużych farmach pobór prądu go wyklucza), ale wydajność jednowątkowa zabija ten procesor - edycja gęstej siatki czy duży projekt to na ten procesor stanowczo za dużo (co tu dużo mówić 1x rdzeniowe operacja na tym AMD FX są 2x wolniejsze niż na tym i5).

No co ty nie powiesz. Przecież cały czas o tym pisze - 4x rdzenie z HT ma Xeon (czyli każdy rdzeń ma 2wątki, co przekłada się na kilka % wyższą wydajność w stosunku to 1x rdzeń 1x wątek). Maxa 2012 i dokładniej to nie maxa, a Mental Raya z maxa i od tamtego czasu w kwestii wsparcia dla HT się nic w nim nie zmieniło. Cena czyni cuda. Czytaj pracować na AMD się nie da, w wielu wątkach zbliża się do 4x rdzeniowców od Intela, ale ma znacznie niższą cenę platformy - jak dużo tańsze płyty główne, przez co do faremek nadaje się - do komputera na którym zamierza się pracować niezbyt. W jednej serii - w życiu, w innych seriach jak najbardziej - Haswell (seria 4k) jest 8% wydajniejsza przy tym samym zegarze i ilości rdzeni co Ivy Bridge, a IvyBridge jest 5% wydajniejszy od Sandy Bridge (z tego Xeona) i ten Xeon z wątku jest 2x generacje starszy i ma niższy zegar - w okolicach 15% jest słabszy niż ta i5... trochę odrabia Xeon na HT, ale nie tak wiele, żeby nadrobić, już nie mówię o większych możliwościach operacji wektorowych (AVX2) i na raz mnożenia i dodawania (FMA2) które w rendererach są bardzo przydatne (a jeszcze nie używane w najnowszych wersjach). Ten i7 z poprzedniej generacji jest podobny pod względem wydajności (poniżej zamieszczam bezpośredni test w 3ds z powyżej wymienionym i7 i tym i5), ale jedynie do czasu wykorzystania nowinek z Haswella - i5 jest Jak widać wyżej i7 3770 jest bardziej wydajny od tego i5 AŻ o 2.4%, a po aktualizacji oprogramowania będzie wręcz przeciwnie. i5 4670 nie ma startu do i7 tej samej generacji gdzie różnica wynosi w okolicach 20% do i7 4770, ale z i7 poprzedniej generacji spokojnie może stawać do walki... ofc obroncy starego Xeona (4x rdzenie Sandy Bridge 8x wątków), nawet wyżej spoglądać nie powinni bo i7 2700K (4x rdzenie Sandy Bridge, 8x wątków... i to wyżej taktowanych niż w tym Xeonie) wypada jak widać gorzej (Xeon z niższym taktowaniem byłby tylko gorszy).

Zdaje się, że mówił o 8x rdzeniowym, więc nie o tym. Co do tego co podałeś 4x rdzeniowego z HT to IMHO nie ma się nawet co nad tym zastanawiać. Większość czasu pracy będzie wydajniejszy (2x generacje nowszy CPU + wyższa częstotliwość dają mu około 15% przewagi), a w renderingu w Mentalu HT nie odrobi tego 15%, więc i tak ten i5 będzie szybszy (już pomijam renderery OpenCL, na których CPU z i5 może pomagać GPU (nawet jak działa inne GPU w Viewporcie), którego ten Xeon wcale nie ma). Dlatego tylko tak wtrąciłem o LW, ale w 3ds Maxie 2x na 2x więcej wątków zyskujesz tylko 8% (na tym samym CPU) Ten i7 jest faktycznie szybszy, bo nie jest tak stary jak ten Xeon, a HT, które niewiele daje ale jednak te kilka % tak... i w syntetycznym benchmarku jest 11% wydajniejszy... w Maxwell render już powinno być około remisu (jedyny test renderera w podanym przez Ciebie teście to CINEBENCH R10 i 7% różnicy wydajności, a ten renderer jest najbardziej sprzyjającym HT z istniejących rendererów), a w wydaniach najnowszych (lub przyszłorocznym) powinno już być sporo na korzyść tego i5 (gdy kompilatory będą wspierać już AVX w wersji 2 (od serii 4k) czy FMA w wersji 2 (od serii 4k)). Ogólnie mocno zastanawiałbym się w tej samej cenie, ale różnica pomiędzy tym i5 i i7 to 300zł, a różnica wydajności mocno marginalna z perspektywą zmian w sofcie na i5 będzie wydajniejszy... cóż ten i7 mnie nie przekonuje - już prędzej i7 z serii 4k, ale te kosztują już w okolicach 450zł więcej więc nie jest to jakaś 100% jasny wybór, a opcja do rozważenia (z pewnością nie w wyżej wymienionym budżecie)

Śmiesznie brzmi "tylko 4 jajka", bo taką ilość rdzeni mają najmocniejsze desktopowe procesory... raczej nie wychwalasz rozwiązania HT (czyli 4x rdzeniowe, ale 8x wątkowe jak w i7), bo w pracy niewiele to da poza minimalnie (dosłownie) lepszym czasem renderingu http://www.extremetech.com/computing/133121-maximized-performance-comparing-the-effects-of-hyper-threading-software-updates (w Maxwell czy Mental Ray - bo w rendererze Lightwave przykładowo HT i więcej wątków wręcz spowalnia rendering). Raczej nie radzisz procesorów AMD, które mimo 8x rdzeni, mają tak słabe pojedyncze rdzenie, że nawet w wielowątkowości są słabsze, nie mówiąc o różnicy przy modelowaniu i ogólnie pracy poza renderingiem są po prostu beznadziejne (bo poza renderingiem kod programów zazwyczaj jest jednowątkowy). Xeony możesz radzić 8x rdzeniowe, ale sam taki procesor kilkukrotnie przewyższa tu budżet, a co dopiero z resztą podzespołów (w tym niezbyt tania płyta do niego), więc porada bardzo teoretyczna i bardzo pozbawiona sensu (czemu nie radzić zbudowania sobie farmy renderującej z tysiąca procesorów - będzie działać jeszcze szybciej i jeszcze bardziej poza budżetem).

Przyzwoity procesor do stacjonarnego komputera kosztuje około 1 tys zł, podobnie karta graficzna... tylko te "przyzwoite" do stacjonarek są dużo wydajniejsze od najwydajniejszych laptopowych rozwiązań - gdzie CPU kosztuje 3 tys zł i podobnie karta graficzna. Zapewne traktujesz i5 mobilne jak i5 stacjonarne (podczas gdy średni stacjonarny i5 jest wydajniejszy od mobilnych i7 Extreme Edition)... podobnie jest z GPU. Dlatego za podobny wydajnościowo sprzęt musiałbyś wydać wielokrotnie więcej (dlatego laptopy są droższe - tej klasy co ten komputer z pierwszego posta laptop, kosztowałby minimum kilkanaście tysięcy zł). Ofc nie przeczę temu, że Kramon jak zwykle gada trochę obok tematu i nie koniecznie z sensem. Słabsza karta, ale z większą ilością pamięci nikomu do szczęścia nie jest potrzebna (ten CPU będzie szybciej liczył, a do viewportu 1gb spokojnie wystarczy). Jeśli jednak się ma zamiar renderować na GPU to nawet niewielkie scenki i bardzo ograniczona ilość tekstur zabiją to 1GB - tekstura 4k na 4k pixeli zajmuje 64MB w pamięci GPU (w rendererach GPGPU muszą być w postaci czystej nieskompresowanej) czyli zmieści Ci się na karcie 14x tekstur (odliczam 100MB na siatkę), a jeśli będziemy pamiętać o tym, że tekstur ma po kilka każdy obiekt (spec, normal, kolor...) to niewiele możemy zdziałać - ofc mniejsze tekstury pozwolą na wyrenderowanie czegoś, ale poszaleć z 1gb nie poszalejemy. Ogólnie jednak nie nalegałbym na więcej niż 1GB, bo to zależy czy ogólnie ktoś chce renderować na GPU (w viewporcie są kompresowane w stosunku minimum 1 do 4, a często też jest ich rozdzielczość zmniejszana, więc nie obawiałbym się o viewport, a jedynie o renderowanie)... jednak ze względu na to, że podana w zestawie karta w wersji 1GB kosztuje około 530zł, a 2GB 570zł to nie oszczędzałbym tych 40zł.

O takich rzeczach to zapomnij na PC do filmów czy nawet gier - tak to sobie mogę robić materiały glossy na telefonie komórkowym, ale nie na PC gdzie jakość jest wyższa wymagana. W PC w najnowszych silnikach stosuje się*Voxel Cone Tracing https://research.nvidia.com/sites/default/files/publications/GIVoxels-pg2011-authors.pdf i ofc dalej jest to lekki fake obniżający jakość względem wydajności, ale już nie większy niż Pixar/ILM ze swoimi Point-Based Global Illumination (podobny fake - ba nawet działający na tej samej zasadzie, z tym, że Voxele są bardziej uporządkowane, a Chmura punktów jest chaotyczna) w największych produkcjach filmowych/animowanych.

To co tam pokazali to znane od prawie 2ch lat ich rozwiązanie Separable Subsurface Scattering (więc SSSS, a nie SSS ;p). CryEngine 2 czy Unreal Engine 3 korzystały z 5x S czyli Screen Space Subsurface Scattering (poprzedni SSS, od tego kolesia z Activision z 2011 roku - w CE2 pojawił się ten shader przed wydaniem przez kolesia z Activision publikacji, a w UE3 miesiąc po), ale prawdopodobnie w CE3 u UE4 zobaczymy nowszą odsłonę SSS (opublikowane papiery wraz z gotową implementacją są od początku 2012 roku, ale nowa generacja silników dopiero teraz). Ogólnie to co pokazywałeś wyżej to nie jest z okazji shaderu SSS skóry robione http://www.iryoku.com/separable-sss-released, a z okazji shaderu oczu http://www.iryoku.com/open-your-eyes ewentualnie animacji od ICT (z której korzystała też Nvidia przy Face Works) czyli Digital Ira i demonstracji na GDC. Nie chcę Cię zasmucać, ale począwszy od UP SSS u Pixara raczej ma niższą jakość niż wcześniej... jedyne co to jest bardziej wyeksponowane. Razem z UP Pixar zamienił raytracing GI, raytracing SSS na metodę zupełnie inną - dokładniej opartą o chmurę punktów, która obniża jakość, ale niesłychanie zmniejsza czas renderingu - ze względu na szybsze renderowanie SSS w nowych produkcjach nie muszą sobie odmawiać, bo dawniej ze względów czasowych SSS było tylko tam gdzie niezbędne (bo czas renderowania zabijał możliwość powszechnego stosowania).

Warto wziąć pod uwagę to, że laptopowe i5 zasysają. Najlepszy mobilny i5 ma 2x rdzenie w okolicach 2.8GHz... ten i5 który podałeś jest desktopowy, a to zupełnie inna klasa sprzętu - ma 4x rdzenie i 3.2GHz więc nie ma porównania. i7 w drugiej podanej konfiguracji też ma 4x rdzenie troszkę wyżej taktowane bo 3.4 GHz, więc tylko 6% większa częstotliwość... jednak i7 posiada Hyper-threading, więc w zależności od oprogramowania będzie większa różnica niż te 6%, ale nie tak znowu wiele - podaje link z testami jednego procka z i bez HT w programach graficznych, abyś miał pogląd ile i w czym zyskasz na i7 (w Maya czy 3ds Max praktycznie nic w czasie pracy, a i minimalnie w renderingu w mental ray) http://www.extremetech.com/computing/133121-maximized-performance-comparing-the-effects-of-hyper-threading-software-updates. Ogólnie rzecz biorąc jeśli pytałbyś o procka do laptopa, to po pierwsze odradzałbym laptopa (najmocniejsze i7 laptopowe będą wolniejsze od tego i5 z Twojego postu, a w dodatku kosztować będą po kilkanaście tysięcy zł (sam najlepszy mobilny procek i7 kosztuje 1100$, nie licząc reszty laptopa, a jest mniej wydajny niż ten i5)), ale jeśli już laptop to i7... skoro jednak stawiasz na stacjonarkę to IMHO i5 desktopowy Ci wystarczy, bo różnica wydajności tych procesorów jest dużo mniejsza duża niż różnica w cenie (edit: mówisz o małej różnicy w cenie (210zł) ale chyba zapominasz o widocznie słabszym GPU przy i7). Viewport zależy od karty graficznej, a nie od procesora. Jeśli procesor jest u niego wąskim gardłem to nie rozumiem po co gadasz od rzeczy o viewporcie?

Faktycznie coś z blenderem jest nie tak. Normalizacja to podstawowe działanie na wektorach, node jest w menu Vector... a nie przyjmuje wektorów nie działa na nich jak powinno, a zmienia dynamikę całej kompozycji w oparciu o pojedyncza wartość danego pixela (przykładowo zawartość bufora Z, aby było widoczne w zakresie widzialnym dla oka). Ogólnie ten node nie działa jak powinien (zgodnie z matematyczną definicją normalizacji wektora - czyli tak jak opisano działanie w dokumentacji http://wiki.blender.org/index.php/Doc:2.6/Manual/Composite_Nodes/Types/Vector ), a działa bardzo dziwnie - nawet jeśli wydaje się*że w tym wypadku działa raczej odradzałbym stosowanie go i jeśli ktoś nie lubi 2ch nodów to niech użyje Map Range.