Skoti

Ja się zapytam niestandardowo - Jaki masz system operacyjny (wersja i bitowość), oraz ile bitowa wersja vraya

C2 spodziewano się w styczniu - konkretnej daty nie było, a nawet styczeń był tylko spodziewanym terminem. Może wyjdzie za miesiąc, może za dwa, może wcale i od razu będzie IvyBridge w kwietniu, a poprawki w wirtualizacji SB-E oleją.

Nie powinno Cię to ile w idle bierze, a ile pod obciążeniem (bo w jak obciążysz kartę/procka to Ci się spali jak będzie za słaby zasilacz), a tu przy kartach z 2x GPU masz na zestaw nawet pod 500W: http://pclab.pl/zdjecia/artykuly/majkel/7970/wykresy/mocload.png Pamiętaj też, że praktycznie cały pobór prądu tu to obciążenie lini 12V (procek + karta graficzna), a np. zasilacze 700W dają około 460W czyli wystarczy na styk 700W przy prądożernej karcie graficznej i procku - jeśli myślisz dodatkowo o kręceniu to nawet więcej może się przydać 700W (ofc mówiąc o tych smokach a nie kartach ;p) OFC nie będziesz płacił tyle ile obliczyłeś, bo bez obciążenia procek będzie działał na mniejszych obrotach, z mniejszą częstotliwością i podobnie karta, więc i cały komputer będzie mniej brał (a zasilacz pobiera tyle ile komp potrzebuje - to 700W to wartość maksymalna sumująca wszystkie linie zasilania (np. 560W na cpu i gpu + 140W na resztę czyli linie 3.3V i 5V (dyski, usb...))), ale jednak warto kupić większy, niż żeby miało zabraknąć. Kosztuje, ale nie warto tu oszczędzać - Dobry zasilacz 700W da Ci ~550W na 12V (tzn tyle będzie pobierał maksymalnie bo do kompa przy dobrej sprawności czyli 85% da 467W). Kupując noname będziesz miał np sprawność 68% to pobierając 550W będzie dawał do kompa 375W, a w dodatku będzie to niestabilny prąd i popali Ci procka i kartę. Zależy od karty i procka jaki wybierasz ale jeśli to karta z jednym chipem (na tym teście co podałem max 350W zestaw) to po kręceniu będzie pewnie na 12V około 450W, czyli 700W dobry zasilacz się przyda (ofc zależy jak ekstremale OC) - ofc mocniejszy sprzęt czyli 6990 i 590 wymagają nawet większych zasilaczy.

Nie wiem jakiego systemu używasz więc dam takie linki: Stabilne najnowsze sterowniki znajdziesz tu: http://www.nvidia.pl/Download/index.aspx?lang=pl A najnowsze sterowniki beta masz tu: http://www.nvidia.pl/Download/Find.aspx?lang=pl

@Berseker: czytaj komunikat - program wymaga OpenCL 1.1, a znalazł 1.0 i są dwa rozwiązania (które najlepiej połączyć w jedno, bo będzie najlepiej działać): - Używaj lepiej dopracowanej wersji CUDA, a nie OpenCL, której obrywa się przez AMD, - Zainstaluj nowe sterowniki w których jest OpenCL 1.1 (i nowsze stery CUDA). OFC karta jest dobra technicznie, bo obsługuje OpenCL 1.1 i CUDA 2.1, ale słaba ze względu na wydajność (bo to najniższy segment kart) i szybciej powinno renderować na CPU ;p.

Jeśli porównywać sam sprzęt to Quadro 600 to coś w okolicach GeForce GT 430 (czyli kilkukrotnie słabszy sprzęt niż 460), ale Quadro to przedewszystkim inne stery, wsparcie, obsługa 10bitowych kolorów, obsługa 3d Vision Pro (poczwórne bufforowanie w OpenGL), dodatkowe sprzętowe operacje czy większa proporcja wydajności podwójnej precyzji w stosunku do pojedynczej. Ogólnie rzecz biorąc jeśli nie wiesz co to Quadro i nie jesteś na 100% pewny, że akurat go potrzebujesz to olej karty na rynek profesjonalny (bo tu za te dodatki do karty graficznej płacisz wielokrotnie więcej niż za samą kartę o tej mocy i jeśli tego nie potrzebujesz to jest to kasa w błoto).

Wacom jest lepszy, ale od Virtuoso i Designer nie aż tak, żeby z góry odpuszczać tą opcję (trzeba przekalkulować za i przeciw i osobiście do siebie wybrać odpowiedni) - ja Pentagrama nie biorę pod uwagę nawet z innego powodu - w przeciwieństwie do Wacoma nie działa pod Linuksem co jest dla mnie dużym minusem.

@t0m3k: przestaw renderer na OpenGL i sprawdź czy dalej będzie ten sam problem. @Mafin: to zależy - jeśli chcesz tylko modelować, a renderujesz tylko na CPU to możesz i Radeona (chociaż on sprawia również problemy maxowi, a w reszcie programów 3d z których prawie wszystkie korzystają z OpenGL jest zdecydowanie gorszą opcją). Jednak jeśli chcesz używać GPU tez do renderowania to tylko Nvidia (już pomijam to, że większość renderów na GPU działa tylko na Nvidii oraz to, że iRay w 3ds max jest specjalnie dostosowywany pod karty Nvidii i działa tylko na nich (w końcu Mental Ray i cała firma Mental Images należy do Nvidii)), bo AMD ma złą arch do obliczeń i sobie nie radzi w obliczeniach - dopiero seria 79xx tu może coś zmienić, ale to tylko HiEnd, a niższe modele mają starą architekturę i z GCN nie mają nic wspólnego.

@Monio: Mówisz przez pryzmat starych Pentagramów opartych o Aipteki, ale teraz się to trochę zmieniło i Pentagram używa tej samej technologii co Wacom, a co do recenzji to zazwyczaj, nie oznacza zawsze i masz chociażby recenzje Virtuoso (tylko Virtuoso i Designer są warte rozważania, bo reszta to stare zabawki) na max3d testowany przez grafików http://www.max3d.pl/article.php?id=158 OFC nie mówię, żeby od razu wybierać Virtuoso czy Designer, ale są jednak warte rozważenia, bo to już nie te same zabawki co stare pentagramy.

Do ilu podkręcisz zależy od konkretnego egzemplarza, ale tak ~4.5GHz powinieneś spokojnie wyciągnąć. GTX285 ciężko dziś dostać, wydajność ma na poziomie 460, tylko nie ma nowinek jak większe możliwości w CUDA (jeśli chciałbyś renderować), oraz Tesselacji (jeśli w przyszłości powstaną sculpty korzystające z tessellacji i ty malujesz tylko po obiekcie teksturę wysokości, a wyświetlaniem w 3d zajmuje się już GPU), dlatego radzę raczej coś z Fermi (serie 400 i 500) wybrać (albo zaczekać na Keplera - seria 700 wychodząca za kilka miesięcy razem z nowymi prockami Intela).

Jeśli będziesz kręcił to: Intel i5 2500K ~900zł Dobre chłodzenie (np. Scythe Mugen 3/Ninja 3) ~170zł Płytę to brałbym w pełnym wymiarze i z chipsetem z68 ASUS P8z68-V LX ~400zł Zasilacz może być ten OCz ModXstream PRO 700W ~300zł (lub 50zł mniej za 600W która też starczy) - za to tego feel 500W to bałbym się nawet podłączyć na minutę ;p. Geil 4x4GB 1600MHz CL9 ~330zł (w sumie to możnaby 1333MHz bo takie max obsługują procki SandyBridge, ale jak będziesz kręcił procka to będą działać i pamięci z wyższą częstotliwością niż 1333). Jeśli masz dobrą obudowę (która pomieści potwory Scythe i długie karty graficzne - jeśli nie to już za 120zł można kupić przyzwoitą obudowę) i dysk to ze starego komputera i daje nam to 2100zł - do tego dodać kartę graficzną GeForce GTX460 1GB (~600zł) i za 2700zł jest przyjemny zestawik.

Do zdjęć lustrzanka Canona jak najbardziej, ale do wideo słaby wybór (podobnie jak lustrzanki Nikona) - do filmów najlepiej się nada Sony Alpha (błyskawicznie łapie fokus, a nie jak u Nikona i Canona wieki ustawia ostrość podczas kręcenia ;p). W Hollywood kręci się wszystkim - Profesjonalnymi kamerami Sony, Canon, Red i firm jakich nawet nie znamy (a pod niektóre tytuły są specjalnie tworzone nowe kamery). To czym jest film kręcony zależy od preferencji operatorów i budżetu... ale to nie ważne bo takich kamer prawie nikt na oczy nie zobaczy, więc jak to się układa w tamtym segmencie nikogo nie powinno obchodzić - ważne dla amatorów którzy chcą się pobawić jest tylko to co się dzieje na rynku amatorskim (tu najlepiej lustrzanki sony chyba obecnie wypadają) i rynek kamer półprofesjonalnych (od 8k do 20kzł) - tu jest konkurencja głównie pomiędzy Sony/Canon/Panasonic. Wszystko co wyżej raczej nas nie będzie tu interesować (jeśli kogoś interesuje to nie będzie sobie wyrabiał zdania o kamerach tu ;p).

Opteron jest i w wersjach 16x core (6272, 6274, 6276, 6282 SE i 6262 HE) co daje przy 4U do 64 rdzeni... a systemy klastrowe w szafach mogą mieć już znacznie więcej (system dalej widzi pojedynczy komputer tylko z całą masą procesorów). Z tego co pamiętam VRay jest w kilku wersjach na Linuksa (standalone, i dla linuksowych wersji Softimage czy Maya i chyba jakieś dodatkowe wersje serwerowe) i co najmniej dwie działają z eksporterem blenderowym (wersja Standalone i for Maya).

@_Orion_: Strasznie drogo ktoś ci to policzył - na samych procku, dysku i karcie graficznej przepłacasz po 200zł, kupuj po 2 kości, żeby działały w dualu, karta dźwiękowa słaba (IMHO warto brać dopiero droższe z serii jak Asus Xonar i Creative X-FI - w tanich to lepiej pozostać na integrze w płycie i dokupić później dobrą i radzę na PCIEx1 bo PCI już wychodzi, a karta dzwiękowa to zakup na wiele lat (ja swojego xonara mam od 3ch komputerów)), a najbardziej dziwi mnie płyta główna - tańsze są P8Z68-V LE z Z68 (obsługa zintegrowanego GPU w Twoim procku - traktować można ją jako zapasową, ale zawsze lepiej mieć ją tym bardziej, że płyta ma szereg zalet jak więcej USB3, czy po prostu pełne ATX - dzięki czemu mniej się będzie grzała (nie jest wszystko tak upchane) i będziesz mógł wykorzystać PCIE-1 (w tej mini karta Ci je zasłoni i nie będzie dostępna), a po włożeniu karty graficznej i dźwiękowej i tak będziesz mógł coś dodać (w tej mini więcej niż 2x grafika lub 1x grafika i 1x dźwiękowa się nie zmieści bo karty graficzne mają 2x slotowe chłodzenia i zablokują PCI i PCIE x1)). Nie ma co sprawdzać - nawet jeśli są triple chanel to nic nie da - procesor ma 2x kanałowy kontroler i max tyle będzie obsługiwał - tylko serie i7 Extreme obsługuję 4x kanałowe, a 3x kanałowe są tylko procki na podstawkę LGA1356 (czyli serwerowe lub poprzednia generacja i7). Wszystkie zwykłe SandyBridge (do 2700K) obsługują tylko 2x kanałowe pamięci i 1333MHz (ja mam w swoim 2500k, 1600MHz ale standardowo działają one z 1333MHz - tylko kręcąc procek można dojść do odpowiedniej częstotliwości pamięci - bez kręcenia masz 1333MHz i więcej nie będzie na Sa) Dyski mają być jeszcze droższe, ale jeszcze można taniej kupić ;p. Tylko jeśli coś tam to Enterprise i mamy 6x core procek (obsługuje do 8 fizycznych procesorów) lub Datacenter (do 64 fizycznych procków), lub zainstalować vraya na linuksie i tam renderować (standardowo linux obsługuje do 256 core, ale jak potrzeba więcej można przestawić).

Z Modecom Step 2 to będą pewnie problemy z upchaniem kabli w obudowie (nawet z modułowym zasilaczem), tak żeby był przepływ powietrza i ogólnie z przepływem powietrza więc bez zmiany obudowy nawet dobre chłodzenie nie da rady (no chyba, że otworzymy obudowę), a nawet może być problem z upchnięciem tam karty z dłuższym chłodzeniem (nawet niektóre 560 mogą mieć problemy). Ale tak jak mówisz wystarczy nawet tania obudowa tylko dobra ze stosunkowo dobrą wentylacją, żeby się wszystko pomieściło i nie trzeba wcale więcej wydawać niż za tą modecom (który pewnie w zestawie jest dzięki taniemu zasilaczowi w zestawie). Równie dobrze można kupić dobre polskie obudowy SilentiumPC Brutus 310 (120zł) lub 410 (130zł) i będzie przewiew, miejsce i Scythe Mugen 2 rev. B nie będzie straszny http://chlodzenie.net/reviews/silentiumpc-brutus-310-410-vs-wysokie-coolery-cpu/4/ Ja jeszcze miałbym obiekcje do Kingstonów, bo wolałbym jakieś Geile, Patrioty czy OCz do kręcenia za tą samą kasę, ale niech będą.

@Heha: Żeby oglądać filmy w 3d potrzebujesz specjalnych: - Okularów (dostosowanych do ekranu), - Specjalnych ekranów, - wersji Filmów w 3D, Metoda anaglyfowa (te okulary za złotówkę z różnymi kolorami szkiełek jak z początków kina) jest stara, i rezultaty są marne (trafisz kolory i ogólnie wygląda słabo), Metoda pasywna stereoskopii opierająca się na filtrach polaryzacyjnych ma tanie okulary (od 10zł do 50zł) jednak wiąże się z koniecznością zakupu ekranu ze spolaryzowanymi liniami (co druga linia dla lewego i co druga dla prawego - dziś monitory LG 3D i to nie wszystkie, bo tylko oznaczone Cinema 3d) - tracisz jednak w ten sposób połowę rozdzielczości obrazu, ale ma ta technologia swoje wady i zalety, Metoda aktywna korzystająca z okularów migawkowych (każde oko ma swój ekran LCD który się w odpowiednim momencie przyciemnia odpowiednie oko - (raz jedno, raz drugie jest przyciemniane 120x na sekundę (po 60Hz na oko))) - wiąże się to z drogimi okularami (od 150 do 600zł za okulary), koniecznością ładowania okularów (lcd i elektronika w okularach muszą mieć zasilanie), synchronizacji pomiędzy ekranem, a okularami (aby ekran wyświetlał odpowiedni obraz dla odpowiednio odsłoniętego oka) - to jest najdroższa opcja, nie każdy może z niej korzystać, ale z TV plazmowym daje najlepsze rezultaty (tą technikę wykorzystują prawie wszyscy Nvidia, Samsung, LG, Panasonic, Asus, Acer...). Ja mam wszystkie wymienione okulary i 2 typy ekranów i anaglyfami lepiej sobie głowy nie zawracać, a jeśli chcesz do komputera to koszt monitora + okularów jest podobny (efekt na małym LCD też będzie podobny, chociaż ze względu na co drugą linię wyciętą można się zastanawiać czy kupować pasywne jeśli będziesz oglądać z bliska). Na koniec musisz się zmierzyć z niewielką ilością filmów (dostępnych tylko na dyskach Blu-ray 3D) i droższych od zwykłych 2d (100+ zł). Ogólnie jeśli nie masz przynajmniej 1.5k-2k do wydania na start to nawet się nie interesuj.

W Supported masz wspierane renderery, w Experimental masz zarówno wspierane jak i eksperymentalne - CPU i CUDA to wspierane typy urządzeń, OpenCL jest eksperymentalny i do niedawna produkował tylko AO - teraz obsługuje już maretiały ( http://img808.imageshack.us/img808/6840/zrzut11.jpg ), ale nie wiem czy działa to na AMD (AMD ma problemy z kompilacją programów OpenCL z którymi radzą sobie kompilatory Nvidii czy Intela i to przez sterowniki AMD są problemy z wersją OpenCL).

@deshu: Twórca Octane to programista, który wcześniej pracował przy LuxRender z tego co pamiętam, Brecht pracował przy Octane tylko chwilkę (~ pół roku) - wcześniej pracował w Blender Fundation (nad Blender Internal zarówno w normalnym trybie jak i przy filmach i grze z Blender Fund.) i znowu tam pracuje (nad Cycles i kilkoma innymi rzeczami). Mylisz osoby.

Jeśli czekasz na plugin do blendera to musisz poczekać aż ludzie z Blender Fund. zrobią api dla pluginów, które nie koliduje z licencją (nie jest linkowany z kodem na GPL), bo teraz nie możesz pisać pluginów dla blendera z zamkniętym kodem (przez co zdatnych do użytku komercyjnego), i nawet nie ma API dla pluginów (bo jeśli i tak przez licencje musi mieć otwarty kod to może to być skrypt). Skrypty integracyjne Octane są dla blendera, jednak działają wolniej (skrypty działają wolniej ze swojej natury, ale do tego dochodzi to, że musi się komunikować z rendererem kopiując dane, zapisując na dysk i otwierając w rendererze standalone, który musi zapisać plik, żebyś odczytał w blenderze i zobaczył głupi podgląd materiału - plugin nie musi się komunikować z zewnętrznym programem bo renderer jest częścią wtyczki która wykonywana przez program ma bezpośredni dostęp do pamięci programu jak 3dmax).

Jeśli ktoś robi programy dla klienta końcowego to nie może sobie pozwolić na problemy ze sterownikami - program ma wyjść i działać, a nie sprawiać problemy i zapychać support. Kiedy OpenCL będzie dobrze wspierany można wypuścić łatkę dodającą OpenCL (tym bardziej, że języki bardzo podobne, a nawet są konwentery kodu przepisujące CUDA do OpenCL) lub sprzedać jako nową wersję. Poprawne działanie na wspieranych konfiguracjach to podstawa w aplikacjach dla użytkowników końcowych (badania akademickie mogą się ograniczać do jednego sprzętu i jednej implementacji więc pisząc w OpenCL można olać, że program nie działa na innych implementacjach OpenCL - firma dla end user tego olać nie może). Nvidia nie wspierała x86 w CUDA - robiła to zupełnie inna firma (http://www.pgroup.com/resources/cuda-x86.htm), ale teraz po zmianie na LLVM x86 dostał kompilator za darmo (LLVM jest kompilatorem dla x86 już więc nie trzeba nic pisać). Nad przykładowym Bullet pracuje też niewielka grupa osób i to tylko jeden z ich projektów - przykładowo autor Bullet czyli Erwin Coumans (teraz pracuje dla AMD, wcześniej pracował dla Sony czy nad silnikiem Havok) pisze Bullet cały czas podsyła łatki do Blendera, oraz robi własny silnik do prototypowania gier, później jest rponom (też z tego co pamiętam teraz pracuje dla AMD, ale robi 1/50 tego co Erwin) i trzeci jest [email protected] który od siebie dał jeszcze mniej - to wszystkie osoby które się udzielały przez kilka ostatnich lat. Ogólnie do stworzenia programów o wielkich możliwościach. OFC prosty pathtracer to zabawa nawet na kilka dni dla jednego programisty, jednak nie skala projektu decyduje o wykorzystanym API. To miło... mniej więcej wtedy (luty) ma się pojawić Blender z nodami kompozycji liczonymi w OpenCL (na CPU i GPU). Jednak tu OpenCL jest wyborem naturalnym podobnie jak w wypadku Hudiniego - program jest wieloplatformowy... też na Apple i ich komputery, które jako twórca OpenCL mają tylko implementację OpenCL i w obecnej generacji karty AMD (ze sprawną implementacją OpenCL bo od Apple, a nie od AMD). W tych konkretnych wypadkach do tej pory wybór CUDA był nie tylko ograniczeniem Nvidia only, ale też odejściem z MacOS X (teraz gdy mają programiści kompilator CUDA w LLVM (projekt wspierany przez Apple)). CUDA teoretycznie była zawsze otwarta i tak mówiła o niej Nvidia (podobnie jak OpenCL - jest specyfikacja i trzeba sobie zrobić kompilatory na swoją arch) - Nvidia nawet zachęcała AMD do napisania CUDA dla kart AMD, żeby miały PhysX. Teraz Nvidia podała im kompilator na talerzu (kompilator LLVM kompiluje kod do pośredniego, z którego AMD już ma backend do kodu dla kart, bo korzysta z LLVM przy OpenCL), więc brak CUDA w sterownikach AMD mogą tłumaczyć tylko niechęcią. Co do OpenCL od Nvidii to jak pisałem nie wiem czy można nazywać je "obcym" - Apple stworzyło go na podstawie CUDA, ze wsparciem Nvidii, przekazane zostało do Khronos gdzie rozwijane było pod okiem wiceprezesa Nvidii i przez niego wydane jako ostateczne 1.0. Nvidia jako pierwsza udostępniła kompilatory OpenCL i dała wsparcie w sterownikach... trudno tu mówić o czymś obcym. Bardziej obcym i zdecydowanie niekorzystnym dla obliczeń GPGPU jest C++AMP i IMO to jest powód wydania OpenACC i otartej implementacji CUDA gotowej do wykorzystania.

Nie tyle nie miały wyboru, co wolały wybrać coś stabilnego i działającego maksymalnie szybko. Niektóre programy przyglądają się OpenCL i będą przechodzić z prostego powodu - karty AMD jeśli będą takie jak je zapowiadają (najwyższe modele GCN) to będą się nadawać do GPGPU, więc wersja OpenCL powstanie (jednak nikt nie mówi o zamiast tylko o obok, bo CUDA daje większe możliwości optymalizacji). Ale żeby poważnie OpenCL weszło to AMD musi poprawić sterowniki. Taki Bullet czy Houdini? Z Houdini nie jestem na bieżąco, więc prosiłbym o podanie kiedy dostał akcelerację GPGPU i jaką. Co do Bullet to korzystam z tego silnika fizyki i GPGPU ma od 2008 roku akcelerację CUDA i później po kolei dostawał fluidy, softbody, cloth dla CUDA. Teraz przechodzi na OpenCL prace pewnie jeszcze przez rok będą zanim coś sensownego wyjdzie, a twórcy narzekają na sterowniki i sprzęt AMD i ciężko mówić o tym, że przechodzenie na OpenCL to ich całkowicie autonomiczny wybór... tzn chcą z pewnością, żeby działało w OpenCL, bo Bullet ma po kilka implementacji na x86, po kilka na ppc (razem z spu dla sony), osobno na arm, osobno na cuda... i OpenCL miał być kolejnym targetem, jednak skupienie się na OpenCL całkowicie to pomysł AMD który od kilku wersji ma prawie całkowity wpływ na Bullet (wszyscy aktywni programiści są teraz pracownikami AMD, przez co nie można podawać tego przykładu jako pokazówkę, że przechodzą na OpenCL (AMD ma tylko OpenCL więc nad OpenCL rozkazuje pracować)).

Wszyscy by chcieli, żeby sterowniki OpenCL były dopracowane, ale też wszyscy wiedzą jak to wygląda ze sterownikami OpenGL i kompilatorami GLSL (intel siedzi w prehistorii, a w amd wiele rzeczy działa źle lub nie działa wcale). Najlepiej w OpenGL i OpenCL wygląda Nvidia, ale OpenCL na ich kartach nie działa tak dobrze jak CUDA (która daje niższy poziom dostępu i lepiej da się zoptymalizować kod). Producenci oprogramowania GPGPU olewa w tej chwili OpenCL jeszcze ze względu, że karty AMD są słabe w obliczeniach takich jak rendering, a na Nvidię lepiej pisać w CUDA. Dlatego dziś mamy takie Octane, IRay (to naturalne bo właścicielem Mentala jest Nvidia), Indigo, Cycles i inne mają sprawne renderery CUDA, a OpenCL albo olewają, albo są wczesne wersje które muszą się zmagać z AMD. Akademikom nie przeszkadza OpenCL - piszą na dane urządzenie i działa, a właśnie twórcą oprogramowania dla użytkownika końcowego wolą CUDA (bo działa, w porównaniu do OpenCL szybciej, a karty AMD i tak się nie liczą w GPGPU). AMD może się liczyć w GPGPU od nowych kart z rdzeniami "ala Fermi" czyli 16 rdzeni w SIMD (zamiast 80 lub 64) czyli GCN i kartami z serii 79xx (może nowa arch zahaczy o 78xx). Możliwość wsparcia przez AMD i innych CUDA to dobra wiadomość dla GPGPU (inna sprawa, że AMD mimo korzyści dla swoich klientów przez udostępnienie im aplikacji dla CUDA, może nie chcieć wspierać tego API (bo porównanie w aplikacjach pisanych z myślą o NV byłyby bardzo niekorzystne dla ich kart)). Ja bardzo lubię OpenCL i piszę w nim i wiąże z nim duże nadzieje na przyszłość ze względu na wsparcie praktycznie wszędzie już dziś (od x86, przez arm w telefonach i ppc w konsolach, na kartach graficznych w pc i mobilnych w telefonach/tabletach), jednak jeśli sterowniki amd nie potrafią skompilować poprawnego kodu w OpenCL i się wywalają bo jest za długi (a przypominam, że od HD2000 podobno karty AMD mają nieograniczoną ilość instrukcji w programach (wymogi SM4 w DX10)) to całe obliczenia OpenCL tracą sens, jeśli się nie da w nim napisać programu przez problemy których nie spotkasz w CUDA (ofc w wersji CUDA dla AMD też mogłyby być problemy podobne, bo muszą napisać backend (zapewne ten sam co z OpenCL wstawić) do LLVM i problemy byłyby te same - tylko na NV wydajniej ;p). CUDA mnie nie ciągnie, ale zawszę wolę mieć wybór z kilku API działających na wszystkim (niezależnie od systemu i sprzętu), niż być skazany na jedno (inna sprawa, że tak czy tak jesteśmy skazani na Nvidię bo zarówno rozwojem CUDA zajmuje się Nvidia jak i OpenCL (przewodniczy grupie pracującej nad OpenCL i prezesem całego Khronos Group jest wiceprezes Nvidii Neil Trevett)).

OSL wykorzystuje tylko renderer CPU, przyszłe passy jak i wersje OpenCL i CUDA nie mają z OSL nic wspólnego - przynajmniej do czasu, aż Sony napisze kompilator dla GPU (czytaj zapewne nigdy). OSL się Brechtowi spodobał, ale w CUDA i OpenCL musi wszystko robić jeszcze raz (inna sprawa, że tu po prostu Shading Language to po prostu języki OpenCL i CUDA ;p). Wsparcie dla GPU ze strony OSL - co więcej prawdopodobnie nigdy go nie będzie... tu blender nie ma nic do gadania jak OSL będzie działać na GPU to pewnie będzie i w blenderze obsługa jeśli dobry kompilator zrobią... jeśli nie to będzie tak jak teraz - osobne shadery dla CPU w OSL, osobne dla CUDA i osobne dla OpenCL CPU (OSL) i Nvidia (CUDA) działają dobrze, Brecht napisał shadery OpenCL i działają one na Nvidii (OpenCL) i CPU (OpenCL), ale problem jest z AMD i od tygodni siedzi i próbuje obejść błędy sterowników AMD, ale praca się słabo posuwa i w repo jest tylko to co działa też na AMD (więc na NV też masz tylko to co działa na AMD, bo tego kodu nie wrzucił). Co do jednak białego shadera AO to trochę przesadzasz, bo już trochę poszło do przodu - dalej nie działają tekstury, a shadery są trochę uproszczone, ale to już nie biały shader http://img808.imageshack.us/img808/6840/zrzut11.jpg

@SYmek: akurat programiści często wolą pisać tylko dla CUDA niż borykać się z problemami sterowników AMD i tłumaczeniu się za pół roku przed klientami dlaczego ich program który dostosowali do Nvidii i AMD nie działa na GPU intela i ich sterownikach (bo jak wyjdzie IB, sterowniki z pewnością będą miały braki i podobnie jak AMD dziś wywalały się w nieoczekiwanych miejscach). Dodatkowo Nvidia ma tu nowego "wroga" czyli microsoftowy C++AMP (w kodzie C++ wstawki się robi podobne do OpenMP i już ten kod wykonuje się na GPU... nie jest to tak wydajne jak kernele w CUDA/OpenCL/DirectCompute, ale szybciej można to dodać) z tego powodu Nvidia i współpracujące firmy zrobili OpenACC (też pragmy do kodu C++ jak OpenMP)... jednak aby to spopularyzować i być konkurencyjnymi trzeba albo oddać do Khronos Group (tak jak Apple oddało OpenCL) i Khronos Group musi mieć środki, żeby rozwijać, jak i główne firmy muszą chcieć to wspierać (AMD ze względu, że Nvidia już ma gotowe wsparcie mogła by się nie zgodzić) lub właśnie zachęcić konkurencyjne firmy do wspierania CUDA (przez co OpenACC będzie i tam działał) - z tego co pamiętam AMD dla swojego GPU kompilator opiera na LLVM (GLSL i OpenCL) więc będą mogli szybko dodać swój target.

Bzdura - nie umożliwia tego oparcie silnika o Open Shading Language... ba OSL działa tylko na CPU w C++ Wsparcie dla kart AMD (nie Ati bo te skończyły się na serii 4k która z pewnością nie będzie wspierana) będzie przy okazji wersji OpenCL - wersja OpenCL ma działać w założeniu wszędzie od procesorów x86 (na nich będzie działać wersja zwykła C++ i OpenCL - w przyszłości może przejść tak też na arch PPC i ARM które również wspierają OpenCL), jak i kartach graficznych (nie tylko AMD, ale i Nvidia i w przyszłości Intel (od kolejnej generacji)). Problemem jest to, że wersja OpenCL napisana teraz działa na prockach i kartach Nvidii... a karty AMD się wywalają i w tej chwili Brecht ma trochę związane ręce - kompilator AMD wywala się na tak długich kernelach i nie potrafi ich wykonać na kartach (na kartach Nvidii Brecht nie ma takich problemów bo jak długie kernele by nie były kompilatory Nvidii skompilują kod OpenCL i karty wykonają). Teoretycznie nie powinien być to problem sprzętu, a oprogramowania (kompilatory w sterownikach do kart AMD ssą).