Jump to content
adek

Flowbox FX - narzędzie do przetwarzania i kompozycji obrazów

Recommended Posts

Fajnie by było zobaczyć jakiś filmik bo na razie trochę enigmatycznie na stronie :)

No ale jak alfa dopiero to się nie dziwie :)

 

Pozdr.

Share this post


Link to post
Share on other sites

Cześć :) Jestem jedną z osób, która poczyniła Flowboxa :) Jeżeli macie pytania, z ochotą na nie odpowiem :)

 

@Mortom: Bardzo dziękujemy za uwagę. Obecnie jesteśmy pochłonięci dopieszczaniem wersji alpha, ale w niedalekiej przyszłości zamierzamy zamieścić więcej informacji na stronie :)

 

pozdrawiam, Wojtek

Share this post


Link to post
Share on other sites

Ja sie z chęcią zgłąszam na testera.

Kontakt: [email protected]

Folio niekomercyjne: www.deshu.pl

 

Obecnie pracuje nad wizkami produktowymi, wnętrzami, i 2 animacjami "for fun"

Dajcie znaka na maila, jeśli chcecie na mnei to potestować (tak, szukam tańszej alternatywy dla Nuke:P )

Share this post


Link to post
Share on other sites

@Kramon: Flowbox FX jest skupiony na przetwarzaniu i kompozycji obrazu, a więc jest zdecydowanie bardziej 2D.

 

Nie zmienia to jednak faktu, że przetwarzanie grafiki 2D jest przykładową funkcjonalnością, jaką można zbudować na Flowboxie. Nic nie broni Ciebie przed stworzeniem bloczków przetwarzających obiekty 3D, dźwięk, czy obliczających symulacje :)

Jako pierwszy "use case" wybraliśmy właśnie grafikę 2D.

 

Mam nadzieję, że ogólna idea jest teraz jaśniejsza? :)

 

 

@deshu: Zapraszam Cię na naszą stronę internetową: www.flowbox.io - tam możesz zapisać się do wersji alpha :)

 

Btw - nie chcemy być tylko tańszą alternatywą Nuka - chcemy dostarczyć narzędzie, które pozwoli Tobie na szybszą pracę, którą będziesz mógł lepiej dostosować do swoich potrzeb.

Mówię tu zarówno o technicznych jak i nietechnicznych aspektach pracy. Dla przykładu - nasz kompilator analizuje przepływ stworzony przez Ciebie, optymalizuje go i kompiluje, przez co nawet bardzo duże sceny składające się z tysięcy nodów powinny działać szybko, niczym pisane w C++. Mówię tu również o automatycznym zrównoleglaniu przepływu pomiędzy istniejące CPU i GPU czy też możliwości rozszerzania samej platformy (o własne narzędzia) przy użyciu nodów - bez potrzeby pisania pluginów w C++ lub innym niskopoziomowym, podatnym na błędy języku.

Edited by danilo2

Share this post


Link to post
Share on other sites

Brzmi to świetnie:) Dokałdnie tak pracuje w nuke. Zrobiłem sobie pare swoich gizmo, i właściwie już nie uzywam wbudowanych, defaultowych narzedzi.

 

 

Ok, wpisałem adres maila i odpaliłem rakiete, dzięki!

Share this post


Link to post
Share on other sites

@manabanana: Oczywiście na samym CPU też można pracować. Mamy obecnie wsparcie dla automatycznego rozpraszania na wiele CPU, ale nie wiem czy będzie to dostępne w Alphie. Jeżeli nie, to na pewno niedługo po jej wypuszczeniu :)

 

@deshu: Dzięki! Czekaj na powrót kosmonauty :D

Share this post


Link to post
Share on other sites

Mega szacun za ten flowbox. Ostatnio co raz bardziej siedzę w kreacji proceduralnej i jaram się wszelakimi nodalnymi systemami. :)

Share this post


Link to post
Share on other sites

@smiler: Na naszej stronie - jest podana na samym początku newsa :)

 

@Monio: Bardzo nas to cieszy :) Chyba właśnie dlatego cały nasz team zrezygnował z pracy zawodowej i zajął się tym projektem. Cieszy nas wizja platformy proceduralnej, która pozwala na przetwarzanie dowolnych danych (2D, 3D, dźwięku, symulacji etc) w bardzo wygodny i wydajny sposób. Rozumiem, że o takich systemach mówisz? :)

 

@Idlero: Dziękujemy :)

Share this post


Link to post
Share on other sites

Zgłoszenie wysłane :) Można jakoś przyrównać flowbox do clarisse? - mam na myśli pracę z instancjami zaimportowanych obiektów.

Share this post


Link to post
Share on other sites

danilo2 - Właśnie takich. Mnie szczególnie interesuje proceduralne tworzenie leveli i całych światów w grach. Jak ktoś robi gry to wie że nie zawsze coś co wygląda dobrze na papierze przekłada się na dobrę grę. Dlatego nieliniowe tworzenie i edytowanie środowisk jest lepszym rozwiązaniem.

Share this post


Link to post
Share on other sites
Guest User190

Chyba dobrze dla projektu, że poszło to w tą stronę. Kroczycie ścieżką utartą przez Nuke'a - tam były dokładnie takie same początki.

Edited by User190

Share this post


Link to post
Share on other sites

linux osx win .. ? czy dystrybucja będzie na wszystkie platformy ?

"...zamkniętą wersję alfa..." czy to oznacza że zamierzacie sprzedawać wasz projekt jako produkt ?

Share this post


Link to post
Share on other sites

@Bilay: Odpiszę Ci jutro, bo dzisiaj zdążyłem odpisać tylko legomirowi (poniżej). Przepraszam :)

 

@Monio: Racja. Co ciekawe (i może Cię to zainteresuje) - nasz Flowbox pozwala Tobie na definiowanie bloczków przetwarzających dowolne dane - możesz na przykład stworzyć bloczki, które przetwarzają 3D albo tworzą proceduralne opisy tekstur. Co jeszcze ciekawsze - możesz takie bloczki wraz z naszym środowiskiem "obrandować" i dystrybuować jako Twoją platformę do proceduralnego tworzenia leveli do gier - pozwalając Twoim użytkownikom na wizualne ich tworzenie.

My właśnie w ten sposób tworzymy Flowboxa FX - to są bloczki pozwalajjące na przetwarzanie i kompozycję obrazu, bazujące na naszej platformie Flowbox. :)

 

@[email protected]: Dzięki :) Też się cieszymy!

 

@szawel: Flowbox będzie działał na wszystkich platformach - linuxie, macu i windowsie. "...zamkniętą wersję alfa..." oznacza, że nie wszystkie osoby, które się zapiszą zostaną przyjęte do grona alpha testerów - grono to zamierzamy powiększać aż do wydania produktu w wersji 1.0. Odpowiadając na pytanie poboczne - tak, nasze narzędzie będzie produktem komercyjnym.

 

@legomir: Hej :) W dużym skrócie: Luna (nasz język) posiada o wiele większe możliwości, daje Ci większą kontrolę, o wiele łatwiejszy sposób wyrażania myśli i często dużo większą szybkość niż VEX czy ICE.

 

A teraz, żeby wyjaśnić moje powyższe słowa, musimy zajrzeć pod maskę :)

 

Problemy istniejących systemów nodowych

  1. Wraz ze wzrostem ilości node'ów, przepływ wykonywany jest coraz wolniej
  2. Jesteśmy bardzo mocno ograniczeni możliwościami takich bloczków - często musimy głowić się i wykorzystywać pewne bloczki "naokoło", wykorzystując bloczki nieprzeznaczone do tego konkretnego zastosowania.
  3. Nie jesteśmy w stanie w pełni wykorzystywać naszego hardware'u - z wielu CPU / GPU potrafią korzystać tylko te narzędzia, które zostały specjalnie do tego przygotowane - sam natomiast, tworząc przepływy bloczkowe, nie możesz oczekiwać tego, że będą one wykorzystywały CPU / GPU wydajnie.
  4. Istniejące systemy nodowe skupione są na pewnym rodzaju danych - jeżeli chciałbyś dla przykładu komponować obrazy 2D w ICE, musiałbyś napisać odpowiednie bloczki w C++ albo poczekać aż Autodesk to zrobi (chyba że ICE ma już wsparcie dla 2D) - w każdym razie sam łatwo tego nie zrobisz.

 

Zarys działania istniejących systemów nodowych (np. ICE)

Postaram się pokazać Ci trochę głębsze spojrzenie na cały temat, ale będzie to wymagało nieco bardziej technicznego spojrzenia.

Luna (nasz język) nie posiada schedulera node'ów - mechanizmu spotykanego w większości bloczkowych rozwiązań, który opisuje w jaki sposób wykonują się nody. Taki sheduler najpierw każe wykonać pierwszy node, potem drugi, kolejny (etc) przesyłając pomiędzy nimi dane.

Podejście to sprawdza się przy niewielkiej ilości bloczków, ale przy większych scenach szybko pokazuje swoje wady. Dlatego też w praktycznie wszystkich rozwiązaniach dostępne są bloczki napisane w pewnych niskopoziomowych językach (jak C++), a oprogramowanie pozwala nam używać ich w celu opisu pewnych wysokopoziomowych operacji. To jest też powodem tego, że nie możemy np. w Houdinim "wejść do środka" nodu "blur" lub nodu opisującego symulacje rigid body.

To wszystko niesie za sobą wyżej wymienione konsekwencje - spowolnienie działania przy dużych networkach, często utrudnioną pracę, dalekie od optymalnego wykorzystanie mocy sprzętu (CPU, GPU).

 

 

A co z VEX?

Vex jest bardzo specyficznym rozwiązaniem, więc opiszę go osobno. W VEX'ie jesteś w stanie opisywać pewne ograniczone przepływy (np. w kontekscie SOP'ów możesz używać Vexa w VOP'ach tylko do przetwarzania atrybutów punktów bez kontekstu - czyli bez uwzględnienia sąsiadów tego punktu). Oczywiście pewne proste operacje można "fakować" używając node'ów do obsługi chmury punktów - ale w tym momencie staje się to wszystko ciężkie w użyciu, a sam ten opis jest już bardzo skomplikowany.

VEX'a nie możesz używać również do przetwarzania dowolnych danych - jak geometria, dźwięk, obraz 2D, symulacje - możesz używać go w ściśle okreslonych miejscach. To co zrobisz w Vexie zamieniane jest na coś C++ podobnego, a następnie kompilowane i uruchamiane. Vex może być uruchomiony na wątkach, bo jest dozwolony właśnie w takich kontekstach - jak np. przetwarzanie atrybutów każdego punktu geometrii.

Takie rozwiązanie co prawda pozwala na uzyskanie szybkiego kodu (często szybszego niż analogiczny działający na bloczkach ICE), ale możliwości wykorzystania VEX'a są (jak już wspomniałem) są bardzo ograniczone. Poza tym nie ma co liczyć na automatyczną równoległość na GPU / CPU czy dostęp do standardowych struktur programistycznych (skoro pytasz o VEXa to jesteś blisko programowania) - takich jak tablice, mapy czy choćby funkcje lub lambdy.

 

Kilka słów o nodach w Houdinim

Poza tym, że w niektórych miejscach możemy używać VEX'a - problem pozostaje ten sam - jeżeli stworzymy wiele node'ów, network działa coraz wolniej. Bloczki są bardzo ograniczone, a o automatycznej ich równoległości na CPU i GPU możemy tylko pomarzyć.

 

A więc co z tą Luną? (bloczkowym językiem Flowboxa)

Bardzo ważna dla nas jest łatwość pracy użytkownika. Nie chcemy aby kiedykolwiek czuł sie ograniczony przez nasze narzędzie albo by musiał szukać jakiś obejść, wynikających z ograniczeń bloczków - co ma miejsce w codziennej pracy takiego przykładowego Houdiniowca.

 

Sama Luna to ogromne przedsięwzięcie. Nasze nody kompilowane są przez nasz kompilator do szybkiego kodu maszynowego. Innymi słowy - nasze narzędzie analizuje w jaki sposób przepływają dane, optymalizuje przepływ, wyszukuje miejsc możliwych do zrównoleglenia na CPU i GPU i robi to wszystko przeźroczyście dla użytkownika.

W wyniku, dostajesz dostęp do standardowych narzędzi - znanych z innych softów, ale masz pewność, że nie ważne ile bloczków połączysz, z Twojego sprzętu zostanie wyciśnięte więcej mocy (i co ważniejsze - mamy tutaj duże pole do popisu i wyniki będą się poprawiały wraz z ulepszaniem naszego narzędzia, co nie jest łatwe a czasem nawet możliwe w rozwiązaniach takich ja Houdini, czy XSI).

 

Innymi ciekawymi cechami jest to, że możesz używając naszych node'ów opisywać programy wykonywalne - czyli takie "exeki", które możesz potem komuś dać i które nie wymagają Flowboxa do uruchomienia i działania.

Dla mnie natomiast najważniejszą cechą jest to, że ze względu na tą architekturę Luny, możliwe jest przetwarzananie 2D, 3D, dźwięku, analiza obrazu i tak na prawdę, sam możesz zdecydować jakie jeszcze dane będziesz przetwarzał w wizualny (lub tekstowy) sposób.

My obecnie koncentrujemy się nad działką 2D (czytaj kompozycją i przetwarzaniem obrazu)

 

Reasumując

Mam nadzieję, że odpowiedziałem Ci na pytanie, przedstawiając zarys tego jak to działa od środka. Jeżeli masz dalsze pytania, z chęcią na nie odpowiem. Każdemu, kto zastanawia się nad tym jak nasz projet działa pod maską i jakie korzyści niesie, polecam zapoznanie się z wątkiem na cgsociety. Opisałem tam również, czemu idea kompilowania node'ów do czegoś takiego jak C++ jest po prostu zła (jak to dla przykładu robi VEX) :) : http://forums.cgsociety.org/showthread.php?f=59&t=1132960&page=1&pp=15

 

Jeżeli macie dalsze pytania, z chęcią na nie odpowiem! :)

Share this post


Link to post
Share on other sites

@legomir: Nasza Luna ma 2 równoważne reprezentacje - wizualną i tekstową - oznacza to, że możesz przełączyć się między kodem a językiem wizualnym w dowolnym momencie pracy (edytując kod - edytujesz nody, edytując nody, edytuje się kod). Jeżeli chcesz, możesz również nody pisać w C++ lub innych wspieranych językach, ale nigdy nie jest to wymagane.

 

Dzięki za info od Houdiniego - fajnie, że to dodali akurat tą konkretną możliwość, co nie zmienia wyglądu całej sprawy.

 

Fabric Engine - służy do tworzenia wydajnych aplikacji w Pythonie i JavaScripcie. Ich logiczny system nodów znowu podlega pod sheduler a ich język KL jest mega prymitywny. Celują w zupełnie inną działkę niż my.

 

Houdini Engine - to już prędzej. Natomiast Houdini (tak jak i Houdini Engine) bazuje na tym samym "silniku node'ów", który opisywałem powyżej. Poza wadami, które wymieniłem - Houdini celuje w przetwarzanie grafiki 3D i symulacje (2D też mają po drodze). Natomiast w każdej z tych działek - jeżeli chcesz zrobić coś bardziej zaawansowanego, szybko dochodzisz do ściany, ponieważ dostępne nody nie pozwalają Ci na nic więcej.

 

Bifrost - o nim dokładniej napisałem na cgsociety: http://forums.cgsociety.org/showpost.php?p=7695786&postcount=17

Z chęcią odpowiem na dalsze pytania na ten temat :)

 

Flowbox, tak jak i każdy produkt na świecie ma konkurencję - do tej konkurencji możemy zaliczyć każdy system nodowy przetwarzający dane. Mówię tu o Houdinim, Max MSP, ICE, Fabric Engine, XSI, TouchDesignerze, vvvv, etc - przykłady można mnożyć. Chcemy dostarczyć rozwiązanie, które będzie działalo lepiej, dawało większą swobodę i szybkość pracy, a przy okazji będzie o wiele bardziej otwarte, niż pozostałe.

Chcemy, abyś na naszych nodach był w stanie w prosty sposób stworzyć przepływy modyfikujące np. dźwięk, w momencie gdy my dźwięku nawet nie wspieramy :)

 

Czy udało mi się wytłumaczyć Tobie naszą ideę lepiej? :)

Share this post


Link to post
Share on other sites

Hej Wojtek! Gratuluję postępów!

 

Kilka słów a propos porównania z VEX i ICE. Takie porównanie jest kłopotliwe. Zarówno VEX jak i ICE powstały w bardzo konkretnym celu i kontekście aplikacji macierzystych, podczas gdy Luna wydaje się znacznie bardziej ogólnym konceptem. Trochę jakby porównywać otwieracz do konserw ze scyzorykiem... Ten scyzoryk zresztą zapowiada się rewelacyjnie.

 

Saying that...., Wojtek jest zaaferowany swoim błyskotliwym konceptem, co jest zresztą zupełnie zrozumiałe, ale warto pamiętać, że VEX już dawno nie jest procesorem SIMD dla punktów i może przetwarzać obrazy, dźwięk, voxele, prymitywy, a właściwie dowolne dane za pomocą CVEX'a, portu w Pythonie, procesora standalone i embedowalego interpretera. VEX staje się uniwersalnym procesorem danych. To bardziej architektura samego Houdiniego odróżnia go od Flowboxa, niż przetwarzanie danych w VEX.

 

To raz. Dwa, że SESI nie stoi w miejscu i podobnie jak chłopcy od Flowboxa, Biforsta, Fabric Engine i wielu innych, podąża z duchem czasu, kiedy niemal każdy projekt wymagający wydajności, opiera się na jakieś wersji auto optymalizacji/ runtime-paralelizacji, JIT, czy abstrakcji kodu od platformy sprzętowej

 

Tak dla przykładu: od wersji H13, VEX nie działa już na wirtualnej maszynie SIMD, co poważnie ograniczało jego możliwości, jest natomiast kompilowany w locie do kodu maszynowego i nic nie stoi na przeszkodzie, żeby wcześniej czy później wykonywał się także na GPU (będzie miał w tym względzie dokładnie te same problemy, co Luna - czyli na przykład, co zrobić z strukturami danych, które nie są GPU firendly, albo które trzeba odtworzyć na GPU w inny sposób). To nie operacje algebraiczne, ale operowanie na skomplikowanych strukturach jest prawdziwym wyzwaniem przetwarzania danych. Jeśli Lunie uda się połączyć unikatowość swojego środowiska z standardowymi bibliotekami (jak VDB), będzie to prawdziwa petarda :)

 

Ile się dziś dzieje w tych tematach łatwo zauważyć czytając choćby o V8 Google'a..., właściwie już dziś można go po prostu zaimplementować do Blendera i mieć swój VEX ;)

 

Anyways, Luna zapowiada się super!

skk.

Share this post


Link to post
Share on other sites

Tak. Zresztą wielki dzięki dla Ciebie i SYmka za wyjaśnienie paru spraw. Życze powodzenia i chyba zgłoszę się do testów swoją drogą :)

Share this post


Link to post
Share on other sites

Heej, brzmi to na tyle fajnie, ze chciałbym zobaczyc czy mogę sobie Waszymi procedurami wesprzeć swój workflow. Jest gdzieś dostępna dokumentacja języka, czy mam się zapisać na beto-alfe?

Share this post


Link to post
Share on other sites

@olaf: Zapraszam do zapisania się do Alphy :) Dokumentacje i podstawowe tutoriale mamy, ale udostępnimy je dopiero w Alphie.

 

@legomir: Nie ma za co - postaram się następnym razem więcej spać i dokładniej opisać rzeczy (jak celnie zauważył w niektórych przypadkach Szymon :) )

 

@Szymek:

Hej Wojtek! Gratuluję postępów!

Hej Szymku! Dziękujemy bardzo!

 

Porównanie Luny do scyzoryka w kontekscie VEX'a i ICE'a jest bardzo fajne! Muszę to zapamiętać :)

 

Saying that...., Wojtek jest zaaferowany swoim błyskotliwym konceptem, co jest zresztą zupełnie zrozumiałe, ale warto pamiętać, że VEX już dawno nie jest procesorem SIMD dla punktów i może przetwarzać obrazy, dźwięk, voxele, prymitywy, a właściwie dowolne dane za pomocą CVEX'a, portu w Pythonie, procesora standalone i embedowalego interpretera. VEX staje się uniwersalnym procesorem danych. To bardziej architektura samego Houdiniego odróżnia go od Flowboxa, niż przetwarzanie danych w VEX.

Masz Szymku absolutną rację! Moja wypowiedź powyżej była niekompletna i mogła wprowadzać w błąd. Wynika to trochę z faktu, że przez ostatnie dni bardzo mało sypiam ale postaram się takie tematy tłumaczyć dokładniej.

 

VEX jest typowym procesorem SIMD - ja wiem, że może przetwarzać dźwięk, obrazy, voxele etc. Dużym problemem z VEX'em natomiast jest to, że jest on językiem imperatywnym. Oznacza to (to tłumaczenie nie jest skierowane do Ciebie Szymku), że pisząc w Vexie piszemy krok po kroku instrukcje które mają być nałożone na dane. (To tak jak w C++, Javie, Pythonie, Rubym, JavaScripcie i wszystkich innych językach imperatywnych). Luna jest językiem funkcyjnym (podobnie jak Erlang, Haskell czy Scala) - oznacza to, że my piszemy co chcemy uzyskać, niekoniecznie w jaki sposób. Mimo, że podejścia wydają się podobne, w Lunie i Flowboxie nie występuje bardzo wiele problemów występujących w ICE lub Vexie. Mówię tu między innymi o "side effectsach" (czyli efektach ubocznych - termin informatyczny, nie mylić z producentem Houdiniego), globalnym stanie danych etc (można więcej poczytać tutaj: http://en.wikipedia.org/wiki/Functional_programming).

 

Co takie podejście niesie za sobą? Luna nie tylko jest doskonałym procesorem SIMD! Nie musimy zastanawiać się nawet jakie dane ktoś chce przetwarzać - możemy z łatwością wykrywać przepływy, które można zrównoleglić i jesteśmy w stanie dostarczyć wielu funkcjonalności, których nie będzie w stanie dostarczyć ani VEX ani ICE dopoki nie przepiszą wszystkiego od nowa - mówię tu zarówno o bardzo fajnym zarządzaniu pamięcią (mamy w wielu miejscach praktycnzie statyczny garbage collector - dane są niszczone dokładnie w miesjcu, w którym przestają być potrzebne, Luna jest językiem "lazy", co oznacza, że nie oblicza zbędnie danych - jeżeli każemy jej zblurować obrazek, a potem wyciąć tylko dolny lewy róg, to tylko ten róg zostanie zblurowany (oczywscie na GPU) etc).

 

Reasumując - stworzyliśmy nasze bloczki i tekstową wersję Luny bazując na bardzo mocnych przemyśleniach dotyczących architektury istniejących aplikacji i jak dla mnie największą siłą Luny jest to, że daje ona zupełnie nowe możliwości optymalizacji, niż jest to obecnie możliwe.

Nie wierzę, by Vex bez zmian architektonicznych mógł być "automatycznie" i w każdym przypadku tłumaczony na GPU, tak jak nie istnieje możliwość tłumaczenia C++, Pythona, Javy i innych języków imperatywnych. Oczywiście Side Effects będzie w to wkładał kase i dorabiał pewne ograniczone możliwości - np. dla każdego punktu geometrii, lub kazdego voxela, lub każdego pixela etc - ale w ogólności nie dostarczy takich rozwiązań jak Luna, dopóki nie napiszą tego od 0.

 

To raz. Dwa, że SESI nie stoi w miejscu i podobnie jak chłopcy od Flowboxa, Biforsta, Fabric Engine i wielu innych, podąża z duchem czasu, kiedy niemal każdy projekt wymagający wydajności, opiera się na jakieś wersji auto optymalizacji/ runtime-paralelizacji, JIT, czy abstrakcji kodu od platformy sprzętowej

Już Bifrost jest o wiele bliższy bardziej ogólnego rozwiązania, ale wciąż - ich idea robienia z bloczków jednego dużego grafu i jego kompilacji jest słaba - szczerze mówiąc jest to idea jaką Flowbox miał 1,5 roku temu - gdy rozmawialiśmy o Lunie z Tobą Szymku wtedy w Krakowie o ile dobrze pamiętam :)

 

Tak dla przykładu: od wersji H13, VEX nie działa już na wirtualnej maszynie SIMD, co poważnie ograniczało jego możliwości, jest natomiast kompilowany w locie do kodu maszynowego i nic nie stoi na przeszkodzie, żeby wcześniej czy później wykonywał się także na GPU (będzie miał w tym względzie dokładnie te same problemy, co Luna - czyli na przykład, co zrobić z strukturami danych, które nie są GPU firendly, albo które trzeba odtworzyć na GPU w inny sposób).

Racja, oni przeszli, jak się nie mylę, na LLVM'a i JIT. LLVM dostarcza im pewnych optymalizacji + dodatkowo możliwość wsparcia OpenCl'a w fancy way (jak opisałem powyżej). Nie zmienia to jednak faktu, że dopóki nie zmienią podejścia imperatywnego na funkcyjne (też opisane wyżej) będą mieli zupełnie inne problemy niż my.

 

Będą mieli problem choćby w zrównolegleniu kodu wywołującego funkcje (!) - analiza zależności między funkcjami jest niemożliwa (jeszcze nikomu się tego nie udało zrobić) - mówiąc prościej - nie jesteśmy w stanie np. w C++ przeanalizować czy wywołując funkcje nie zmienia ona pewnych globalnych danych w programie, które mogą wpływać na wyniki działania innych funkcji, a co za tym idzie nie wiemy czy tą część kodu da się zrównoleglić, bo nie wiemy jak powinna wyglądać komunikacja między wątkami na takiej przykładowej CUDA'ie.

 

Oczywiście mogą ograniczyć VEX'a i zrobić z niego prościutki imperatywny język z bardzo ograniczonym dostępem do pamięci i trochę poprawić sytuację na tym polu, ale w tym momencie nie ma co porównywać drewnianego scyzoryka do takiego samego, tylko z metalu :)

 

To nie operacje algebraiczne, ale operowanie na skomplikowanych strukturach jest prawdziwym wyzwaniem przetwarzania danych. Jeśli Lunie uda się połączyć unikatowość swojego środowiska z standardowymi bibliotekami (jak VDB), będzie to prawdziwa petarda :)

Bardzo mocno nad tym pracujemy! :)

 

Anyways, Luna zapowiada się super!

skk.

Dziękuję Szymku za ważne uwagi! :)

Edited by danilo2

Share this post


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