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.

Ilość i jakość modeli jak najbardziej automatycznie zmienisz. Modele mają przydzielone priorytety (które można usunąć, a które muszą zostać), modele mają przygotowane w wersji na najmocniejsze karty, a w wypadku słabego sprzętu używa się niższego LOD. Ilość kości jest ważna, ale TYLKO dla CPU (dlatego pisałem, że obliczeń CPU się nie da skalować, dlatego trzeba przygotować dla mniej low-endowych CPU)... dla GPU ilość kości zupełnie nie ma znaczenia - tu ważne jest ograniczenie ilość kości wpływająca na wierzchołek (i ogranicza się do 4x kości na wierzchołek, aby ładnie przesyłać dane w 2ch wektorach - jeden z numerami kości, a drugi z wagami). Zmniejszenie zużycia pamięci na tekstury było zarządzane przez silnik gry zazwyczaj (virtual texturing)... teraz idzie to jeszcze dalej i w wypadku PRT nawet nie musisz się martwić czy karta ma wystarczająco pamięci (tu tak jak Rage z 2011 po prostu jest sprawdzane ile karta ma pamięci i część z tego przeznacza się na bufor). W wypadku Hi-Endów musisz i tak musisz zrobić te LoDy zrobić (dla oddalonych obiektów) i te tekstury (chyba nie myślisz, że kolejne mipmapy są w grach AAA generowane automatycznie?). To już masz gdy targetem jest HiEnd i to nie jest dodatkowa praca do wykonania. Nie do końca - shadery PBR nie są skompilowane obliczeniowo (dziś nawet na mobilkach się je stosuje), skomplikowane są shadery postprocess jak SSS, HBAO... i to nawet nie chodzi o moc obliczeniową (też, ale nie najbardziej), a obciążenie fillrate... jednak z shaderami postprocess jest tak, że nie celuje się z nimi w przeciętne komputery. Shadery nie pisze się do gier, a pisze je dział R&D lata przed pojawieniem się kart potrafiących je obsłużyć i gdy tylko taki sprzęt się pojawia przechodzą małe modyfikacje i są wrzucane do gier na HiEndy. Słabszymi shaderami nikt już wtedy sobie głowy nie zawraca... nie trzeba ich implementować, tylko co najwyżej włączyć (słabsze shadery już są w silniku i nie trzeba ich pisać). No chyba, że mówisz przykładowo o decydowaniu o zmniejszeniu ilości sampli przykładowo w SSAO/FXAO/Voxel Cone Tracing... to jest jeszcze łatwiej, bo to wysłanie uniforma do shadera czy ustawienie stałej przy kompilacji i cała robota. Tak - jest błąd... robiłem na szybko zestawienie i ram wyparował. Dodaj 120zł na 4GB ram. Co do GPU to faktycznie skopiowałem dane z ceneo na szybko - niech będzie 2GB VRAM (aż nadto przy PRT, do którego dziś są praktycznie zmuszeni programiści nawet na konsolach - w wypadku Microsoftu jest to konieczność wymuszona mocno, ale i w wypadku Sony i przez to, że te 4.5GB na dane zarówno CPU jak i GPU (sytuacja jak w PC 2GB ram i 2GB Vram), są zmuszeni korzystać z PRT, aby streamować potrzebne tekstury do buffora w pamięci z bluray/hdd). Playstation 4 ma 8GB pamięci, ale dostępne dla gier jest tylko 4.5GB. siatki gdzieś muszą się pomieścić (w wypadku PC są tylko na GPU, ale w PS4 zajmują pamięć). W praktyce aplikacja ma 3gb max (w praktyce mniej, bo tekstury też gdzieś muszą się podziać). Zalet związanych z unifikacją praktycznie nie ma. Byłaby gdyby nie PRT, ale jest i jest wykorzystywana w większości gier (również Exów na PS4 i XboxOne), dlatego właśnie Microsoft olał wydajną zunifikowaną pamięć a zainwestował tylko w 32mb "VRam" i prawda jest taka, że dobrze zrobił, bo GDDR5 bardzo źle wpływa na na wydajność (i tak kiepskiego) CPU w PS4. Chodzi o to, że CPU odczytuje dane wybiórczo i małe porcje (GDDR5 jest super do GPU, ale do CPU to spora pomyłka). W praktyce PS4 zamiast zyskać na unifikacji pamięci stracił (zarówno względem PC, bo obecnie nie ma potrzeby współdzielenia pamięci w grach jak i względem XboxOne, które ma ram dobrze spisujący się z CPU i szybkie 32mb ram dla GPU). Jak najbardziej - cache na rdzeń jest tyle samo - 0.5MB, a to się liczy, a nie sumaryczna jego ilość. Flopsy nie są suche - Jaguar instrukcje wektorowe AVX robi w 2ch cyklach... przedstawiony procek w jednym (czytaj jeden rdzeń ma wydajność 2ch przy tej samej częstotliwości). Co więcej ten A4 ma częstotliwość 3.7GHz... co oznacza, że wydajność jednego rdzenia jest 2.3x wyższa, a to ma duże znaczenie dla wydajności, bo nie wszystko da się rozbić na małe wątki (wtedy ten A4 będzie znacznie wydajniejszy niż te 6x słabych jaguarów). Piledriver względem Jaguara ma też mocno poprawiony branch predictor czy scheduler. Wydaje się, że nie wiesz jak słabe jest te 6x Jaguar w PS4 dostępne dla gier, więc wyjaśnię: 2x rdzeniowy procesor Nvidia Denver w tablecie Nexus 9 jest od niego wydajniejszy (4x rdzeniowe Snapdragon 800 przykładowo z Samsung Galaxy S5 są wydajniejsze jedynie we flopsach, dlatego go nie podaje). Możesz zawsze używać SteamOS, bo z debiutem w marcu konsol SteamMachines powinni wydawać na niego prawie wszyscy wydawcy. Możesz też mieć już licencje windowsa z innego komputera, więc nie doliczałem, bo to już zależy od sytuacji. Tak tylko większość z tego zupełnie nie interesuje twórców gier AAA. Przeciętny gracz to gracz causalowy. I tak jak nie obchodzi nikogo, że Wii sprzedało się w wielokrotności PS3/Xbox360, czy użytkownicy Android 2.x tak nie obchodzą twórców gier gracze ze słabymi komputerami. Jeśli się da to się daje im możliwość grania poprzez wywalenie niektórych shaderów, ale ogólnie nie jest to jakoś szczególnie potrzebne, bo nowe gry kupują tylko osoby z nowymi komputerami dlatego takie Assassin's Creed: Unity jako wymagania minimalne wpisali GeForce 680 ;p GTA5 faktycznie inaczej podchodzi do sprawy. Ma pozwalać na grę nawet na archaicznym sprzecie (w sumie to logiczne, bo obcięcie grafiki to nie problem, a skoro już obcięli wymagania od CPU do formy na smartfony (czytaj nowe konsole) to i na starym PC można grać), ale jednak to też przykład gdy w którą wkładają dużo siły razem z Nvidią, aby hi-endowe karty się nie nudziły i przy maksymalnych ustawieniach, aby gta5 z konsoli schowała się ze wstydu.

Jedyna karta z 2011 roku, o której można to powiedzieć co powiedziałeś ;p. "Złożyłem" testowy komp i wyszło, że lepszy kopmputer złożysz za około 1560zł. Samo pudło - myszkę czy pada to dolicz do różnicy w cenie pierwszej kupionej gry ;p Zestaw w załączniku. //edit: dodam jeszcze tu link, bo załącznika nie widać pod newsami: http://max3d.pl/forum/attachment.php?attachmentid=98254&d=1423678860 To jaki sprzęt mają gracze PC developerów zupełnie nie obchodzi! Piszą pod maksymalną konfigurację, a jedyną troską o graczy ze słabszym sprzętem jest dodanie możliwości wyłączenia niektórych efektów, aby minimalne wymagania nie odstraszały (jednak gra w minimalnych ustawieniach to zupełnie nie jest to czym się developerzy przejmują - tu nie przejmują się optymalnym dopasowaniem pod sprzęt czy maksymalnymi wrażeniami przy słabym sprzęcie - cała praca odbywa się, aby gra wyglądała najlepiej na najlepszym możliwym PC, a późniejsze cięcia pod słabsze blaszaki są robione z pominięciem jakiejkolwiek optymalizacji czy najlepszego dostosowania efektów do mocy sprzętu (tu martwi się już gracz - co sobie wyłączy to tak będzie miał i programiści maja to gdzieś jak u niego wygląda)). Dlatego gry jak Metal Gear Solid V: Ground Zeroes na nowych konsolach wyglądają strasznie słabo w porównaniu z PC. Nie taka znowu świerzynka. W OpenGL już jest od dawna (marzec 2012) i większość obecnego hardware go wspiera (u Nvidii od Fermi (seria 400 z 2010 roku) i u AMD od Radeon HD7770 z początku 2012). Gier też już jest trochę: Rage (2011, ale wsparcie dla Sparse Textures dodano później w 2012), Wolfenstein: The New Order, The Evil Within... Świeżynką jest dopiero na nowych konsolach i w DirectX (od Dx11.2... ale wspierane dalej na Fermi+ i GCN+), ale też i tu już mamy gry wykorzystujące to jak przykładowo Ryse: Son of Rome (dzięki temu wersja Xbox One jeszcze jakoś się trzyma ;p).

Bzdura. Gry są optymalizowane pod najlepsze GPU na rynku (pod CPU nie, bo się kiepsko skaluje takie obliczenia i nie da się zrobić "wyłącz to", aby działało na słabszych CPU, ale najgorsze i3 obecnie są wydajniejsze od konsolowych procków, które mają wydajność 6cio letnich Nehalemów). Optymalizuje się TYLKO pod najlepsze GPU... a do 90% PC się nie optymalizuje nic tylko umożliwia wyłączenie efektów, aby można było i zagrać na low-endach. Jest ich mimo wszystko więcej przykładowo Konsol PS4, a ta przewaga z czasem tylko się zwiększa. Obecnie GeForce 960 (poniżej $200 - co prawda niższa przepustowość pamięci, ale nadrabia z nawiązką wydajność obliczeniowa) sprawia, że taniej złożysz mocniejszy komputer niż konsolę, a po GDC za miesiąc powinna zniknąć ostatnia zaleta konsol... niskonarzutowe API (glNext/Dx12). Nie wiem o jaką większą przepustowość pamięci Ci chodzi, ale konsole mają znacznie niższą niż GPU w PC. Ilość pamięci ram jest dziś praktycznie ważna tylko w systemie (8GB to raczej standard na PC, a na konsolach nie masz dla gier dostępne nawet 5GB), a ilość pamięci VRAM czy przepustowość PCI-E praktycznie w grach nie mają znaczenia od Partially Resident Textures (inaczej zwane Sparse Textures czy Tiled Resources). Dziwisz się? Masz zapewne GeForce 580 czyli 1581 GFLOPS (vs 1843 w PS4 i 1310 w XboxOne nie wypada źle) i przepustowością pamięci na poziomie 192 GB/s (140 GB/s w PS4 i 68 GB/s w XboxOne... no ten ma jeszcze 32mb eSRAM 200 GB/s, co go ratuje - gry wykorzystują Tiled Resources (przez co są tylko te tekstury, które są w danej klatce widoczne i według obliczeń MS 12MB to odpowiednik 6GB VRam) i renderbuffory w tej pamięci, więc z powolnej pamięci są czytane tylko siatki obiektów).

Jeśli robisz to głupio i piszesz wsparcie samemu to tak jest to bardzo trudna sprawa. Jeśli robisz to mądrze to wykorzystujesz LittleCMS tak jak Krita czy Scribus i masz doskonałą konwersje RGB/CMYK (ale też inne) uwzględniającą profile ICC praktycznie gratis.

Starałem się, pisać zrozumiale, ale nie obrażać intelektu rozmówcy, jednak do tego mnie zmuszasz, bo widzę, że nie rozumiesz słowa pisanego i trzeba łopatą: "W projekcie chodzi o podwaliny pod nowocześniejsze API", a dokonano tego poprzez "jedynie wywalenie starych rzeczy przed OpenGL 2.1 i nie "wykraczania" poza jego możliwości". VFX zakładał wywalenie starych rzeczy jak fixed pipeline (2.0 wymaga shadery, a od 2.1 język GLSL jest używalny, dlatego takie wymaganie), zapewnienie framebuffer object. To jest to całe przygotowanie pod nowe OpenGL, bo do dziś stosuje się FBO, do dziś stosuje się shadery GLSL (ofc ich język i API to już zupełnie inna rzecz i trzeba napisać je od nowa) do dziś stosuje się VBO (to co, że dziś pakuje się do VAO, używa instancingu i rysuje niebezpośrednio). Polegało to na wywaleniu dinozaurów i zastąpienie starociami, które teraz będzie się znowu przepisywać, poza FBO (no ok, jeśli będą chcieli mieć MSAA w viewporcie to będą musieli poprawić (OpenGL 3.2), ale to potrzebuje najmniejszych zmian). Tu mnie zszokowałeś! Co niby zyskujemy dzięki obsłudze EGL (obsługiwanego tylko na Androidzie i działającego tylko z OpenGL ES) poza dodatkowym kłopotem martwienia się o kolejny sposób tworzenia kontekstu (blender już wspiera SDL, WGL, GLX, Cocoa to jeszcze dowalono EGL... którego obsługe już miał poprzez SDL)? Ktoś Ci podpowiada, żebyś pisał takie brednie, czy tak sam z siebie je wypluwasz? Wysiłek po pierwsze zbędny - taki sam byłby koszt czasowy stworzenia viewportfx od razu minimum 3.3 pomijając pisanie kodu dla 2.1, który nikomu do szczęścia nie jest potrzebny. Koszt pisania wsparcia dla OpenGL 3+ szacuję na połowę czasu ViewportFX (jest to więcej niż połowa pracy włożonej w VFX (bo tu już były gotowe shadery pamiętające jeszcze yo franky (w GL3.0 api GLSL się zmieniło i trzeba je przepisać, a wszystko poza FBO co zrobiono teraz też trzeba robić od zera (poza usuwaniem starego kodu))), ale licze, że widząc efekty będzie iść szybciej)... Blender 2.80 pojawi się za jakieś 1.5 roku, a viewportFX to projekt mający już blisko 3 lata.

W projekcie chodzi o podwaliny pod nowocześniejsze API, dla przyszłych projektów jednak nie o ich wykorzystanie obecnie. I nie kłam, że tak nie jest bo dobrze wiesz, że właśnie tak. Ofc możesz zamiast pierdzielić farmazony z sufitu udowodnić, że tak nie jest - kod zarówno w czystej postaci jak i już obecnie połączony z master masz i wystarczy jedna linijka, aby udowodnić swoje racje, jednak wiesz, że jej tam nie znajdziesz. Do projektu już link podałem, ale jeśli chcesz kod już po połączeniu z masterem to proszę bardzo: https://developer.blender.org/diffusion/B/browse/ Podaje Ci link do skończonego projektu - to jest gotowy kod, który został połączony z master branch i nowych możliwości tam się nie rozwija. Na nowe możliwości musisz poczekać dopiero na przyszłe projekty. Co do "osób pracujących nad projektem" to masz na myśli: psy-fi (jedyne co zrobił to stworzył brancha), campbellbarton (poprawki stylu wyglądu kodu do reszty blendera, aby wyglądał jak reszta 20 letniego kodu) czy kilka innych osób, których wkład to bugfixy na danych platfomach, ale nie praca nad możliwościami? Jeśli nie masz pojęcia o czym mówisz to lepiej nie mów

Jaki defetyzm? Mógłbyś o nim mówić gdyby chcieli dodać wsparcie teraz, a ja bym mówił, że im to się nie uda. Ja mówię tym, że będą działać właśnie zgodnie z planem, więc gdzie tu widzisz defetyzm? Dodatkowo uważam, że zaimplementują to dobrze (jako jeden z małego grona zapewne), ale zajmie im to tyle co planują, bo nic się nie dzieje, aby to wyprzedzić. Teraz projekt ViewportFX pracował nad przepisaniem wszystkiego, nad usunięciem FixedPipeline i uzależnieniu viewportu jako minimum = shadery, a nie fixedpipeline. To dużo pracy i nad tym się skupiał (aby w przyszłości w OpenGL 3+ gdzie jest wyrzucony fixed pipeline nie robiło problemów). To bardzo ważna praca, ale nie wciskaj ludziom, że jest tam cokolwiek z OpenGL 3+, bo nie ma. VFX miał zrobić refraktoryzacje i napisać wsparcie minimum. Jest możliwość rozszerzenia tego o możliwości OpenGL 3+, ale to praca na przyszłość i IMHO błędem było pisanie wsparcia dla 2.1, bo już teraz mogłoby od razu napisane dla OpenGL 3.3, a tak to musisz poczekać na 2.8 (sam pomyśl - obecnie mamy 2.73... wsparcie dla OpenGL 3+ jest obecnie na etapie planów... wcześniej niż w 2.8 po prostu nie ma szans się pojawić... i to by było mega tępo!).

Totalny refraktoring jest potrzebny do usunięcia starych elementów pamiętających jeszcze OpenGL 1.0. Fajnie, że podałeś link potwierdzający moje słowa i że na tym się skupia (wywalenie staroci (niestety też, dzięki temu linkowi dowiedziałem się, że celem jest marnowanie dodatkowo czasu na implementacje staroci z OpenGL 1.0 za pomocą emulowania ich w nowym, jak glBegin/End za pomocą VBO (aby dalej skrypty mogły używać nieefektywnego sposobu rysowania))). Jedyne co w tym projekcie pocieszające to właśnie refractoring i oczyszczenie kodu co da możliwość w przyszłości dodawania możliwości OpenGL 3.x i wyżej, ale to już nie jest celem tego projektu na teraz - celem jest jedynie danie możliwości, żeby za następne kilka lat to wykorzystać. Ja jednak podam Ci poważniejszy link czyli kod: https://developer.blender.org/diffusion/B/browse/soc-2014-viewport_fx/ Niestety tam nie jest nawet rozpoczęte wsparcie dla jakichkolwiek możliwości wyżej niż OpenGL 2.1. To był i jest projekt jednoosobowy. Nie pisze, że pracuje nad nim cała fundacja... cała fundacja olała viewport i czeka na efekty pracy tej jednej osoby. Wcześniej taka sytuacja była przy BMeshu, który od 2007 roku powstawał jeszcze dla 2.4x wszedł dopiero w 2012 roku w mękach i raczej rozczarowująca.

Widzę, więc spróbuję napisać prosto. Piszę tylko, że na to wygląda i jeśli tego nie widzisz to uargumentuje to. Soc-2014-viewport_fx jest projektem obecnie jedynym prowadzonym w ramach viewportu. Jego celem jest jedynie wywalenie starych rzeczy przed OpenGL 2.1 i nie wykracza poza jego możliwości (dalej nie ma mowy nawet o instancigu itp - możesz sprawdzić, bo źródła są dostępne). Jedyne plany na temat wprowadzenia obsługi API OpenGL 3+ to ta roadmapa z znaczącym znakiem zapytania (czyli dopiero następca projektu viewport_fx), która sugeruje, że dodanie możliwości OpenGL 3 może będzie możliwe w okolicy Blender 2.8x (nie jako minimum, a jako wsparcie jako takie). Hmmm Mudbox wymaga OpenGL 3.x jeśli dobrze pamiętam, Maya olała kompatybilność i napisała nowy viewport 2.0, który jeśli dobrze pamiętam wymaga GL3+ (jako failback zostawili nierozwijany viewport 1, ale nowy już wymaga wyżej). Ofc są takie jak Softimage, które dalej są kompatybilne z OpenGL 1.5 i rozszerzeniami obsługują nowe GPU... problem w tym, że blender do tej pory łącznie z mającym dołączyć do niego viewportfx tego nie robi (to dopiero pole do popisu na kolejne lata rozwoju blendera, a obecnie jedynie usunięto starocie). Ja też. Tylko zauważ, że w wypadku blendera to strata zasobów w tym wypadku to długi okres czasu - od kilku lat są prowadzone projekty tylko w sprawie uporządkowania api i usunięcia staroci z viewportu, czego zwięczenie ma się pojawić w 2.7x (projekt soc-2014-viewport_fx) i będzie można zacząć myśleć o wsparciu OpenGL 3+ (jako rozszerzeniach do minimalnego 2.1). Dodanie obsługi dla OpenGL 3.x w 2.8x to mega szybkie tępo jak na rozwój viewportu w blenderze. Obsługa OpenGL 4.x puki co nawet planowana nie jest.

Mówię o roadmapie może już nie najmłodszej (połowa 2013), ale najbardziej aktualnej i stosunkowo dokładnie realizowanej. Ofc możesz nazywać opieranie się na oficjalnej roadmapie z oficjalnej strony jako wróżenie z fusów i sianie FUDu... to już twoja sprawa http://code.blender.org/index.php/2013/06/blender-roadmap-2-7-2-8-and-beyond/