Jump to content

darmowa render farma


Recommended Posts

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

Link to post
Share on other sites
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?

Link to post
Share on other sites
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

Link to post
Share on other sites
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.

Link to post
Share on other sites

Create an account or sign in to comment

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

Create an account

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

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We are using cookies. Read about our Privacy Policy