Skoti

Nie tylko... i OpenCL nie jest szybsze, tylko cycles w wersji OpenCL szybciej sampluje... co oznacza, że N sampli per pixel zrobi Ci szybciej, ale obrazek w porównywalnej jakości już wolniej, bo potrzebuje conajmniej kilkukrotnie więcej sampli na pixel aby rezultat był podobny - czyli jeśli zrobisz benchmark renderowanie N sampli to faktycznie wyjdzie szybciej, a jeśli po jakości/zaszumieniu sromotnie przegra - zależy czy mówimy o rezultacie czy cyferkach których się nie da porównać rzetelnie ;). Na CPU też renderery z samplingiem Monte Carlo czy Metropolis light transport samplują wolniej i tyle samo sampli uzyskasz dużo szybciej na weekendowych projektach studentów... tylko szum przy tej samej ilości sampli nieporównywalny - jeśli liczysz czas jako sample per pixel w danym czasie to wszystkie najlepsze renderery unbiased zasysają względem prostych hobbystycznych projeków... jeśli liczysz czas do wyrenderowania produkcyjnej jakości obrazka to już jest odwrotnie.

OpenCL 2.2 jest porównywalny z CUDA... no ok SPIR-V i możliwość kompilacji C++ do niego jest naprawdę fajna, ale to nie sprawa wydajności, a odpowiedniego pośredniego języka i dostarczonych kompilatorów. Nie jest bardziej zaawansowane, ale nie ma żadnych słabości. I tak... Nvidia specjalnie nie wypuszcza sterowników do OpenCL (którego sami tworzą, a szefem standaryzacji OpenCL dalej jest wiceprezes Nvidii). Dlatego, że nie wszystkie algorytmy są dla architektury SIMT/SIMD zabójcze, a nie mają z nim problemów arch MIMD (jak CPU). Nie bez powodu fizyka akcelerowana przez GPU w grach to dalej nie jest standard... o ile GPU sobie świetnie radzą z fizyką ciuchów, fluidów itp... to zupełnie padają przy zwykłej fizyce brył sztywnych. Tak samo tu jest. Liczenie permutacji w Correlated Multi-Jittered Sampling prowadzi do branchowania kodu przez co przykładowo jeśli masz 64 rdzeni w SIMD na karcie graficznej to w zależności od danych wejściowych działać może od 1 do 64 rdzeni (czytaj od 0 do 63 na 64 rdzenie odpoczywa i nic nie robi, bo mogą wszystkie wykonywać na raz taką samą instrukcje na innych danych, a że już tamte wyszły z brancha to muszą czekać aż inne też to zrobią, aby prace kontynuować). CPU jest tak zaprojektowane (MIMD) z prostej przyczyny - jest uniwersalne i nie zwalnia w zależności od danych wejściowych. Wersja OpenCL ma bardzo prosty sampling i nie branchuje. OFC możesz sobie sprawdzić czy to wina CUDA odpalając blendera i w wersji OpenCL na karcie Nvidii (sterownik Nvidii OpenCL implementuje tak, że kompiluje kernele OpenCL online do CUDA i ogólnie tak czy tak wykonywany jest kod CUDA - tylko gorszy jakościowo, bo na kompilacje kernela nie miał kilku-kilkunastu minut (jak to jest w kompilacji offline, gdzie optymalizacja jest dogłębna), a kilka sekund ;)).

Nie sprawi - TO PRAWDA, jednak wydajność mocno spadnie i o tym mówię. Obecnie sampling w wersji OpenCL jest bardzo prosty (szybciej zrobi N-sampli, ale wygląda nieporównywalnie gorzej przy tej samej ilości sampli). Correlated Multi-Jittered Sampling od Pixara czyli quasi-Monte Carlo robi olbrzymią różnicę w jakości i wydajności, dlatego teraz porównywanie wersji OpenCL bez niego z CUDA z CMJ jest po prostu niepoważne, bo przy tej samej ilości sampli na jednym masz tylko szum, a na drugim jakość produkcyjną. To zupełnie nie tak. Porównujesz po prostu dwa zupełne renderery. Wygląda to trochę tak jakbyś mówił, Cycles ssie, bo Blender Internal szybciej wyrenderuje - prawda, ale efekt jest zupełnie inny. Co do AMD i OpenCL to AMD dobi bardzo dobre karty obecnie a i OpenCL jest obecnie wyśmienity. Problem nie w tym, że nowe karty AMD są złe czy 2.2 nie daje Ci czegoś ważnego dostępnego w CUDA, bo daje wszystko. Kompilacje offline kernelów (z możliwością znacznie dalej idących optymalizacji niż online) dzieki SPIR-V masz od OpenCL 2.1, Dynamic parallelism z CUDA masz w OpenCL 2.0, Concurrent Kernel Execution (Hyper-Q) masz w teorii od OpenCL 1.2. Tylko tak jak kilka lat temu OpenCL dobijały karty i sterowniki AMD tak teraz dobija go Nvidia i przykładowo wszystko powyżej OpenCL 1.2 nie jest wspierane przez ich sterowniki (mimo, że sterowniki OpenCL 2.x mają od lat i mam do nich dostęp, ale nie wydają publicznie), a Concurrent Kernel Execution przez nich nie jest wspierane (a przynajmniej poprawnie) przez co w programach konsumenckich zostaje używać api w wersji zupełnie nieprzystosowanej do obecnego sprzętu (specyfikacja 6-7 lat) - to nie znaczy, że OpenCL jest pisany na kolanie, o nie... to znaczy jedynie, że jego ekosystem jest bardzo podzielony i tym co dzielą wcale nie zależy na popularyzacji OpenCL'a, więc dopóki nikt Nvidii nie zmusi (a był czas gdy tak było, bo był hype na OpenCL, ale AMD go wtedy ubijało), ich polityka się nie zmieni, a co za tym idzie OpenCL będzie w plecy

Tak i że tak przekornie powiem to zdanie "The OpenCL Split Kernel now supports nearly all features" nie do końca oddaje jak daleko to nearly jest ;). Teraz nie chodzi już o to, że na sterownikach amd nie da się zrobić wszystkiego, ale o to, że to pokłosie tragicznych starych sterowników dalej się ciągnie w tym, że nie dali rady jeszcze wszystkich zaległości nadrobić... i w tym, że obecnie co lepsze możliwości blokuje Nvidia oferując jedynie OpenCL 1.2, a wszystkie smaczki dostępne od OpenCL 2.0 czy 2.1 zachowuje dla CUDA (i są wykorzystywane w Cycles w CUDA, ale Cycles używa OpenCL jedynie w wersji 1.1).

Jeśli chodzi Ci o to co zrobione przy Gooseberry to tak aktualne dane... jeśli coś się dodatkowo zmieniło to nie.

Nie VRAM tylko 16GB masz VRAM i możesz dodać SSD jako pamięć SWAP. Jest to świetna wiadomość do wielu dziedzin obliczeń, ale nie renderingu (jeśli komuś włączył się swap dysku na SSD podczas renderingu na CPU to wie, że jeśli nie chce czekać 100 lat na wyrenderowanie to lepiej wyłączyć i odchudzić scenę, aby się w ramie mieściła - a tak jest przy małym wyścigu o zasób 4x rdzeni, a nie 4k rdzeni (miałbyś szczęście jeśli gpu renderowałoby tylko 8tysięcy razy wolniej - znaczy się, jeden rdzeń by pobierał powoli dane i zwolnił tylko 2x działanie przez to względem VRAMu, a 4095 rdzeni by czekało, aż zwolni dostęp do dysku ;p)). Czytaj świetna sprawa dla aplikacji liczących ekstremalnie dużo, wymagających dostępu do big data, ale czytających je rzadko. Nie działa w pełni na OpenCL - nie ma bardzo, bardzo wielu rzeczy... przez co renderuje dużo szybciej (ale dużo gorszej jakości) niż w CUDA. To jeszcze pokłosie kart AMD których sterowniki próbowały nadrobić braki w konstrukcji i optymalizowały kod ekstremalnie - gdy kernel stawał się odrobinę bardziej skomplikowany to wywalał się sterownik karty graficznej i przez AMD zaprzestano bardzo wcześnie rozwój wersji OpenCL (na poziomie który nie wywalał sterowników AMD - nie było problemu na Nvidii i Intelu, aby prace kontynuować, ale intel się nie liczy, a po co robić OpenCL który działa tylko na Nvidii gdy jest CUDA?). Dalej efekty tego okresu w kartach AMD mamy w oprogramowaniu i mimo że w Cycles jest już lepiej dalej brakuje wielu rzeczy z wersji C++/CUDA(prawdopodobnie nie tylko w cycles , ale obecnie nie jestem na bieżąco czy dalej VRay RT wykrywa kartę czy Nvidia czy AMD i ustawia gorszej jakości kernele na AMD, aby nie wywalały sterownika, czy już z tego zrezygnowali z nastaniem nowej architektury).

Są też dostępne slajdy i filmiki z tworzenia http://aras-p.info/blog/2016/07/23/Adam-Demo-production-talk-at-CGEvent/

Chętnie przyjdę zobaczyć.

MacOS jest bardziej stabilny od Windowsa, ale też dlatego, że sam z siebie nie wiele robi (nie mówię, że to źle), ale w kwestii zarządzania pamięcią ram, wielowątkowością czy scheduler (czyli techniczne sprawy) jest to obecnie system z końca stawki (za Linuksem, FreeBSD i Windowsem), a są to rzeczy istotne. Co do interface to niektórzy go lubią, ja wolę mieć większą kontrolę (w macu jest wszystko poukrywane, bo sobie użytkownik krzywdę zrobi, i jeśli chcesz zrobić coś ponad podstawy to masz problem), więc używam KDE i zgadzam się, że Explorer z Windowsa czy brak wielu pulpitów sprawia, że nie jest to najprzyjemniejsze doznanie, jak i również to, ze w MacOS zmiany idą szybciej niż w Windowsie (w którym od Visty poza zmianami interface na kafelkowy i spowrotem, niewiele się działo... no ok mamy nowe Dx12 (w MacOS nowy Metal)). Niestety jest to piórko bateryjne wykrywające nacisk po stronie piórka, a nie tabletu jak w starych pentagramach czy aiptekach (prawie każdy tu wie, z jaką dokładnością działania to się wiąże i jak bardzo nie nadaje się to nawet do amatorskich zastosowań). Konkurencja za to ma tablety korzystające z indukcji elektromagnetycznej (jak tablety Wacom czy Pentagram Virtuoso) Zważywszy na doświadczenie z użytą przez nich technologią, oraz znajomość konkurencyjnych tabletów mobilnych, śmiem twierdzić, że to będzie jedno z najgorszych dostępnych z piórkami. I łamiące się iPhone6+, i wybuchające baterie i wiele innych, których ilość ciężko zliczyć i pamięta się tylko te, które uniemożliwiają używania urządzenia do podstawowego zadania (łamanie się telefonu w kieszeni spodni, czy telefon bez możliwości rozmawiania, bo antenę zasłaniasz). Większość*mobilnych tabletów o których mówiłem, wykrywają kąt nachylenia piórka i czułość tak samo dobrze jak tablety wacoma (w sumie ten sam digitalizer, te same piórka). Od lapka to raczej MacBook, ale reszta nie jest pomylona ;p.

@Synuś: Wątpię, żeby MacOS i iOS kiedykolwiek stały się jednym systemem, bo to zupełnie inna filozofia. Inna sprawa, że moim zdaniem do takiego tabletu MacOS po prostu się nie nadaje, a aplikacje na iOS/Android pozwalają na wygodne szkicowanie w terenie... dlatego też Wacom też jest na tym rynku z Wacom Cintiq Companion Hybrid (tablet z Androidem - co prawda mają też Wacom Cintiq Companion z W8, ale ten system do pracy na tablecie jest mocno słabym wyborem (mam tablet microsoftu i nie polecam)). Samo rozwiązanie techniczne z piórka Apple wygląda bardziej jak zabawka od Nvidii czyli DirectStylus 2 (który swoją drogą jest fajnym pomysłem, dodawania praktycznie darmowego piórka, bo nie trzeba digitalizera, a po prostu oprogramowanie odczytuje jak mocno naciskasz, więc cena produktu nie rośnie, ale jak pisałem to raczej zabawka, bo precyzja słaba) niż faktycznie narzędzie do pracy profesjonalnej jak digitalizery Wacoma czy N-trig (które są szeroko stosowane u konkurencji). Co do MacOS to mimo, że tego nie pisałem, technicznie nie jest to czołówka systemów operacyjnych i raczej jeden ze słabszych systemów operacyjnych (i z wielu powodów na swoim maku używam Linuksa ;p), ale nie da się pominąć faktu, że jest wiele fajnych programów dla grafików które są tylko na MacOS co sprawia, że ten system jest popularny wśród grafików (a nie to, że to dobry system ;p).

@Olaf: Po co Samsung czy ktoś inny miałby się interesować tym czymś wymagającym bateryjnego piórka, skoro konkurencja ma digitalizery Wacoma (jak przykładowo Samsung Galaxy Note 12.2, Toshiba Encore 2, Asus VivoTab Note 8, Lenovo ThinkPad 10) i inne z digitalizerem N-trig (Microsoft Surface)

@alex3d: Korzyści niewielkie, ale zawsze jest to 60 tysięcy dolców mniej w budżecie na opłacanie takich projektów jak viewportfx

Wygląda na to, ze w tym roku blender nie będzie miał żadnych projektów Google Summer of Code (Google odrzuciło ich).

Po pierwsze zanim napiszesz coś przeczytaj czy tak jest. AC:U nie było w programie Nvidii i Nvidia tam nic nie pomagała (pomagała przy poprzedniej części AC4 tak i miałeś tam wolumetryczną mgłę, dynamiczną symulacje dymu itp (Nvidia PhysX), ale nie akurat przy AC:U (Intel Havok) i ta gra nie była w programie The Way It's Meant to be Played, a jedynie wykorzystali dostępne dla wszystkich gotowe implementacje Nvidii z ich strony). Na 660 te gry działają poniżej 30FPS już przy fullHD. Swoją drogą to, że Cię dziwi, że działa na GTX 780 (co więcej na granicy płynności) to mnie szokuje - ta karta to absolutny HiEnd (3x wydajniejsza niż GPU w XboxOne i ponad 2x wydajniejsza niż w PS4). Wydajnościowo ta karta jest pomiędzy 970 i 980, a ma większą przepustowość pamięci niż 980. Rozumiem, że zadowoliliby cie tylko gdyby gra nie była grywalna na karcie graficznej kosztującej tyle co konsola (no chyba, że wymagasz poniżej 30FPS na 980 SLI?).

Gra jest kierowana do takiego odbiorcy, który grę kupi i wygeneruje to zysk. Dlatego tak samo jak gry AAA omijały Wii, tak omijają ponad 90% graczy Steama, bo tam się NIE sprzeda i nie wygeneruje żadnych zysków. Statystyki Steama nabijają causalowi gracze grający w gry kupione na Humble Bundle za jednego dolara czy darmowe Dota2, TF2 czy archaiczne gry jak CS. Zobacz sobie statystyki Stema (nie sprzętowe, a gier). W nowe gry AAA gra tam może kilka % graczy - i tylko to jest dla nich targetem, bo reszta rynku Steama to causale, którzy jeśli mają zamiar grę kupić to za kilka lat za 2-3 dolary. Zrozum, że nie liczy się statystyka całego rynku PC (podobnie jak nikogo nie interesuje cały rynek konsol), a tylko statystyka graczy, którzy kupują gry AAA (a te statystyki wyglądają zupełnie inaczej niż cały rynek). Testy kompatybilności są prowadzone tylko po to, żeby dać wyższe wymagania niż faktycznie są, aby nie zostać ofiarą pozwu zbiorowego w USA ;p. Nie jest to prawda. Zazwyczaj owocuje voxelowymi symulacjami dymu, cieczy (zazwyczaj jednak tylko na HiEnd i tylko na Nvidii), dynamiczną symulacją futra i ofc tak jak napisałeś postprocesami... w dzisiejszym świecie gdy dosłownie cała grafika jest generowana w postprocess (Deferred shading) Bardzo chętnie Dokładnie tyle gier ile do niedawna było kart graficznych potrafiących ten to GI wykorzystać bez straty jakości całej reszty. Czyli zero. To, że w demkach sobie karty radzą nie znaczy, że to samo jest z grami gdzie dochodzi masa obliczeń na CPU i GPU ma mniej czasu. Wyprzedzam pytanie "kiedy zaczną?" i odpowiadam gdy 980, będzie można wykorzystać w DirectX czyli Dx11.3 lub 12, bo od 980 mamy możliwość sprzętowej akceleracji voxelizacji sceny (Conservative Rasterization). Myślę, że od połowy roku możesz się zacząć rozglądać za grami wykorzystującymi NVIDIA VXGI (implementacja VCT przy wykorzystaniu sprzętowej voxelizacji), bo wreszcie będzie to możliwe w hiendowych kartach do zastosowania nie tylko w demach. Dlatego, że skalowanie wymagań od GPU jest łatwe i jeśli by bardzo chcieli mogliby i ściąć grafikę do poziomu telefonów bez praktycznie żadnego kosztu dodatkowego (kosztem jest portowanie obliczeń z CPU do innej architektury z innymi instrukcjami wektorowymi... - ścięcie grafiki to nie problem). Z bardzo prostej przyczyny PRT to tylko textury, a gdzieś siatki muszą siedzieć, a sceny się rozrosły w grach (ofc mamy sparse buffers, ale tylko i wyłącznie w OpenGL). W wypadku silnika AC:U nie wspierają jeszcze PRT, bo praca siłą rzeczy nie skupiała się na grafice. Problemem twórców AC:U była wydajność*CPU w konsolach i konieczność zmuszenia liczenia AI na prockach o smartfonowej mocy (i twórcy przyznają sami, że polegli). Jednak AC: U jest świetnym przykładem jak traktują twórcy gier słabsze komputery - jeśli przystosowanie do słabszego PC wymaga odrobiny zachodu to się po prostu olewa słabe PC. Może i tak, ale z drugiej strony takie GPU jest około 4x wydajniejsze niż w Xbox One, więc cena nie jest tak wygórowana jak się wydaje.