materalia

Działa bezproblemowo na R9 380, także HD 7650M i Intel Haswell (choć tu wolno przy większych proj. - brak własnego VRAM). Pobawiłem się tym modelem Hans. PBR działa elegancko, idealnie. Aplikacja jednak dość specyficzna. Mocno obciąża RAM i szynę PCIx kiedy zaczyna brakować VRAM (dlatego PCIx 3.0 by się przydało), potrzebuje naprawdę sporo VRAM (mi zjadło na dzień dobry w tym projekcie 1.5GB na karcie graf., a bez problemu dobiłem do 3GB, jako amator tej aplikacji, przypominam, że GTX970 ma realnie szybkiego VRAM tylko 3.5GB). Dużo mieli też CPU (nie są typowo ciężkie obliczenia)... Pewnie na VRAM i wolniejszej PCIx (masz 2.0 na Phenomie X6 - to jednak 2x wolniej niż 3.0) ten GTX 660 2GB tak niedomaga w tym programie najbardziej.

NVIDIA też kręci chwilę, potem wypuszcza i poprawia, nie sądzisz chyba, że ktoś tam tygodniami testuje każdy program przy każdej kolejnej wersji sterownika. Wiesz, ja wolę sprawdzić niż fantazjować nt. nieistniejących bugów na podstawie plotek, bo kiedyś gdzieś coś tam było to tak musi być itd. Waszym zdaniem to ja ponoć od razu miałem przekonać się o tych bugach na tym Radeonie, niestety nic na razie nie wykryłem z tego co piszecie, teraz wygląda na to, że musiałbym pokręcić kilka tygodni, no super podejście :). Kręcę w innych programach niż Maya na Radeonie i tam bugów nie ma. Jeszcze pokręcę czasami, chociaż Maya to nie mój target - za drogo, może coś znajdę to będziecie hepi :)

Windows 7. W Windows 10 na razie nie będę wchodził, bo problemy są chyba nie tylko z Autodesk, nawet program do faktur mi się wywalał he:). Używam jeszcze Linux na drugim kompie - szkoda kasy na kolejną licencje. Na laptopie też Win7. Testowałem Win 8.1 i nie było fajnie, nie chodzi o sterownik, tylko sam system.

na jakiej podstawie sądzisz, że będą problemy ?. Czyli teraz viewport na Radeon będzie się psuł po określonym czasie :) owszem, przy założeniu, że zostanie to wykorzystane, więc nie sadzę żeby to dało jakiś duży narzut czasowy na końcowy rendering sceny benchmarka, który tej funkcjonalności nie wykorzysta. nie decydują o tym powody technologiczne tylko ramy czas/praca/ludzie itp. np: brak obsługi hdr w cycles ocl nie wynika z braków technologicznych kart AMD:), tylko nie ma kto tego zrobić itd. jest z resztą cyclesa. PS. nadal jest to OCL1.1 i poprawki na samym kodzie kernela, które są ważne i przechodzi wyżej, ale dopiero przepisanie na OCL2.x pozwoli zrównać funkcjonalność z wersją CPU przy dalszym wykorzystaniu GPU. CUDA cycles nigdy nie zrówna się z wersją CPU tak żeby nadawało się do finala. https://www.blender.org/manual/render/cycles/features.html Tu masz pobieżnie porównanie po tym pierwszym patchu OCL(GCN). Experimental można odłożyć na półkę, bo to prędzej rozwali sterownik niż zadziała, transparent shadows w kolejnym patchu OCL, potem branched path integrator, coś jeszcze ma sens na małych rdzeniach GPU ?. Noo, jest Volume, ale to takie jest, bo ma duże wymagania. PS. jest alternatywna w postaci obecnie Luxrender 1.5... do Blendera i nie tylko :)

Dzięki za docenienie trudu, bo nie używam Maya, ale w programach które używam godzinami nie mam takich "problemów" jakie wymyślasz. Ludzie zatwierdzający sterowniki w NVIDIA robią dokładnie tak samo jak w AMD, więc nie bardzo rozumiem do czego zmierzasz. NVIDIA naprawdę nie jest nieomylna i też robi nie mniej bugów od AMD lub podąża drogą skazaną na porażkę. Tak czy owak na końcu o jakości implementacji viewportu OGL na różnych GPU decydują głównie twórcy samego softu i to do nich należy kierować ew. zarzuty z przykładami bugów. napisz jak sprawdzić to sprawdzę i zob. czy wystają w takim przypadku jak opiszesz. zacięcia zdarzają się też na NVIDIA, czasami programy tak mają i nie jest to najczęściej wina sterowników. Resztę postaram się sprawdzić przy kolejnej sesji z Maya2016, chociaż nie wiem czy znajdę scenę 15GB. Nie przesadzasz, czy ktoś tu robi takie sceny ?. :) nie wiem czy to z helpa, ale wszystko okej (na w/w GPU od AMD i Intel): http://area.autodesk.com/blogs/duncan/scene-files-from-my-maya-2014-unfold-presentation Kuriozalna farsa to jest hejtowanie na AMD Radeon poparte, no nie wiem czym właśnie poparte, chyba plotkami. Miałem problemy z AMD i NVIDIA, średnio takie same na przestrzeni lat, więc w tym kontekście nie widzę powodów żeby którąkolwiek firmę faworyzować. Wolę AMD, ale używałem wielu kart NVIDIA, bo akurat tanio mi się trafiła i było okej, poczynając od Riva128ZX/TNT, podobnie jak inni dałem się zrobić w CUDA, które są przereklamowane w użytku... Każdej z tych firm zdarzają się lepsze i gorsze momenty. Nie będę ich wymieniał. Tak było i jest.

napisz co i jak to sprawdzę, nie chce mi się wertować dokumentacji obsługi Maya :). Marking Menu działa, jeżeli to to samo co myślę jest w C4D, zarówno na AMD R9 380/HD 7650M i IntelHD Haswell. Funkcje to działają raczej wszystkie, te sceny nie wyglądają na proste dla viewportu http://area.autodesk.com/blogs/duncan/scene-files-from-my-maya-2014-unfold-presentation - to nie jest sama tylko kulka z uv i teksturką, jest tam także smoke, shadery itp. i jest okej, ale mogę sprawdzić jeszcze tekstury hdr. Nie mam punktu odniesienia do wydajności viewportu, bo nie używam Maya, ale o ile Maya jest sama w sobie ciężka (od zawsze) to viewport działa nadzwyczaj lekko. Sprawdzę jeszcze któryś z kolejnych tych programów, ale to dziś lub jutro wieczór.

Nie no, skończcie z tym hejtem, bo to jest naprawdę żałosne. Tak źle przeżyć, że wszystko działa okej w viewport Maya 2016sp4 na AMD OpenGL ?:), chociaż miała być straszna kaszana. Dla mnie to żadne zaskoczenie, bo w innych programach jest podobnie na AMD. Główny powód dla którego karty AMD odstają w temacie silników renderujących korzystających z GPU to mniejsze tym zainteresowanie ze strony także AMD i krótszy czas rozwoju... Z OpenCL da się wycisnąć ile fabryka dała tylko tak samo jak w przypadku CUDA wymaga to specjalnego i czasochłonnego optymalizowana. Problem z NVIDIA jest taki, że od wersji 1.1 praktycznie przestali rozwijać OpenCL (1.2 chyba jeszcze nie ma, to zrozumiałe, bo faworyzują zamknięte CUDA) i dzisiaj są tutaj daleko w tyle za AMD (OpenCL 2.1) i także Intelem (OpenCL 2.0) - także innymi (OCL2 mają nawet już niektóre mobilniaki), także optymalny silnik OpenCL dla AMD nie ruszy na NVIDIA GPU, raczej na Intel GPU, bo na CPU to wiadomo. Myślisz, że dodanie tego co brakuje w Cycles OCL spowoduje znaczny spadek wydajności na karcie AMD w tym benchmarku ?:). Nie sadzę, bo ten benchmark tego nie używa:). Poprawki dla AMD nie korzystają z dobrodziejstw OpenCL 2.x, tylko zoptymalizowano sam kernel pod goły rdzeń GCN. Kernel dla Cyclesa jest okrojony na AMD, bo to wymaga czasu i pracy, ale dla CUDA pomimo niemal równego parcia z CPU też jest okrojony, bo musi być przykrojony do rdzeni CUDA (niektóre rzeczy działają, ale są nadal nieużywalne w praktyce), sęk w tym, że to już tak zostanie, bo GPU zawsze będzie mieć "ograniczony" rdzeń i pewne bariery zostaną na zawsze, a OpenCL nie jest tymi barierami ograniczony, szczególnie przy wersji 2.1 ze wsparciem HSA. Mówiąc prostym językiem, kończy się era specjalnie krojonych silników tylko i wyłącznie pod GPU. Kernele OCL mogą być wykonywane zarówno na CPU i GPU, to było. W zależności od możliwości sprzętu lub skali danych są wykonywane na CPU i GPU, to faktycznie działa dobrze dopiero od 2.0. HSA rozwiązuje tutaj problem dzielenia zasobów danych (SVM) - dodaje też ochronę zasobów, poprawia znacznie rozdział zasobów - asynchroniczność, out-of-order itd., integruje wszystko w SPIR-V (OCL/OGL/Vulcan/DX12, praktycznie dowolny język programowania) i jeszcze kilka innych istotnych "drobiazgów" doszło. Oczywiście dalej trzeba mocno optymalizować kernel żeby wycisnąć najwięcej z małego rdzenia GPU, bo CPU poradzi sobie z "każdym" kodem i wielkością danych. Nie zmienia to faktu, że takie podejście pozwala pisać pełne silniki renderujące dotychczas dostępne tylko dla CPU, które zależnie od sytuacji skorzystają z dobrodziejstw GPU lub wykonają się na CPU. Wiem, że obecnie takich silników renderujących nie ma i trochę wody upłynie nim będą, ale przykładowy LuxRender czy Indigo, a także Octane 3.x mogą zacząć z tej możliwości kiedyś korzystać i przestać być ograniczone barierami rdzenia GPU, wtedy na kartach NVIDIA coś nie ruszy wcale lub w bardzo ogr. zakresie dla mniejszego zbioru danych. Do tego czasu może NVIDIA dopracuje arch. Pascal lub Volta i naprawią ułomności swojej przestarzałej architektury CUDA :) Inną sprawą jest wydajność operacji na samych rdzeniach NVIDIA vs Intel vs AMD. Tu wszystko zależy od zadania i jakości kompilatora (ostatecznie jest asm), bo nie ma tak, że rdzeń GPU na NVIDIA lub AMD lub Intel... będzie lepszy we wszystkim od pozostałych.

Owszem, tylko piszecie takie bajki o kartach AMD, że wg. tych słów to moje dwa Radeony (R9 380 i mobilny 7650M) nie powinny w ogóle działać:), bo OpenGL ma trylion niespodziewanych błędów na każdym kroku, także nie da rady z tym żyć i trzeba cieszyć się jak cokolwiek wyświetli, choćby jednego piksela, a nie walnie focha i spali komputer, nie wyświetlając nawet fucka na pożegnanie, bo to zbyt skomplikowane dla Radeona bez cudów:). Dla mnie to jakieś niedorzeczności powielane i narastające przy takich okazjach, bo osobiście nie dostrzegam żadnej jakościowej różnicy w OpenGL między obecnym R9 i GTX, baa, nawet między mobilnym RadeonHD 7650M. W kwestii wydajności viewportu to R9 380 nie jest na pewno słabszy od GTX970, zarówno w FHD i UHD(4K), przynajmniej w programach których używam. Na siłę to ja też znajdę Geforca który coś tam pominie w viewport, mam jeszcze w szafie GF9800, bo nie wiem jak można porównywać kartę Radeon HD 4xxx (znacznie gorszą od IntelHD) do GTX660, przecież to jest zupełnie inna bajka z innej epoki. Nawet porównanie z tego filmiku jest mocno naciągane pod tezy. --- No dobra koniec bajeczek pora na fakty o rzekomo rozkraczającym się viewport na AMD Radeon w Maya. Zaintalowałem Maya 2016 SP4 trial. Nie mam scen, więc wziąłem z tego linku: http://area.autodesk.com/blogs/duncan/scene-files-from-my-maya-2014-unfold-presentation . Są tam zrzuty więc mam pi razy drzwi porównanie jakościowe na oko. No cóż mogę powiedzieć. Maya jest tak samo ciężka jak ostatnio tj. lat temu xx kiedy próbowałem ogarnąć Pixar Rend (wtedy geforce2), ale poddałem się... Wszystko jest jak być powinno na R9 380, wygląda identycznie jak na tych zrzutach. Wszystkie scenki są płynne na maks. ustawieniach viewportu (AA itd.). Pobawiłem się chwilę w prostą edycje tj. vertexy, facy, uv itp. i wsio działa jak należy. Nic nie znika, linie są proste, kule okrągłe, nigdzie się nic nie rozjeżdża...:) No nie wiem co jeszcze dodać, jest stabilnie, nic się nie wywaliło przez godzinę. Co teraz mam pomyśleć, hejt czy nie hejt ?. Dobra, sprawdziłem na laptopie z Radeon HD 7650M (poprzednia generacja AMD VLIW), poza tym, że jest wyraźnie wolniej, bo to układ mobilny, to wszystko okej. Wyłączyłem Radeona i przeszedłem na IntelHD Haswell, tu musi być kicha, nie ma bata, zaskoczenie, jest jeszcze wolniej lecz wszystko okej. W przypadku IntelHD jestem naprawdę zaskoczony poprawnością wyświetlania jak na tak w sumie zaawansowany viewport Maya. W zasadzie można używać Maya 2016 na IntelHD, jak nie ma innych lepszych opcji. Odinstalowałem Maya 2016. Tak to wygląda na szybko z OpenGL i viewport Maya 2016sp4. --- Co do GPGPU to CUDA jest pewną zaletą jak się z tego skorzysta i jest soft CUDA (tego nie ma za wiele) w miarę stabilny, mi na GTX550Ti i 650Ti tak czesto wywalało sterownik i program jednocześnie - poza Octane (najlepszy moim zdaniem), że dałem sobie z tym spokój i w ogóle z renderingiem na GPU, chociaż tak; LuxRender działa całkiem stabilnie na R9 380 i 7650M, podobnie Indigo (choć nie tak wydajnie jak LuxRender), nawet jest już niezbyt stabliny Cycles na AMD który osiąga na R9 380 zawrotną wydajność GTX980 (karty ponad 2x droższej) - tutaj brakuje funkcji do wersji CPU. Postanowiłem jednak pozostać przy CPU dla świętego spokoju, po prostu łatwiej tym zarządzać i raczej można doczekać szczęśliwego końca bez niespodzianek, być może HSA to zmieni i pozwoli dodatkowo renderować CPU&GPU, nie tylko "ograniczone" GPU.

akurat ten film jest dużo mniej wiarygodny od tych testów Maya 2013 z linku jaki zapodałem, porównuje się na tym filmiku karty które dzieli przepaść i nie znamy środowiska testowego... A co do forów, to już chyba wyjaśniłem, że to są przepisywacze z CUDA NVIDIA na OCL, gdyby było na odwrót, takie same narzekania leciałyby na NVIDIA. Możesz oczywiście zaprzeczać, ale NVIDIA ze swoją wizją CUDA jest w głębokiej d. w kwestii HSA (OCL2.x, C++ Amp itp. ). Tak czy owak CUDA się kończy w tej formie i będzie wcześniej czy później byebye jak nie będą mieli asynchronicznego GPU ze wsparciem dla spec. HSA/hUMA itd. Nikt nie będzie chciał w to dalej wchodzić jak NVIDIA nie zmieni architektury na coś podobnego do AMD GCN.

wszystkie są oparte na OGL, a od kiedy OGL to jakiś NVIDIowy standard, działa OGL tak samo na NVIDIA i AMD ?. Tak jak kiedyś weszły GLSL, tak pewnie wejdzie kiedyś Vulcan, albo prędzej DX12. Do tego czasu może NVIDIA zaoferuje układ wspierający to natywnie. I karta za 1500 zł ma w tym pomóc, trochę dziwny argument, bo aż takich cudów to po tych CUDAch bym się nie spodziewał :). Szczerze, to przy GTX660 zastanawiałbym się raczej nad sensem tego zakupu, bo lepiej byłoby przenieść kasę na wymianę płyty i procesora (ma Phenom II X6), bo to jest tutaj główny hamulcowy, nawet tego GTX 660. np: http://www.morele.net/procesor-serwerowy-intel-xeon-e3-1231v3-3-4-ghz-lga1150-box-bx80646e31231v3-640233/ 1139 zł do tego jakaś płyta za 300-400 zł, resztę ma :). Dużo większy zysk to da niż zakup tego co już ma - GTX660 też dostanie powera w viewport i nie tylko.

Ad.1 owszem, ale jest okej. Jeżeli takie coś ma miejsce to wina jest na 100% po stronie twórców Maya, a nie sterowników Radeon. Nigdy nie miałem z tym problemów na innych soft, od kiedy pamiętam. Ad.2 sugerujesz, że Radeon jest zbyt prymitywny do opensubd ?:) Ad.3 Tam nie tylko AMD Fire Pro są w testach, także Radeon 7750 za 200zł:). FirePro poza wyższą wydajnością głównie w dp (double prec.) i SLI nic więcej nie wnoszą względem tych konsumenckich, a wszystko to ten sam GCN..., więc po co kupować 5-10x tańszą NVIDIA, jak 8x-15x tańszy Radeon da to samo ;). Ad.4 iRay to jest właśnie przykład polityki NVIDIA i zamykania wszystkiego na klucz co tylko dotkną. NVIDIA iRay to w ogóle działa na Radeonach, przecież to chyba jest CUDA. To, że się kaszani na Radeonach to wcale mnie nie dziwi, zdziwłbym się gdyby było inaczej, naprawdę :) Troszkę stary i mało wiarygodny ten film; Radeon 5670 vs GTX560Ti, bardziej odpowiedni byłby Radeon HD 69xx. ps. zawsze można sprawdzić demo Maya 2016, ale coś czuję, że wszystko będzie okej tj. kula niezjajczeje itp. i nie chce mi się tej kobyły instalować, ale może jutro sprawdzę żeby zamknąć ten absurdalny hejt na AMD, bo już kiedyś miałem podobny dt. 3dsmax i też miało się sypnąć na amen, a jak na złość wszystko działało normalnie:)

to raczej kwestia początków, bo jak ktoś napisał swój program na CUDA, a potem przenosi na szybciocha do OCL, to zaczyna narzekać na AMD, jakby odwrócić sytuację to będzie dokładnie tak samo, z tym jednak warunkiem, że kodu OCL2.x nie da się przenieść do CUDA tak żeby zadziałało i dopiero byłby lament na NVIDIA. masz już działający DX12 i jest Mantle, a przecież Vulcan = Mantle 2.0 :) AMD ma już nowatorską archtekturę z ACE zgodą z HSA, teraz musi za tym podążyć soft, a co ma NVIDIA, od 10 lat trzepie te swoje ograniczone mikrordzenie CUDA pod CUDA SDK na tysiąc sposobów, raz lepiej, raz gorzej, tu doda, tam utnie, przytnie, zmieni nazwę i wykastruje itp., i na tym utknęli. W tym czasie AMD zaprezentowało pierwsze na świecie niskopoziomowe API do 3D tj. Mantle, które ekspresem wjechało do DX12 i ustanawia nowy osobny standard Vulkan który będzie wspierany przez wszystkich, AMD pierwsze na świecie zrobiło asynchronicznie działający układ GPU (ACE itp.) i powiązało to z CPU poprzez współdzieloną chronioną pamięć, a na poziomie oprogramowania power zaczyna się od OpenCL 2.x (teraz jest 2.1) z tymi bajerami, gdzie NVIDIA chyba już na dobre utknęła na 1.2, a CUDA dalej trzepie się ze swoim mikrordzeniem i prymitywnym schedulerem zyskując głównie na skoku tech. AMD pierwsze na świecie zaprezentowało pamięć warstwą (HBM) zintegrowaną z rdzeniem GPU co zmniejszyło TDP, rozmiar karty i dało niezły w tej relacji power karcie. Pewnie jeszcze coś pominąłem :), ale widać u AMD jakąś wizję rozwoju, a bez wizji kręcilibyśmy na OGL1.1, pewnie NVIDI by to pasowało:), bo tak to ciągle coś musi podglądać, tak jak będzie to w Pascalu który najpewniej będzie repliką wieloletniej już arch. AMD GCN otoczonej w rdzenie CUDA i wzbogacone rzekomo lepszym HBM. Faktem jest, że CUDA jest i nawet dobrze działa w pewnych małych operacjach, ale faktem jest, że ten model programowania GPGPU już skończył się na dobre i kręci się w kółko, jak pies ogrodnika za swoim ogonem. Od jakiegoś czasu to jakby zastygło, nawet softu nowego na horyzoncie nie widać. Nikt jednak CUDA szybko nie porzuci, za dużo ludzi dało się nabrać na to hasło wierząc w cuda :). --- Co do zarzutów dt. OpenGL w viewport to chciałbym żeby mi ktoś pokazał jak to kula sama jajczeje itp.. Jeszcze chwila i hejt sięgnie absurdów typu na AMD to 2+2 = 5, a trójkąt ma cztery boki itp. Gdybym nie używał kart AMD od 15 lat, podobnie jak NVIDIA, to może dałbym się naciąć na tego typu opinie :)

A tutaj szerokie testy Maya 2013, czyli dość stare na AMD i NVIDIA, a teraz przecież jest nie gorzej. https://www.pugetsystems.com/labs/articles/AutoDesk-Maya-2013-GPU-Acceleration-166/ i jakoś nie widzę żeby takie cudeńka tworzyli jak "ca mel", czytając nieraz o tym jak złe jest AMD to człowiek myśli, że po zainstalowaniu AMD komputer wybuchnie prosto w twarz, a o wyświetleniu viewportu to nie ma mowy, za skomplikowane, wszystko zniknie:), bo ta karta nadaje się tylko do zabijania ufoków i to nie za dużych, bo brakuje cuda :)

To proszę dowieść, że AMD obecne na rynku ze swoim OGL nie działają prawidłowo na jakimś sofcie. Proste jak drut, bo inaczej uznam to za takie samo gdybanie. Tak się składa, że mam kartę AMD i mogę gdybania zweryfikować :). Jak ktoś mi pisze o znikających elementach to traktuje to niezbyt serio, bo jeszcze nic takiego na dwóch posiadanych przez siebie kartach AMD nie zaobserwowałem w żadnym z używanych softów. Do stabilności też nie mogę się specjalnie przyczepić. Skoro działa tak samo to po cholerę 2x przepłacać za taką samą wydajność i możliwości, dla świętego spokoju ?. bo producent skaluje jednostki ROP i TMU do przepustowości pamięci, ale wystarczy jak obniżysz zegar RAM to przekonasz się o tym co waży najmocniej, nietrudno chyba to dowieść.

Z tymi petycjami z 2012/2013 roku to pojechałeś, także rzeczy uznaje za hejt, tylko jak to się ma do obecnego czasu, trochę nijak. Osobliwa technologia CUDA z GPU NVIDIA zawsze będzie lepiej zintegrowane niż otwarty standard w NVIDIA, szczególnie kiedy tygodnie pracy idą na optymalizacje konkretnie pod architekturę vide Octane dla Maxwella gdzie szarpnięto się w poprawki na poziomie assemblera.., wystarczy porównać CUDA do OCL na samej NVIDIA, widać to także było w przypadku AMD na przykładzie Mantle vs DX11, tylko AMD zresztą słusznie postanowiło ten projekt nie faworyzować publicznie i przenieść rozwiązania do standardu DX12 i Vulcan - które są implementowane nie tylko na AMD. CUDA nie jest do zaakceptowania w szerszym kontekście, było super w czasach pionierskich GPGPU, ale na dłuższą metę NVIDIA przegra z tym uzależniającym podejściem, bo co z tego, że można sobie całkiem mocno akcelerować GPU jakieś niewielkie operacje skoro np: cały końcowy rendering trzeba już puścić na CPU po to żeby ogarnąć całą złożoność projektu vide VrayRT vs Vray czy Blender Cycles itp. - który jak wiesz nie wspiera wszystkiego pomimo tytanicznej pracy jaką wykonano..., wtedy już bez jakiegokolwiek wsparcia GPU, to na co taki GPGPU ?. Na tym osadza się niewielka przydatność GPGPU w renderingu 3D. Obecnie OpenCL2.x i OpenGL Vulcan w AMD są nieporównywalne do swoich poprzedników. AMD dawno temu w pierwszej kolejności rozwijało swoje CUDA które nazywało się wtedy Brook++, potem zarzucili na rzecz standardu OpenCL, ale byli w tyle za NVIDIA, teraz to się zmieniło i jest na odwrót. OpenCL to nie jedyne rozwiązanie i nawet nie najlepsze od strony dev jakie ma do zaoferowania teraz AMD, że wspomnę choćby Microsoft C++ Amp, itp. Mógłbym uwierzyć w to co piszesz nt. OGL gdyby nie Cinema4D która jest jednym ze stabilniejszych kolubryn3D i notorycznie wywalała mi się w OpenGL na GTX550Ti, ale rozumiem, NVIDIA zmieniła kolejny raz architekturę i poprzednią zaczęła nieco olewać w sterownikach. AMD robi to jeszcze bardziej okrutnie i przestaje całkowicie wspierać stare architektury. CUDA nie wywalają się przy różnych okazjach, tak to jeszcze uwierzę w nieomylność NVIDI, mi się wywalało dość często na GTX550Ti, następował freez i restart sterów, to chyba tutaj normalka ?:) Na AMD z OGL to akurat nie miałem jakiś problemów na używanych softach, ale nie wątpię w ich istnienie :). Ty nastawiasz się na full only GPU, okej, czyli taki stary czysty GPGPU ścisle powiązany z jednym układem ze wszystkimi tego konsekwencjami tj. wyższa wydajność lecz ograniczone możliwości i zakres użycia, a dzisiaj się od tego odchodzi na rzecz HSA tj. asynchronicznej integracji CPU, GPU, współdzielonej pamięci itd. NVIDIA też podąża w tym kierunku, przekonasz się o tym za rok jak zerzną od AMD architekturę GCN i wypuszczą pod swoją nazwą jako Pascal GTX 1000, wtedy zacznie się euforia i chwalenie tego co robi obecnie AMD jako wielkie odkrycie na przyszłość NVIDIA :)

W takiej opozycji której nie ma tak jak tej rzekomej lewicy w parlamencie hehe:). Istnieje od lat jakaś zmowa na czerwonych, nie wiem czemu, może to wina koloru i dlatego zieloni są bardziej trendy ;). ps. w domu są jeszcze dwa inne kompy użytkowane przez domowników i nie są to czerwoni ;).

co się zmieni, jakościowo to nic, a ilościowo to być może, czyli może dupki nie urwać, może być przeciwnie. Patrząc na osiągi OGL w Cinebench http://cbscores.com/index.php?sort=ogl&order=desc , to sam widzisz jakie to zmiennie, ten sam GPU może mieć osiągi diametralnie różne, wystarczy spojrzeć na rozstrzał wyników dla GTX Titan; od 95fps do 193fps. Ktoś to wyjaśni, dlatego lepiej nawet pożyczyć i sprawdzić niż być rozczarowanym :). Problem z OpenCL jest taki, że skoro coś działa w OpenCL na NVIDIA to nie jest optymalne na OpenCL, bo NVIDIA praktycznie olała OpenCL od wersji 1.1, a wsparcie dla 1.2 dała dlatego, bo niewiele to kosztowało..., a obecnie AMD ma już OpenCL 2.1 (także Intel i mobilni), który nawet nie da się zaimplementować na układach NVIDIA Maxwell (GTX9xx/Titan), może dopiero na arch. Pascal która ma być w 2016, bo układy NVIDIA nie mają takich funkcjonalności i sporo trzeba byłoby emulować programowo w sterowniku co byłoby mało efektywne i postawiło układy NVIDIA w złym świetle. NVIDIA robi to celowo zmuszając twórców do używania swojego zamkniętego frameworka CUDA lub starego OpenCL 1.1 ew. 1.2, jeżeli sama karta ma być w pełni wykorzystana lub jakkolwiek wykorzystana. CUDA ma taką wadę, że działa tylko na GPU od NVIDA, działa tylko na GPU, nie wspiera asynchronicznego HSA/hUMA. To jest ogromna wada dla twórców oprogramowania konsumenckiego, także coraz więcej z nich będzie przechodzić na OpenCL, oby 2.x od razu vide zapowiedź Octane 3.0 na OpenCL. To będzie tutaj nowy wyścig. OpenCL 2.x daje możliwość implementacji bardziej złożonych procedur/algorytmów niż CUDA. Na OpenCL opiera się także C++ Amp, OpenACC itp. OpenCL 2.x (jeszcze w połączeniu z Vulcan) praktycznie eliminuje wąskie gardła GPGPU, czyli można stworzyć kompletny silnik renderujący bez podziału na GPU i CPU np: w Vray zniknąłby podział na VrayRT i Vray. Kto sobie pozwoli na niewspieranie kart NVIDIA w 3D, jakoś łatwiej przyjęło się niewspieranie kart AMD/Intel itd., ale NVIDIA, dlatego wszyscy będą czekać x lat z tym jak NVIDIA się ogarnie..., bo takie karty są najpopularniejsze wśród "weteranów" 3D ?:)

to raczej nie jest wina sterowników Radeon, gdyby tak było jak piszesz to podobnie byłoby w innych programach, a tak w innych programach nie jest, więc leży to tylko w geście twórców Maya i to tam kierowałbym ew. zapytania. OpenGL w Radeonach jest bardziej strict ze standardami Khronos, czyli mniej wrażliwy na błędy wynikające z mieszania specyfikacji poszczególnych wersji i rozszerzeń, być może w tym leży problem, pomijając różnice w obsłudze specyficznych rozszerzeń dla AMD i NVIDIA. Reszta to mity. Co do samego OpenGL to AMD wspiera już Vulcan, a nie ma innej drogi rozwoju, bo klasyczny OpenGL w pewnym sensie skończył się już jako API do 3D i nie może rozwijać się w dotychczasowej formie, a co robi NVIDIA, na razie niewiele, bo mają zbyt kiepską i niedopasowaną architekturę GPU do Vulcana - wspomniałem o tym wcześniej, że muszą porzucić Maxwella na rzecz czegoś na wzór AMD GCN, tak czy owak. fillrate jest powiązany bezpośrednio z przepustowością pamięci (liczba bitów i zegar pamięci) i to będzie ostatecznie wąskim gardłem. Podawane tam teoretyczne wartości są obliczane tylko wg. wzoru; liczba jednostek x zegar rdzenia.

coś czuję, że będzie kicha, bo jak się Polacy za coś wezmą tak wespół to tylko usiąść i płakać ;), ale jestem optymistą i dobrze wszystkim życzę.

Zarabiam ile zarabiam:), ale na pierwszym miejscu skneruje hehe. W związku z tym dla siebie zamiast i7 mam AMD FX-8320E do OC 4.x Ghz, a zamiast GTX980 mam najtańsza wersje układu Tonga/GCN1.2 (GCN w drugiej odsłonie zadziałał na moją wyobraźnię) tj. R9 380 4GB i nawet tego żałuję, bo do viewportu to taki sam komfort miałbym na Saphhire R7 370 OC 2GB - sprawdzałem pod siebie. Pocieszam się tylko tutaj bardziej miodnymi grami, które na marginesie zazwyczaj śmigają niewiele gorzej niż na GTX970 i zazwyczaj wyraźnie lepiej niż na GTX960. Nie wiem jakie duże sceny robisz (poly + tex), na jak dużych pracujesz, bo głównie tym powinieneś kierować się przy wyborze sprzętu. To najbardziej oczywista oczywistość jak rzekł klasyk. ps. wydajność w 3D tej nowej karty jaką wybierzesz i tak będziesz miał ograniczoną przez wydajność CPU i reszty. Możliwe, że nic się nie zmieni względem GTX 660, tylko w kieszeni będzie jakby lżej :)

Artykuł dość stary kiedy CUDA było dobre w czasach gdy GPGPU dopiero zaczynało swoją karierę, programista decydował co przepisze na GPU, bo się da, a wtedy GPU działa synchronicznie (in-order) z takimi "małym" zadaniami które się dało. Dzisiaj patrzy się na OpenCL 2.x, Microsoft C++ Amp (wymaga OCL2.x, hardware async compute-jednostek ACE w GPU), OpenACC/HMPP itp. Dzięki temu podejściu pisze się jeden ten sam kod do wszystkiego, gdzie w zależności od rodzaju/wielkości danych, dostępnego sprzętu w systemie, kod działa na CPU i GPU w asynchronicznym modelu HSA/HUMA wspieranym sprzętowo lub programowo. CUDA tego nie oferuje, dlatego NVIDIA coś jakby kombinuje z dodaniem rdzeni CPU do GPU na karcie graficznej np: w projekcie Volta - na pewno nie będą to rdzenie x86. Od DX12 to DirectX też ulega przebudowie w tym kierunku i podobnie jest z OpenGL Vulkan. Skoro mowa jest o wykorzystaniu ogólnym GPU wraz z CPU to raczej CUDA nie będą tutaj wiodącym frameworkiem. Na razie NVIDIA udało się skutecznie wcisnąć swoje CUDA GPU do kilku silników renderujących, które praktycznie całkowicie się uzależniły od NVIDIA np: Octane, stanowiący pewien wzór profesjonalnego silnika renderującego GPU, także Cycles z powodu swojej bezpłatności i zazwyczaj zadowalających rezultatów na GPU, chociaż wersja CPU ma większe możliwości i jest stabilniejsza:).

To można powiedzieć raczej o różnicy między AMD R9 380 2/4GB kosztującej 850-900 zł i GTX 970 4GB (3.5) kosztującej 1500-1600 zł :) - w porywach 20% wydajniejsza i to głównie w produkcjach giercowych mocno używających NVIDIA Gameworks np: Wiedzmin3. Na dniach będzie R9 380x droższa o ok. 100-150 zł, która praktycznie zrówna się z GTX970. Najtańsza GTX 980 kosztuje 2000-2100 zł, bez przesady z tym dużo wyższa cena, bo to +500-600zł, chociaż moim zdaniem cena GTX970 jest mimo wszystko za wysoka jak za takie kastracje. Pytanie mam inne, czy dajecie gwarancję, że viewport w GTX970 będzie blisko 2x wydajniejszy od R9 380, bo to jest dylemat ?:) ps. fillrate to nie jedyny ważny wskaźnik. w tych tabelkach są zawsze teoretyczne.

Nie z powodów technologicznych, tylko raczej marketingowych i finansowych produkują słabsze układy, chociaż nie tylko, bo jest ogromne zapotrzebowanie na mniejsze powierzchniowo układy o niskiej energetyce, więc gadanie jakoby były z gorszego kawałka krzemu też nie jest prawdą... Nie odcinają rdzeni piłką do krzemu, bo to są kompletne układy, zarówno mniejsze i większe :), chociaż zdarzały się dziwaczne modele z wyłączonym jednym blokiem np: GTX670 (względem GTX680), którego następcą jest w pewien sposób 970 -też w sumie taki dziwaczny kastrat.

to kastrowanie jest przyczyną wolniejszego działania 0.5GB z 4GB na GTX970 - tak twierdzi NVIDIA, więc nie jest to takie coś do czego przywykliśmy w słabszych wersjach, ale to wynika też z ograniczeń architektury Maxwell, której dużo brakuje do AMD GCN, ale pewnie Pascal lub Volta to nadrobią. NVIDIA Pascal zapewne będzie jakąś bardziej lub mniej udaną kopią AMD GCN, jak sądzę, bo nic lepszego raczej nie wymyślą, dodadzą HBM (też od AMD) i będziemy mielu Fury X Nano od NVIDIA tylko z kilku letnim poślizgiem o nazwie GTX i wsparciem NV CUDA-i to będzie największy plus. Tak to wygląda od strony hardware. Od strony software wygląda to tak, że bazuje się na poprzednich API OGL/DX/OCL, a więc poprzednich założeń dt. użycia GPU. nie 2.5x tylko 2.1x, wiesz 0.4 to tutaj kilkaset zł, cena takiego GTX750Ti lub R9 370 :) 4k tekstury to są do ultra detal w grach FHD, a 8k i 16k tekstury są do gier UHD i UHD+, także nawet do FHD to 8GB w R9 390 może zostać szybko zjedzone przez tekstury. Pytanie jak grafik może zużyć 6GB GTX 980Ti lub 8GB R9 390/390x to sobie musi każdy sam odpowiedzieć w zależności od swoich potrzeb. Do renderowania kosztujący tyle samo R9 390 z 8GB byłby lepszy od GTX970 4GB (3.5), ale brak tak szerokiego wsparcia ze strony softu niestety praktycznie go dyskwalifikuje z małymi wyjątkami. Do reszty to zależy kto co jak duże wielkie itp. wykonuje, bo może całkowicie karta 2GB starczyć i szkoda kasy na GTX970, bo to samo dostanie na karcie kosztującej 2x lub 3x mniej. Owczy pęd to nie jest dobra strategia na pozbywanie się biletów NBP :)

GTX 970 to kastrat GTX 980 o czym świadczą problemy z obsługą więcej niż 3.5GB, chociaż karta ma 4GB, to używalne jest tylko 3.5GB - architektura NVIDA ma takie ograniczenia..., pozostałe 0.5GB to taki szybszy bufor, dlatego zastanowiłbym się raczej nad 980Ti 6GB ew. 980. Nie wiem po co NVIDIA wypuściła GTX970, mogli dać od razu 980. W tym temacie AMD R9 390 8GB zwyczajnie miażdży GTX970 o dwie klasy. Kiedy GTX970 będzie przesuwał dane po szynie PCIx to R9 390 będzie dopiero w niecałej połowie drogi rześki niczym młody Bóg:) - obsługuje całe 8GB w pełnej prędkości. Co do wydajności obliczeniowej to surowe dane wyglądają tak dla fabrycznych ustawień: GTX970 - 3494 gflops single prec., 109 gflops double prec. - 4GB (3.5) 256bit R9 390 - 5120 gflops single prec., 640 gflops double prec. - 8GB 384bit (wydajność na poziomie 980/980Ti w single, w double 3x wyższa) R9 380 - 3476 gflops single prec., 217 gflops double prec. - 4GB 256bit, ale ma mniej taktowaną pamięć i rdzeń od GTX970, za to kosztuje blisko 2x mniej ok. 800 zł :). Faktycznie ile się z tego uzyska zależy od optymalizacji. Optymalizuje się często pod konkretne modele vide Octane. Dodatkowo R9 390 obsługuje async compute, a NVIDIA słabo i programowo. W przypadku wykorzystania viewportu OGL4.5/DX12 i OpenCL 2.0 przewaga AMD będzie odczuwalna. Ja tam problemów nie mam w viewport; Cinema4D, LW, Modo, Blender, z tego co testowałem..., co do 3dsmax i Maya to nie mam pojęcia :), ale skoro ktoś ma problemy to nie stawiałbym na sterowniki AMD tylko raczej twórców tego softu!. Sterowniki NVIDIA też się wywalają i wcale nie mniej od sterowników AMD, więc włożyłbym między bajki ich wyższą stabilność. Odnośnie renderowania na GPU to niestety AMD prawie nie istnieje. Silniki renderujące które liczą się na rynku są optymalizowane najczęściej pod NVIDIA CUDA, a w przypadku AMD potrzeba specjalnych optymalizacji wersji OpenCL, gdzie będą olewać NVIDIA, bo NVIDIA jest w tyle jeżeli chodzi o OpenCL z racji rozwijania swojego frameworku CUDA. AMD wraz z OpenCL 2.0 wprowadza HSA, a to niweluje ograniczenia typowe dla samego GPGPU, co jest poza zasięgiem CUDA..., tylko kiedy jakikolwiek silnik zacznie tego używać, nie mam pojęcia, może Octane 3.x, albo Luxrender, chociaż w Luxrender to AMD daje już ładnie radę. Wystarczy spojrzeć jak późno pojawiło się wsparcie dla AMD w Blender Cycles, gdzie karty ponad dwuletnie AMD które mogły obsłużyć ten silnik renderujący dopiero teraz zaczynają w ograniczonym zakresie coś tam normalnie renderować, a de facto mogą to samo, jeżeli nie więcej przy wykorzystaniu potencjału arch. GCN i OCL2.x, a jeszcze żaden soft tego nie robi. http://blenderartists.org/forum/showthread.php?376184-How-is-it-that-the-R9-390x-beats-GTX-TitanX Mówiąc krótko, chcesz renderować na GPU, na razie nie ma wielkiego wyboru i zostaje tylko NVIDIA, chyba, że to jakiś konkretny przypadek... W przypadku viewportu to nie gra roli, moim zdaniem, przynajmniej ja nie odnotowałem żadnych problemów.