Zobacz więcej w kategorii: oprogramowanie | grafika
producenci: Khronos
Khronos Group udostępniła najnowszą wersję autorskiej specyfikacji OpenCL 1.2. Jest to otwarto źródłowa aplikacja wspomagająca pisanie aplikacji multiplatformowych składających się z różnych jednostek obliczeniowych np. CPU i GPU.
OpenCL umożliwia wykorzystanie procesorów graficznych do niegraficznych obliczeń. Znacznie zwiększa możliwość i elastyczność programowania współbieżnego. Definiuje język programowania C99 z wieloma rozszerzeniami do programowania równoległego. Definiuje API dla koordynowania danych i zadań obliczeń równoległych z wielu różnych jednostek obliczeniowych. Określa wymagania numeryczne wraz ze standardem IEEE 754. Zapewnia efektywność współpracy pomiędzy innymi graficznymi interfejsami programowania jak: OpenGL, OpenGL ES czy też DirectX.
Nowa odsłona specyfikacji zachowuje wsteczną kompatybilność zarówno z OpenCL 1.1 jak i 1.0. Wśród nowości można wymienić między innymi wdrożenie obsługi partycjonowania urządzeń, dzięki czemu możliwe jest dzielenie każdej jednostki na cząstki które mogą być przyporządkowywane do oddzielnych, obcych zadań.
Dodano opcje zezwalającą na migrowanie pamięci do innych urządzeń. Dodano obsługę wbudowanych funkcji urządzeń, które mogą wykonywać czynności definiowane przez różne frameworki.

Projekty Khronos Group
Umożliwiono wprowadzanie odnośników, odsyłających do innych bibliotek OpenCL. Zwiększono elastyczność dzięki rozdzieleniu kompilacji. Grafikę urozmaicono o obrazy jednowarstwowe, wykonane w teksturach OpenGL, a także tablic tekstur 1D i 2D. Dodano opcję współdzielenia powierzchni z interfejsem programowania DirectX 9/11.
Pokaz możliwości OpenCL
Pełna specyfikacja jest dostępna na stronach grupy Khronos. Warto również wspomnieć o członkach grupy Khronos, którzy wspólnie cegiełka po cegiełce tworzą kolejne wersje projektów grupy. Są to między innymi: Apple, AMD, NVIDIA, Intel, ARM, IBM, S3 Graphics, Qualcomm, Samsung, Epic Games, Sony, Ericsson, HP, HTC, Adobe, Broadcom, Google, Fujitsu, EA, Creative, Oracle, NOKIA, Texas Instruments, Matrox, Mitsubishi Electric, Motorola, Mozilla, NEC, Opera Software, Panasonic, Razer, Renesans, Toshiba, WMWare, Yahama i wiele innych.
Przykładowe demo OpenCL
Więcej o grupie Khronos i jej projektach:
Źródło: Khronos, OSnews, OSworld, Geeks3D, Softpedia
Powinno się bardziej jeszcze iść w tym kierunku. I bardzo podoba mi się pierwsza część nazwy "Open".
dzieki czastce "open" nie bedzie jak DX, ktory dziala tylko na windowsie i wynalazkach majkrosoftowych.
nieh sie rozwija, wszystkie procesory w komputerach bede wykorzystane szkoda tylko ze z procesorów dzwieku zrezygnowano i tylko creative je montuje, MS je zabił [vista/seven]
Jak widać (ja już to wiem od kilkunastu miesiecy)- OpenCl/Gl jest wydajniejsza, stabilniejsza, po prostu lepsza i nowsza od Microsoftowskiego D3DXX, ale nie wiem dla czego tak ało gier produkują na bibliotekach Open'a
Jedno słowo... "Monopol".
Microsoft jest Monopolistą na rynku gier komputerowych (nie mówię tu o konsolkach). Jeśli nawet wsparcie dla OpenAL/Gl/CL się pojawia to jest strasznie ograniczone, głównie z tego powodu, że jeśli jakas gra będzie wykorzystywać środowiska OPEN w pełni, to będzie niezależna od Windows. Co oznacza mniejsze zyski dla Microsoftu...
To nie Microsoft daje wsparcie dla OpenGL/CL czy OpenAL, a producenci sterowników i sprzętu - OpenGL i OpenCL tworzą m.in. Intel, Nvidia i AMD i powinno im zależeć na promowaniu tego na co mają największy wpływ, ale wpływ ma na to już rynek jaki jest - Dx był wieloplatformowy (Xbox 1 zanim w PS był OpenGL), a OpenGL stał w miejscu (był rozwijany jeszcze przez ARB w którego skład wchodził Microsoft), a dodatkowo sterowniki ATI były słabe co nagle prawie zabiło OpenGL - od tamtego czasu kręci się w kółko - twórcy sterowników wspierają bardziej Dx bo pod niego są pisane gry, gry są pisane pod silnikami korzystającymi z Dx... bo ten lepiej działa na kartach graficznych... dziś już Microsoft ma na to znikomy wpływ bo to już idzie siłą rozpędu i musieliby zrobić dużą wpadkę, żeby się zmieniło szybko (OpenGL może dziś tylko powoli odzyskiwać programistów, bo nie ma powodu, żeby nagle firmy wydawały dużo kasy przepisując silnik, aby dodatkowo działał gorzej na kartach graficznych, bo jest dalej problem ze sterownikami u niektórych producentów).
wdowa94 akurat może mieć trochę racji, tylko zwykli użytkownicy są po prostu robieni w jajo. Możliwości OpenGL czy teraz OpenCL są porównywalne jeżeli nie większe od rodziny DirectX Microsoftu. Różnicą jest wsparcie dla tej pierwszej technologii, które jest niemalże zerowe, ponieważ cały rynek gier i aplikacji komputerowych tańczy jak mu zagra Microsoft i inne firmy oraz korporacje przyklaskujące mu za pewien procent udziałów sprzedaży. Co więcej, programiści wiedzą jak wygląda sprawa, sam Carmack z ID Software twierdził przez długi czas, że jego gry będą działały na silniku OpenGL, jednak zrezygnował z tego zabiegu przy pracy nad grą Rage i potwierdził oficjalnie, że przy obecnym rozwoju i ukierunkowaniu DirectX nie ma sensu pogrążać się w słabo wspieranym OpenGL i jego gry nie będą się opierały o ten silnik. Wszystko to oczywiście otoczka medialna niedostępna dla przeciętnego Kowalskiego, który po prostu pójdzie do sklepu i zobaczy na opakowaniu karty graficznej napis: "DirectX 11 Ready!" i kupi, bo pan ze sklepu tak powiedział. Niestety, DirectX jest mocno skomercjalizowany i przynosi zbyt duże zyski wielu firmom z korporacjami AMD oraz NVidia na czele, natomiast jak nie trudno zauważyć - przedrostek 'Open' świadczy o jego łatwej dostępności i co najważniejsze ceny, którą jest jedynie wkład programistów w nauczenie się danego języka programowania pod OpenGL/CL. Możecie się ze mną nie zgadzać, ale to tylko moje zdanie, niniejszym nie chciałem nikogo sprowokować ani obrazić.
Po pierwsze OpenGL to nie silnik a API.
Po drugie Rage korzysta z OpenGL. Wlasnie dlatego na kartach ATI chodzi gorzej.
Po trzecie OpenGL ma slabe wsparcie innych firm niz nVidia.
Po czwarte pod D3D programuje sie wygodniej. Naprawde DirectX jest bardziej przemyslanym API. W OpenGL masz mase funkcji pamietajacych poczatek lat 90tych ktore albo nie dzialaja, albo nie powinno sie ich uzywac bo nie sa dzis akcelerowane.
w DX dzieki architekturze COM dostaje taki interface jaki obowiazuje w danej wersji bez przestarzalych funkcji. Prosze o D3D9 i dostaje D3D9 bez funkcji zakazanych z DX8, 7, 6 itp.
Przespałeś ostatnie 5 lat. W Win7 też ma biblioteki DX6 i DX7 bo muszą być, natomiast nie masz obsługi tych funkcji w bibliotekach DX10 i 11, prawda? Prawda. Tak samo OGL3.x i 4.x zupełnie nie mają nic wspólnego z prehistorycznymi funkcjami OGL1.x, natomiast dzięki odpowiednio zbudowanej kompatybilności wstecznej jest możliwe uruchomienie starych aplikacji.
@mgkiler: W OpenGL programuje się bardzo wygodnie, jest bardziej przemyślane, a nie masz żadnych tak starych funkcji (od 3.x tworzysz kontekst i taką wersję OpenGL dostajesz od sterowników (funkcje starsze czy nowsze (bez sprawdzenia czy obsługuje) nie zadziałają) - w dodatku stworzono dwa profile - core w którym jest tylko to co nowe i tylko to trzeba wspierać, żeby być zgodny z GL (w każdej specyfikacji masz napisane co wyleciało z Core ze starych funkcji oraz co jest odradzane (bo prawdopodobnie wyleci w kolejnej wersji API)), oraz profil kompatybilny ze starymi wersjami którego wspierać nie trzeba jeśli się nie chce).
Problemem jednak pozostaje omijanie problemów ze sterownikami (jednak AMD sporo pracuje nad tym, żeby tu poprawić swój wizerunek).
Czekaj czekaj, bo czegoś nie rozumiem. Carmack rzeczywiście coś mówił o DX, ale z tego co pamiętam to wychodziło, że skoro pracują nad OpenGL i wszystkie ich silniki są open to nie widzą sensu przerzucania i uczenia się na nowo tworzyć wszystkie bajery w DX. A następne silniki z ID Software oparte na ID TECH będą właśnie nadal na OpcenGL.
więc dodam swoje dwa grosze.... DirectX potrafi przesyłać dane do GPU wielowątkowo... basta....
ta jedna funkcja sprawia, że obojętnie jakie by OGL nie było to nie opłaca się go stosować.
Tylko Dx11 i tylko dlatego, że w Dx10 narzut jest już tak duży, że musieli to zrobić - OpenGL ma znacznie mniejszy narzut dlatego potrafi się nawet w jednym wątku szybciej wyrobić (wielowątkowość tu w Dx11 tylko zmniejsza narzut robiąc kilka rzeczy na raz, ale i tak wąskim gardłem jest przesył przez szynę do GPU tak jak w OpenGL).
nie zauważyłem tak dużego narzutu, względem OGL. Z tego co widzę fakt jest mniej, ale...
... żyjemy w czasach, gdzie mamy względnie nieograniczoną ilość rdzeni, nieograniczoną moc GPU (multi GPU), a ograniczoną moc 1 wątku CPU....
Dajmy na to Llano/Athlona II, nie wiem co będzie tu lepsze DX11 czy OGL. Procesor dwukrotnie mniej wydajny od SB (mniejszy zegar+gorsza Arch)
Różnica narzutu jest spora - OpenGL daje mniejszy narzut niż Dx9. Wydajność jest ograniczona, ilość rdzeni również, a procesory takie jak podałeś i tak się nie nadają do nowych gier, ze względu na fizykę, a wielowątkowość na takim procku nie poprawi sytuacji - i tak na raz może dane przepychać do GPU tylko jeden wątek w Dx11 (wielowątkowość pozbywa się tylko narzutu, a szybciej niż ogranicza Cię szyna i tak danych nie przepchasz choćbyś na 100 rdzeni rozbił)).
szyna nie jest takim znów dużym limitem, a fizykę można uprościć zawsze... zresztą fizyka nie jest tak rozbudowana znowu i ją można robić na wszystkie wątki....
Gdyby szyna była limitem to najnowsza platforma SB-E biłaby tak bardzo 2600k,że szkoda gadać.
tymczasem zegar wyższy o 100Mhz sprawia, że to właśnie 2600k czasem jest minimalnie szybszy.
Rozumiem, że testowałeś na karcie zgodnej z PCIe 3.0, że takie stwierdzenia dajesz (dopiero przy Keplerze i HD79k ruszy). Wkładając kartę zgodną z PCIe 2.0 do 3.0 dalej masz przepustowość 2.0.
niech mi ktoś wytłumaczy. jest karta np radeon 4870 i ma zgodność z dx10. jest to api nie? czemu nie da się wgrać do niej api zgodnego z dx11? może da się ale się tego nie stosuje np. bo jest zabezpieczone? próbował ktoś już kiedyś w świecie komputerowym to robić??? nurtuje mnie to że nieraz zmiany między dx 10, 10.1 a 11 są raczej niewielkie...
O Boze... tak jakbys se nie mogl wyobrazic: kazdy wyprodukowany chip ma swoja liste rozkazow. Do tego chipa zaraz powstaje API - czyli cos na wzor oprogramowania niskiego poziomu, czyli biblioteki, klasy.. ktore wykorzystuja w 100% potencjal chipa. I teraz se wyobraz, ze jest funkcja konkretnej wersji API, niech to bedzie dana funkcja DX11, ktora korzysta z klas, bibliotek, a moze i nawet specyficznych rejestrow i (na pewno) wlasciwosci (to przez biblioteki i klasy) kart w standardzie DX. No i teraz wez se tego swojego Radeona 4870, ktory ma zgodnosc z API jedynie do DX 10.1 i zapusc na nim kod, ktory odwoluje sie do NIEISTNIEJACYCH wlasciwosci karty... Odpowiadajac na Twoje pytanie - da sie, oczywiscie, ze sie da ZAPUSCIC na takim Radeonie programowy emulator DX11 (bo sprzetowo ten Radeon nie obsluzy wlasciwosci DX11, jak np. wykorzystania teselatora, ktorego PO PROSTU NIE POSIADA).. tylko wiesz, o ile ten Radeon wowczas spowolni emulujac kod DX11 ? Powiem Ci - na tyle duzo, by pisanie takich emulatorow bylo niepoplacalne, ani nawet niepotrzebne.
@Darkpoint: OpenGL/OpenCL itp są tworzone właśnie przez firmy jak Nvidia, Intel i AMD i inne wchodzące w skład grupy Khronos (np. szefem całego Khronos i jednocześnie szefem standaryzacji OpenCL jest wiceprezes Nvidii). Problemem nie są możliwości czy zachęcanie programistów (i tak piszą w OpenGLowych API dla Playstation3 czy smartfonów/tabletów) - problemem są sterowniki i wsparcie producentów sprzętu - Intel wspiera w SB od początku Dx10.1 (odpowiednik GL3.2), a dopiero ostatnio dostaliśmy implementacje GL3.1 w sterownikach (o dostępie do MSAA z shaderów zapomnij, mimo, że w Dx10.1 dali to od początku)... podobnie jest z zapowiadanym IvyBridge - Dx11, a GL 3.2 (zapomnij o tesselacji z GL4.x). AMD ostatnio się stara, ale to oni prawie zabili OpenGL przez swoje sterowniki - dziś jest znacznie lepiej w nowych wersjach, ale dalej pozostawiają wiele do życzenia - tu masz taki mały test zgodności ze specyfikacją http://www.g-truc.net/post-0426.html
Niestety, ale przy słabym wsparciu ze strony sterowników prawie nikt nie chce pisać w OpenGL i mieć problemy (w Dx jest oficjalny kompilator shaderów Microsoftu, ich API i biblioteki, a sterowniki muszą przechodzić testy zgodności i problemów nie ma) - teraz powstały testy zgodności z OpenCL i mają powstać z OpenGL to może się sytuacja poprawi.
tylko nikt nie każe developerowi robić od razu OGl 4.x.
Nikt nie zabrania robić gry zgodnej z OGL 3.2 ....
Używając 3.2 byłoby jeszcze ok, bo masz dostęp do MSAA z shaderów i obsługę wszystkich kart Nvidii od 8k i AMD od HD2k i możesz sprawdzić czy obsługuje tessellacje (jako rozszerzenie jest dostępna od właśnie 3.2). Problemem jest Intel i konieczność pogodzenia się z tym, że nie będzie działać na żadnym Intelu (HDx000 obsługują do 3.1), a i w wypadku zapowiadanych IvyBridge trzeba przełknąć niesmak związany z tym, że na sprzęcie który obsługuje tesselację nie możesz jej użyć, a korzystając z Dx mógłbyś - a intel mimo wszystko to nie jest tak mały rynek końcowy jak się zdaje.
kto użyje tesalacji na GPU intela....
Jeśli tesselatory Intela będą szybkie w IB (podobno mają być), to prędzej na Intelu niż AMD.
ale co da teslacja framerate będzie wtedy za niski. Przecież zbudowanie tak kompleksowej sceny na GPU mniej wydajnym od Llano?
u AMD można limitować tesalację. Co zdaje egzamin.
Nie wiem skąd znasz już wydajność IB, ale co ma wydajność shaderów GPU do wydajności tessellatorów tego nie rozumiem (Intel mając dobre tessellatory może np. tessellować wszystko do poziomu 128 i nie będzie miało wpływu na wydajność (jeśli tessellatory będą dostatecznie szybkie), a wystarczy większa tekstura czy ciekawsze obliczenia w shaderach i będzie kicha (jednostki teksturujące i procki słabe)). AMD ma shadery ok, ale tessellatory ma bardzo słabe i jeśli Intel będzie miał wydajniejsze to większy sens będzie na Intelach tesselacje robić niż na AMD (wydajność reszty GPU nie ma tu nic do rzeczy).
AMD ma tesselator (+tesselator niezgodny z DX11 ale on nie ma nic do rzeczy, więc jego w tym przypadku nie liczymy), a nie tesselatory (jedynie w HD69xx mamy 2 tesselatory) więc liczba mnoga średnio tutaj pasuje. Jeśli jednak weźmiemy pod uwagę wydajność pojedynczego tesselatora to AMD jest zdecydowanie przed NV, o Intelu nie wspominając (sorki, ale w cuda nie wierzę, że będą dysponowały one ogromną wydajnością), tak więc w przypadku nowej architektury zobaczymy zapewne kilka(naście) tesselatorów na układach AMD podobnie jak ma to miejsce w przypadku obecnych układów NV, a wtedy wydajność w tesselacji powinna być po stronie Radeonów (chyba, że NV zdecydowanie poprawi wydajność pojedynczego tesselatora to wtedy faktycznie może być ciekawie). Dokładanie do obecnej dwójki (nawet do obecnych układów AMD z pojedynczym tesselatorem) Intela jest wg mnie zdecydowanie na wyrost sądząc po jego dokonaniach w kwestii wydajności GPU (HD3000 ogólnie nie jest już taki zły, ale w porównaniu do jego odpowiedników od AMD wypada słabiej chyba pod każdym względem i podejrzewam, że z IB będzie podobnie).
Tessellatory napisałem nie bez powodu - bo jak zauważyłeś w kartach AMD z VLIW4 masz po 2, a mówiłem o całej konstrukcji - AMD ma jeden lub 2 tessellatory które się nie sprawują za dobrze - nie spodziewaj się, że w kolejnej generacji zobaczysz tyle co w Fermi (16), bo są za duże i się nie pomieszczą, więc mogą zostać przy 1/2 tessellatory (w większości HD7k tak zapewne będzie - takie są limity obecnych chipów które mają być wykorzystane w HD7k na segmentach konkurencyjnych integrze intela), a nieliczne z GCN mogą mieć więcej... więcej, ale mniejszych i słabszych - IB ma mieć 16x core i wystarczy, żeby dostały po małych tessellatorkach (podobnie jak Nvidia 1 na Cuda Core tylko Intel ma pojedyncze niezależne procki) i suma wydajności tessellatorów będzie większa niż w konkurencyjnych kartach AMD.
Oboje macie więc rację. Widocznie coś musiało mi się wydawać, że ID rezygnuje z OpenGL.
Nie tak dawno, bo jakiś miesiąc temu miałem okazje testowania owego RAGE'a na karcie NVidii oraz ATI i muszę przyznać, że podobne segmentowo karty radziły sobie zupełnie różnie, z oczywistym pozytywnym akcentem na NVidię.
Nie jestem programistą i nie interesuję się tym hobbystycznie, więc nie znam się na tym tak jak mgkiller, ale miło jest się od takich ludzi czegoś nauczyć czytając ich odpowiedzi. Muszę się więc zgodzić z mgkiller'erm, że jest łatwiej programować w D3D, ponieważ technologia ta jest mocno wspierana i nie dziwię się temu ani trochę, Open, to open i rzeczą oczywistą jest, że mogą ją tworzyć mniejsze firmy, jedynie dla własnej satysfakcji a nie korzyści komercyjnych. Czyli rozumując co napisałeś, przesiadając się na kartę graficzną obsługującą DX11 mam pewność, że przestarzałe funkcje z poprzednich wersji zostały usunięte/zastąpione nowymi? A może po prostu są tak napisane, że DX samo wykrywa swoją uruchomioną wersję w danym programie i się do niego dostosowuje: gra w DX11 - wyłączenie funkcji z wersji wcześniejszych/ Gra w DX9 - wyłączenie funkcji 'wstecznych' jak i następujących? Poprawcie mnie, jeżeli się mylę.
Pozdrawiam
DirectX oparty jest o architekture COM ktora pozwala interface projektowac praktycznie na nowo co wersje.
Mozna wszystko zburzyc i stworzyc na nowo.
Programista prosi konkretna wersje interfacu np D3D9 i dostaje taka wersje.
Dlatego jest to wygodniejsze bo jak sie pokomplikowalo cos to mozna bylo zburzyc i na nowo stworzyc. Rzeczy ktore wyszly z uzycia mozna bylo usunac w nowym interfacie, a jednoczesnie zachowac kompatybilnosc, bo taki DX11 caly czas zawiera stare interfacy D3D10, D3D9, D3D8 itd... Stad stare aplikacje beda dzialac, ale piszac nowa nie trzeba patrzec juz na stary zestaw funkcji i rozwiazan.
Natomiast interface to tak jakby zestaw funkcji. DX sie na nich opiera, a dokladnie architektura COM.
Oczywiscie nie jestem przeciwniekiem OpenGL. Nie chcialbym by to API zniknelo. I pewnie nie zniknie bo cos musi byc na innych platformach. Nie tylko Windows jest.
pytanie, czy do obsłużenia tych kilku kulek jest potrzebne 2 x hd4890? Nie wiem czy do dobrze świadczy o hd4890 czy o OpenCL, a może jeszcze o czymś innym. Ktoś może mi to wyjaśnić?
Poniewaz jest tu uzyty Pathtracing czyli jedna z technik sledzenia rozchodzenia sie swiatla.
Dla laika moze wygladac slabo, ale czy widziales w jakiejkolwiek grze by cienie zachowywaly sie tak realistycznie, albo odbicia w kulkach gdzie kazda odbija sie w kazdej, albo to jak swiatla przenika przez kulke jak przez soczewke.
Takiego czegos nie uswiadczysz jeszcze w grach. A to ze tutaj sa jedynie kulki a nie smoki, auta, statki kosmiczne itp to tylko dlatego ze to proste techdemo.
Generalnie w 3D Studio aby wyrenderowac podobna animacje potrzeba wiele godzin a nawet dni.
Akurat ten pokazany tu renderer to przepisany na OpenCL smallpt (prosty renderer na 99lini w C++) i działa on stosunkowo wolno (jest on naiwnym rendererem, który sprawdza każdy z każdym, a z tego co pamiętam to kule (ze względu na banalność implementacji) są jedynym obsługiwanym prymitywem bok plane, więc nie ma "smoków" nie dlatego, że to techdemko, a po prostu kod speedzik nie obsługujący nawet trójkątów).
Co do 3d Studio to teraz ma on w sobie iRay (renderer interaktywny w CUDA) i on dałby radę szybciej to wyrenderować niż licząc w dniach ;].
Chociaz oczywiscie do renderingu w czasie rzeczywistym i czegos wiecej niz kul DALEKA droga jeszcze.
hehe...
Szkoda, że SB jest wydajniejszy od 2x4890. Seria 4xxx nie wspiera opencl, pewne rzeczy są emulowane, dlatego seria 5xxx jest krotnie wydajniejsza tutaj.
W praktyce SB ma wydajność przynajmniej taką jak 55xx/56xx. Natomiast Radeon 6970 jest już 5 krotnie wydajnieszy.
----> Piszę obrazowo, bo powinieneś się zagłębić w temat dlaczego tak jest.
mówie o konkretnym zastosowaniu LuxRender....
zupełnie inaczej będzie w zastosowaniach kryptograficznych, a nawet w innym silniku jak IRAY, czy też SmallLuxRender.
-------------------
CPU nie jest takie słabe rendery RT istniały od dawna i lata temu potrafiły renderować sceny na CPU w czasie prawie rzeczywistym... czasy Pentiuma4. Jakość dyskusyjna, ale i tak wgniata w fotel to kiedyś potrafiły te rendery.
Co do serii 4k to wypada napisać o co chodzi - nie masz dostępu w nich do pamięci lokalnej karty... i jest ona emulowana, co zabija sens tych kart jako GPGPU.
Co do wydajności SB to wszystko zależy od programu - na niektórych będzie mocniejszy od Hi-End GPU, a na innych wolniejszy niż Lo-End.
CPU jest słabe do rendererów RT - ofc można napisać raytracer w którym siatkę sobie zorganizujemy w QBVH akcelerowanym za pomocą SSE i nie będziemy przesadzali z ilością siatki, oraz rozdzielczością... ale to będzie zwykły raytracer - jeśli będziesz chciał trochę realniejsze wyniki za pomocą np. bipathtracera z samplowaniem Monte Carlo to już trzeba mówić o dniach na CPU (na dobrych GPU o godzinach).
Powiedz mi tylko po co taki "realistynczy" model, jeżeli Mental Ray, daje wszystko to co trzeba i nie trzeba dni, a godzin by uzyskać podobvny efekt. Moim zdaniem wciąż V-Ray/Menal są niezastąpione. Głównie ze względu na nieograniczoną pamięć...
Dla mnie GPU to tylko do RT. I używam tego od paru lat....
Jakość RT w GPU teraz wgniata w fotel, ale to wciąż za mało i za długo względem CPU.
Uniwersalność CPU sprawia, że można zrobić coś zawsze inaczej=szybciej...
za to np. fajna jest akceleracja GI przez GPU... Jak widać czasem da się coś przyśpieszyć :)
Pamiętaj - nie zawsze kiedy coś wystarczy amatorowi do animki (lub profesjonaliście po długich ustawieniach i oszukiwaniu widza) wystarczy profesjonaliście do statyka (statyczne ujęcia wymagają dużo większego realizmu).
hrrr.
No masz rację tutaj... Choć ja osobiście do statycznych metod wolę "klasyczny" render+photoshop
Ja prawie zawsze korzystam z grafiki 3d i często jestem z tego powodu wyśmiewany, ale jak mam tworzyć conept art, schematy, ilustracje, to po prostu szybciej zrobić podstawowy szkic w 3d, a potem kolorować w 2d...
Po co do statycznego obrazu 3d?
W statyku każdą próbę oszukania oka łatwo rozpoznać i wszystkie błędy widać jak na dłoni - jeśli ma być fotoreal to nie da rady, swoje musi się renderować - przy animacjach jest inaczej, bo ze względu na ruch nie zauważasz szczegółów (a i nie ma czasu na tyle, żeby jedna klatka się robiła dni więc przyspiesza się rendering kosztem jakości).
ale te niedoróbki obrabiasz w photoshopie.... cały statyk zrobić w oparciu o photoshopa.
Tych niedoróbek nie poprawisz w PS - co najwyżej możesz próbować zamaskować robiąc ich przy okazji jeszcze więcej.
Matte rendering i compositing to podstawa w produkcji 3d. Nikt nie siedzi tygodniami poprawiając pierdólki w projekcie zeby wyszło idealnie prosto z renderu. Ciekawe jaki klient bedzie miał tyle cierpliwości i kasy?
Robi się po prostu technicznie poprawny render 32-bit float EXR, renderujesz wszystko w osobnych kanałach(diffuse, spec, glossy, reflex, GI, etc) + do tego maty dla wszystkich mesh id oraz wybranych obiektów. To jest najtańsza, najszybsza i najwygodniejsza metoda produkcji.
Do animacji niczego nie obcinasz tylko po prostu wykorzystujesz progresywny GI o interpolacji optymalnej dla dynamiki ruchu kamery o obiektów. W przypadku spokojnej animacji kamery wystarcza co 20 klatek.
Zależy co robisz z tą grafiką - jeśli przygotowujesz prostą wizualizację na już to nie potrzebujesz wybitnie dobrej jakości, a kompozycja się bardzo przydaje zawsze. Ja nie jestem grafikiem i ja jak miałem wizualizacje zrobić 1k m^2 to renderowałem 10 min obraz i reszta postpro, ale dało się to zaakceptować tylko dlatego, że czas gonił (ale jak widzę większość wizualek na rynku to było i tak bardzo pro).
Co do tygodniami - to akurat trochę w tej branży siedzę i znajomi graficy potrafią siedzieć nad projektami miesiącami, a nawet zdarza się i pół roku, żeby uzyskać pożądany efekt i dobrze zarobić - nie wszędzie liczy się na już - w tej branży przeważnie chodzi o jakość, a tylko jako wykonawca dla innej branży liczy się również czas (wiem coś o tym, bo jak czas goni z terminami, to przyjmuję modele których w życiu bym nie przyjął).
Do animacji robi się najczęściej chmurę punktów/dysków (bardzo upraszcza to GI które staje się mniej naturalne... ale wystarczające do animacji) i renderuje się nie szukając przecięcia promieni z siatką, a chmurą punktów (tak robi Disney Pixar (animacje jak np. UP, Toy Story 3, Wall-e...), jak i filmy Piraci z karaibów, Harry Potter, Ironman czy Dystrykt 9). Nikt dziś nie przelicza co n klatek danych do GI (zapewne chodzi Ci o Radiosity), bo jest to mało efektywne i nie najlepsze efekty są - dziś robi się chmury wrzucone hierarchicznie do drzew i aktualizuje się tylko pozycje całych chmur przy przesunięciu jakiegoś obiektu.
Nigdy nie słyszałem od tym żeby ktoś siedział poł roku nad projektem. Chyba, że jakimś prywatnym po godzinach.
Dzień pracy zespołu 2-4 grafików 3d kosztuje ok. 1000€. Nawet jak robimy projekt dla wielkich firm deweloperskich, motoryzacyjnych lub przemysłu lotniczego, to max. 2-3 miesiące. Puki co jedynie jeden z najwiekszych kreatorów mody pozwolił sobie na projekt trwający prawie rok ale to akurat 3d czasu rzeczywistego więc bardziej skomplikowany proces i inne priorytety.
Progresywne GI daje bardzo dobre efekty i nie chodzi o żadne radiosity tylko o light cache i progressive path tracing.
Podane przez Ciebie rzeczy to proste wizualizacje i faktycznie kilka miesięcy wystarczy, a o kosztach mi nie musisz pisać, bo najdłuższy projekt jaki do tej pory utrzymywałem trwał 2 lata i był bardzo produktywny bo samej grafiki powstało 5tb assetów - to był mały projekcik i zespół.
"light cache i progressive path tracing" po terminach sądząc mówisz o VRay - light cache to nic innego jak Light Mapping (stosowany najczęściej z Radiosity, dlatego o nim pisałem) - tu zmienia się tylko sposób tworzenia mapek - do animacji średnio się nadaje (lepiej się sprawdzają chmury punktów).
Też mnie to zaskoczyło. Jak porównywałem vray RT na R4870 do dual quad xeona, to wyglądało to marnie, a na dodatek vray RT gpu jest nieco wykastrowany w stosunku do wersji procesorowej.
Chopcy chopcy, ta wersja OpenCL- jak sama nazwa wskazuje jest oprograowaniem OTWARTYM, a nie szczelnie zamknięty jak Darek od Microsoftu... OpenCl używa tyle zasobów procesora co DirectX w 2D, bo potrzebuje jedynie kontroli pracy GPU, a w DirectX CPU analizuje, oblicza, kontroluje funkcje GPU....
@wdowa94: Nie każde Open dotyczy Otwartego Oprogramowania - OpenCL to otwarty standard, ale nawet nie jest oprogramowaniem (a większość implementacji (wszystkie poza "hobbystycznymi", których nikt używać raczej nie będzie) to oprogramowanie zamknięte). Dalej to albo nie zrozumiałem co chciałaś napisać, albo coś pokręciłaś (w sumie jedno nie wyklucza drugiego).
@ART: Zdołałem przeczytać tylko do "Jest to otwarto źródłowa aplikacja wspomagająca pisanie..." i nie chciałem się dalej denerwować - OpenCL nie ma otwartych źródeł (jest Otwartym Standardem, i każdy może sobie napisać implementacje - np. korzystam z implementacji AMD, Nvidii i Intela na PC (i żadna z nich nie ma otwartych źródeł)). Po drugie to nie jest aplikacja, a standard API dla C++ i język programowania kerneli oparty na C - implementacje (kompilatory, sterowniki) tworzą osoby/firmy które chcą dać możliwość pisania w danym API (Intel, IBM, ARM, AMD, Nvidia, PowerVR...) i w żadnym wypadku nie udostępnia ich Khronos. Dalej nie chciałem czytać, bo jeśli tekst o OpenCL pisany przez osobę która nie wie co to OpenCL, to szkoda mojego zdrowia.
Zaczęło się od bełkotu i objawów analfabetyzmu (jakież to powszechne), a dalej nie czytałem.
"Jest to otwarto źródłowa aplikacja" a może jednak "otwartoźródłowa" albo zamiast nowomowy, to po prostu "aplikacja o otwartym kodzie"?
Lećmy dalej:
"Jest to (OpenCL)... aplikacja" - g... prawda, to jest język programowania, a nie aplikacja. + uwagi @skoti powyżej.
Lećmy dalej:
"aplikacja wspomagająca pisanie aplikacji" - nie ma to jak "tryndy"-słowa powtarzane w kółko. "Ach, jak to mądrze napisałem", no nie?
Lećmy dalej:
"pisanie aplikacji multiplatformowych składających się z różnych jednostek obliczeniowych np. CPU i GPU" - no proszę, jaki postęp technologiczny. Kiedyś "jednostki obliczeniowe np. CPU" to był sprzęt, aa teraz CPU to "aplikacja, którą można sobie napisać". Biorę się za tego OpenCLa, napisze sobie nowe, szybsze CPU.
Lećmy dalej:
"jednostek obliczeniowych np. CPU" - no proszę, a ja myślałem, że "jednostką obliczeniową jest najwyżej FPU (Floating Point Unit), który jest teraz fragmentem (wcale nie największym) CPU, a kiedyś był osobnym scalakiem (i80307, i80407), który kupowało się za grube pieniądze.
I to wszystko w jednym zdaniu - całkiem nieźle Panie Redaktorze. A zadania z polskiego na jutro odrobione?
z ostatnich 30 dni
odsłon: 160148
odsłon: 95503
odsłon: 34551
odsłon: 28553
odsłon: 26508
odsłon: 24842
odsłon: 22763
odsłon: 21797
odsłon: 18934
odsłon: 18838
odsłon: 18771
odsłon: 18213
odsłon: 17283
odsłon: 15887
odsłon: 15649
odsłon: 15485
odsłon: 14965
odsłon: 14562
odsłon: 14398
odsłon: 13559
odsłon: 13461
odsłon: 13374
odsłon: 12424