człowiek Napisano 22 Luty 2010 Share Napisano 22 Luty 2010 Dobrze zrozumiałem ze strony Luxrendera, że są w fazie testów z wykorzystaniem GPU do obliczeń, ale na razie nie udostępnili aplikacji? Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Skoti Napisano 22 Luty 2010 Share Napisano 22 Luty 2010 Dobrze zrozumiałem ze strony Luxrendera, że są w fazie testów z wykorzystaniem GPU do obliczeń, ale na razie nie udostępnili aplikacji? Źródła są dostępne i można sobie zbudować we własnym zakresie - ale póki szkoda czasu (póki co nawet nie nadaje się do testów). Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
człowiek Napisano 23 Luty 2010 Autor Share Napisano 23 Luty 2010 Szkoda, bo już czas, żeby wreszcie powstało coś poważnego w wersji darmowej Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Gość Gosc Napisano 23 Luty 2010 Share Napisano 23 Luty 2010 same zrodla nie zrownolegla niektorych operacji, trzeba troche potweakowac :D ale faktycznie majac zrodla i ogolna wiedze na temat kodu zrodlowego Luxrendera mozna to w miare latwo zrobic najwieksyz problem raytracerow polega na tym ze jedynym miejscem gdzie mozna wprowadzic rownolegle obliczenia to tracer glownych promieni z kamery,cala reszta jest tak napisana ze nie daje sie za bardzo zrownoleglic, dlatego wyniki szybkich testow pokazuja ze cienkie jest to przyspieszenie - dlatego beda musieli poswiecic troche wiecej czasu, odrobic lekcje i poprawic ogolny workflow danych wewnatrz renderera tak zeby maksymalnie korzystac z rownoleglosci obliczen Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Skoti Napisano 24 Luty 2010 Share Napisano 24 Luty 2010 same zrodla nie zrownolegla niektorych operacji, trzeba troche potweakowac :D ale faktycznie majac zrodla i ogolna wiedze na temat kodu zrodlowego Luxrendera mozna to w miare latwo zrobic Tu nie chodzi o Tweakowanie źródeł Luxrendera. Jest udostępniona osobna gałąź gdzie przepisują na OpenCL (http://src.luxrender.net/lux-opencl/). Przecież na forum grafików nie pisałbym przepisz sobie sam ;p. Jednak póki co nie ma co w tym branchu oglądać (ostatnio jak testowałem scena cube i światełko wywalało program, bo zajętość pamięci hosta rosła w nieskończoność (8gb mam i się skończyło)). najwieksyz problem raytracerow polega na tym ze jedynym miejscem gdzie mozna wprowadzic rownolegle obliczenia to tracer glownych promieni z kamery,cala reszta jest tak napisana ze nie daje sie za bardzo zrownoleglic, dlatego wyniki szybkich testow pokazuja ze cienkie jest to przyspieszenie - dlatego beda musieli poswiecic troche wiecej czasu, odrobic lekcje i poprawic ogolny workflow danych wewnatrz renderera tak zeby maksymalnie korzystac z rownoleglosci obliczen Pathtracer da się na CPU zrównoleglić w bardzo wielu miejscach i na wielu poziomach (rzucanie promieni od kamery, da się przetwarzać równoległo, przeglądanie drzewa w poszukiwaniach który najbliższy obiekt został uderzony, tęż można na wiele wątków rozbić, rzucanie losowych sampli w GI/materiałach Glossy też się da zrównoleglić...). Z pisaniem tego na GPU jest trochę trudniej, ale też się da (w razie jak się nic nie wymyśli to można renderować w kilku przebiegach (każdy poziom, osobno i na każdym będziesz mógł przetwarzać równolegle)). Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Gość Gosc Napisano 24 Luty 2010 Share Napisano 24 Luty 2010 Pathtracer da się na CPU zrównoleglić w bardzo wielu miejscach i na wielu poziomach (rzucanie promieni od kamery, da się przetwarzać równoległo, przeglądanie drzewa w poszukiwaniach który najbliższy obiekt został uderzony, tęż można na wiele wątków rozbić, rzucanie losowych sampli w GI/materiałach Glossy też się da zrównoleglić...). Z pisaniem tego na GPU jest trochę trudniej, ale też się da (w razie jak się nic nie wymyśli to można renderować w kilku przebiegach (każdy poziom, osobno i na każdym będziesz mógł przetwarzać równolegle)). no niby tak, ale popatrz jak jest napisany... obiektowo, sciezki sa roznej dlugosci, a to co oferuja wspolczesne GPU najlepiej zeby odbywalo sie w turach o tej samej dlugosci, dlatego zadna optymalizacja na "pale", w stylu o znalazlem fajna petle ktora da sie zrownoleglic nie przyniesie dobrych skutkow, a tak narazie wszyscy chca na sile zrownoleglac Luxrendera Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Skoti Napisano 24 Luty 2010 Share Napisano 24 Luty 2010 no niby tak, ale popatrz jak jest napisany... obiektowo, sciezki sa roznej dlugosci, a to co oferuja wspolczesne GPU najlepiej zeby odbywalo sie w turach o tej samej dlugosci, dlatego zadna optymalizacja na "pale", w stylu o znalazlem fajna petle ktora da sie zrownoleglic nie przyniesie dobrych skutkow, a tak narazie wszyscy chca na sile zrownoleglac Luxrendera Możesz powiedzieć co to za różnica jak jest napisany (obiektowo możesz pisać i w C, mimo że nie jest to język obiektowy). Ścieżki są różnej długości, ale jak renderujesz w passach to możesz posortować, po kazdym passie (na GPU zeby było szybko) tak żeby na i wysłać do przeliczenia tylko te piksele które tego potrzebują... ale nawet bez tego wydajność GPU będzie dużo większa niż CPU (nawet jak w procesory strumieniowe w jednym core będzie np. 32 i będziesz, miał 1 piksel taki, że idzie na 5ty poziom, a 31 zostają na pierwszym to zysk z uzyskania 32 pikseli na raz zrównoważy poczekanie na ten 1 piksel kolejne 4 poziomy (na CPU w optymistycznym wypadku (4x core) te 32 piksele byłyby robione przez na 4xcore na 9 razy (31+5 poziomów czyli 36 dzielone 4 rdzenie w wypadku = 9 promieni na każdym wątku)) - ofc to się równoważy bo CPU przeważnie mają 2x większe taktowanie i szybciej wykonują pewne instrukcje... z tym że porównanie było do 1core na GPU a takich zestawów po 32procki jest więcej (po przemnożeniu się liczy w setkach/tysiącach) i w bardzo pesymistycznej dla gpu wersji (wszystkie czekają na jeden procek, a CPU nie czeka na nic- gdyby było więcej poziomów w tych które mają na 1 to CPU pogrążyłby się zupełnie)). Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Gość Gosc Napisano 24 Luty 2010 Share Napisano 24 Luty 2010 taka Roznica ze na pierwszym poziomie masz PathSampler, a to co dalej sie dzieje to jedna wolna amerykanka na ktora nie masz wplywu i ilosc kodu ktory sie odpala i roznice w dlugosciach sciezek moga byc od 1 do 100 zaleznie jak duzo odbic nastepuje i ten idealistyczny przypadek ktory podales odpada, bo w srednim przypadku te 31 jednostek bedzie czekac 100 cykli az najdluzsza sciezka dobiegnie do konca... nie jest tak prosto jak sie wydaje i to wlasnie ze wzgledu na obiektowa konstrukcje kodu i nature sledzenia sciezek Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Skoti Napisano 24 Luty 2010 Share Napisano 24 Luty 2010 taka Roznica ze na pierwszym poziomie masz PathSampler, a to co dalej sie dzieje to jedna wolna amerykanka na ktora nie masz wplywu i ilosc kodu ktory sie odpala i roznice w dlugosciach sciezek moga byc od 1 do 100 zaleznie jak duzo odbic nastepuje i ten idealistyczny przypadek ktory podales odpada, bo w srednim przypadku te 31 jednostek bedzie czekac 100 cykli az najdluzsza sciezka dobiegnie do konca... Nie dzieje się wolna amerykanka i licząc w wielu pasach liczysz tylko to co musisz i nic nie czeka (to z czekaniem to był przypadek jakby nic nie zmieniać). Poza tym podaj mi kto liczy na 100 poziomów (nikogo nie obchodzi światło odbite więcej niż 4 razy, ani które przejdzie przez 5-6 ścianek), a ty mówisz o śledzeniu 100 poziomów ;p. Jednak w przypadku robienia w passach nic nie czeka. nie jest tak prosto jak sie wydaje i to wlasnie ze wzgledu na obiektowa konstrukcje kodu i nature sledzenia sciezek Kolejny raz się pytam co Cię tak boli obiektywność, skoro to nic nie zmienia (minimalnie zmienia zapis, ale nie jest to zmiana godna wspomnienia). Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Gość Gosc Napisano 24 Luty 2010 Share Napisano 24 Luty 2010 Nie dzieje się wolna amerykanka i licząc w wielu pasach liczysz tylko to co musisz i nic nie czeka (to z czekaniem to był przypadek jakby nic nie zmieniać). Poza tym podaj mi kto liczy na 100 poziomów (nikogo nie obchodzi światło odbite więcej niż 4 razy, ani które przejdzie przez 5-6 ścianek), a ty mówisz o śledzeniu 100 poziomów ;p. Jednak w przypadku robienia w passach nic nie czeka. Kolejny raz się pytam co Cię tak boli obiektywność, skoro to nic nie zmienia (minimalnie zmienia zapis, ale nie jest to zmiana godna wspomnienia). dobra, szkoda sie klocic, pokaz kod/fragmenty kodu LuxRendera ktore sie tak latwo daly zoptymalizowac passy dotycza integracji pierwszego poziomu, czyli distributed rendering, a sciezki juz podlegaja mutacjom i rosyjskiej ruletce, dlatego ciezko jest okreslic ad hoc jak dlugie beda sciezki i dekompozycja tego na passy wymaga zmiany podejscia, w obiektowym modelu naraz pracujesz na pojedynczej sciezce to sie swietnie zrownolegla ale pod warunkiem odseparowanych procesorow, jak wiadomo na wspolczesnych GPU nie bedzie tak rozowo argument co do dlugosci sciezek ograniczonych do 4 odpada, gdybys chcial uzywac tak krotkich sciezek to rownie dobrze mozesz nie uzywac path tracera... bo i po co, to co sie zalapie w sciezkach o dlugosciach 1-4 to bardzo trywialne przeplywy swiatla, te nietrywialne pojawiaja sie dopiero przy dluzszych sciezkach Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Skoti Napisano 24 Luty 2010 Share Napisano 24 Luty 2010 dobra, szkoda sie klocic, pokaz kod/fragmenty kodu LuxRendera ktore sie tak latwo daly zoptymalizowac Na razie się nie dały, bo jeszcze dobrze nie zaczęli robić. passy dotycza integracji pierwszego poziomu, czyli distributed rendering, a sciezki juz podlegaja mutacjom i rosyjskiej ruletce, dlatego ciezko jest okreslic ad hoc jak dlugie beda sciezki i dekompozycja tego na passy wymaga zmiany podejscia Passy nie muszą służyć tylko do tego, a można ich użyć jak przy Deferred shading gdzie przy renderingu pierwszego poziomu zapisujesz dane potrzebne przy kolejnym passie (kolejnej głębokości) i możesz spokojnie to posortować i wysłać do przeliczania tylko te ścieżki, które tego potrzebują. w obiektowym modelu naraz pracujesz na pojedynczej sciezce to sie swietnie zrownolegla ale pod warunkiem odseparowanych procesorow, jak wiadomo na wspolczesnych GPU nie bedzie tak rozowo Z obiektowością nie ma to nic do rzeczy, a dzisiejsze pathtracery na raz pracują na kilku ścieżkach (a każda z tych ścieżek jest liczona na kilku rdzeniach). argument co do dlugosci sciezek ograniczonych do 4 odpada, gdybys chcial uzywac tak krotkich sciezek to rownie dobrze mozesz nie uzywac path tracera... bo i po co, to co sie zalapie w sciezkach o dlugosciach 1-4 to bardzo trywialne przeplywy swiatla, te nietrywialne pojawiaja sie dopiero przy dluzszych sciezkach Głównym powodem użycia pathtracerów jest GI i właśnie nie obchodzi cię jakie GI ma 100 obiekt w kolejce odbicia, tylko pierwszy, ewentualnie 2gi - głębiej cię nie obchodzi (nie obchodzi Cię to jaki kolor oczu ma obiekt w innym pomieszczeniu ;p)... za to bardzo ważna dla jakości obrazu (mały szum) jest ilość sample (czyli drzewo pathtracera nie idzie w głąb, tylko w szerz (każda ścieżka ma po kilka poziomów, ale różnych ścieżek jest olbrzymia ilość), co świetnie się zrównolegla na GPU i CPU). Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Gość Gosc Napisano 25 Luty 2010 Share Napisano 25 Luty 2010 Na razie się nie dały, bo jeszcze dobrze nie zaczęli robić. no ponad 300tys linii kodu robi swoje, to co ugryzl Dade, to czubek gory lodowej, zabral sie za przeciecia promieni z obiektami Passy nie muszą służyć tylko do tego, a można ich użyć jak przy Deferred shading gdzie przy renderingu pierwszego poziomu zapisujesz dane potrzebne przy kolejnym passie (kolejnej głębokości) i możesz spokojnie to posortować i wysłać do przeliczania tylko te ścieżki, które tego potrzebują. no mozna, jak najbardziej tylko kloci sie to z algorytmem pathtracera ktory zaimplementowano, gdzie sciezki sa laczone dynamicznie lub mutowane z dluzszych sciezek i wtedy juz tak latwo nie daje sie zdekomponowac algorytmu na passy - tutaj jest pole do popisu Z obiektowością nie ma to nic do rzeczy, a dzisiejsze pathtracery na raz pracują na kilku ścieżkach (a każda z tych ścieżek jest liczona na kilku rdzeniach). pracuja na seriach sciezek i ich mutacjach - trzeba to oddzielnie zrownoleglic, bo w obecnej implementacji czesc sciezek powstaje ze sciezek w serii, co utrudnia dekompozycje na duza ilosc niezaleznych sciezek - jest silna zaleznosc sciezek zmutowanych z juz istniejacych, oczywiscie mozna przyjac jakas heurystyke ustalajaca progi podzialu ilosci sciezek do mutacji - i tutaj rowniez jest pole do popisu, ale jak widac przyjety algorytm utrudnia zadanie Głównym powodem użycia pathtracerów jest GI i właśnie nie obchodzi cię jakie GI ma 100 obiekt w kolejce odbicia, tylko pierwszy, ewentualnie 2gi - głębiej cię nie obchodzi (nie obchodzi Cię to jaki kolor oczu ma obiekt w innym pomieszczeniu ;p)... za to bardzo ważna dla jakości obrazu (mały szum) jest ilość sample (czyli drzewo pathtracera nie idzie w głąb, tylko w szerz (każda ścieżka ma po kilka poziomów, ale różnych ścieżek jest olbrzymia ilość), co świetnie się zrównolegla na GPU i CPU). no to jest oczywista-czywistosc jak mawia moj znajomy, ale niestety nie do zrealizowania przy obecnym algorytmie Luxrendera, bez pozbycia sie tych zaleznosci i przejscia na pelnego bruteforcea ciezko bedzie zrealizowac tak utopijne zalozenie - z kolei przejscie na bruteforca bez zaleznosci miedzy sciezkami: mutacje istniejacych, skracanie istniejacych, czesc pary pojdzie na ogrzewanie atmosfery ziemskiej bo na pewno nie na szybsze obliczenia co do zalozen pathtracerow bardzo sie mylisz, wlasnie po to stworzono mutowanie sciezek i generowanie dlugich sciezek zeby rozwiazywac problemy bardzo zlozonych przeplywow swiatla i stosowanie pathtracera do obliczania swiatla pochodzacego z najblizych obiektow to jak strzelanie do muchy z armaty, jest pelno prostych algorytmow ktore radza sobie z tym lepiej Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Skoti Napisano 25 Luty 2010 Share Napisano 25 Luty 2010 no mozna, jak najbardziej tylko kloci sie to z algorytmem pathtracera ktory zaimplementowano, gdzie sciezki sa laczone dynamicznie lub mutowane z dluzszych sciezek i wtedy juz tak latwo nie daje sie zdekomponowac algorytmu na passy - tutaj jest pole do popisu Klasycznego pathtracera nie ma w Luxrender - tam jest bi-pathtracer, ale też nie klasyczny bo to rendering unbiased z Metropolis light transport (który jest mutacją metody Monte Carlo)... więc już na wstępie kłuci się z "algorytmem pathtracera" - co do wersji GPU to ona nie ma działać tak samo, a to samo generować i nie ma co sztywno się trzymać tego co było pisane dla Cpu (daje się łatwo zdekomponować na passy, ale trzeba robić multi render target, żeby zapisywać więcej informacji niż kolor jak normalnie). no to jest oczywista-czywistosc jak mawia moj znajomy, ale niestety nie do zrealizowania przy obecnym algorytmie Luxrendera, bez pozbycia sie tych zaleznosci i przejscia na pelnego bruteforcea ciezko bedzie zrealizowac tak utopijne zalozenie - z kolei przejscie na bruteforca bez zaleznosci miedzy sciezkami: mutacje istniejacych, skracanie istniejacych, czesc pary pojdzie na ogrzewanie atmosfery ziemskiej bo na pewno nie na szybsze obliczenia Ale kto powiedział, że będzie stosowany algorytm z CPU, a nie jego modyfikacja? co do zalozen pathtracerow bardzo sie mylisz, wlasnie po to stworzono mutowanie sciezek i generowanie dlugich sciezek zeby rozwiazywac problemy bardzo zlozonych przeplywow swiatla i stosowanie pathtracera do obliczania swiatla pochodzacego z najblizych obiektow to jak strzelanie do muchy z armaty, jest pelno prostych algorytmow ktore radza sobie z tym lepiej Tak tylko tym złożonym przepływem jest samo GI. Nie do tego "stworzono" generowanie długich ścieżek (które jest w raytracerach dla wielokrotnych odbić bardziej przydatne), bo sam pathtracer (jako rozwinięcie raytracingu, czyli od kamery do światła) nie pozwala liczyć dokładnego przepływu światła (nie masz np. kaustyki). To daje path casting lub inaczej zwany forward pathtracer (w przeciwieństwie do klasycznego pathtracera i raytracerów, a podobnie jak w Forward raytracing promienie idą od światła do kamery (i ten rodzaj rendererów wymaga już długich ścieżek i daje lepsze rezultaty)). Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Gość Gosc Napisano 26 Luty 2010 Share Napisano 26 Luty 2010 caly czas tlumaczysz oczywistosci, przeciez kazde dziecko wie ze w luxie siedzi bipathtracer, ktory laczy sciezki i od kamery i od swiatla i radzi sobie z wszystkimi przeplywami, byc moze w kontekscie tego ze myslisz o zastosowaniu zwyklego path tracera ktory ma klopoty z kaustyka - w kodzie na GPU tak czy inaczej, nie musisz mi tlumaczyc algorytmow, bo znam je na wylot, wytlumacz mi jak zaimplementujesz wydajnie bipathtracer na GPU, i to jeszcze z "paluszkiem w pewnym ciemnym miejscu", bo sorry ale generowanie miliardow sciezek zwyklym pathtracerem po to ze moze przy okazji cos trafi w swiatlo nietrywialna sciezka jest smieszne i nieefektywne - tutaj sie rozmijamy, ja mysle o dwukierunkowym pathtracerze a ty po malemu cichu wciskasz mi pathtracer na GPU jako super rozwiazanie i bardziej wydajne Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
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ę