pressenter Napisano 26 Kwiecień 2010 Napisano 26 Kwiecień 2010 Hmm, czyżby idea obliczeń rozproszonych zastosowana do renderowania? Wygląda obiecująco przyznam, również po przeczytaniu komentarzy na FB od użytkowników. Dzięki za newsa. Sz.
Reanimator Napisano 27 Kwiecień 2010 Napisano 27 Kwiecień 2010 ja postanowilem sie przylaczyc, chociaz nie uzywam blendera. Dla idealow:) Takze jakbys Aniu, czy ktokolwiek inny potrzebowal, to mozecie na moim komputerze liczyc;)
hcpiter Napisano 27 Kwiecień 2010 Napisano 27 Kwiecień 2010 "Learn how to use vSwarm with Blender and LuxRender in our wiki" fuuuuuuuuuuu!!!
Gość Gosc Napisano 27 Kwiecień 2010 Napisano 27 Kwiecień 2010 no takie nie do konca rozproszone liczenie, po chamsku obraz systemu z blenderem i luxem odpala sie u kogos i zamula kompa na maxa :D troche malo to optymalne i bezpieczne dla srodowiska :P kiedy ktos w koncu z jajami na miejscu napisze rozproszony renderer, ja pokladam wielkie nadzieje w Thea Renderer ale to tez nie do konca tak wyglada jakby moglo, bo ciagnie cala scene i tekstury, mam nadzieje ze chociaz spakowane :P
SYmek Napisano 28 Kwiecień 2010 Napisano 28 Kwiecień 2010 no takie nie do konca rozproszone liczenie, po chamsku obraz systemu z blenderem i luxem odpala sie u kogos i zamula kompa na maxa :D troche malo to optymalne i bezpieczne dla srodowiska :P kiedy ktos w koncu z jajami na miejscu napisze rozproszony renderer, ja pokladam wielkie nadzieje w Thea Renderer ale to tez nie do konca tak wyglada jakby moglo, bo ciagnie cala scene i tekstury, mam nadzieje ze chociaz spakowane :P Dlaczego wirtualizacja, na której opiera się cały cloud computing business, nie jest rozproszonym liczeniem? Mógłbyś sprecyzować, co w takim razie oznacza ten termin?
Gość Gosc Napisano 28 Kwiecień 2010 Napisano 28 Kwiecień 2010 Dlaczego wirtualizacja, na której opiera się cały cloud computing business, nie jest rozproszonym liczeniem? Mógłbyś sprecyzować, co w takim razie oznacza ten termin? bo jest to rozproszenie obliczen w wersji dla biednych (umyslowo) a bogatych (w sprzet i zasoby systemowe) jest to najkosztowniejsza wersja rozproszenia obliczen jaka sobie mozna wymyslec - i najbardziej prosta do realizacji nikt nie pochylil sie zeby zrobic cloud computing z prawdziwego zdarzenia, na zasadzie dekompozycji zadania renderingu na skladowe niskiego poziomu, np. uslugi filtrowania bitmap, sledzenia promieni etc - jest to duzo bardziej skomplikowane do opanowania, ale wtedy obciazenie jednego punktu sieci rozproszonej byloby optymalne i wydajnosc systemu calosciowo duzo lepsza, nikt nie bierze pod uwage tego ze wrzucanie calego zadania na jednego node'a wymaga zaladowania wszystkich danych, co moze trwac wieki - i konsekwentnie: mniej wydajne node'y skutecznie spowalniaja zakonczenie zadania no ale rzeczy trudne zazwyczaj sa nie do zrealizowania, wspolczesni programisci ida na taka latwizne ze juz zeby bola, a rozwiazania sa w zasiegu reki, skoro daje sie zdekomponowac algorytmy do pracy batchowej na GPU gdzie wykonywane sa duze ilosci identycznych obliczen o charakterze jednostkowym (chociaz tutaj tez mam duzo zastrzezen bo wcale tak nie jest we wspolczesnych rozwiazaniach) to mozna sie pochylic i analogicznie przeprowadzic synteze systemu rozpraszajacego pool'e zadan podstawowych, np. obliczen na wektorach, ktore mozna podeslac duzo szybciej bez ciagania wszystkich danych tam i spowrotem
bapi23 Napisano 28 Kwiecień 2010 Napisano 28 Kwiecień 2010 Hcpiter - tak piszą osoby, które nigdy na oczy nie widziały Blendera, Luxrendera i całe życie renderują w Vrayu. Lux Render nadal zablokowany na vswarm, więc wypadałoby poprawić newsa...
Creator Napisano 28 Kwiecień 2010 Napisano 28 Kwiecień 2010 Niestety to jest na razie kupa. Sceny czekają w kolejkach godzinami, często nie kończą się renderować. Trzeba poczekać aż udoskonalą to od strony technicznej.
narwik Napisano 28 Kwiecień 2010 Napisano 28 Kwiecień 2010 Jeszcze jest BURP, który działa już od paru lat: http://burp.renderfarming.net/ , też dla Blendera.
SYmek Napisano 28 Kwiecień 2010 Napisano 28 Kwiecień 2010 bo jest to rozproszenie obliczen w wersji dla biednych (umyslowo) a bogatych (w sprzet i zasoby systemowe) jest to najkosztowniejsza wersja rozproszenia obliczen jaka sobie mozna wymyslec - i najbardziej prosta do realizacji nikt nie pochylil sie zeby zrobic cloud computing z prawdziwego zdarzenia, na zasadzie dekompozycji zadania renderingu na skladowe niskiego poziomu, np. uslugi filtrowania bitmap, sledzenia promieni etc - jest to duzo bardziej skomplikowane do opanowania, ale wtedy obciazenie jednego punktu sieci rozproszonej byloby optymalne i wydajnosc systemu calosciowo duzo lepsza, nikt nie bierze pod uwage tego ze wrzucanie calego zadania na jednego node'a wymaga zaladowania wszystkich danych, co moze trwac wieki - i konsekwentnie: mniej wydajne node'y skutecznie spowalniaja zakonczenie zadania no ale rzeczy trudne zazwyczaj sa nie do zrealizowania, wspolczesni programisci ida na taka latwizne ze juz zeby bola, a rozwiazania sa w zasiegu reki, skoro daje sie zdekomponowac algorytmy do pracy batchowej na GPU gdzie wykonywane sa duze ilosci identycznych obliczen o charakterze jednostkowym (chociaz tutaj tez mam duzo zastrzezen bo wcale tak nie jest we wspolczesnych rozwiazaniach) to mozna sie pochylic i analogicznie przeprowadzic synteze systemu rozpraszajacego pool'e zadan podstawowych, np. obliczen na wektorach, ktore mozna podeslac duzo szybciej bez ciagania wszystkich danych tam i spowrotem No nie wiem..., to znaczy wiem, że kompletnie nie rozumiem, skąd ta pewność, że nie istnieją powody, których nie znasz a które sprawiają, że takich systemów się nie rozwija. Dlaczego akurat lenistwo? Naprawdę zagadkowa opinia. Spodziewam się natomiast, że tych kilka tysięcy matematyków i inżynierów, którzy zajmują się rendererami zawodowo, a którzy stanowią, obok ludzi od symulacji, awangardę naukowców w tej branży, wie coś, co powstrzymuje ich od rozwijania modelu, który opisujesz. Chyba, że opacznie Cię rozumiem... Dzielenie renderowania na atomowe części i posyłanie ich innym, czyli poza cache procesora, nie ma najmniejszego sensu, ponieważ już dzisiaj bodaj największym "spowalniaczem" procesu nie są same obliczenia (algebra wektorów etc), tylko dostęp do danych, na których te obliczania mają być wykonane. Gdyby Xeony miały cache mieszczący w sobie całą scenę, rendering odbywałby się o rząd wielkości szybciej. To komunikacja na zewnątrz jest za wolna. Ty tymczasem oczekujesz (jeśli dobrze rozumiem?), że programiści wykorzystają jeden procesor do teselacji, drugi (najlepiej po drugiej stronie świata, jak to ma miejsce w cloudach) do filtrowania tekstur, a trzeci wykona kod shadera? Przecież to przepis na najwolniejszy renderer świata, a do tego najbardziej zawodny! Odnoszę wrażenie, że mylisz się też co do analogii z GPU. Marność obecnych rozwiązań bierze się właśnie stąd, że wszystkie dane, na których operuje taki renderer GPU muszą być upakowane do pamięci karty w optymalnej strukturze. Wszystko co nie mieści się w tym schemacie odbywa się wielokrotnie wolniej niż na CPU. Stąd te renderery to zabawki, potwornie ograniczone i nieelastyczne. Właściwie jedyne co potrafią dobrze, to wykorzystać 256 rdzeni do śledzenia promieni z wykorzystaniem wspólnej struktury akceleracji, która musi znajdować się w pamięci karty (i którą przygotowuje dla nich CPU). A jeśli trzeba przefiltrować dużą teksturę, wykonać długi shader z wieloma warunkami, otworzyć teksturę 3d albo policzyć kosztowny noise? Dupa. Przeładowania pamięci karty nie wchodzi w rachubę, obliczenie czegoś kosztownego poza GPU i przesłania na kartę zajmuje wieki. Reasumując, GPU to modelowy przykład tego, że renderingu nie da się sprawnie rozproszyć z wykorzystaniem platformy komunikacji o prędkości PCI, nie wspominając już o ethernet. Wygląda na to, że jest dokładnie odwrotnie niż opisujesz. Najlepszym, najbardziej efektywnym i niezawodnym rozwiązaniem, jest właśnie oddanie każdej klatki lub bucketa innej maszynie. Nikt tu nikogo nie spowalnia... żadna maszyna nie przeszkadza innym. Doskonałe rozproszenie. Sprawdza się to właśnie dlatego, że każdy klient przechowuje w pamięci swoją kopię danych. Bez superszybkiej pamięci współdzielonej (na poziomie wewnętrznych prędkości procesora) inne rozwiązanie nie ma praktycznego sensu. Inna sprawa to kompletnie zbędna komplikacja kodu, który trzeba by napisać dla takiego potworka. Po co? Przecież to proszenie się o kłopoty. Dobre rozwiązania, to proste rozwiązania.
tomik8on69 Napisano 29 Kwiecień 2010 Napisano 29 Kwiecień 2010 mam nadzieje że evermotion ze swoim noxem przyłączy się to jednego z tych projektów , ich silnik póki co strasznie wolno rędzi i takie coś w sam raz.
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ę