AMD i nowa strategia dla profesjonalnych kart graficznych

[adek]

AMD wdraża nową wizję i strategię dla profesjonalnych kart graficznych. Seria Radeon Pro WX to pierwsze produkty z rodziny Polaris dla stacji roboczych.

 

Pełna treść: AMD i nowa strategia dla profesjonalnych kart graficznych

[Pleszer]

"Pojawienie się wirtualnej rzeczywistości" lol :D

[Mirkowaty]

ale marketingowy bełkot, karta z jednoslotowym chłodzeniem, ma sobie niby poradzić z wymagającym środowiskiem VR albo rendererem GPU :D ? I to jedynie w cenie 1000USD, a ta niezawodność przypuszczalnie obliczona jest na okres gwarancji, karta zagrzeje się w tym czasie na śmierć. Litości czy stacje graficzne to urządzonka do których trudno cokolwiek wcisnąć, żeby tak oszczędzać na chłodzeniu?

[Tomala]

Mirkowaty, widocznie za mało ludzi mieli żeby na to wpaść. Napisz do nich albo zadzwoń może jeszcze zmienią to chłodzenie ;)

[KLICEK]

radeon + grafika przestrzenna :D :D :D

[Kroopson]

grafika hiperprzestrzenna może? :)

[SYmek]

Jedyna strategia, jaką AMD potrzebuje to tych ~80 programistów, którzy nieustannie łatają sterowniki Nvidii, sprawiając że karty częstokroć gorsze wyparły z rynku pro sprzęt AMD.

 

Co mi po krzemie, którego żaden program, może poza Catią, nie potrafi użyć.

[materalia]

Co mi po krzemie, którego żaden program, może poza Catią, nie potrafi użyć.

 

Może tylko uruchamiłeś CATIE, bo jakoś wszystko inne działają, na tyle na ile zostało przewidziane w samym programie. Nie wiem po co ten hejt.

[SYmek]

Może tylko uruchamiłeś CATIE, bo jakoś wszystko inne działają, na tyle na ile zostało przewidziane w samym programie. Nie wiem po co ten hejt.

 

 

To nie hejt, tylko obserwacja, że AMD straciło rynek aplikacji profesjonalnych z powodu słabych sterowników, a nie jakości procesorów.

[Monio]

jakoś wszystko inne działają, na tyle na ile zostało przewidziane w samym programie.

No jasne. Jak twórcy przewidzą wszystkie bugi sterownika od AMD i przepiszą cały soft tak żeby je obchodzić na około to wszystko będzie śmigało elegancko. ;)

 

[Maciek Jutrzenka]

AMD, po prostu hardwerowo imituje szczotkowany metal :D a ty się czepiasz :D

[materalia]

Cycles GPU nie wspiera w pełni OCL, od niedawna działa jakkolwiek na OCL, co jak na soft otwarto źródłowy jest raczej deprymujące, żeby używać własnościowego i zamkniętego API Cuda. Analogicznie to tak jakby widok w tym Blenderze był w DirectX, a potem ktoś przerabiał na OpenGL, narzekał, jakie to OpenGL jest złe, a DirectX cudowne.

[Monio]

Dla twojej informacji- Support OpenCLa w Cyclesie był częściowo pisany i audytowany przez inżynierów z AMD. Działało chwilę, pojawiły się nowe sterowniki i już nie działa. Jeśli inżynierowie z AMD nie są w stanie napisać kodu który funkcjonuje poprawnie na ich kartach to trudno winić developerów softów.

 

Wybór supportu dla biblioteki(CUDA) i hardwareu(NVIDIA) który jest relatywnie stabilny jest tutaj oczywistością.

[Nezumi]

Z AMDkiem jak z Linuksem. W teorii wszystko jest lepsze, smiga i w ogole rewelacja. W praktyce sie trzeba nagimnastykowac a i tak sa problemy i szukanie winnego. Ja tam wole dolozyc troche do NVidii i na tym (och!och! jakie to straszne!) ZAMKNIETYM cuda spokojnie renderowac. Jak AMD wezmie sie w garsc to sie zastanowie - ale to tez powaznie bedzie trzeba rozwazyc zeby nie bylo jak zwykle. Bo juz mieli to OCL we wspolpracy z Blendkiem zrobic, cos zaczeli, rozgrzebali i poszli. Teraz wracaja z nowym super pomyslem - ich rendererem. Wiec jak znam zycie to ten ich w miare dopracuja a Cyclesa oleja.

Przez lata stracilem sentyment do AMD - wieczne zapowiedzi cudow na patyku i pozniej realia majace sie nijak do zapowiedzi.

[materalia]

O ile wiem to inż AMD napisali to zupełnie niedawno i dopiero zaczęło coś cokolwiek działać, przynajmniej u mnie (bo wcześniej ni w cholerę), a developerom Cyclesa nie bardzo chciało się od samego początku. Przykładem lepszego renderera niż cycles jest choćby luxrender czy indigo (ten płatny), jak widać można, można, tylko trzeba umieć, a nie amatorzyć jak blender developerzy na żołdzie NV. Wybór CUDA jest cokolwiek poroniony jak na otwarto żródłowy soft, bo co to za otwartość, kiedy korzysta się z zamkniętych i własnościowych rozwiązań, po prostu śmieszne nabijanie środowiska free w butelke. Moim zdaniem Cycels GPU (to jest słabsze od wersji CPU) powinien być już dawno oddzielony od głównego repozytorium Blendera i dostępny jako plugin, ale to moje zdanie, kogoś kto używa gnu/linuxa/openbsd od 20 lat. Lepiej jakby to Luxrender GPU lub inny OpenCL render zastąpił Cyclesa GPU w Blenderze.

 

Z AMDkiem jak z Linuksem. W teorii wszystko jest lepsze, smiga i w ogole rewelacja. W praktyce sie trzeba nagimnastykowac a i tak sa problemy

 

Bzdura, działa od dawna o wiele lepiej niż zabugowany po sufit Windows, którego nie da się używać na dłuższą metę, bo się sam sypie i uciążliwy z tym swoim instalowaniem, zarządzaniem itp. o świrusach nie wspomnę. Ten system to zawsze była pomyłka.

 

Path tracing od dawna na OCL działa bardzo ładnie, a nawet lepiej niż na CUDA, bo nie jest ograniczony zasobami tylko GPU. Model programowania CUDA jest już dawno przestarzały. Tkwienie przy tym wynika tylko z lenistwa developerów.

Edytowane 12 Sierpień 2016 przez materalia

[SYmek]

Path tracing od dawna na OCL działa bardzo ładnie, a nawet lepiej niż na CUDA, bo nie jest ograniczony zasobami tylko GPU. Model programowania CUDA jest już dawno przestarzały. Tkwienie przy tym wynika tylko z lenistwa developerów.

 

 

To zdanie nie ma niestety uchwytnego sensu. Path tracing działa bardzo ładnie nawet w Pythonie, jak sobie ktoś go napisze, ale w pełni funkcjonalny renderer niestety wciąż łatwiej napisać na CUDA. I zdaje się właśnie dlatego Cycles wybrał CUDA - kilka lat temu ta różnica była znacznie większa. Podobnie zresztą jak Redshift, Vray i inne profesjonalne narzędzia (akcelerowane kodeki, korekcje koloru, zestawy montażowe etc etc). Myślę, że dla nikogo nie było to dobre rozwiązanie, ale ludzie, którym zależało na funkcjonalności i wsparciu technicznym nie mieli wyjścia, szczególnie kilka lat temu. OCL 1.2 może coś zmieni, o ile doczeka się implementacji wszystkich graczy.

 

 

Model programowania CUDA jest przestarzały? Co masz na myśli? Co roku się zmienia do tego stopnia, że właściwie można już dzisiaj pisać w czystym C++. Niestety obecne implementacje OCL (

 

 

 

 

Bzdura, działa od dawna o wiele lepiej niż zabugowany po sufit Windows, którego nie da się używać na dłuższą metę, bo się sam sypie i uciążliwy z tym swoim instalowaniem, zarządzaniem itp. o świrusach nie wspomnę. Ten system to zawsze była pomyłka.

 

Znów jakaś logiczna zagadka. W niektórych zastosowaniach działa, w innych nie działa. Windows, Linux, OSX wszystkie mają mocne i słabe strony, które zależą zwykle do tego, w co włożyli pracę ich główni architekci. W pewnych zastosowaniach Linux nie ma sobie równych, w innych nie nadaje się do użytku. Jak to w życiu.

 

 

ps Nvida otworzyła źródła kompilatora CUDA, więc nie jest to już zamknięty standard (właściwe nie otworzyła, ale dała możliwość rozwijania wsparcia dla własnej platformy sprzętowej).

Edytowane 12 Sierpień 2016 przez SYmek

[Nezumi]

Bzdura, działa od dawna o wiele lepiej niż zabugowany po sufit Windows, którego nie da się używać na dłuższą metę, bo się sam sypie i uciążliwy z tym swoim instalowaniem, zarządzaniem itp. o świrusach nie wspomnę. Ten system to zawsze była pomyłka.

Wiesz, z tym gadaniem jest troche tak jakbys staral sie mnie przekonac ze pada, a ja wygladajac za okno widze ze swieci slonce :D No nie przekonasz mnie ni cholery, ze mi sie system sypie kiedy nic mi sie nie dzieje od lat. Ani tez mnie nie przekonasz ze dziala wszystko swietnie na Linuksie i jest wygodne bo mialem Minta jakis czas i widzialem jak to wyglada w praktyce. Jak Symek powiedzial - zgodze sie ze jest masa zastosowan gdzie Linux bedzie lepszy od windowsa ale nie dotyczy to niestety tego co ja robie.

[Idaho]

Ot takie generalizowanie. O ile dobrze pamiętam to nie mogli skompilować cyclesa dla AMD gdyż był za mało pamięci ("czy cuś") dlatego później podzielili kod - coś tam było (Monio jest bardziej zorientowany :)) - ale fakt też uważam że to bardziej mała moc przerobowa devów od cyclesa niż wina AMD - vide Luxrender, Indigo. Co się tyczy AMD no ja raczej unikam tych kart jak kilka lat temu olali sterowniki do mojego Radeona 8500 pod linuxem - tutaj jednak nic nie pobije nVidie. Zresztą z kim nie gadam czy linux czy windows zawsze jest problem ze wsparciem od strony AMD . Co do tego renderera to skończy się tak jak z Gelato btw pamięta ktoś co to było ? Przypomnę, samodzielny renderer działający tylko na kartach nV wykorzystujący CUDA - za darmo. I co ? I nic, nie przyjął się i tak samo będzie tutaj.

Co do linuxa - od kilkunastu już lat używam i szybkości oraz stabilności to windows jeszcze długo, długo nie będzie miał takiej. Te same programy pod linuxem działają o wiele szybciej niż pod windowsem. Co do systemu to polecam opensuse, centosa, fedorę i ubuntu mają najlepsze wsparcie. O jakości Minta świadczy fakt sprzed 2-3 miesięcy jak obrazy okazały się zainfekowane wirusem i tyle w temacie.

[SYmek]

Co do tego renderera to skończy się tak jak z Gelato btw pamięta ktoś co to było ? Przypomnę, samodzielny renderer działający tylko na kartach nV wykorzystujący CUDA - za darmo. I co ? I nic, nie przyjął się i tak samo będzie tutaj.

 

Gelato nie było na CUDA i nie przyjął(o) się, bo był poronionym pomysłem nastawionym raczej na eksplorację nowych terenów, niż faktyczne korzyści. Gelato tylko shading robiło na karcie, raszta była na CPU, właśnie wchodził ray tracing do użycie powszechnego, więc największy koszt i tak miało wysyłanie promieni. Ani dla zwykłych ludzi, albo dla studiów, naprawdę nie wiadomo dla kogo był ten renderer (może dla Larrego Gritza, który właśnie stracił swoje dziecko (Entropy) o chciał szybko napisać coś nowego za pieniądze korpo)..

 

Co do linuxa - od kilkunastu już lat używam i szybkości oraz stabilności to windows jeszcze długo, długo nie będzie miał takiej. Te same programy pod linuxem działają o wiele szybciej niż pod windowsem.

 

To jest właśnie generalizacja, o której sam pisałeś...

[Monio]

O ile wiem to inż AMD napisali to zupełnie niedawno i dopiero zaczęło coś cokolwiek działać

Już przestało, po nowych sterownikach.

 

a developerom Cyclesa nie bardzo chciało się od samego początku.

Nie masz najmniejszego pojęcia o czym mówisz. Zanim zaczniesz pisać takie bzdury to wejdź na mailing listy i poczytaj ile pracy w to poszło. Cycles od początku był pisany z myślą o supporcie OpenCL, cały problem w tym że sterowniki od AMD nie są zgodne ze specyfikacją. OpenCL to nie jest technologia AMD więc to oni muszą się dostosować a nie oczekiwać że wszyscy w branży nagną się do ich wizji.

 

Ja już tu nie piszę bo trudno dyskutować z niewiedzą. Jak zdejmiesz klapki z oczu i choć trochę zorientujesz się w temacie to możemy gadać.

[materalia]

Cycles od początku był pisany z myślą o supporcie OpenCL, cały problem w tym że sterowniki od AMD nie są zgodne ze specyfikacją.

 

Jak jakiś hejter NV zaczyna od słów, "nie masz pojęcia", to prawdę mówiąc nie widzę sensu dalszej dyskusji :). A NVIDI są zgodne, jak tam cały czas OCL 1.1 i może 90% 1.2, sypie się na prostych procedurach :D, a gdzie 2.x ?. OpenCL od NV jest słabszy od wersji AMD, ale to AMD jest złe :). OpenCL to wszelkie CPU/GPU/AMD/INTEL/NV itd. - razem i osobno cpu/gpu, ale oczywiście wg. Ciebie problem był tylko na AMD, więc wybrano przestarzałe własnościowe CUDA (wymaga specjalnego programowania i działa tylko na jednym urządzeniu, bez sensu), dobre, tłumaczysz rzeczy zupełnie nielogicznie. Dziwne, że inne procedury OCL o wiele bardziej złożone od pathtracingu śmigają no problem od lat, tylko ten Cycles GPU jest problemem, dowód na złe AMD, super NV :). Tak czy owak, Cycles GPU na CUDA powinien być wywalony z Blendera na zewnątrz jako plugin.

 

SYmek:

 

Model programowania CUDA jest przestarzały? Co masz na myśli? Co roku się zmienia do tego stopnia, że właściwie można już dzisiaj pisać w czystym C++.

 

Wspomniałem, czemu przestarzały, bo tu się dąży do unifikacji coś jak C++ Amp, żeby nie pisać osobno kodu na cpu, osobno na gpu, wykonywane może być na wszystkim, zależnie tylko od zasobów. OCL jest o wiele bliższy tej idei i dużo bardziej nadaje się do renderfarm, chociaż nie jest idealny.

 

Nvida otworzyła źródła kompilatora CUDA, więc nie jest to już zamknięty standard (właściwe nie otworzyła, ale dała możliwość rozwijania wsparcia dla własnej platformy sprzętowej).

 

Czytasz czasami co piszesz, najpierw zaczynasz, że otworzyli, a potem "(właściwie nie otworzyła)" :D . CUDA nie jest otwartym standardem i na tym koniec, nie dość, że jest zamknięte to jeszcze wymaga do działania tylko jednego rodzaju sprzętu, co jest samo w sobie zaprzeczeniem idei otwartości.

Edytowane 15 Sierpień 2016 przez materalia

[SYmek]

Ze swojej strony powiem, że według mnie rozmowa nie dotyczyła jakości implementacji OpenCL przez AMD, tylko stanu standardu OpenCL w ogóle, w tym jego wszystkich implementacji - w szczególności kilka lat temu. Moja teza jest taka, że rozwijał się zbyt wolno, żeby dorównać praktycznej (nie papierowej!) funkcjonalności CUDA. Nie muszę tego dowodzić, dowodzi tego rynek, który w większości rozwiązań end-userskich opera się na CUDA. Dlaczego end-userskich? Bo tam nie możesz kontrolować środowiska wykonania. Ma działać i już. OpenCL okazał się pieśnią przyszłości.

 

To nie jest wina AMD czy Kronos. To raczej normalna konsekwencja tego, że OpenCL był tworzony przez znaczenie szersze grono zainteresowanych, z założenia na heterogeniczne środowisko, a to po prostu jest trudniejsze i zajęło znacznie więcej czasu.

 

Jak to ma się do sterowników AMD, czy są lepsze czy gorsze od sterowników innych dostawców sprzętu (w tym Intela), nie wiem, nie interesuje mnie to. Wiem, że CUDA dawała już dawno większe szanse powodzenia projektu, więc ludzie (w pewnych zastosowaniach w każdym razie) zagłosowali nogami. Jak to ma się ma do idea open source, to nie moja sprawa.

 

 

Wspomniałem, czemu przestarzały, bo tu się dąży do unifikacji coś jak C++ Amp, żeby nie pisać osobno kodu na cpu, osobno na gpu, wykonywane może być na wszystkim, zależnie tylko od zasobów. OCL jest o wiele bliższy tej idei i dużo bardziej nadaje się do renderfarm, chociaż nie jest idealny.

 

Bliżej idei. Dobrze powiedziane. Ale bliżej rzeczywistości codziennego programowania była Nvidia. Tak, teoretycznie OpenCL jest lepsze dla renderfarm, w praktyce nadal najlepsze jest x86_64. Kropka. Cuda nie nadaje się na renderfarmy, dlatego mało kto pisze oprogramowanie, które ma z założenia działać na farmie w Cuda. Cuda osiągnęła względny sukces (w porównaniu do OCL), tylko w zastosowaniach end-userskich.

 

Jest ponoć jakiś rynek HPC na Cuda, ale o ile mam wierzyć temu, co słyszałem od ludzi budujących te klastry faktyczna użyteczność klastrów Cuda jest znacznie mniejsza, niż oczekiwana.

 

Czytasz czasami co piszesz, najpierw zaczynasz, że otworzyli, a potem "(właściwie nie otworzyła)" :D . CUDA nie jest otwartym standardem i na tym koniec, nie dość, że jest zamknięte to jeszcze wymaga do działania tylko jednego rodzaju sprzętu, co jest samo w sobie zaprzeczeniem idei otwartości.

 

Jeśli sprzeczność jest jawna, to jest jawna, czyli zamierzona. Przykro mi, że moja subtelna ironia umknęła ostrzu Twej inteligencji. Nie rozmawiajmy o ideach, tylko o faktach, a fakty są takie, że poza wąskim kontekstem HPC, to kompilator decyduje o tym, jakie konkretnie mikro-instrukcje wykona procesor, i to kompilator powinien wspierać architekturę i jej specyfikę. Już dzisiaj można pisać w prostych przypadkach kod C++, który wykona się na x86/Cuda/OpenCl. I to jest przyszłość.

[Creator]

Widzę dyskusja jak Xbox vs PlayStation, czyli racjonalizowanie swoich zakupów ;) Powinien być jeszcze jakiś trzeci producent, który robi dziwne karty i ma resztę w dupie. Myślę, że wiecie jaki odpowiednik konsoli mam tutaj na myśli :D

[keajra]

Myślę, że wiecie jaki odpowiednik konsoli mam tutaj na myśli :D

 

Ja chyba WIIem. Ale moge sie mylic.

[wujek_kane]

Ja chyba WIIem. Ale moge sie mylic.

 

Szkoda, że japko nie produkuje konsol ostatnimi czasy :P

[materalia]

Moja teza jest taka, że rozwijał się zbyt wolno, żeby dorównać praktycznej (nie papierowej!) funkcjonalności CUDA.

 

Teza to jest tylko, a praktyka jest taka, że dzisiaj większość programistów wybiera OpenCL lub inne frameworki korzystające pośrednio z funkcjonalności OpenCL. Nie potrafię wymienić cokolwiek od lat co stawiałoby tylko na CUDA.

 

Nie muszę tego dowodzić, dowodzi tego rynek, który w większości rozwiązań end-userskich opera się na CUDA.

 

Opiera się być może jeszcze w większości na kartach NV, ale niekoniecznie CUDA, tylko raczej już OpenCL.

 

OpenCL okazał się pieśnią przyszłości.

 

Przyszłość właśnie nadeszła, skoro lista programów only CUDA maleje, a OpenCL rośnie, a w nauce CUDA jest zupełnie nieopłacalny z uwagi na brak wsparcia CPU i bardzo niską wydajność kart NVIDIA w double precision już od dłuższego czasu np: RX 480 (1200zl) - Double 323 GFlops (OpenCL 2.2), Geforce 1060 (1400zl) - Double 120 Gflops (staruteńki OpenCL 1.2) . Przepaść!. Karta NV nadaje się tylko do specjalnie zoptymalizowanego kodu CUDA w single precision, na większą wydajność w duble lub half nie ma co liczyć, bo CUDA jest tylko na NV, nawet nie działa na CPU (który ma już zwyczajnie większą wydajność w double i half od kart NVIDIA). W sumie dla kogo NV, dla gracza tak jak AMD, dla użytkownika Octane lub Cycles, ale to tylko z winy developerów, szczególnie w przypadku przereklamowanego Cycles GPU (nie to samo co CPU). Jakiegoś większego specjalnie zastosowania dla CUDA nie widzę obecnie w grafice. Do tego jak sam też potwierdzasz, nie nadaje się CUDA na renderfarmę, a OpenCL daję radę angażując w miarę możliwości wszystkie zasoby obliczeniowe CPU i GPU - wystarczy luxrender, żeby się o tym przekonać.

 

Bliżej idei. Dobrze powiedziane. Ale bliżej rzeczywistości codziennego programowania była Nvidia.

 

Jedynie na początku tej drogi GPGPU. OpenCL trochę czerpał.

[HubertP]

Geforce 1060 (1400zl) - Double 120 Gflops (staruteńki OpenCL 1.2)

 

A jakby było 2.2 to mogło by być ich więcej?

[Nezumi]

dla użytkownika Octane lub Cycles, ale to tylko z winy developerów, szczególnie w przypadku przereklamowanego Cycles GPU (nie to samo co CPU)

 

Pokaz mi te REKLAMY Cycles :D

Prawda wciaz pozostaje taka sama - na NVidii moge i tego i tego uzywac, na AMDku juz nie. AMD zdecydowal sie zaplacic za rok pracy developera zeby dokonczyc tego OpenCLa w Cycles. Zobaczymy co z tego wyniknie.

Praktyka jest taka, ze jesli cos bedzie smigac na tym lepiej niz na CUDA to wybiore karte AMDka (przy okazji sa tansze :D). Ale to MOZE za rok. A na razie to mam gdzies czyja to wina, ze nie dziala bo to nic mi nie zmienia. Bo na razie to AMD przyzwyczail mnie do zapowiadania rewolucji a pozniej niestety jest jak z tym NoMansSky (zarcik taki, spokojnie fanboye :P)

[SYmek]

Teza to jest tylko, a praktyka jest taka, że dzisiaj większość programistów wybiera OpenCL lub inne frameworki korzystające pośrednio z funkcjonalności OpenCL.

 

Jeśli to prawda, byłaby to bardzo dobra wiadomość, ale od niedawna. Faktem jest, że wielu poważnych graczy po prostu czeka na OpenCL, żeby zacząć poważnie rozważać programowanie na GPU.

 

Przyszłość właśnie nadeszła, skoro lista programów only CUDA maleje, a OpenCL rośnie

 

Skąd masz takie dane?

 

Na marginesie warto zauważyć, że odbiory tych technologii mogę się od siebie nieco różnić. Czym innym jest pisanie desktopowej/interaktywnej aplikacji dla jednej branży, a czym innym pisanie kodu, który ma działać na klastrze i mieć szerokie zastosowanie w przemyśle. Gdybym pisał plugin do Maxa, a Cuda dawała mi 40% większą wydajność albo ważną funkcjonalność, nie wahałbym się specjalnie. Ale akceleracja nodów w aplikacji a'la Nuke... wolałbym OpenCL. Albo, mając takie zasoby jak jego producent, po prostu napisałbym własny język, który kompiluje się zarówno na CPU jak i GPU. Wiesz dlaczego Blink nie działa po prostu na OpenCL? Właśnie dlatego, że 5 lat temu, kiedy startowały takie projekty, i kiedy programiści podejmowali decyzje a propos GPGPU, OCL było jeszcze w lesie...

[keajra]

@Nezumi, rozwaliles tym filmikiem...

[ptaszek]

Maxwell v4 za rogiem z GPU http://www.maxwellrender.com/products/maxwell_

 

Chocby nie wiem jak super bylo OpenCL to na celowniku mam Octane (CUDA), Cycles (CUDA), vray RT (CUDA edit: & OpenCL) no i Maxwell v4

CUDA czy OpenCL?

oczywiscie ze CUDA

 

"For now it works only with CUDA and we will keep you updated on any news :)"

[SYmek]

Maxwell v4 za rogiem z GPU http://www.maxwellrender.com/products/maxwell_

 

Chocby nie wiem jak super bylo OpenCL to na celowniku mam Octane (CUDA), Cycles (CUDA), vray RT (CUDA edit: & OpenCL) no i Maxwell v4

CUDA czy OpenCL?

oczywiscie ze CUDA

 

"For now it works only with CUDA and we will keep you updated on any news :)"

 

Arnold GPU również tylko CUDA for now.

 

ps heterogeniczność OpenCL nie ma dla rendererów wielkiego znaczenia, ponieważ przy obecnym stanie technologii kod i tak trzeba optymalizować pod konkretną platformę dla maksimum wydajności. Podstawowa wada Cudy, staje się jej zaletą. Jeden dostawca sprzętu, oprogramowania i sterowników...

Edytowane 16 Sierpień 2016 przez SYmek

[Imperator]

No i Redshift też CUDA :) Fstorm i akceleracja w 3Dcoat też CUDA czyli gołym okiem widać, że rok OpenCL tak jak rok linkusa już 20 raz z rzędu ;)

Edytowane 17 Sierpień 2016 przez Imperator

[SYmek]

No i Redshift też CUDA :) i akceleracja w 3Dcoat też CUDA czyli gołym okiem widać, że rok OpenCL tak jak rok linkusa już 20 raz z rzędu ;)

 

Akurat Linux jest najpopularniejszym systemem operacyjnym na ziemi... od wielu, wielu lat.

 

 

Swoją drogą renderery niekoniecznie muszą być wyznacznikiem uniwersalnej przydatności jakiejś technologii, ale w przypadku desktop / high performance / graphics, Cuda rules.

[materalia]

Chocby nie wiem jak super bylo OpenCL to na celowniku mam Octane (CUDA), Cycles (CUDA), vray RT (CUDA edit: & OpenCL) no i Maxwell v4

CUDA czy OpenCL?

oczywiscie ze CUDA

 

Z tego co wymieniłeś jest tylko Octane i Cycles GPU (Cycles GPU to nie to samo co Cycles - w domyśle CPU, nawet nie można renderować naprzemiennie klatek, bo różnice są widoczne gołym okiem), vray RT to też nie to samo co vray. Maxwell ???, działa tylko cpu. Arnold dla CUDA ???, na razie działa tylko cpu. Nadal są 2 pathtrejsery only cuda warte uwagi, które już wymieniłem, tylko to już trwa od lat, zmian wielkich tam nie ma, bo CUDA nakłada duże ograniczenia, więc nie należy spodziewać się rewolucji. Reszta operacji jednak najczęściej w OpenCL. OpenCL wspiera Intel, AMD i także MS.., a CUDA działa na coraz słabszych karcinach NVIDI, przecież Pascal to jest porażka, też przypominam niektórym hejterom NV, że NVIDIA zapowiadała cuda w Pascalu, a wyszła strasznie droga lipa, także NVIDIA nie lepsza, jak każda normalna firma naciąga na zakup, bo tak działa rynek, ja ich za to nie winię, ale niektórzy wieszają psy na AMD za podobną praktykę, bo rządzą nimi podwójne standardy :)

 

ps. Octane v3 ma być też na OCL.

 

SYmek:

 

heterogeniczność OpenCL nie ma dla rendererów wielkiego znaczenia

 

Ma znaczenie jak renderujesz na renderfarmie. Jeszcze większe będzie miało znaczenie jak w końcu zerwą ze zgodnością OCL 1.2 (bo nie musi ruszyć na NV), całkowicie przejdą na 2.x, gdzie można już implementować bardziej złożone algorytmy korzystając ze wspomagania GPU. Większość obecnych developerów też wybiera naukę jednak OCL jako bardziej przyszłościowe, choćby też z uwagi na dostępność sprzętu OCL, skoro nawet w smarkfonach jest już OCL, w Web itp...

 

Akurat Linux jest najpopularniejszym systemem operacyjnym na ziemi... od wielu, wielu lat.

 

To fakt. Linux rządzi na renderfarmach, a coraz częściej na stacjach roboczych :). Rok Linuksa trwa od dawna. Rok CUDA, może już ostatni, schyłek jak z tym imperium, co to słońce nie zachodziło, a dziś gasną ostatnie promienie ;).

 

PS. po prawdzie, ogólnie moim zdaniem GPGPU jest często przereklamowane.

[SYmek]

Z tego co wymieniłeś jest tylko Octane i Cycles GPU (...)

 

No jednak się mylisz i to w takim miejscu, że gdybyś chciał zrozumieć, dlaczego się mylisz, rozmowa stałaby się bardziej na temat. Nie rozmawiamy o tym, czy OpenCL jest lepszym pomysłem niż CUDA i czy karty Nvidii są przereklamowane i przeszacowane. Rozmawiamy o tym, że skoro:

 

a) Chaos Group wybrał Cudę dla VRayRT

b) Octane też

c) Maxwell też (bo właśnie wydają wersję pod Cuda)

d) Arnold również ma demo na GPU pod Cudą

 

to oznacza, że zastosowaniach związanych z renderowaniem Cuda musi mieć coś, czego nie ma OpenCL. Celowo nie wymieniam Cycles, skupiam się na komercyjnych dostawach, którzy nie mogą sobie pozwolić na marnowanie czasu i to takich z najwyżej półki. OpenCL 2.0 coś zmieni? Może, ale stan na dziś jest taki, jak widać.

 

ps. Octane v3 ma być też na OCL.

 

No to właśnie może znaczyć, że coś się zmienia.

 

heterogeniczność OpenCL nie ma dla rendererów wielkiego znaczenia

Ma znaczenie jak renderujesz na renderfarmie.

.

 

Dopóki nie możesz napisać w pełni działającego algorytmu w jego formie state-of-the-art na dzisiaj, to praktycznie nie ma. OpenCL 2.0? Będzie się dało? Nadal wątpię, żeby TEN sam kod renderera działał równie dobrze pod CPU jak i GPU. Będzie się dało co najwyżej to, co w Cuda, czyli napisać kod po GPU i oddzielny pod CPU. Dlatego twierdzę, że heterogeniczność OpenCL może nie mieć takiego znaczenia dla developerów rendererów. Znaczenie może mieć zgodność z kartami AMD i Intela.

 

To fakt. Linux rządzi na renderfarmach, a coraz częściej na stacjach roboczych :).

 

W Polsce chyba? Na świecie w tej branży jest standardem. Od 10 lat widuję Windowsa, jak muszę coś zmontować (czyli raz na 4 lata). Pisząc najpopularniejszy miałem na myśli wszystkie procesory świata.. nie tylko te od 3D :)

 

PS. po prawdzie, ogólnie moim zdaniem GPGPU jest często przereklamowane.

 

Tu się zgodzę. Gdybym nie musiał, trzymałbym się z dala od całej awanturki. Intel z szerokimi rejestrami (floatx512) i po sprawie :)

Edytowane 17 Sierpień 2016 przez SYmek

[Imperator]

No tak linux jest najpopularniejszy ale jak zawęzimy to do desktopów to ma trochę ponad 2% czyli nie tak dużo, choć przy zastosowaniach profesjonalnych znacznie częściej niż dla zwykłych użytkowników.

 

A co nvidia kontra amd oraz czy cuda są fajne czy umierają to rozchodzi się głównie o to, że teraz jak masz kartę nvidii albo 4 w swoim blaszaku to możesz skorzystać z każdego programu i pluginu cuda czy opencl, coś nie pasuje to sobie przeskoczysz na inny, mając amd już na starcie bardzo zawężasz sobie opcje. A przy pracy zarobkowej to czy zapłacisz 2k czy 3k za kartę nie ma aż takiego znaczenia bo to jest inwestycja która się zwróci, a dopóki amd nie będzie miało większej wydajności i/ lub dużo lepszego stosunku ceny do wydajności i producenci oprogramowania nie dostarczą wersji openCL to nie widzę sensu żeby już się do amd pchać. A skoro arnold i maxwell mają w pierwszej kolejności iść w cuda to chyba jeszcze nie wszyscy wiedzą, że openCL to jedyna słuszna opcja i dopóki to się nie zmieni to nadal amd będzie miało ~20% rynku a nvidia będzie wyciskała każdy grosz od swoich klientów.

[SYmek]

dopóki amd nie będzie miało większej wydajności i/ lub dużo lepszego stosunku ceny do wydajności

Zdaje się, że materalia zwraca słusznie uwagę, że te warunki są spełnione.

 

 

producenci oprogramowania nie dostarczą wersji openCL

 

...a na ten czekamy.

 

nadal amd będzie miało ~20% rynku a nvidia będzie wyciskała każdy grosz od swoich klientów.

 

Pamiętaj, że AMD robi procesory dla XBOXa, Playstation i Maców Pro... rynek 3D to jest jakaś nisza dla nich.

 

Swoją drogą to jednak ciekawe, że w żadnym z tych przypadków sami nie piszę sterowników... :P, czyli jednak jest coś na rzeczy z ich ch*wym softem :)

[HubertP]

Tak sobie czytam wasze posty i nachodzi mnie pewna myśl, że osoby które opisują zalety CUDA w razie, gdyby okazało się, że jest to lipa itp. przesiądą się bez problemu na sprzęt z AMD. Ale za to zwolennicy OCL mogą mieć problemy ideologiczne z porzuceniem sprzętu AMD w przypadku odmiennego scenariusza :)

[Maciek Jutrzenka]

ycles GPU (Cycles GPU to nie to samo co Cycles - w domyśle CPU, nawet nie można renderować naprzemiennie klatek, bo różnice są widoczne gołym okiem

 

co za bzdura.

 

sorry materalia, ale ty tak gadasz od czapy i jesteś tak ogromnym fanboyem że twoich tekstów się nie da czytać.

 

- - - Połączono posty - - -

 

Tak sobie czytam wasze posty i nachodzi mnie pewna myśl, że osoby które opisują zalety CUDA w razie, gdyby okazało się, że jest to lipa itp. przesiądą się bez problemu na sprzęt z AMD. Ale za to zwolennicy OCL mogą mieć problemy ideologiczne z porzuceniem sprzętu AMD w przypadku odmiennego scenariusza :)

 

dokładnie..

[materalia]

a) Chaos Group wybrał Cudę dla VRayRT

b) Octane też

c) Maxwell też (bo właśnie wydają wersję pod Cuda)

d) Arnold również ma demo na GPU pod Cudą

 

VrayRT akurat jest OCL, ale mniejsza z tym, i tak nie używam produkcyjnie żadnego z tych, prędzej wybrałbym Indigo z komercyjnych... Wybór CUDA i optymalizacji na NVIDIA (optymalizują niskopoziomowe, grzebią w asemblerze, często pod konkretny model np: 980Ti w Octane) wynika tylko z większej popularności tych kart wśród grafików kupujących sprzęt, powód jest czysto rynkowy, a nie dlatego, że OpenCL jest złe lub się nie da itp., bo już ze 7 lat temu śmigały takie pathtracery na radkach hd48xx

. OCL 2.x jest obecnie dużo lepsze od CUDA, a że NVIDIA olewa OpenCL to insza inszość, dlatego chcąc mieć odbiorców wśród grafików trzeba kopać się z CUDA, taką politykę ma NVIDIA i dlatego dostała faka od Torvaldsa, a ja bym dołożył im kolejnego faka za drożynę tego ich badziewia pod nazwą Maxwell czy Pascal (Fermi było lepsze), bo karty są wyjątkowo cienkie do GPGPU, tylko nadrabiają lepiej opt. softem komercyjnym przez producentów :)

 

No to właśnie może znaczyć, że coś się zmienia.

 

dla mnie to akurat nic nie znaczy, ale wielu ludzi posługuje się takimi "drogowskazami", mi to akurat wisi czy Octane będzie wspierał OCL czy nie, bo nie używam, ale wątpię żeby implementowali powyżej CUDA, prędzej zrobią jakiś wrapper na OCL i na tym się skończy.

 

Będzie się dało? Nadal wątpię, żeby TEN sam kod renderera działał równie dobrze pod CPU jak i GPU.

 

OpenCL pozwala kompilować kod równie wydajny dla CPU i GPU, przy czym jak ktoś wejdzie w jednym i drugim przypadku w optymalizacje niskopoziomowe uzyska wydajniejszy kod dla CPU i GPU, co w przypadku tak prostych algorytmów jak np: pathtracing przynosi korzyści widoczne, a w przypadku złożonych zabawa jest już niewarta czasu na to poświęconego.

 

Sprawę świetnie rozwiązuje https://github.com/GPUOpen-LibrariesAndSDKs/RadeonRays_SDK , podobnie jak Intel Embree dla CPU, z Embree korzysta Vray, Cinema4d, Luxrender i pewnie inne mi nieznane... W kierunku tych frameworków powinno to iść jak AMD FireRays i Intel Embree, a nie wybór OCL czy CUDA czy x86_64 ;)

 

Intel z szerokimi rejestrami (floatx512) i po sprawie :)

 

To jest ślepa uliczka, bo akurat wektoryzacja kodu pod takie długie rejestry jest kosztowna, sam rdzeń jest większy (da może bez spec. opt. +15% w realnych zadaniach), lepiej i taniej dołożyć kolejny rdzeń ze std. 128bit rejestrami - łatwiejsza wektoryzacja, tym bardziej, że to obliczenia wielowątkowe, więc ładnie się też skaluje, i rdzeń mniejszy, także nie wiem czy to ma sens dawać tak długie rejestry, ale ludzie to kupią, tak jak kupują aparaty z większą liczbą mpiksli z oczkiem jak dziurka wysikana w śniegu :)

 

W Polsce chyba? Na świecie w tej branży jest standardem. Od 10 lat widuję Windowsa

 

Windows nadaje się tylko do zabawy w gierki. 98% gra w gierki to jest na 1 miejscu :)

 

Jutrzenka:

 

co za bzdura.

 

to nie bzdura, to fakt, nie możesz tej samej animki, nie mówiąc o pojedyńczej klatce renderować trochę CPU trochę GPU w Cycles, nie mówiąc o tym, że Cycles GPU nie jest pełnowartościowym Cyclesem, jak włączy się experimental w Blender to coś tam więcej obsługuje, ale stabilność woła o pomstę do nieba, mi na prostych scenach z Volume i SSS resetowało driver grafiki nv...

 

Co nie zmienia mojego zdania, że Cycles GPU na CUDA powinien być osobnym pluginem do Blendera, dla zasady :)

 

HubertP:

 

Tak sobie czytam wasze posty i nachodzi mnie pewna myśl, że osoby które opisują zalety CUDA w razie, gdyby okazało się, że jest to lipa itp. przesiądą się bez problemu na sprzęt z AMD. Ale za to zwolennicy OCL mogą mieć problemy ideologiczne z porzuceniem sprzętu AMD w przypadku odmiennego scenariusza :)

 

To dt. użytkowników NVIDIA, bo są skazani na używanie kart NV w CUDA :). Pewnie zapłacą za niewypały takie jak Pascal nawet 10x więcej niż są warte niż przejdą na OCL i obozu czerwonych. OCL nie ma takiego problemu, bo działa na CPU/GPU/FPGA:) itd., sam używam OCL jeszcze na GPU IntelHD, oprócz GPU AMD, nie wspomnę o CPU.

Edytowane 17 Sierpień 2016 przez materalia

[ptaszek]

Kurde mega bym się cieszył jakby CUDA miała faktyczną konkurencję w GPU. Materalia masz może jakiś link gdzie można zobaczyć jak to pięęęknie śmiga? Bo z tego co na około widzę to po prostu cieżko mi Tobie wierzyć. Czy wszyscy się mylą? Co do Blendera i Cycles to się nie zgadzam. Uważam że jest to bardzo dobry pełnoprawny renderer GPU. Mi tam nic nie brakowało. Przykład? https://www.behance.net/gallery/31900219/Infiniti-Q70-Sedan Jakieś 15 min w Cyclesie gdzieś 3-4k może, na starej grafice GTX 670.

[SYmek]

VrayRT akurat jest OCL, ale mniejsza z tym

Rozumiem, że dodali później, choć sami piszą, że działa wolniej na OCL.

 

że OpenCL jest złe lub się nie da itp., bo już ze 7 lat temu śmigały takie pathtracery na radkach hd48xx

.

 

Wybacz, ale to video nie jest żadnym argumentem. W ogóle, w kilku miejscach (także w innych postach), zdajesz się twierdzić że Path tracing jest prostym algorytmem i że na OpenCL od dawna "śmiga". To jest strasznie naiwne myślenie, a śmiga nic nie znaczy. Jest przepaść między implementacją programu z Twojego video a jakimkolwiek, nawet najprostszym rendererem takim jak Vray RT.

 

Tak, path tracing to koncepcyjnie prosty algorytm, ale profesjonalny renderer to nie algorytm, który, jak wiadomo można zapisać w 100 liniach kodu C, tylko skomplikowana maszyneria, a śledzenie promieni jest tylko niewielką jej częścią.

 

OCL 2.x jest obecnie dużo lepsze od CUDA,

Może tak, może nie. Jakieś konkrety? Dlaczego konkretnie OCL2.0 jest lepsze od Cuda 7.5? Poza tym, że jest otwartym standardem?

 

OpenCL pozwala kompilować kod równie wydajny dla CPU i GPU, przy czym jak ktoś wejdzie w jednym i drugim przypadku w optymalizacje niskopoziomowe uzyska wydajniejszy kod dla CPU i GPU(...).

 

Jeśli ktoś optymalizuje, to oznacza, ze OCL nie potrafi kompilować równie wydajnie na CPU i GPU, co mnie zresztą nie dziwi. Nikt tego nie potrafi. I w tym cały problem. I jeszcze raz, produkcyjna implementacja path tracingu nie jest prostym algorytmem! Setki ludzi i miliony dolarów wydano na jego rozwój. Skąd wziąłeś taką opinię?

 

Sprawę świetnie rozwiązuje https://github.com/GPUOpen-LibrariesAndSDKs/RadeonRays_SDK , podobnie jak Intel Embree dla CPU, z Embree korzysta Vray, Cinema4d, Luxrender i pewnie inne mi nieznane... W kierunku tych frameworków powinno to iść jak AMD FireRays i Intel Embree, a nie wybór OCL czy CUDA czy x86_64 ;)

 

Radeon Rays jest amd'owska wersja OptiX'a, więc nie ma co go porównywać do Cudy.

 

 

To jest ślepa uliczka, bo akurat wektoryzacja kodu pod takie długie rejestry jest kosztowna, sam rdzeń jest większy (da może bez spec. opt. +15% w realnych zadaniach), lepiej i taniej dołożyć kolejny rdzeń ze std. 128bit rejestrami

 

Inżynierowie Intela najwyraźniej uważają inaczej. Głupcy.

 

Windows nadaje się tylko do zabawy w gierki. 98% gra w gierki to jest na 1 miejscu :)

 

Ludzie kupujący komputery w korporacjach uważają inaczej... Także miliony użytkowników tego systemu, którzy nigdy w nic nie grali a nadal go używają do pracy.

 

To dt. użytkowników NVIDIA, bo są skazani na używanie kart NV w CUDA :).

 

Nie są na nic skazani. Mogą używać zarówno Cuda jak i OCL.

Edytowane 17 Sierpień 2016 przez SYmek

[materalia]

Kurde mega bym się cieszył jakby CUDA miała faktyczną konkurencję w GPU

 

Ty to chyba zajmujesz się renderowaniem od wczoraj skoro wymyślasz takie dyrdymały. Na GPU to renderuje się co najmniej od 2009/10, przynajmniej ja pamiętam to jeszcze na stareńkiej AMD Radeon HD48xx, a Ty piszesz dzisiaj, że pojawiła się konkurencja w GPU, żal czytać takie głupoty :D . Lux jest akurat jakościowo powyżej Cyclesa.

 

Tu masz filmik z 2010 roku, wtedy nawet Cycles jeszcze nie był w Blenderze, resztę sobie chyba sam znajdziesz;

 

SYmek:

Rozumiem, że dodali później

 

I co z tego, że dodali później, to znaczy wcześniej nie było możliwe, było, tylko im się nie chciało, nie było opłacalne, zapłacono najpierw za wersje only CUDA na NV itp.itp. VrayRT to akurat nie jest jakaś tam specjalnie mocna sprawa, bo Vray to raczej only cpu.

 

To jest strasznie naiwne myślenie, a śmiga nic nie znaczy. Jest przepaść między implementacją programu z Twojego video a jakimkolwiek, nawet najprostszym rendererem takim jak Vray RT.

 

z 2010 wyżej kolejny filmik, jak najbardziej używalne, a do reszty bez problemu trafisz.

 

produkcyjna implementacja path tracingu nie jest prostym algorytmem!

 

ehe, to jest akurat prosty algorytm (tak samo jak prosty jest raytracing) i średnio zaawansowany programista z mojej uczelni implementuje to w ciągu kilku godzin w języku C, jako ćwiczenie, inną sprawą jest optymalizacja i integracja tegoż z całą strukturą danego softu, żeby obsłużyć jak najlepiej najwięcej ustawień, to zajmuje dopiero ogrom czasu...

 

Radeon Rays jest amd'owska wersja OptiX'a, więc nie ma co go porównywać do Cudy.

 

Akurat to nie jest prawda, tylko widzimisię hejtera NV :).

 

Inżynierowie Intela najwyraźniej uważają inaczej. Głupcy.

 

Jakoś nie dodali AVX512 w Skylake itd., jest tylko eksperymentalnie w Xeon Phi. Poszerzanie rejestrów nie ma sensu, jeżeli np: cykl pobrania i zapisania jest znacznie dłuższy od cyklu wykonania, na to cierpiał już PowerPC G4/5 ze swoim doskonałym Altivec/VMX, tylko w bardzo syntetycznych testach dawał VMX kopa lub operacjach nie wymagających zbyt częstego load/store, więc co by tam dało poszerzenie rejestru, niewiele... a za to znacznie skomplikowało (uczyniło kosztowniejszą) wektoryzację kodu pod to.

 

Ludzie kupujący komputery w korporacjach uważają inaczej

 

Od kiedy to ludzie w korpo podejmują decyzję na czym pracują ?:). Decyzyjni w korpo to najczęściej bardzo wąska klika nie mająca pojęcia o tym i nie bardzo lubiąca zmiany. Windowsa jednak używało się na długo przed Linuxem w korpo biurach, szkołąch itp. DOSa w wielu firmach na np: stanowiskach księgowych używano jeszcze długo po roku 2000 itd., a stanowiskach diagnostycznych na produkcji stoją do dzisiaj, baa, niedawno w Polsce wyłączono jakąś Odrę w jakiejś tam nastawni na kolei :). Największym zarzutem wobec Linuxa była zbyt mała wciąż windowsowatość, choć oferuje znacznie lepsze rozwiązania, tak to niestety działa :).

 

Nie są na nic skazani. Mogą używać zarówno Cuda jak i OCL.

 

Pod jednym wszakże warunkiem, że nie wyskoczy to poza wersje 1.2 :). Co oferują wersje >2.x to można sobie odszukać w necie, bo to wprowadza nową jakość jaką daje HSA, czyli w końcu normalność korzystania z GPU, bo obecnie to jeszcze epoka DOSa, oczywiście epoka DOSa miała też z początku znaczną przewagę nad OSami jak Win, szczególnie w wydajności, ale to minęło i se ne wrati... CUDA też ma być dostępna na AMD, ale pod warunkiem ponownej kompilacji, z powodu braku zgodności binarnej, z tego co tam kiedyś czytałem, tylko nie wiem czy to ma jeszcze sens :)

[HubertP]

Pod jednym wszakże warunkiem, że nie wyskoczy to poza wersje 1.2 :)

 

Eee... to w kartach AMD nie ma wyżej 1.2?

[Nezumi]

Smieszna ta dyskusja :D Nie ulega ZADNEJ watpliwosci ze karty AMD sa w tej chwili slabsze on NV. Nawet dwie spiete RX 480ki nie daja rady jednej gtx1080

http://arstechnica.co.uk/gadgets/2016/07/amd-rx-480-crossfire-vs-nvidia-gtx-1080-ashes/

Mimo, ze przeciez AMD sie oficjalnie chwalil, ze tak wlasnie jest (http://goo.gl/1aijcK). Wiecej - te dwie 480ki sa tylko troche lepsze od jednej 1070ki z NV...

I mozna fanbojowac, snuc teorie spiskowe, tlumaczyc ze to nie wina AMD tylko niekorzystna koniunkcja planet... Tylko, ze to totalnie niczego nie zmienia. AMD ma na dzien dzisiejszy slabsze karty, odpowiednio tansze. Moze cos sie zmieni a moze nie. Oby, bo brak konkurencji dobry nie jest. Tylko niech sie zabiora do roboty bo marketing marketingiem a w testach i tak potem wszystko wychodzi :/

[materalia]

Nezumi:

 

Śmieszne to są Twoje wnioski. Ty masz jakiekolwiek pojęcie, więc pokrótce wyjaśnię.

 

1. Połączenie dwóch kart w grach nie podwaja fpsów, to tylko GPGPU faktycznie podwaja wydajność obliczeń, ale nie DirectX i OGL, więc porównywanie tutaj dwóch kart do jednej jest akurat czystej wody idiotyzmem, powstałym chyba na potrzeby zgnilizny zielonych, którzy są w szoku jakim cienkim i drogim okazał się Pascal w stosunku do zapowiedzi, bo to tylko mały lifting Maxwella, więc łączą sobie dwa AMD (akurat udane i zgodne z tym co AMD zapowiadało, chociaż z obcięciem zasilania chyba przesadzili) do DX żeby poczuć się mniej oszukanymi przez cwaniaków marketingowych z NVIDIA.

 

2. RX 480 kosztujący 1200zł nie jest odpowiednikiem GTX 1080 kosztującego 3200 zł hehe :). Puknij się w głowę.

 

3. RX 480 jest odpowiednikiem GTX 1060. AMD idzie raczej najpierw w dół tj. RX 470 i bardzo dobry RX 460 (cena do wydajności w grach). Polaris nie ma w tej chwili nawet odpowiednika dla GTX1070 i GTX1080. Jeżeli patrzeć nawet na numerologię to 480 jest jak poprzednie R9 380/380X, to jest właśnie ten przedział, więc odpowiednikiem GTX 1080 będzie raczej RX 490 lub RX 490X z 16GB (raczej RX 490X, RX 490 to GTX 1070).

 

AMD jest firmą o wiele bardziej nowatorską od NVIDIA, nie dość, że GCN wiele lat temu już wprowadził GPU na wyższy poziom, podczas gdy NVIDIA nadal tłucze kolejne wersje Fermi, to jeszcze jako jedyni mają karty z HBM (marketing NV też zapowiadał, i co, i nic). To jeszcze do wszystkiego mają dobre ceny. To są fakty :).

[Nezumi]

Smieszne to jest twoje fanbojstwo. To AMD zaczelo ta zabawe z porownywaniem dwoch kart do jednej. Bo nie maja jednej ktora by dala rade :D. Dalem ci linka do fotki z konferencji AMD - wez temu panu napisz zeby sie puknal w glowe :D Albo sam sie puknij - jak wolisz.

A fakty sa takie za AMD jest nowatorski jak cholera tylko zanim wydadza te swoje nowatorskie produkty to bedzie juz nastepna NVidia. Ale mowie po raz N-ty: ja w odroznieniu do ciebie nie jestem fanbojem :P i jak AMD wyda cos godnego uwagi to to kupie. Ja rozumiem, ze jest ci ciezko zrozumiec to z pozycji fanatyka, ale wiesz, sa tacy ktorym zwisa i powiewa to czy ich karta ma zielona czy czerwona naklejke O ILE swietnie dziala i jest przydatna i do zabawy i do pracy. Na razie taki komfort oferuje mi NVidia, chocby nie wiem ile razy sie pukac w glowe nie chce byc inaczej :D

[materalia]

Bredzisz jak typowy śmieszny zielony ujadacz na AMD gdzie tylko pojawi się jakikolwiek news AMD, odmawiając nawet prawa AMD od podkręcania marketingu, podczas gdy NVIDIA ściemnia na maksa..., zupełnie ignorujesz fakt, że jednak AMD wyprzedza już o epokę NVIDIA w konstrukcji GPU > kolejne gen. (już 4) GCN vide Fermi,Kepler,Maxwell,Pascal prawie na jedno kopyto. Jeżeli AMD już coś tam pokazało to tylko to, że gra zoptymalizowana pod Crossfire/SLI (DX12) uzyskuje widoczny wzrost fps, biorąc pod uwagę fakt, że niezoptymalizowane gry nad dwóch kartach często mogą działać nawet wolniej niż na jednej karcie to jest bez wątpienia jakiś krok do przodu :). Wniosków rozumnych nie nauczyłeś się wyciągać, bo masz zielone bryle na ślepiach i wszystko widzisz w kategoriach NVIDIA vs AMD, a AMD tylko próbuje popchnąć temat łączenia kart w DX/OGL do przodu, w odróżeniu od NV, dla nich temat prawie nie istnieje!, potem go odkryją jak AMD już przetrze drogę, tak jak z HBM, choć nie są na to gotowi itp. hehe... Powtórzę raz jeszcze, że RX480 8GB nie jest odpowiednikiem GTX1080 8GB, a fanbojem jesteś NV, choć się tego wypierasz, a ja przynajmniej nie ukrywam swojej sympatii do AMD, bo firma wniosła ogromny wkład do świata PC, w stosunku do swojej wartości rynkowej itp... AMD od dawna wydaje godne uwagi karty bijące na głowę jakością do ceny produkty NVIDIA i nie bawi się w ściemy jak zapowiedzi dt. Pascala co miał być 10x wydajniejszy od Maxwella i w ogóle GCN miało leżeć na łopatkach, a nie są nawet na poziomie gen.1, a jak pisałem, że NVIDIA nie stać na zaprojektowanie czegoś nowego, skoro marketingiem wcisną każdy złom, a CUDA pokaże +10% więcej w czymś tam, fan boje polecą do sklepu żeby dalej przepłacać za to samo hehe:)

 

Na razie taki komfort oferuje mi NVidia, chocby nie wiem ile razy sie pukac w glowe nie chce byc inaczej

 

Mi taki komfort oferuje AMD, jakby się nie pukać, zawsze wychodzi, że jednak wybieram AMD, bo akurat niczego z CUDA nie używam, bo nie ma czego, a przepłacać nie mam zamiaru, skoro za 1200 zł mam kartę z 8GB, a nie za 3000 zł hehe:)

Edytowane 18 Sierpień 2016 przez materalia

[rice]

2x rx480 to jest 300W

1x 1080 to jest 180W

1x 1070 to jest 150W

 

więc ten swój 500$ vs 700$ soluszyn mogą sobie w dupe wsadzić. Fajnie że amd się podnosi po ciągłych porażkach ale narazie polaris w niczym nie zaskoczył. Dogonili karty z przed 2 lat czyli 970, teraz pozostaje czekać na vege.