Skoti

Myślę, że nie rozważał, ale rozważał całość w OpenCL, jednak go AMD odstraszyło ;p. Blender obecnie korzysta pod linuksem z gcc, pod windowsem z kompilaotra microsoftu, a do OSL llvm. LLVM to tylko maszyna wirtualna/kompilator - do tego trzeba back end - są gotowe front-endy OpenCL ogólnodostępne (a LLVM już wykorzystuje - OSL to front-end dla LLVM, OpenCL/CUDA/MSL u Nvidii czy OpenCL u Apple (głównego twórcy llvm) to front-end do LLVM - przez ostatnie kilka lat mocno się rozwijał i teraz jest mocnym konkurentem dla GCC).

Shadery z blendera są na GPL (była rozmowa kiedyś na liście dyskusyjnej, gdzie Ton nie do końca był pewien na jakiej licencji, ale miały automatycznie doklejone GPL, więc na takiej) i ktoś tam pytał czy może użyć ich shaderów (nie wiem po co, bo nic w nich ciekawego) i nie mógł przez licencje (która nie była wymagana, bo kod nie był linkowany z kodem programu w żaden sposób). Co do jednak GLSL i HLSL to nikt się nie dzieli - podaj mi shadery z Unreal Engine, Unity czy innych komercyjnych silników (podobnie jak shaderów Pixara nie widziałeś i nie zobaczysz, mimo, że masz darmowe rendermany). Mimo, że wystarczy odpalić debugger gpu i kod masz nie możesz go użyć. Dzielą się ludzie kodem shaderów tylko na otwartych licenchach jak MIT, BSD czy GPL (w tym 3cim wypadku dzielą się tylko pomiędzy osobami lubiącymi GPL). Ogólnie przyjemnym konceptem byłoby API do eksportu z nodów blendera i pojawienie się eksporterów do OSL, RSL, MSL, GLSL czy sam mógłbyś łatwo dopisać eksport do przykładowo własnego binarnego formatu + zapis/odczyt z natywnego dla blendera formatu (dawno ubolewałem nad tym, że grupy nodów można robić, a nie można sobie zapisać i odczytać w innym projekcie tylko budować z klocków od zera) - ułatwiłoby to współprace z rendermanami i innymi renderami (nawet silnikami gier) - nie tylko z OSL.

A kiedy taka wymiana się odbywała? Ba ze względu na licencje nie jest możliwe zabrać kod shadera z jednego silnika do innego. OFC jeśli na tym zależy komuś to nic nie stoi na przeszkodzie stosować "import/eksport" shaderów i generować z shaderów nody/generować shadery OSL z nodów, w cycles nie korzystając z OSL, a korzystając z wewnętrznego rozwiązania opartego o OpenCL (OSL można traktować jako taki uniwersalny format pośredni dla samych nodów, a używać ich bezpośrednio w rendererze).

Nie - wywalić OSL zupełnie i o OSL zapomnieć. Zamiast OSL wykorzystać po prostu kernele OpenCL, które wcale nie gorzej (dobra odrobinę gorzej, ale jest to nieistotne przy zaletach) się do tego nadają niż OSL czy MSL. Ot zamiast shaderów zrobić include funkcji "shaderów" w OpenCL. Najlepiej zrobić w OpenCL po prostu ubershader i wykonywać go prosto z renderera w OpenCL. Z OSL to jest taka moda chwilowa IMHO i skończy się tak jak rozwijanie osobno fizyki brył sztywnych dla GE osobno ciuchów, osobno... a teraz zdano sobie sprawę, że nie tędy droga, i trzeba to co pisano przez lata wyrzucić i skorzystać z Bullet. W Cycles przynajmniej od początku wiadomo, że z OSL to droga na manowce i trzeba rozwijać zupełnie osobne renderery. OpenCL nie stał się podstawą wszystkiego, bo wyszedł Brecht z założenia, że nie jest jeszcze do tego gotowy i rozdrabnia się pisząc jednocześnie w CUDA, OpenCL i C++/OSL 3 różne renderery. Brecht ma racje bo OpenCL w wykonaniu AMD nie daje rady, a implementacje AMD/Intel na x86 zasysają jeśli chodzi o wydajność. Jednak w między czasie pojawiły się implementacje korzystające z LLVM z wydajnością bardzo dobrą (jest kompilowany normalnie jak C/C++) i już można zrobić na OpenCL implementacje dla wszystkiego (a przynajmniej CPU i Nvidii w GPU) jako jednolitą platformę - renderer w OpenCL korzystający z ubershadera w OpenCL (+ filtry kompozycji postprocess w OpenCL i jest miodzio ;]). Nie wykorzystali (bo te które istnieją są zamknięte), a napisali program/bibliotekę tłumaczącą OSL na kernel OpenCL, ale wtedy i tak nie połączysz tego z rendererem na GPU tylko obliczysz shader.... w przeciwieństwie do implementacji renderera w OpenCL

Nie do końca - OSL to otwarta specyfikacja i przykładowa implementacja. W implementacji nie mają zamiaru wprowadzać wsparcia dla GPU i innego sprzętu niż jest dziś obsługiwany, a zbywają jedynie tym, że jeśli ktoś chce to sobie napisze warstwę pośrednią tłumaczącą kod (co w sumie nie jest wielkim problemem). Więc jeśli blender chce korzystać z OSL i tłumaczyć to na OpenCL to jest to dla nich ToDo - tylko nie do końca jest tu sens... ba większy sens ma wywalić OSL i oprzeć całkowicie o OpenCL.

Nie zaczynają się w żadnym wypadku wzorować na OSL. To jest naturalne, że jeśli chce się oprzeć renderer i materiały na nodach to język shaderów sam przychodzi. Jest to koncepcja znana co najmniej od pierwszych rendermanów i języka RSL i dalej jest wykorzystywany przez Pixara czy 3Delight. Od tamtego czasu powstało wiele języków opierających się o tą koncepcję - od języków GLSL, Cg, HLSL po VEX Shaders, MetaSL (MSL) czy OpenSL (OSL)... dodatkowo z tej koncepcji korzystają kernele OpenCL i Cuda. Podsumowując nic nie jest "inspirowane" przez OSL, a to OSL jest inspirowane przez inne rozwiązania z rynku i tyle. Jedyne co można powiedzieć o OSL to to, że jest otwarty, z gotową implementacją na liberalnej licencji, więc jest szansa, że ktoś go wykorzysta w większej ilości niż jeden renderer - minusem względem takiego MetaSL jest to, że ma implementacji na GPU i OSL nie potrafi dziś przetłumaczyć swojego kodu na kernele obliczeniowe OpenCL/CUDA... zapewne będzie miał dopisaną zamkniętą opcję translacji przez twórców Vraya itp. Jednak podsumowując OSL to nie żadna inspiracja (nią jest masa programów i języków, które były inspiracją do powstania OSL). OSL to po prostu tani środek do celu.

Tak może pisać tylko zupełny laik w tym temacie. Zapewne według Ciebie łatwiej przenieść program z języka C do OpenCL niż z C++ do C (bo OpenCL to przecież podzbiór języka C, a to, że inny sprzęt wymaga innych algorytmów i zupełnie innego podejścia zupełnie cię nie obchodzi). DX i OpenGL to tylko różne API - w praktyce różnią się szczegółami (które OpenGL od kilku lat zacierał i jeśli przepisujesz z DX dodajesz kilka linijek i zachowuje się jak DX) i tylko wystarczy zamienić api co jest banałem. W wypadku OpenGL ES masz do czynienia z innym sprzętem, przez musisz zmienić wszystko od algorytmów sortujących obiekty do renderowania - GPU mobilne generują obraz przez renderowanie kafelkowe, a nie przez rasteryzacje, przez co musisz sortować po materiałach, a nie po odległości od kamery, nie potrafią renderować MRT, przez co zamiast w jednym shaderze zapisać do wielu tekstur, musisz napisać wiele shaderów i wiele razy rysować zamiast raz - przez słabą wydajność musisz wyrzucić cały pipeline oparty dziś o deferred shading i musisz wszystko przepisać na forward rendering, z shaderów postprocess jak i często nawet z shadowmap musisz zrezygnować bo mają za niski fillrate... ogólnie przepisywanie z OpenGL na OpenGL ES odbywa się tak, że olewasz kod który masz w OpenGL bo nic nie ma w nim przydatnego i piszesz od nowa kod dla OpenGL ES. Aaa to pisz jasno - FFmpeg ma jasny status prawny i licencje są znane. Inna sprawa to patenty na niektóre kodeki (i to jedne są opatentowane w USA, inne w Europie, a jeszcze inne w Japonii) i to samo dotyczy DirectX Media - jeśli piszesz program i chcesz wykorzystać jakiś kodek to musisz poszukać właściciela praw do tego kodeka i wykupić licencje na patent - taka jest norma... dlatego gry nie korzystają z takich opcji i wykorzystują bezpośrednio jeden kodek zazwyczaj w implementacji właściciela praw (czasami bywa to ffmpeg skompilowany tylko z jednym kodekiem bez patentowych problemów lub wykupując patent ale ffmpeg ma lepszą implementacje). Wersja GCC nie ma nic do rzeczy (gracz zazwyczaj nie ma nawet zainstalowanego GCC) - ofc już pomijam to, że z GCC prawie żadna gra nie skorzysta, bo do gier zarówno na Windowsa jak i Linuksa stosuje się kompilator ICC od Intela, a już z glib to niesamowity strzał (ja go przykładowo nawet zainstalowanego nie mam - tylko kilka programów z gnome go wymaga)... chyba, że chodziło Ci o glibc, ale nie ta wersja glibc jest problemem tylko dla kilku otwartych programów. Dla zamkniętych programów ważne jest jedynie, aby była zgodna z 6tą wersją ABI (aby był w systemie plik libc.so.6), ale o starszą wersję ciężko bo zmiana API na 6 miała miejsce w 1997 roku. Z tą cinelerra to żartujesz? Bardzo intensywnie korzysta z ffmpeg - nie do wszystkich kodeków, ale do większości. Z Mplayer to już na 100% żartujesz - od 1ponad 13 lat z niego korzystam, od samodzielnych buildów przez dystrybucyjne i eksperymentalne ze wsparciem dla vdpau i vaapi i nigdy nawet mi aplikacji nie wywaliło, a o jądrze to już nie wspominając. Chrome to przykład aplikacji właśnie takiej jak gra - wymaga odtwarzania tylko wybranego kodeku. Chrome odtwarza za pomocą FFmpeg filmy HTML5 - a że jest walka o oficjalny kodek to wspiera swoje WebM i Ogg Theora i walczy przeciw H.264 (na którego za chwilę wejdą płatne patenty co zamknie ten standard dla wielu firm). Co prawda dawno z Softimage pod linuksem nie miałem styczności, ale przed przejęciem przez Autodesk był on zlinkowany z qt (ofc nie ma mowy o korzystaniu w jego przypadku z kontrolek Qt tak jak nie robi tego pod Windowsem - Softimage ma własne API i implementuje je na Qt bądź MFC/WinAPI - jest to podobna strategia do Blendera tylko oni opierają swoje Api o OpenGL jako wspólny dla wszystkich)... teraz też nie podejrzewam, aby było inaczej, bo wszystko nowe Autodesk robi w Qt, razem z przepisywaniem starych interface programów 3ds Max i Maya na Qt Qt jest całkowicie natywnym rozwiązaniem... może chodzi Ci o QML? Jednak zakładając, że przez natywny chodzi Ci o najniższą warstwę komunikacyjną z serwerem wyświetlania, to Qt jest biblioteką komunikującą się z libX pod Linuksem czy z WinAPI pod Windowsem. Jest stworzony, aby było jedno API niezależnie od systemu i dawało duże możliwości przy prostym API. Przez proste API korzysta się z niego, a nie z WinAPI czy Api Xów. Jednak wracając do meritum w linuksie masz jedno api czyli api Xów, ale z nich nie korzysta nikt... tak jak bezpośrednio z WinAPI pod Windowsem. Dlatego też Microsoft stworzył MFC (dokładnie takie coś jak Qt ale jedynie na jedną platformę, a nie jak Qt uniwersalny) jako warstwę, z której programiści aplikacji używają... a ostatnio stworzył dodatkowe 2x oba nie są natytne nawet dla procka (WinForms i Modern UI), ale zrobić je musiał, bo MFC już jest stary i żadnym konkurentem dla Qt nie jest (dlatego Qt wybierają ostatnio prawie wszyscy - z samej branży The Foundry, Next Limit, Autodesk, DAZ 3D, Lucasfilm, DreamWorks Animation... nawet NewTek przepisywał UI Lightwave do Qt (ale nie śledziłem tematu czy już wydali to), nie z branży to już większość oprogramowania korzysta z Qt (łącznie ze Skype czy Gadu-gadu) reszta używa albo MFC albo WxWidgets). Qt to nie standard w Linuksie tylko ogólnie w oprogramowaniu na wszystkie systemy. Jednak co ma CentOS do tego to już zupełnie nie wiem. Naturalnie - i w ten sam sposób twórca programu nie wie czy dany format odtworzy (czy jest w systemie zainstalowany), więc musi brać ze sobą kodeki, a te mają albo niejasną sytuacje prawną (często są problemy nawet natury licencyjnej kodu), albo musi kupić licencje na patenty. Jak najbardziej problemy są - głównie jak ktoś kombinuje i wymienia serwer dźwięku a program gada bezpośrednio z api jakiegoś (przykładowo program wymaga alsa, a masz zmieniłeś oss)) - w przypadku gier i wyższego poziomu jak OpenAL twórcy gry nie uzależniają się od konkretnego rozwiązania.

Przepisać coś z DirectX na OpenGL i w drugą stronę jest bardzo łatwo... przepisać na OpenGL ES 2.0 to zupełnie inna sprawa i nawet z OpenGL nie jest to łatwe (porównywalne z DX->ES) - nie ma MRT nie ma wielu formatów tekstur i możliwości przez co w praktyce musisz zupełnie zmieniać koncepcje renderera (w DXOpenGL tego nie masz). Trochę lepiej jest z OpenGL ES 3.0 (które jednak jest dopiero przyszłością), ale dalej nie jest to to samo - nie masz shaderów obliczeniowych, nie masz tessellacji, nie masz Granie na nosie bardziej oznacza, że dla samego powodu, że się nie lubi MS i nie chce się, żeby on zarobił (a to bardzo odmienne powody niż dbanie o własne interesy). Ale skoro tak to rozumiesz to wyjaśnione, że się zgadzamy. To jest bzdura. A co to ma do rzeczy to już nikt nie wie. To jaką dystrybucja ma wersję bibliotek czy rozwiązania jest ważne tylko i wyłącznie dla otwartych programów, które korzystają z bibliotek systemowych. Programy i gry komercyjne o zamkniętych źródłach wszystko biorą ze sobą (tak jak w Windowsie gdzie instalator instaluje wszystkie potrzebne dll... w linuksie są one po prostu w którymś z podkatalogów gry). Ważne, żeby dystrybucja miała glibc, Xy i jakąś implementacje OpenGL (sterowniki) - resztę gra bierze ze sobą (tak jak i na Windowsie). Niby w czym? Jeśli stosują api zależne od środowiska graficznego (Phonon czy GStreamer jako api dla KDE i Gnome... to co, że korzystają z FFMpeg, trzeba przecież mieć "swoje") to sami są sobie winni. Status prawny jest jak najbardziej jasny - biblioteka LGPL z kilkoma kodekami GPL standardowo wyłączonymi (oraz dla pewności przy budowaniu jest flaga dla LGPL only). Co do pierwszego to jakie do tych kodeków masz wsparcie pod DirectX Media? A no tak tam nie masz żadnego, bo to framework i nawet nie jesteś pewien czy obsłuży dany format i musisz instalować ffmpeg aby obsługiwać (i tu szukać wsparcia). Co do programów zlinkowanych do FFMpeg to: Blender, Google Chrome, Cinelerra, MythTV, Mplayer (pod Windowsem również) - jeśli te progaramy jednak uznajesz za niewystarczające to Autodesk (pod linuksem Mudbox, Maya, Softomage) z jego programami może Cię przekonają (ogólnie Autodesk nie korzysta z windowsowych bibliotek - do wszystkich interface od Mudboxa, przez Maya, Softimage po 3ds Max korzystają z Qt). Jednak rozmawialiśmy o grach - podaj mi jedną grę korzystającą z DirectX Media pod Windowsem. Nie rozumiem o co dokładnie Ci chodzi - pod Ubuntu sterowniki instalują się same (lub przez instalator sterowników - dla większości użytkowników jest to łatwiejsze niż pod Windowsem instalacja), automatycznie działa Ci ALSA, a nawet jeśli zapragniesz zmienić na OSS (chociaż wątpię, aby robiło to wielu graczy) to nikogo to nie obchodzi, bo gry korzystają z OpenAL, a ten zadziała z którymkolwiek.

DirectX to znacznie więcej niż grafika: - DirectDraw - nikt go nie używa w 2D... w takich grach rządzi rzutowanie ortogonalne w OpenGL (wyższa wydajność i akceleracja sprzętowa gratis) lub biblioteki jak SDL. - Direct3D vs OpenGL - DirectCompute - w OpenGL jest częścią standardu (shadery obliczeniowe), ale ich możliwości są bardzo okrojone... aby zrobić coś poważniejszego w obliczeniach trzeba skorzystać z OpenCL. - DirectSound - od okrojenia w Vista, prawie żadna gra z niego nie korzysta tylko wykorzystuje OpenAL. - DirectInput - wszystko jest w API linuksa... ale aby pisać wieloplatformowo (za jednym razem dla MacOS i Linuksa) korzysta się z SDL - w przyszłości będzie to trochę inaczej bo teraz jest tworzony StreamInput przez grupę Khronos (od OpenGL i OpenCL) - jedno api od klawiatury, myszki i pada, po wszystkie mobilne sensory w tabletach i telefonach, i urządzenia w stylu kinekt. http://www.khronos.org/streaminput/ - DirectX Media - mało kto tego używa w grach - tu królują Bink Video itp. Ale jeśli chcesz pod linuksem API jak DirectX Media jako uniwersalne api do popularnych formatów to pod linuksem jego rolę ma FFmpeg (mniej popularnym rozwiązaniem jest użycie implementacji OpenMAX na linuksa i jeden kod załatwi od razu i kod dla Androida). - DirectWrite nie używa nikt w grach pod Windowsem - silniki mają własne implementacje oparte o standard w tej kwestii czyli FreeType. - DirectPlay - silniki gier go nie używają operując na znacznie niższym poziomie posiłkując się bibliotekami w styku boost... przykładowo w silnikach idTech operuje się tak nisko, że uznali TCP za zbyt powolne i sami kontrolują czy pakiety docierają przez UDP. Ogólnie w kwestii bibliotek, to z DirectX w praktyce są wykorzystywane tylko Direct3D i DirectInput (reszta kodu zazwyczaj jest już przenośna tak jak OpenGL). A oba mają bardzo dobre alternatywy w postaci OpenGL i I/O Kit dla MacOS X czy LinuxAPI (tylko, że jeśli już na te systemy się pisze to korzysta się z SDL, które w zależności od systemu użyje DirectInput, I/O Kit lub Linux API). Co więcej te 2 api są różne na Androidzie - tam do obsługi wejścia trzeba użyć Android NDK API (bo nie masz normalnie obsługi dotykowego ekranu w linuksie (tzn masz, ale nie w Linux API, a w api Xów, których w androidzie nie ma), nie masz też żyroskopu itp.), a i OpenGL nie masz, tylko OpenGL ES więc ostatni akapit twojego postu trochę w ścianę, poza tym, że nie chodzi o granie na nosie MS tylko obrona przed tym, żeby w przyszłości MS nie zagrało im na nosach (już w Windows RT tak robi, bo nie można sprzedawać samemu gier, a wymagane jest użycie sklepu Microsoftu gdzie producenci zmuszeni są oddać 30% udziału - nie chodzi o to, że trzeba oddać, bo to normalne, ale chodzi o przymusowe zmonopolizowanie przez co jak w przyszłości MS zażąda 60% to nie bardzo te firmy będą miały wyjście, jeśli dziś nie zdywersyfikują swoich działań). Ot MS sam zmusił twórców gier do poszukiwania alternatyw w postaci Linuksa.

Wyglądać może (tak jak pokazówki Nvidia OptiX). Tylko jak to wygląda na filmiku, a jak nagrywane były (nie wiadomo w jakim klastrze i na ilu akceleratorach Raytracingu Caustic Series2). Tak samo fajnie jak Nvidia OptiX, mniej możliwości niż OpenCL/CUDA, mniej uniwersalnie niż OpenGL/DirectX. Ot producent sprzętu dał programistą API aby mogli wykorzystać ten sprzęt (a to, że na tym api pisali to nie dziwi, bo są częścią producenta sprzętu) - nic w tym nadzwyczajnego, a ze względu na 1x Vendor i nowy niepopularny sprzęt, chcący konkurować z powszechnymi GPU to nawet nie jest fajne api. Ot renderer i api dla innych jako akcja promocyjna i reklamująca sprzęt.

Wymodelować moduł kwadratowy, wypalić tekstury normal i dispace na plane i zastosować (jeśli chcesz wystające kamienie po zbliżeniu kamery to po prostu animujesz LVL modyfikatora subsurf w trybie simple (modyfikator displace z mapką displace zrobi resztę roboty) jak tylko kamera się zbliża do danego fragmentu, olewając zwiększanie szczegółów odległych modułów).

@up: nadaj dyskowi etykietę, to zamiast dziwnego numeru (numer UUID (uniwersalny unikatowy identyfikator) partycji - jakie numerki oznaczają jaką partycję na jakim dysku możesz zobaczyć wpisując "ls -la /dev/disk/by-uuid/" w konsolę) będziesz miał w /media katalogi jak "Windows", "DyskD" czy "Pendrive"

Niekoniecznie była to wina linuksa (bardzo mało prawdopodobne), a raczej samego systemu plików NTFS, który nie jest niezawodny (wręcz przeciwnie i "ostre" wyłączenie komputera podczas gdy Windows (ofc również Linux bo to nie jest specyficzne dla OS tylko dla NTFS) pracuje na dysku może prowadzić do znikniknięcia plików/katalogów). Większość plików odzyskasz za pomocą CHKDSK (skrót od sprawdź dysk) pod Windowsem lub NTFSFIX (możliwe, ze go nie znałaś bo jest inna nazwa niż fsck (skrót od "sprawdź system plików") używanych w linuksowych systemach plików) pod Linuksem - to są narzędzia niezbędne przy NTFS tylko Windows po prostu wykrył "złe" zamknięcie komputera (co sugeruje, że to Windows zepsuł Ci pliki bo go na ostro wyłączyłaś) i odpalił chkdsk. PS. Te problemy powinny Cię właśnie uwrażliwić na problemy NTFS (których również nie jest pozbawiony ext4 jednak on jest znacznie mniej podatny na uszkodzenia), a zainteresować powinny Cię systemy plików jak Btrfs czy ZFS, które są dużo fajniejsze (nie tylko są bardziej odporne (plus planowana w kolejnych jądrach jest sprawdzanie systemu plików btrfs online (w trakcie działania w tle, automatycznie) - defragmentacja i wiele innych rzeczy w tle już robi, więc zawsze masz szybki i sprawny system plików (nie zwalnia razem z czasem użytkowania)), a możesz nawet wracać do poprzednich wersji plików (jak niechcący nadpiszesz plik to nie ma paniki ;p) i masz masę dodatkowych możliwości).

@bambosz: Płacąc kartą nie obchodzą Cię koszty przelewu bo to inna bajka. Przykładowo chciałem zapłacić z angielskiego konta za zakupy w polsce i bank angielski od przelewu brał 30 funtów, podczas gdy za płatność kartą nic (jedynie niewielka strata na przeliczniku walut której też doświadczysz jeśli nie masz konta walutowego) - jedyne co w płatności kartą możesz zapłacić to dodatkowy koszt, który dolicza sklep za obsługę płatności kartą (zazwyczaj do 10 zł - przykładowo karen.pl dolicza 7zł)... ale akurat Google nic Ci nie doliczy nic.

@Lucek: Z pewnością nie ma nic czego nie znalazłbyś w internecie, bo na stronie http://www.computerarts.co.uk/ masz większość starszych (czyli takich jakie są w polskiej wersji drukowanej). //Edit: Aby dać przykład tutorial z okładki najnowszego polskiego numeru 9/12 http://www.computerarts.com.pl/Resources/152.cov_big.jpg http://www.computerarts.co.uk/tutorials/create-liquid-effects-photoshop

Jest wiele takich programów jak przykładowo https://play.google.com/store/apps/details?id=com.aor.droidedit&feature=search_result ale nie uważam, żeby był to wygodny sposób na pisanie czegokolwiek. Całkowicie poprawną obsługę formatów tych aplikacji zobaczymy dopiero pod koniec roku kiedy LibreOffice i Microsoft Office mają wyjść na Androida.

Warto dodać też link do samej strony ISO, bo z tego powodu się pojawił news ;p http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=25&ics2=040&ics3=40&csnumber=59902

Rozgraniczmy 2 rzeczy - w DX9 dałoby się to wykonać, ale działałoby to znacznie wolniej (a ma to być czas rzeczywisty, więc jest problem). Co do OpenGL to jak najbardziej dałoby się wykonać nawet więcej niż tu jest, bo poza tym, że sam OpenGL 4.2 to więcej niż DX 11.1, za tydzień zostanie wydana nowa wersja (8mego na Siggraph będzie nowy OpenGL ES, zapewne nowy OpenGL i inne API (przy okazji OpenGL obchodzi 20 lat)), a producenci sprzętu dają takie rozszerzenia jak Nvidia Bindless Graphics czy Bindless Texture (od Keplera), które można wykorzystać tylko z poziomu OpenGL i dają spore przyspieszenie.

Nie czytałem napisów i oceniałem to co widać, a jak sam zauważyłeś bokeh nie widać, a tym bardziej nie widać, żeby rozmycie miało kształt sześciokąta, jak sugeruje napis, a wygląda typowo dla gausa. Dlatego sam napis mnie nie przekonuje, bo robi i tak gausa (dodatkowo słaba wydajność, jak na kilka kulek, z tą samą teksturą i renderingiem do 16bitów na kolor (w tym demie wykorzystują 32bity na kolor)). Musiałaby strona twórcy działać, musiałby napisać to w OpenGL i musiałby udostępnić build na linuksa, żebym to zrobił. Nie wystarczą mocne komputery, jeszcze trzeba skorzystać z jego możliwości, a DX9 na to nie pozwala: - Nie możesz skorzystać z Instancingu, więc podobne obiekty, muszą być przesyłane osobno, zabijając wydajność, - Nie możesz renderować do 8miu tekstur na raz (tylko do 4, więc aby zrobić deffered shading musisz renderować na raty i zejdzie 2x dłużej), - Flary jak błyski na krawędziach, zapewne tu są generowane dynamicznie na GPU w geometry shaderach (w Dx9 musiałbyś to robić na CPU), Tu wysiada DX9 i wymagałby dużo szybszego sprzętu do wygenerowania tego samego efektu, lub nawet gorszego. Jednak nie ma tu nic do czego przydałby się DX11 i DX10 by wystarczył... no chyba, że dalej brakowało wydajności i wąskim gardłem był procesor przesyłający dane do GPU przez jeden wątek, to użyli DX11 (pierwsze API, które pozwala na wielowątkowe renderowanie). Ja wiem o co Ci chodzi. Widzisz, że nie ma teselacji to Dx9 da radę, ale zapominasz o tym, że nowinki, jak 3 nowe typy shaderów (obliczenia na GPU (co też mogli użyć do przyspieszenia postprocess), i 2 typy do teselacji) to tylko mała część zmian, a większość to rzeczy niewidoczne, ale najważniejsze, bo zwiększające wydajność. OFC można mówić, że taki efekt można było uzyskać 50 lat temu licząc wszystko na CPU (tak jak w DX9), ale o to właśnie chodzi, że powstaje nowy specjalistyczny sprzęt i muszą być modyfikacje w API, aby go obsłużyć, olewając nowe API olewamy nowe możliwości sprzętu. Nie mieszaj. Nigdzie nie pisałem, że w jakimś HDRIBL nie ma dofa - pisałem, że go nie ma w podanym przez ciebie pierwszym linku (to nie link z nagraniem HDRIBL, a demo Nvidii, w którym DoFa nie ma). Później faktycznie pokazałeś screen z jakiegoś HDRIBL, ale na to już Ci odpisałem.

@maru: ten screen co pokazałeś ma DoF i rozmywa krawędzie wszystkich obiektów (rozmycie ostrych krawędzi, które mają wpływ na nieostre fragmenty - taka nieostra poświata po najprostszym DoF czyli rozmyciu gausa wyrenderowanej klatki niezależnie od głębokości - brak inteligentnego rozmycia czy bokeh, tylko ordynarny gauss), ale co ten screen ma do tamtego starego dema od nvidii, którego kod mam na dysku? BTW tu też masz jedną mapkę środowiskową dla wszystkich obiektów i obiekty nie odbijają siebie wzajemnie, tak jak na tym demie. Tu jest jedna mapka jak w grze Driver z 99 roku, gdzie na samochody była nałożona mapka chmur, a tu jednak każdy obiekt ma indywidualne mapki co wymaga wyższej mocy obliczeniowej.

@maru: To demo, które podałeś nie ma DoF (to, że cubemapa jest rozmyta, to wynik niskiej rozdzielczości, a nie postprodukcji) - jedyna postprodukcja tam to HDR (na pokazanym tu filmiku jest cała masa postprocess)). Problemem jest to, że w jest to statyczna wygenerowana wcześniej cubemapa ta sama dla wszystkich (trzech) obiektów, dlatego przez przezroczysty obiekt, nie widzisz innego obiektu, ani jego odbicia w obiekcie odbijającym światło - na demie z newsa każdy obiekt ma dynamiczną cubemapę (każda jedna to 6x renderingów offscreen * ilość obiektów), dodatkowo masz całą masę postprocess (które zabijają wydajność), gdzie w pokazanym przez Ciebie demie nie ma prawie nic. Dla lepszego efektu zapewne użyli tekstur zmiennoprzecinkowych wyższej precyzji niedostępne dla sprzętu DX9, dodatkowo mogli skorzystać z deffered shading (MRT w DX9 pozwala na max 4 rendertargety, przez co mogli przejść wyżej do sprzętu DX10 gdzie jest 8 tekstur na raz renderowanych), a i instancing mógł być użyty, niektóre efekty mogły być wykonane na geometry shaderach. OFC nie widzę tu nic co nie dałoby się zrobić w starszych API, ale wynik byłby mniej dokładny i działałoby wolniej, jednak ofc się dało (inna sprawa, że wtedy nie było sprzętu, a teraz mamy lepsze API w postaci OpenGL 4.x i DX11.x które dają większe możliwości, przyspieszenia renderingu, względem starszych). Akurat musieli specjalnie dodatkowo pisać smart blura, żeby tak to wyglądało (w przeciwnym wypadku to co powinno mieć ostre krawędzie będzie miało miękkie).

W wypadku samego SDK nie ma szans, że w czymkolwiek pomogło - instalacja sterowników dla developerów za to mogło pomagać na starszych kartach i w starszym vray rt (źle to świadczy trochę o twórcach vray opierających się na działaniu sterowników, a nie na specyfikacji OpenCL, ale tak mogło być). Sterowniki dla Quadro w wypadku OpenCL to dokładnie ten sam sterownik co OpenCL dla GeForce w wersji 296.10 (i tak jak 301.42 powinien działać bo były testowane przez twórców Vray RT). Jeśli na sterownikach 301.xx czy 296.xx nie działa to znaczy, że to nie wina sterów czy braku zainstalowania czegoś, a jakiś błąd sprzętowy lub w vray i aby cokolwiek naprawić trzeba poznać co wypluwa na konsole (zapewne chodzi jednak o brak pamięci). Nie ma takiej opcji - chyba, że przez instalowanie SDK masz na myśli instalowanie też sterowników dla developerów dostarczanych z SDK (masz starszą kartę, której obsługa jest w serii 195.xx?). Jeśli tak i w zestawie z 1.5 Vray RT to może być przyczyna (może ten Vray wykorzystywał błędy sterowników Nvidii które były niezgodne ze specyfikacją OpenCL i w nowych sterach te błędy poprawiono, więc nie działa... ale też nie będzie działać na Quadro opartych o Fermi z najnowszymi sterami).

Quadro ma specjalne sterowniki OpenGL, ale kompilator OpenCL się nie różni (podobnie jak CUDA) jest taki sam - CUDA jest zresztą kompilowany nie przez sterowniki, a SDK i kod jest bezpośrednio wykonywany na GPU (i sterowniki tu zupełnie nie mają nic do gadania). Co do "nie zapomnij tez o OPENCL SDk" to mnie zaskoczyłeś. SDK nie jest w żadnym wypadku potrzebne! SDK jak sama nazwa wskazuje jest przeznaczona dla twórców softu (zawiera profilery, debuggery, przykładowe kody, papierki itp., ale nic potrzebnego zwykłemu użytkownikowi). W wypadku OpenCL wszystko co jest potrzebne, a czyli kompilator kerneli i biblioteka runtime jest zintegrowane w sterownikach (i są to dokładnie te same implementacje dla quadro, tesla i geforce (co do bitu) i poza kompilatorem jest to wrapper na biblioteki runtime CUDA (które też są niezależne od rodziny kart - rodziny różnią się sprzętem (odblokowane jednostki FP64 które w renderingu nie mają żadnego zastosowania, pamięć z korekcją ECC...) i sterownikami OpenGL (poczwórne bufforowanie, 10bit na kolor (zamiast 8 na GeForce), wykorzystanie sprzętowego przycinania powierzchnią i inne usprawnienia OpenGL))). Czyżby te informacje o SDK nie brały się z tego, że u AMD nie było kompilatora i bibliotek runtime przez długi czas w sterownikach (długa faza beta) i trzeba było ściągać SDK i instalować sterowniki dla deweloperów? Nie mówię, że sam tak wywnioskowałeś, ale może dostałeś info o SDK od osoby która przeczytała na innym forum w sprawie kart AMD? Pytam, bo ciekawi mnie jak powstają takie plotki. Radzę zainstalować najnowsze oficjalne sterowniki (301.42), które były testowane przez twórców Vray RT i razem z GeForce działają. Jeśli dalej nie działa to podaj co wypisuje w konsoli, ewentualnie logu. Jeśli dostajesz "Error -4 at line XXX, in file ./src/ocl_tracedevice.cpp !!!" co jest według twórców VRay najczęstszym powodem wysypania programu to oznacza, że nie mieścisz się w ilości pamięci. PhysX i OpenCL są w sterownikach i jako użytkownik niczego więcej nie potrzebujesz. Jeśli jesteś programistą i chcesz w swojej aplikacji użyć PhysX to masz problem i kilka dni przerwy w dostępie do pobierania SDK, jeśli piszesz w OpenCL to możesz pisać swoją aplikacje bez SDK (nie będziesz miał narzędzi pomocniczych, ale pisać możesz), ale jeśli bardzo chcesz to możesz ściągnąć CUDA SDK (mimo, zamkniętej strony dla dev.), a OpenCL SDK od kilku wersji jest częścią CUDA SDK i wszystkie narzędzia jak profiler, debugger oraz papierki i przykłady są w nim (OpenCL SDK jako taki już nie istnieje i jest tylko archiwalna wersja)... jednak jak pisałem w tym wypadku to kompletny bezsens.

480 jest znacznie lepsze - poza większą ilością rdzeni ma też znacznie lepszą architekturę do obliczeń (karty od 460/560 w dół mają obciętą architekturę i ma znacznie mniej SIMD (ze względu na upakowanie większej ilości procków w SM - a SM w 560TI jest 8x w porównaniu do 15x w 480), dodatkowo widać to w obliczeniach podwójnej precyzji gdzie w pełnych GF jest to 1/8, a w x60 i niżej 1/12 - ma to związek z większym upakowaniem procków w jednym warp schedulerze w SM). Wyniki 680 dla wielu okażą się rozczarowujące, ale architektura 680 się po prostu do obliczeń nie nadaje. Do obliczeń nadawać się będzie dopiero pełny Kepler (GK110), który ma wyjść pod koniec roku (680 to jest kastrat znacznie większy niż 560 z 580).

Jedyne na co potrzeba VRAM to pomieścić scenę i pomieścić render (do którego zapisuje wynik obliczeń). Do niczego więcej pamięć globalna nie jest potrzebna. Jeśli się zmieści scena i buffor zwrotny (wyrenderowany obrazek 2d) jest bez znaczenia ile pozostało wolnego, bo pamięć globalna nie jest wykorzystywana jako cache. Do tego ma L1/local memory/shared memory (zwał jak zwał - PC/OpenCL/CUDA ;p) która jest w każdym SM i jest to pamięć niezależna od global memory. Dodatkowo jest pamięć L2 dostępna na całe już na całe GPU (ale dalej jest to zupełnie osobna pamięć nie wliczana do VRAM). To podam link do innej strony gdzie jest ten obrazek http://www.spot3d.com/vray/images/gpu_chart2.png