karta do zabawy z activeshade, VRAY RT

[Gość kokos6]

Witam, co polecacie? do 1000 złotych, cel to ustawianie i podgląd w czasie rzeczywistym, rendering CPU.

[Gość kokos6]

tutaj chłopaki potrząsali temat http://forum.benchmark.pl/topic/42179-karta-graficzna-dla-grafika-rendering-gpu-cuda-do-700zl/

[BLADE]

Przejrzałem temat który podałeś i nie do końca ze wszystkim można się tam zgodzić. Chodzi mi o ilość pamięci na karcie, ktoś napisał że na 1 gb niewiele da się zrobić... wszystko zależy od tego jak się scenę zoptymalizuje i ile będzie się oszczędzać na poligonach i teksturach. Co prawda v-raya nie używam ale sporo renderuje w cycles w blenderze i jak do tej pory pamięci na karcie gtx 570 (1280 mb) mi nie brakło. Co do Twoich dylematów.. to swego czasu się zastanawiałem. Miałem gtx 460 1 gb oc i nie wiedziałem na co się przesiąść. Stwierdziłem że na gtx 560 nie ma sensu. Niewielkie były między nimi różnice np ta sama szyna pamięci itp. Jeśli gdzieś napisałem bzdury to niech mnie spece poprawią :) pozdro.

[Miłosz3ds]

Ja też siedzę na gtx 570, 1280 MB OC. Szczerze mówiąc też żadnych problemów nie miałem, pamięci mi absolutnie nie brakuje. Zwłaszcza jeżeli chcesz używać tylko do podglądu, a render na CPU. W tej sekundzie pracuję nad scenką, podgląd robię właśnie Vray RT. Po mniej więcej 12 sekundach mam już gotowy podgląd sceny, mogę ocenić czy puszczać render (renderowanie 1920x1080 trwa ok. 7 minut) w scenie są trzy światła, 700.000 poly i ok. 7.000 obiektów. Nie ma absolutnie żadnych problemów z wyświetlaniem viewportów ani zamulania ani nic z tych rzeczy. Z czystym sumieniem mogę ją polecić. Tylko cena - z tego co widzę to jest od ok. 1100 zł. Jeżeli możesz - dokładaj. Warto!

 

Pozdrawiam :)

[Gość kokos6]

dziękuję :-)

[Gość kokos6]

http://www.gainward.com/main/vgapro.php?id=469&lang=en nadaje się? :)

[Gość kokos6]

czy mam zwrócić uwagę na jakiś szczegół?

[Miłosz3ds]

A za ile ją możesz dorwać?

[kitamo]

Jak mozesz to wstrzymaj sie jeszcze chwile z zakupem.

Pojawilo sie sporo kart na keplerze, co chwile zapowiadane sa przez roznych producentow wersje GTX670 itp, i moga byc one w Twoim zasiegu. Jesli nawet nie, to po ich masowym pojawieniu sie spadna ceny seri 5xx wiec warto w chwili obecnej poczekac chwile jeszcze.

Kepler jest mniej pradozerny, mniej sie grzeje, i ma grubo ponad 1500 cuda (wersja 680) a do tego 2Gb vram

[Gość kokos6]

dobra :) dziękuję

[Gość kokos6]

A za ile ją możesz dorwać?

cena: 1083,00 zł

[Skoti]

@kokos6: Nadaje się o ile zmieszczą Ci się sceny w pamięci (1.2GB to nie wiele, i wielu osobom na tym forum nawet w 4GB się sceny by nie zmieściły, ale jeśli stosujesz niskie rozdzielczości tekstur i siatki nie masz w gigantycznych ilościach to może wystarczyć).

 

Jak mozesz to wstrzymaj sie jeszcze chwile z zakupem.

Pojawilo sie sporo kart na keplerze, co chwile zapowiadane sa przez roznych producentow wersje GTX670 itp, i moga byc one w Twoim zasiegu. Jesli nawet nie, to po ich masowym pojawieniu sie spadna ceny seri 5xx wiec warto w chwili obecnej poczekac chwile jeszcze.

Kepler jest mniej pradozerny, mniej sie grzeje, i ma grubo ponad 1500 cuda (wersja 680) a do tego 2Gb vram

Bardzo zła rada - Kepler to krok wstecz w GPGPU. Co z tego, że masz ponad 1.5k rdzeni CUDA, skoro są one:

- 2x niżej taktowane,

- jest więcej rdzeni na SIMD

i ostatecznie w renderingu te 1500 rdzeni cuda z GF680 jest wolniejsze niż 512 z GF580. W serii 6xx Nvidii liczy się pobór energii (nic dziwnego, bo kepler to kolejny krok integracji kilku gałęzi - i teraz jeden projekt jest w obliczeniach (Tesla), zadaniach profesjonalnych (Quadro), dla graczy (GeForce) i na rynki mobilne (Tegra od planowanej na styczeń wersji 4, którego GPU ma zastąpić jeden SIMD Keplera)). Lepiej kupić 580, 570, 470 niż Keplera. W przeciwną drogę poszło AMD i zmniejszyło ilość rdzeni na SIMD i wydajność GPGPU w ich najnowszej serii poszła ostro do góry, ale tu odstraszają sterowniki OpenCL, które nie są najwyższej jakości, a wręcz spowalniają powstawanie aplikacji (przykładowo Cycles dla OpenCL ma od dawna możliwości wersji dla CUDA (na kartach Nvidii obie pełne implementacje działają), ale kompilator AMD ma problemy i co aktualizację sterowników AMD do Cycles dostaje nowe możliwości (zostaje odkomentowany kod od dawna już gotowy, tylko sterowniki AMD sobie z nim nie radziły)).

[kitamo]

Mam pytanie - testowales keplera juz czy tylko wnioskujesz po tym co jest dostepne w sieci ?

 

Owszem w przypadku GTX680 wydajnosc nie jest 4 krotnie wieksza jak by mogla to sugerowac ilosc CUDA ale nie jest tak ze jest wolniejsze.

Glownym problemem w przypadku 680 jest brak fixow dla konkretnego oprogramowania. Nie wiem jak wyglada Vray RT ale na bank sytuacja zostanie poprawiona a wydajnosc bedzie i tak na poziomie 580.

 

Z reszta jak wyjdzie wiecej keplerow to w segmencie mainstream spadna ceny GTX570/580.

 

Ja bym nie podchodzi sceptycznie do keplera

Edytowane 12 Maj 2012 przez kitamo

[Skoti]

Mam pytanie - testowales keplera juz czy tylko wnioskujesz po tym co jest dostepne w sieci ?

 

Owszem w przypadku GTX680 wydajnosc nie jest 4 krotnie wieksza jak by mogla to sugerowac ilosc CUDA ale nie jest tak ze jest wolniejsze.

Glownym problemem w przypadku 680 jest brak fixow dla konkretnego oprogramowania. Nie wiem jak wyglada Vray RT ale na bank sytuacja zostanie poprawiona a wydajnosc bedzie i tak na poziomie 580.

 

Z reszta jak wyjdzie wiecej keplerow to w segmencie mainstream spadna ceny GTX570/580.

 

Ja bym nie podchodzi sceptycznie do keplera

Nie muszę testować, żeby wiedzieć jak będzie się zachowywać karta w danych zadaniach, bo do tego wystarczą dokumenty dotyczące architektury kart i żadne fixy oprogramowania tu nie pomogą, bo to problem sprzętowy i gorszej dla GPGPU architektury sprzętu (lepszej do gier, ale nie do obliczeń).

 

Ilość rdzeni CUDA to jest bardzo mała składowa wydajności całego układu. Swoją drogą zastanawia mnie skąd to 4x skoro jest 3x więcej rdzeni CUDA i do tego z niższą częstotliwością. 680 jest w najbardziej optymalnym przypadku 2x wydajniejsze od 580 (3.1 TFLOPS vs 1.6 TFLOPS), jednak tak to nie działa (no poza prostymi rzeczami jak generowanie hashy czy innych liniowych zadań, ale nie w fizyce czy rendererach) i znacznie ważniejsze od ilości rdzeni jest to jak są one ułożone i zarządzane i tu zaczynają się niekorzystne dla Keplera dane, które nie są tak marketingowo sprzedawane jak ilość rdzeni. Przykładowo strumieniowe multiprocesory (w których mieszczą się rdzenie CUDA) to 8 takich procków jest w 680... podczas gdy w 580 było ich 16, w Fermi te multiprocesory wykonywały zadania na 32 prockach w niezależnych grupach po 16 procków (jest to arch SIMT więc wydajność w pesymistycznym wypadku jest 1/16 wydajności gdy dane pozwalają tylko jednemu prockowi działać), w Keplerze multiprocesory działają na 192 prockach w grupach po 48 procków (przyjmijmy tak dla uproszczenia obliczeń bo tu podobnie jest do fermi z serii 460/560 i niżej czyli jeden wrap scheduler robi po 16, a drugi po 32, tylko w keplerze masz 32 i 64 czyli w najgorszym wypadku osiąga 1/48 wydajności). Rendering jest niestety bliski pesymistycznych danych dla SIMT i 680 ze względu na swoją architekturę w obliczeniach tego typu powinien być gorszy niż 580.

 

Jeśli jednak nie uważasz, że architektura jest ważna, a liczy się liczba rdzeni to dlaczego nie poradziłeś kupić Radeon 5870? Ma więcej rdzeni niż 680 (1600 rdzeni), Teoretyczną wydajność ma trochę niższą ze względu na częstotliwości, ale i tak wyższą niż GTX670 (2.72 TFLOPS vs 2.46 TFLOPS) i jest dużo tańszy. A kogo tam obchodzi, że ma upakowane w SIMD 80 procków i wydajność w pesymistycznym wypadku spada 80cio krotnie i w renderingu średnia klasa Fermi bije je na głowe. OFC jakbyś polecił 7970 to nie miałbym się do czego przyczepić bo tu AMD zrobiło przeciwny krok i SIMD ma po 16 rdzeni czyli tak jak w Fermi (przez co ta seria dostała kopa w obliczeniach), a rdzeni masz 2048 przy teoretycznej mocy 3.8 TFLOPS - tu jednak problemem dalej są sterowniki.

 

Kepler do gier się nadaje wyśmienicie, do mobilków będzie świetny, dla grafików czy do obliczeń to już nie najlepsza architektura (z tego powodu też nie widzisz opartych na Keplerze Tesla czy Quadro, bo to krok wstecz tu - nowe karty tu zobaczysz pod koniec roku jak wyjdzie pełny Kepler (780) i wydajność będzie trochę lepsza bo w pesymistycznym wypadku będzie to 1/32, ale za to podstawowa wydajność będzie już znacznie wyższa niż 580 i będzie już w obliczeniach od 580 w praktyce wydajniejsze (dopiero te karty oparte na pełnym keplerze GK100, a nie na GK104 jak 680 czy 670)).

Edytowane 12 Maj 2012 przez Skoti

[jacenty]

Skoki sorry ale gadasz jak pseudo experci z forum chip czy pclabu i takich tam ,ktorzy bezmyslnie plota farmazony ,sa teoretykami i nie maja bladego pojecia o praktyce.

Nie rozumiem jak karta szybsza w grach ma byc wolniejsza w np programach. Przeciez ten sam sposob wyswietlania grafiki .

Nie wiem kup taka karte lub pozycz, przetestuj ja i dopiero sie wypowiadaj .

[Skoti]

Skoki sorry ale gadasz jak pseudo experci z forum chip czy pclabu i takich tam ,ktorzy bezmyslnie plota farmazony ,sa teoretykami i nie maja bladego pojecia o praktyce.

Nie przekręcaj nicku ;p. Teoria i praktyka to jedno i to samo, co najwyżej ktoś w teoretycznych obliczeniach może nie brać wszystkich danych (i mówić, że jest 2x wydajniejsze 680 ze względu na teoretyczną maksymalną wydajność osiąganą przez kartę).

Ja GPU i ich dobre i złe strony znam dosyć dobrze programując je od kilkunastu lat (więc zarówno od strony teoretycznej i praktycznej).

 

Nie rozumiem jak karta szybsza w grach ma byc wolniejsza w np programach. Przeciez ten sam sposob wyswietlania grafiki .

Tu się mylisz bardzo - to zupełnie inny sposób wyświetlania grafiki! W grach stosuje się rasteryzacje co bardzo pasuje arch SIMD, bo jest to zazwyczaj prosty liniowy kod przekształcający wierzchołki do przestrzeni ekranu (punkty mnożone po kolei przez macierze kości, macierz obiektu, macierz widoku i macierz projekcji), co jest wykonywane z maksymalną możliwą wydajnością karty (ewentualnie jest mały spadek mocy w wypadku jak programista gdzieś da jakąś instrukcję warunkową co jest bardzo rzadkie i dziwne ;p), później karta rasteryzuje to co wyszło z shadera wierzchołków i leci shader fragmentów - też zazwyczaj prosty liniowy kod bez instrukcji warunkowych, pętli etc (jeśli jest tu coś do sterowania to odbyło się zapewne na etapie kompilowania shadera przez dyrektywy preprocesora) dla każdego pixela - karty graficzne są idealnie skrojone pod rasteryzacje i nawet największe upakowanie SIMD nie jest dla nich przeszkodą, ale rasteryzacja ma wady, jak problematyczne i ciężkie obliczeniowo cienie, odbicia, kaustyki... i w zastosowaniu graficznym praktycznie odpada.

Renderery GPGPU działają na zupełnie innej zasadzie, a dokładniej na podstawie raytracingu (jeszcze dokładniej na pochodnych pathtracingu, bipathtracingu z losowaniem próbek monte carlo, MLT czy jeszcze inne algorytmy). Tu nie można tak prosto i liniowo liczyć tu rzuca się promień i trzeba sprawdzać CZY przecina coś w drzewie obiektów (przykładowo QBVH), JEŚLI tak to sprawdza czy przecina się z daną siatką, JEŚLI tak to liczy materiał i JEŚLI odbija to odbić promień i śledzić dalej, JEŚLI załamuje to załamaś i śledzić dalej...

To tylko mały wycinek z tego co musi sprawdzić i wszystko jest zależne od danych. Procesory w kartach grafiki mają arch SIMT czyli cała grupa procesorów dostaje JEDNĄ instrukcję na wiele wątków. Jeśli przynajmniej jeden procesor w grupie ma jakąś instrukcje do wykonania to reszta w tym czasie nic nie robi tylko czeka. Przykładowo mamy kod

if( object.material.reflection ){
  //20 instrukcji
}
else if( object.material.refraction ){
  //30 instrukcji
}

i karta dostaje dane takie, że w grupie wątków (promieni) jeden trafił na obiekt odbijający, jeden na obiekt załamujący, a reszta w materiały bez odbić i załamań lub nie trafiło w żaden obiekt to karta to wykona tak:

wszystkie procesory dostają 20 instrukcji dla obiektu odbijającego światło i je wykonują (tylko jeden zapisuje swoją pracę), później wszystkie dostają 30 instrukcji dla obiektu załamującego światło i czas wykonania pracy takiej grupy wątków to czas wykonania 50 instrukcji i zajęty w tym czasie czas grupy (16 w Fermi, 32 lub 64 (zależy gdzie trafi - średnio 48) w Kepler) podczas gdy przykładowo 62 procki się cały ten czas marnowały, jeden zrobił 20 instrukcji, drugi 30. Im większe są grupy SIMT tym więcej procesorów musi czekać, na inne zamiast pracować. Dla wydajności w rendererach GPGPU ważne jest jak najwięcej SIMT, jak najmniej procków w tych SIMT, podczas gdy w rasteryzacji dla gier jest wręcz przeciwnie, bo tu praktycznie nie stosuje się dynamicznej kontroli przepływu w kodzie i jest to praktycznie liniowy kod, który nie zablokuje żadnego procesora, bo wszystkie mają dokładnie to samo do policzenia, niezależnie od danych wejściowych i tu marnowanie tranzystorów i miejsca na więcej SIMT jest głupotą, podczas gdy najważniejsza jest ilość procesorów ;p.

 

Podsumowując bardzo się mylisz mówiąc "Przeciez ten sam sposob wyswietlania grafiki", bo te sposoby nawet ze sobą nie mają nic wspólnego.

[jacenty]

Sorry ale nie chce mi tego czytac co napisales .W tym tygodniu zamawiam keplera najdalej w przyszlym. Sporo sie naszukalem testow Open GL i nvidia jest lepsza od ati. .Open cl to ponoc syf wiec zostaje Cuda i NV. Wogule render na kartach graficznych jest mocno w powijakach nadal.Wiec jesli sie duzo renderuje to i tak nie ucieknie sie od malej rener farmy . A kepler wydaje mi sie teraz najlepszym rozwiazaniem .

[Skoti]

Sorry ale nie chce mi tego czytac co napisales .W tym tygodniu zamawiam keplera najdalej w przyszlym. Sporo sie naszukalem testow Open GL i nvidia jest lepsza od ati. .Open cl to ponoc syf wiec zostaje Cuda i NV. Wogule render na kartach graficznych jest mocno w powijakach nadal.Wiec jesli sie duzo renderuje to i tak nie ucieknie sie od malej rener farmy . A kepler wydaje mi sie teraz najlepszym rozwiazaniem .

Tak - Nvidia jest lepsza zarówno w OpenGL jak i OpenCL (nowa seria AMD ma kuszącą arch, ale sterowniki ssą i poza DirectX w grach ciężko myśleć o tych kartach poważnie) i mają znacznie bardziej dopracowane sterowniki (ogólnie bardziej dbają o standardy Khronos Group, któremu przewodniczą i zarówno grupom rozwojowym OpenCL i OpenGL przewodniczy wiceprezes Nvidii, a Nvidia daje sterowniki w dniu wydania nowego standardu). OpenCL to nie syf tylko bardzo dobre API, problem w sterownikach AMD, które wywalają się przy bardziej skomplikowanym kodzie (nie potrafią go skompilować nawet jeśli jest 100% zgodny z OpenCL) - co nie oznacza, że OpenCL jest zły, bo kompilator Intela czy Nvidii nie ma takich problemów. Jednak jeśli chce się renderować na GPU (a ten wątek sugeruje, że tak jest) to lepiej wybrać kartę 580, która jest tańsza, niewiele mniej wydajna w viewporcie, a wydajniejsza w renderingu na GPGPU. Kepler będzie lepszy od 580, ale ten pełny (GK100 to pełny Kepler (ma wyjść w tym roku jeszcze), GK104 w 680 to odpowiednik GF104 stosowanego w 460/560, a nie GF100 z 480/580).

[kitamo]

Jeśli jednak nie uważasz, że architektura jest ważna, a liczy się liczba rdzeni to dlaczego nie poradziłeś kupić Radeon 5870? Ma więcej rdzeni niż 680 (1600 rdzeni), Teoretyczną wydajność ma trochę niższą ze względu na częstotliwości, ale i tak wyższą niż GTX670 (2.72 TFLOPS vs 2.46 TFLOPS) i jest dużo tańszy. A kogo tam obchodzi, że ma upakowane w SIMD 80 procków i wydajność w pesymistycznym wypadku spada 80cio krotnie i w renderingu średnia klasa Fermi bije je na głowe. OFC jakbyś polecił 7970 to nie miałbym się do czego przyczepić bo tu AMD zrobiło przeciwny krok i SIMD ma po 16 rdzeni czyli tak jak w Fermi (przez co ta seria dostała kopa w obliczeniach), a rdzeni masz 2048 przy teoretycznej mocy 3.8 TFLOPS - tu jednak problemem dalej są sterowniki.

zastanawia msie czy w ogole czytasz co napisalem czy tylko quatujesz sobie bez zastanowienia.

Nigdzie tez nie napisalem ze GTX680 jest 4x szybszy od czegokolwiek - wrecz przeciwnie, napisalem ze nie jest.

 

Co do radeona to chyba logiczne - nie jest wspierany przez vraya, wiec jaki jest sens go polecac ? poza tym zaznaczylem ze radeony znacznie lepiej radza sobie z gpug ale nie sa wspierane. Niedoczytales chyba tego.

 

Doskonale zdaje sobie sprawe ze gpug gtx680 nie jest jego najmocniejsza strona, ale nie jest tak ze jest ona nagle slabsza od GTX560 itp. Nvidia postawila w tej materii na swoje quadro i tesle wiec nie ma sie co dziwic..

Pytanie tylko czy do samej zabawy w vray rt oplaca sie inwestowac w starsza technologie ktora bedzie w cenie gtx680 ?

Jest wiele plusow keplera. Teraz pojawia sie modele gtx670 z wieksza pamiecia i do tego w dobrej cenie, gtx680 z 4gb juz sa wiec na co tu narzekac ? Teoretyzujesz i teoretyzujesz, wiec wynika z tego ze radeony 79xx beda najlepszym rozwiazaniem , wiec czemu ich nie polecasz ? w obecnym vray rt wieksze znaczenie bedzie miala pamiec bo nawet 5k strumieni cuda nie zdziała cudów.

W vray jestesmy skazani na nvidie, i ogolnie na cude. Trzeba sie z tym pogodzic.

 

Z reszta autor watku wyraznie napisal ze renderowal bedzie na CPU a tyko podglad na vray rt gdzie roznic w wydajnosci nie bedzie a wiecej da tu sama pamiec niz wydajnosc cuda.

Przetestuj najpierw keplera w vray rt.

 

http://pclab.pl/art49195-12.html

 

Bo jak widac w gpug roznie wypada, raz lepiej raz gorzej.

 

http://pclab.pl/zdjecia/artykuly/majkel/GTX680/gpgpu/dcocl.png

Jesli juz mowa o samym opencl i DC to to wyglada ciekawie

Edytowane 13 Maj 2012 przez kitamo

[Skoti]

zastanawia msie czy w ogole czytasz co napisalem czy tylko quatujesz sobie bez zastanowienia.

Nigdzie tez nie napisalem ze GTX680 jest 4x szybszy od czegokolwiek - wrecz przeciwnie, napisalem ze nie jest.

Piszesz, że ilość rdzeni sugeruje 4x większą wydajność, więc pytam się po prostu skąd to wiozłeś

 

Co do radeona to chyba logiczne - nie jest wspierany przez vraya, wiec jaki jest sens go polecac ? poza tym zaznaczylem ze radeony znacznie lepiej radza sobie z gpug ale nie sa wspierane. Niedoczytales chyba tego.

Akurat Vray RT działa na radeonach co zresztą sugerują sami twórcy pisząc, że powinien działać na kartach AMD, ale nie jest to dobrze przetestowane i że aktualnie implementacje w sterownikach są na tyle dojrzałe, aby używać ich z pewnością jest w sterownikach Nvidii. Dlatego też nie radzę kupować radeonów, bo mimo dobrego sprzętu sterowniki ssą i do czasu ich poprawienia (zarówno OpenCL i OpenGL) nie są realną opcją.

 

Doskonale zdaje sobie sprawe ze gpug gtx680 nie jest jego najmocniejsza strona, ale nie jest tak ze jest ona nagle slabsza od GTX560 itp. Nvidia postawila w tej materii na swoje quadro i tesle wiec nie ma sie co dziwic..

Pytanie tylko czy do samej zabawy w vray rt oplaca sie inwestowac w starsza technologie ktora bedzie w cenie gtx680 ?

Nvidia w tej materii postawił na gry, a nie na quadro i teslę z Fermi. Słabsza od GTX560 nie jest - jest słabsza od tańszych pełnych Fermi czyli 580.

 

Jest wiele plusow keplera. Teraz pojawia sie modele gtx670 z wieksza pamiecia i do tego w dobrej cenie, gtx680 z 4gb juz sa wiec na co tu narzekac ?

Możesz napisać plusy? OFC tu nie ma co narzekać, tylko rozważyć opcje:

680 2GB (2k zł), 680 4GB (2.4k zł) 580 3GB (1.5k zł) - z tego wszystkiego najtańszy jest jednocześnie w renderingu najszybszy.

670 2GB (1.7k zł) 570 2.5GB (1.3k zł) i ten tańszy znowu jest lepszy.

 

 

Teoretyzujesz i teoretyzujesz, wiec wynika z tego ze radeony 79xx beda najlepszym rozwiazaniem , wiec czemu ich nie polecasz ? w obecnym vray rt wieksze znaczenie bedzie miala pamiec bo nawet 5k strumieni cuda nie zdziała cudów.

W vray jestesmy skazani na nvidie, i ogolnie na cude. Trzeba sie z tym pogodzic.

Jeśli uważasz, że większe znaczenie ma pamięć to dlaczego nie polecasz 7970? Są karty z 6GB pamięci, pamięci mają szerszą szynę i znacznie większą przepustowość (masz więcej i to szybszej pamięci).

A dlaczego ja ich nie polecam? Bo sterowniki ssą i co z tego że jest sprzęt świetny jak sterowniki psują wszystko.

 

 

http://pclab.pl/art49195-12.html

 

Bo jak widac w gpug roznie wypada, raz lepiej raz gorzej.

 

http://pclab.pl/zdjecia/artykuly/majkel/GTX680/gpgpu/dcocl.png

Jesli juz mowa o samym opencl i DC to to wyglada ciekawie

Widać w GPGPU różnie wypada, bo są różne algorytmy i zadania - tworzenie hashy czy szybkiej transformacji Fouriera (test który pokazałeś, że wygląda ciekawie czyli DirectCompute & OpenCL Benchmark który robi FFT) jest tak szybkie jak maksymalna wydajność sprzętu (prosty liniowy kod jak w shaderach gier) i w takich testach 680 będzie szybszy, jednak tu nie jest wątek na forum kryptograficznym, żeby robić hashe sha/md5 na czas do łamania haseł czy też nikogo nie interesuje FFT, a raytracing, który jest dla kart graficznych dużo bardziej kłopotliwy (mniej więcej tak kłopotliwy jak silniki fizyki na GPU).

[kitamo]

Przeciez wlasnie wyzej napisalem ze GTX680 nie jest 4x razy szybszy, a nie odwrotnie. I nic takieg onie sugeruje wiec dziwnie interpretujesz moje slowa.

 

I wlasnie dlatego nie polecam radeona bo nie ma wsparcia mimo ze teoretycznie bylby wydajniejszy. Kolejna sprawa to to ze CUDa lepiej sa wykorzstane obecnie pod wzgledem opgrogramowania niz ATI.

Mialem sporo problemow z ATI w samym 3d studio, nie mowiac juz o tym ze vray w ogole sie nie uruchomil (wywalal sie odrazu na starcie).

 

Nie wiemy jeszcze obaj jak wypadnie ray rt na gtx680 wiec nie ma co gdybac i nie ma co narzekac ze wydajnosc bedzie nizsza niz na gtx580 bo moze sie okazac ze bedzie podobna a profitow jest wiecej - nowa architektura, mniej sie grzeje, wieksza energooszczednosc no i nie tylko do vray rt autorkupuje grafe zapewne.

I do tego jak zauwazysz zalecam poczekac bo spadna ceny gtx580 na bank wraz z popularyzacja GTX670 a bedzie ich zalew za chwile na rynku. Wszystk oto napisalem wyraznie w pierwszym poscie.

 

(mniej więcej tak kłopotliwy jak silniki fizyki na GPU).

hmm physx to silnik fizyki i gtx580 wypada blado przy gtx680.

Wszystko zalezy od tego co niesie za soba oprogramowanie i jak korzysta z samego GPU.

[Skoti]

Przeciez wlasnie wyzej napisalem ze GTX680 nie jest 4x razy szybszy, a nie odwrotnie.

Wiem tylko pytam skąd Ci się wzięło to 4x, bo na pewno nie z ilości rdzeni (3x), a z uwzględnieniem częstotliwości to nawet nie 2x.

 

Kolejna sprawa to to ze CUDa lepiej sa wykorzstane obecnie pod wzgledem opgrogramowania niz ATI.

Rdzenie mają taką samą wydajność jak rdzenie stream AMD czyli 2 operacje na cykl zegara (mnożenie i dodawanie na raz) - lepsze wykorzystanie tych rdzeni za to było zasługą dużej ilości małych SIMT (w poprzednich seriach Nvidia miała SIMT wielkości 16, a AMD 80 i 64). Większa ilość SIMT zwiększa znacznie ilość tranzystorów i pobór energii, m.in. dla tego teraz karty AMD pobierają więcej energii niż poprzednie serie (pamiętając, że jest różnica w procesie technologicznym), a karty Nvidii mniej.

 

 

Nie wiemy jeszcze obaj jak wypadnie ray rt na gtx680 wiec nie ma co gdybac i nie ma co narzekac ze wydajnosc bedzie nizsza niz na gtx580 bo moze sie okazac ze bedzie podobna a profitow jest wiecej - nowa architektura, mniej sie grzeje, wieksza energooszczednosc no i nie tylko do vray rt autorkupuje grafe zapewne.

Nie wiem jak ty ale ja wiem jak wypadnie w VRay RT (to tak jakbyś mówił, że nie wiesz czym dojedziesz szybciej rowerem czy samochodem 100km znając same ich teoretyczne możliwości (i pokazywanie testów które nie mają nic do rzeczy jak test gdzie jest w mieście w korku nic nie zmieniają, jeśli interesuje nas konkretny typ zadania)).

Profity ładnie pomnożyłeś, ale wszystko to wynik jednego: jest nowa architektura (zmniejszająca stosunek SIMT do ilości rdzeni) dzięki czemu zmniejsza się ilość tranzystorów zajmujących się zarządzaniem rdzeniami i wątkami (czyli nie bezpośrednio wpływające na teoretyczną wydajność, ale mające kluczową rolę w realnych wynikach) - nowa architektura to zarówno profit (zmniejszenie poboru energii) jak i zmniejszenie wydajności w GPGPU.

 

hmm physx to silnik fizyki i gtx580 wypada blado przy gtx680.

Jeśli patrzysz na symulacje softbody czy fluidów to jak najbardziej masz rację bo to są algorytmy dla SIMT bardzo przyjazne. Ja mówiłem jednak o fizyce brył sztywnych (rigid body), które z architekturą SIMT się nie lubi (nie bez powodu softbody i fluidy przez lata w PhysX były na GPU, podczas gdy rigid body robione były na CPU, bo było to szybsze niż na GPU - dopiero niedawno (jeśli dobrze pamiętam ~rok temu PhysX doczekał się implementacji na GPU gdzie 580 już radził sobie kilkukrotnie lepiej niż CPU)).

 

Wszystko zalezy od tego co niesie za soba oprogramowanie i jak korzysta z samego GPU.

Wszystko zależy od oprogramowania - a dokładniej to od algorytmów. Jednak renderery GPGPU to nie rasteryzatory tylko raytracery i tu nie ma opcji - z 680 nie będą się tak lubić jak z 580 - takie to oprogramowanie i w taki, a nie inny sposób musi korzystać z GPU.

[kitamo]

Wiem tylko pytam skąd Ci się wzięło to 4x, bo na pewno nie z ilości rdzeni (3x), a z uwzględnieniem częstotliwości to nawet nie 2x.

matko świeta - jakie 4x bo nie rozumiem Cie. nadal nie wiem co sugerujesz.

 

 

Ja nie lubie wrozenia z fusow, sam vray rt jest na tyle niedoskonaly ze dalej nie wiemy jak bedzie sie zachowywal na gtx680 i czy w ogole bedzie jakakolwiek roznica w stosunku do poprzednikow. Nowy toolkit do cuda tez moze przyniesc zmiany, bo samo korzystanie z cuda czy opencl to wciaz sa powijaki.

Nie ma co teoretyzowac nad wydajnoscia tego rozwiazania bo za chwile wyjdzie ze roznica jest +-5% .

 

Sprawdzalem jak wyglada działanie w iray i roznicy nie widze - zarowno 570 jak i 680 dzialaja tak samo, przynajmniej roznic w samej grafice zbyt nie widze.

[Skoti]

matko świeta - jakie 4x bo nie rozumiem Cie. nadal nie wiem co sugerujesz.

Nie rozumiem czego nie rozumiesz... napisałeś:

Owszem w przypadku GTX680 wydajnosc nie jest 4 krotnie wieksza jak by mogla to sugerowac ilosc CUDA ale nie jest tak ze jest wolniejsze.

I pytam się skąd masz liczbę 4x (poza tym, że wiem, że z sufitu).

 

 

Ja nie lubie wrozenia z fusow, sam vray rt jest na tyle niedoskonaly ze dalej nie wiemy jak bedzie sie zachowywal na gtx680 i czy w ogole bedzie jakakolwiek roznica w stosunku do poprzednikow. Nowy toolkit do cuda tez moze przyniesc zmiany, bo samo korzystanie z cuda czy opencl to wciaz sa powijaki.

Nie ma co teoretyzowac nad wydajnoscia tego rozwiazania bo za chwile wyjdzie ze roznica jest +-5% .

Wróżenie z fusów to można uprawiać kiedy nie ma danych, a wszystkie dane mamy (trzeba tylko je rozumieć i poznać architekturę i aplikacje od środka). Nowy toolkit tu zupełnie nic nie zmieni (pomijając to, że poprawki w nim poprawią działanie w równym stopniu fermi co kepler (oraz to, że nowy toolkit już jakiś czas jest) to wydajność nie ulegnie znacznej zmianie - architektura pozostanie ta sama... nowy toolkit to mniej więcej w porównaniu do samochodu i roweru to wymiana obu kierowców na szybszych).

 

Sprawdzalem jak wyglada działanie w iray i roznicy nie widze - zarowno 570 jak i 680 dzialaja tak samo, przynajmniej roznic w samej grafice zbyt nie widze.

Różnicy wydajności też nie widzisz mimo 2x wyższej ceny, a względem 580 zobaczysz nawet spadek wydajności... za który musisz sporo dopłacić.

680 jest fajną kartą, ale do gier - tu jest wątek o GPGPU, a tu nie jest najlepszą kartą od Nvidii i 580 będzie wydajniejsze w tym zastosowaniu (przy znacznie niższej cenie), więc głupotą do takiego zastosowania polecać karty które w GPGPU są słabe, ale za to w innych zastosowaniach są dobre. Jeśli ktoś chce wydać więcej kasy to i tak lepiej polecić 590 (tylko trzeba pamiętać, że ilość pamięci podawanej trzeba podzielić przez 2x i program musi obsługiwać multiGPU) i ta karta rozłoży wszystkie inne na łopatki.

[kitamo]

4x to tylko takie przyrownanie a nie obliczenia zadne, bo np gtx460 ma 4x mniej cuda.

 

Ty masz dane a ja wlasnie jade na gtx680 i ogladam vray rt. Nie wiedziec czem uale zadnej roznicy nie widze pomiedzy gtx680 a gtx570, jesli jest to mega subiektywna. nie ma zadnego benchmark uw vrayu bym mogl to sprawdzic bo dane ktore pojawiaja sie skacza na obu kartach.

Zaraz sprobuje sprawdzic jeszcze obciazenie gpu.

 

Cena za chwile bedzie nizsza i 580 i 680 jak tylko na rynek wejdzie wiecej referkow 670tek.

 

vray obsluguje multigpu, jednak zakup 590 w chwili obecnej jest bez sensu, chyba ze komus zalezy tylko na wydajnosci.

[Gość Chrupek3D]

Octane ma benchmark, możesz sprawdzić.

[Skoti]

4x to tylko takie przyrownanie a nie obliczenia zadne, bo np gtx460 ma 4x mniej cuda.

Aaa czyli w ten sposób to 4x uzyskałeś. Trzeba przyznać, że sporo naciągane (w ten sposób Fermi też jest wielokrotnie wydajniejszy od niższych modeli Kepler).

 

Ty masz dane a ja wlasnie jade na gtx680 i ogladam vray rt. Nie wiedziec czem uale zadnej roznicy nie widze pomiedzy gtx680 a gtx570, jesli jest to mega subiektywna. nie ma zadnego benchmark uw vrayu bym mogl to sprawdzic bo dane ktore pojawiaja sie skacza na obu kartach.

Zaraz sprobuje sprawdzic jeszcze obciazenie gpu.

Dane oparte na faktach z dokumentów dotyczących architektury czy subiektywna opinia "żadnej różnicy" (poza krotnością ceny)?

 

Cena za chwile bedzie nizsza i 580 i 680 jak tylko na rynek wejdzie wiecej referkow 670tek.

Nie licz na to - cena 670 jest tak wyliczona, aby nie zmieniać cen innych kart.

 

vray obsluguje multigpu, jednak zakup 590 w chwili obecnej jest bez sensu, chyba ze komus zalezy tylko na wydajnosci.

Kupując kartę zależeć powinno tylko na 2ch rzeczach - wsparciu dla standardów, wydajności w zastosowaniach w których będzie wykorzystywana i cenie (w tej kolejności). Wsparcie standardów jest w Fermi i Kepler takie samo, wydajność w GPGPU jest po stronie Fermi, jak i cena. Powtarzam Kepler będzie dobry w pełnej wersji (1/32 wydajności przy ponad 2k rdzeni), ale jeśli ktoś do grafiki dziś wybiera kartę (nie pod koniec roku) to najlepszym wyborem jest pełne Fermi.

[Tomo]

We might have to split into iRay 1 and 2, it seems they changed quite a lot.

 

========== Current Results ============

0:13 GTX 590 3GB i7 980 3.33GHz (Thanks Nanne!)

0:23 GTX 590 3GB, I7 2600

0:23 GTX 580 3GB, i7

0:24 GTX 580, i7 2600K @ 3.40 GHz,

0:27 Zotac 560Ti 448 cores, i7 2600k

0:28 fx 570, i7 2600K

0:29 Fermi 570, Dual Quad Xeon@ 2.26

0:31 GeForce GTX 570, Intel Xeon X5650

0:33 2x quadro fx 3800, dual sixcore 3.4ghz (while realflow)

0:35 GTX 560 Ti Hawk, i7 960 @3.2 24 GB DDR3 Ram

0:36 GTX 560 Ti DirectCU 1GB Asus, 2500k (@4.5Ghz)

0:37 GTX 560, i7 sandy bridge 2600K quad 3.4 GHz

0:40 GTX 470, 1GB Q660 quad-core

0:49 GTX 560 Ti, Phenom II X6 1100T

0:51 GTX 560, Core2 Quad Q8200

0:51 Quadro 400, 6core Xeon

1:02 GTX 285

2:10 i7 920 2.66 overclocked to 3.4Ghz

2:44 9800 GT Core2 Quad Q8200

2:46 core i7 920 quad-core

3:41 secs Firepro v4800, i5 760 (2.8ghz)

3:55 Xeon Quad core (3.0ghz)

13:31 Dual-core laptop

[Tomo]

Kitamo

 

Zrób test zapuść Vray RT ustaw mu 1 minute i napisz ile paths obliczyła albo odwrotnie ogranicz paths i podaj czasy.

Dla każdej karty osobno i jak możesz to razem i wszystko będzie jasne.

Tu jest plik do testu iray ale korzysta z cpu też z ciekawości możesz zlukać też ciekawe porównanie będzie np z 590

http://www.maxforums.org/threads/iray_gpu_cpu_comparison_test/0001.aspx

 

Ja mam 32s konfig z podpisu.

Edytowane 27 Maj 2012 przez Tomo

[kitamo]

Nie mam juz niestety kart, mialem je do testow.

W sumie ciekawostke niezla wkleiles i dla sprawdzenia puscilem ta scene u siebie na samym CPU - wynik 36 sekund.

Niestety moja obecna karta graficzna to nie jest demon szybkosci. W przyszlym tygodniu znow sobie pozycze cos z gtx6xx

Edytowane 27 Maj 2012 przez kitamo

[Tomo]

36 sekund hmmm "na samym CPU" wydaje mi się mało mam wrażenie że jednak karta też pracowała np to daje do myślenia "0:51 Quadro 400, 6core Xeon" no ale nie znam twojego konfigu będę wdzięczny jak mi napiszesz jaki proc i jaką kartę masz aktualnie ;)

No i czekam na testy kart 6xx jak tylko jakąś dorwiesz.

[kitamo]

Moze masz racje, jesli standardowo iray korzysta z cpu+gpu to faktycznie u mnie dziala (nie mam tego smiesznego skryptu gdzie mozna ustawic vraya).

 

Testowale mna 2600k @ 5.2ghz i starym gtx460 na standardowych zegarach.

Tak jak patrze na te wyniki pozostale sklonny jestem uwierzyc ze ten GTX bral tez w tym udzial, tylko niestety nie wiem jak go wylaczyc i sprawdzic bez niego :)

 

Przed chwila w piekarniku wypiekalem 9 kart z artefaktami, sa wsrod nich tez karty dwuprocesorowe wiec moze ktoras z nich jeszcze przetestuje pod tym wzgledem, jak tylko wystygna oczywiscie :)

[Tomo]

to na pewno szedł proc i grafa. Co do iray to też nie mam skryptu co do vray to też chętnie bym zobaczył wyniki tam przynajmniej wybiera się co ma renderować bez skryptu :) A co do wypiekania wczoraj nie wspomniałem i nikt przede mną tego nie zaznaczył że karty do gier nie są przystosowane do obciążenia 100% non stop jakie występuje w renderingu więc trzeba patrzeć na chłodzenie karty kupując ją i dołożyć do lepszego albo wymieniać samemu jak się już ma z jakimś szajsem jak też nie kręcić karty i kręconych przez producenta nie brać tak wyczytałem i jestem skłonny się z tym zgodzić że takie karty szybko potem padają ;].

Mój 480 wiem że grzałka z niego ale 93C po chwili renderingu ma.

Tesle mają niskie zegary nie są wyżyłowane tutaj ale też o temperaturę się nie trzeba martwić.

 

To tak dla przestrogi jak ktoś chce render na gpu odpalać czy nawet podgląd nie oszczędzać na chłodzeniu bo może wyjść drożej wymiana potem na lepsze.

Kitamo jakie masz napięcia na procku ?

[kitamo]

napiecie podbilem o +0,167 w stosunku do nominalnego i to wystarczylo.

Na 4,5Ghz moj proc idzie bez dotykania napiecia na standardowych ustawieniach.

[Tomo]

u mnie jedynie fix mode się spisuje 4.6ghz na vcore 1.336-1.344V (cpuz)

 

Ktoś ma jakieś wieści co do Vray rt i gtx 680 ?

Jakby ktoś miał konkretne porównanie 580 vs tesla c2050 byłbym wdzięczny.

[kitamo]

A wiec tak - problem w sensownym ocenianiu 680tki w vray rt lezy w samym vray. Korzysta on z tego co widze z opencl a niestety w opencl nvidia w tym temacie ssie, i karta znacznie lepiej pracuje przy wykorzystaniu cuda. Ogolnie sam opencl ssie w vray rt.

Sprawdzalem w iray, i przyrost wydajnosci wzgledem i7@5ghz jest ponad 3 krotny. Mysle ze na dzien dzisiejszy nie ma co nawet robic porownania w vray rt bo jest on strasznie ograniczony, a jakosc generowanego przez niego obrazu jest nadal daleka oryginalowi na CPU.

 

Porownywanie Tesli do GTX580 mija sie z celem - mimo mniejszej ilosci cuda i nizszym taktowaniu tesla i tak jest szybsza, ale wszystko tu zalezy od oprogramowania.

[Tomo]

Vray rt 2 ma do wyboru CPU , Opencl, Cuda robiłem testy u mnie na fermi 480 i dodam od siebie że tryb opencl nie jest wiele wolniejszy pytanie czy to poprawna wydajność opencl czy zaniżona wydajność cuda nie widze jakieś wielkiej różnicy. Wyniki testu w formie jpg i opisami dodam na forum potem jeśli ktoś jest zainteresowany.

Co do tesla vs gtx 580 to wiem że jest szybsza pytanie ilu krotnie co lepsze 2x gtx 580 3gb czy nadal tesla będzie wydajniejsza.

Edytowane 21 Czerwiec 2012 przez Tomo

[kitamo]

Tesla jest szybsza ze wzgledu na odblokowany modul podwojnej precyzji ktory osiaga 4 krotnie wyzsza wydajnosc niz w GTX.

 

Hmm gdzie ta opcja w Vray 2 ? ja mam tylko mozliwosc skorzystania z OCL.

Ogolnie wydajnosc w Vrayu zdaje sie byc jeszcze nieco na niskim poziomie bo jest sporo innych rendererow ktore lepiej sobie z tym zdaje sie radza. Roznica jest taka ze w vrayu sa dosc specyficzne algorytmu jesli idzie o swiatlo i moze to powoduje ze karta zapycha sie dosc szybko o vray RT nie wyswietla w 100% takiego samego obrazu jak powinien byc na CPU.

Tego dokladnie nie wiem bo nie mialem czasu testowac.

[Skoti]

Tesla jest szybsza ze wzgledu na odblokowany modul podwojnej precyzji ktory osiaga 4 krotnie wyzsza wydajnosc niz w GTX.

Tesla czy Quadro mają odblokowane jednostki podwójnej precyzji (przez co się grzeją i mają niższe zegary), jednak 4x krotnie wyższa wydajność może być tylko w aplikacjach wykorzystujących FP64 - VRay i inne renderery nie korzystają z takich liczb wcale (wiele kart nawet nie obsługuje FP64 jak Radeon HD 5770, Radeon HD 6870, Radeon HD 7670). W rendererach wydajność Tesli i Quadro będzie niższa niż w GeForce (wyższa wydajność FP32 ze względu na wyższe taktowania).

 

GeForce 580: 1581 GFLOPS FP32 i 198 GFLOPS FP64

Tesla M2090: 1331 GFLOPS FP32 i 665 GFLOPS FP64

 

W aplikacjach liczących w liczbach podwójnej precyzji Tesla zamiata, ale w rendererach które operują na liczbach pojedyńczej precyzji będzie 20% wolniejsza od taniego GeForce

Edytowane 22 Czerwiec 2012 przez Skoti

[Tomo]

[ATTACH=CONFIG]86583[/ATTACH]

 

[ATTACH=CONFIG]86584[/ATTACH]

normalny Vray

 

[ATTACH=CONFIG]86586[/ATTACH]

Vray RT CUDA

 

[ATTACH=CONFIG]86585[/ATTACH]

Vray RT CPU

 

[ATTACH=CONFIG]86587[/ATTACH]

Vray RT OpenCL

[kitamo]

Tesla czy Quadro mają odblokowane jednostki podwójnej precyzji (przez co się grzeją i mają niższe zegary), jednak 4x krotnie wyższa wydajność może być tylko w aplikacjach wykorzystujących FP64 - VRay i inne renderery nie korzystają z takich liczb wcale (wiele kart nawet nie obsługuje FP64 jak Radeon HD 5770, Radeon HD 6870, Radeon HD 7670). W rendererach wydajność Tesli i Quadro będzie niższa niż w GeForce (wyższa wydajność FP32 ze względu na wyższe taktowania).

 

GeForce 580: 1581 GFLOPS FP32 i 198 GFLOPS FP64

Tesla M2090: 1331 GFLOPS FP32 i 665 GFLOPS FP64

 

W aplikacjach liczących w liczbach podwójnej precyzji Tesla zamiata, ale w rendererach które operują na liczbach pojedyńczej precyzji będzie 20% wolniejsza od taniego GeForce

Hmm a gdzie to mozna przeczytac ze Vray na CUDA nie uzywa FP64 ? Z tego co powszechnie wiadomo CUDA korzysta z blokow FP64 i nie bez powodu sa one w tesli o zwiekszonej wydajnosci. Stad tez zastanawia mnie brak FP64 dla Vray.

Iray chodzi znacznie szybciej na Tesli niz na GTX, ale moze to byc tez zasluga o wiele wiekszej pamieci (obliczenia na CUDA wymagaja sporo VRAM)

Ogolnie zastosowanie tesla glownie znajduje nie w samym renderingu a w zupelnie innych obliczeniach, glownie skierowanych w srodowisku CAD'owych (obliczenia plynow, fizyki i działających sił, medycyna).

Edytowane 23 Czerwiec 2012 przez kitamo

[Tomo]

Skoti też bym chciał konkretnego linka gdzie pisze o tym że vray rt nie wykorzystuje FP64 no i że tesla jest wolniejsza.

[Skoti]

Hmm a gdzie to mozna przeczytac ze Vray na CUDA nie uzywa FP64 ? Z tego co powszechnie wiadomo CUDA korzysta z blokow FP64 i nie bez powodu sa one w tesli o zwiekszonej wydajnosci. Stad tez zastanawia mnie brak FP64 dla Vray.

Z powszechnego mitu nie wyciągaj wniosków na temat tego co wiadomo. CUDA samo z siebie nie korzysta z FP64, a tak jak w OpenCL czy C/C++ to programista decyduje jakimi liczbami operuje. VRay jak i inne renderery nie wykorzystują podwójnej precyzji (nawet na CPU gdzie FP64 liczy się tak samo szybko jak FP32) z prostego względu: nie potrzebują takiej precyzji. Przykładowo jeśli pojedyńcza precyzja daje nam precyzję rzędu przesunięcia wierzchołka odległego od środka sceny (0, 0, 0) o 900km o 1 cm od zamierzonej (przy założeniu 1m to jedna jednostka) to podwójna precyzja nikomu tu nie jest potrzebna.

Jako "dowód", że VRay nie wykorzystuje FP64 masz tu zebrane wyniki benchmarku z forum vraya (GeForce są tu najszybsze).

http://postfiles4.naver.net/20110514_259/billywagner_1305334480378P63GO_PNG/gpu_chart2.png?type=w2

 

Iray chodzi znacznie szybciej na Tesli niz na GTX, ale moze to byc tez zasluga o wiele wiekszej pamieci (obliczenia na CUDA wymagaja sporo VRAM)

Pamięć nie ma tu zupełnie nic do rzeczy - ilość pamięci nie zwiększa wydajności! Duża ilość pamięci jest ważna, żeby pomieścić scenę w karcie, ale jeśli się zmieści (aplikacja się nie wywali) to jest zupełnie obojętne ile pamięci jest nieużywane.

Co do tego, że IRay chodzi znacznie szybciej na Tesli niż GeForce to mnie zdziwiłeś... tzn wiem, że Nvidia, która jest twórcą iray chce tak to przedstawiać, ale Nvidia nie byłaby taka głupia, żeby faktycznie używać FP64 i wydajnościowo ssać (nawet na Quadro/Tesla w porównaniu z konkurencją).

Co więcej Autodesk też nie podziela Twojego zdania i w http://area.autodesk.com/blogs/shane/the_iray_faq napisali:

What are the performance differences for iray between NVIDIA’s GeForce, Quadro, and Tesla products in 3ds Max?

 

NVIDIA GPUs vary in their compute performance according to the number of CUDA cores they have, the GPU’s clock speed, and the GPU’s architecture. The GPU brand will not impact iray performance beyond these characteristics. Put into formulae, GPU ray tracing performance looks like this:

 

(CUDA Cores#) x (Clock Speed) x (GPU Architecture) = Relative Performance.

 

This means that for a given GPU architecture and clock speed, iray performance will scale linearly with the number of CUDA cores present on the GPU, and for a given architecture and core count iray will scale linearly with clock speed. The GPU family (Quadro, Tesla or GeForce) does not have additional influence on how iray uses it.

Jeśli jednak ja, oni i cała reszta się myli to proszę o podesłanie małego dowodu mówiącego, że jest inaczej.

Ogolnie zastosowanie tesla glownie znajduje nie w samym renderingu a w zupelnie innych obliczeniach, glownie skierowanych w srodowisku CAD'owych (obliczenia plynow, fizyki i działających sił, medycyna).

Tesla znajduje zastosowanie przy obliczeniach naukowych w medycynie i wszędzie tam gdzie po setkach obliczeń błąd precyzji może zawalić całe badania. Do zadań CAD/grafika Nvidia promuje raczej Quadro - rzadziej tu potrzeba FP64 (ale ma wydajność taką jak Tesla), jednak Quadro ma dodatkowe atuty jak poczwórne bufforowanie OpenGL, czy 10bit na kolor, sprzętowe przycinanie płaszczyzną... ale graficy przeważnie tego nie potrzebują i ich obliczenia prawie nigdy nie widzą 64bitowych liczb zmiennoprzecinkowych, a bez reszty dodatków też się obejdą.

Edytowane 23 Czerwiec 2012 przez Skoti

[kitamo]

Ok link nie dziala ,ale spoko nie mowie ze nie wierze.

Pamiec ma gigantyczne znaczenie jesli idzie o wykorzystanie CUDA i nie tylko ja tak pisze ale i madrzejsci w ty mtemacie takze - jeszcze wczoraj jak szukalem info na temat FP64 w vray trafilem na takie info i to dosc obszernie wyjasnione.

 

Ta wypowiedz speca od autodesk jest z 2010 roku, moze cos sie zmienilo od tego czasu. Ja tam nie wiem ,natomiast ciekawi mnie to bo coraz to wiecej widze zestawow quadro + tesla pod Iray, a przeciez wydajniej by bylo zrobic 2x GTX 570

[Skoti]

Ok link nie dziala ,ale spoko nie mowie ze nie wierze.

Już powinien działać.

 

Pamiec ma gigantyczne znaczenie jesli idzie o wykorzystanie CUDA i nie tylko ja tak pisze ale i madrzejsci w ty mtemacie takze - jeszcze wczoraj jak szukalem info na temat FP64 w vray trafilem na takie info i to dosc obszernie wyjasnione.

Pamięć ma gigantyczne znaczenie, ale szybkość pamięci, a nie pojemność. Czyli szerokość szyny (Quadro/Tesla ma taką samą jak odpowiedniki GeForce) i częstotliwość pamięci (GeForce ma wyższą). Ilość pamięci nie ma żadnego znaczenia (może mieć tylko w jednym wypadku - kiedy scena się nie mieści na karcie i aplikacja się wywala lub liczy na CPU, a nie na GPU). Jednach z chęcią zobaczyłbym ten link który odnalazłeś.

 

Ta wypowiedz speca od autodesk jest z 2010 roku, moze cos sie zmienilo od tego czasu. Ja tam nie wiem ,natomiast ciekawi mnie to bo coraz to wiecej widze zestawow quadro + tesla pod Iray, a przeciez wydajniej by bylo zrobic 2x GTX 570

Jest bardzo nieprawdopodobne, że cokolwiek się zmieniło w wypadku wykorzystania FP64, bo takich liczb nie potrzeba, a Nvidia nie zrobiłaby takiego ruchu nawet po to, żeby promować Quadro, bo konkurencja by odskoczyła (nawet na Quadro wydajność spadłaby 2x, na GeForce Fermi 8x, a na Keplerach 24x względem konkurencji korzystającej z FP32). Nvidii zależy na promowaniu obliczeń GPGPU, a nie blokowaniu rozwoju tego rynku ;p. Bardziej prawdopodobne, że używają FP16 (half-float) do wielu zadań jak przechowywanie normalnych.

[kitamo]

Ale to logiczne by bylo ze wymaga wiecej ramu, gdyz wszystkie obliczenia sa realizowane w vram, wiec sam vram nie jest po to by pomiescic geometrie i textury, ale musi tez dostarczyc miejsca dla samych obliczen gpgpu. Wydajnosc pamieci ma znaczenie jasne bo musi dane pobierac i zrzucac, wiec uwarzasz ze po wrzyceniu renderu ktory wypelnia cala karte graficzna nie jest jej bez znaczenia ile zostalo vram wolnego na te kalkulacje wlasnie ?

 

 

Szukam wlasnie tego linku ale cos slabo mi idzie bo w pracy to sobie czytale ma teraz w domu siedze.

 

ps. link wciaz nie dziala :)

Edytowane 24 Czerwiec 2012 przez kitamo

[Skoti]

Ale to logiczne by bylo ze wymaga wiecej ramu, gdyz wszystkie obliczenia sa realizowane w vram, wiec sam vram nie jest po to by pomiescic geometrie i textury, ale musi tez dostarczyc miejsca dla samych obliczen gpgpu. Wydajnosc pamieci ma znaczenie jasne bo musi dane pobierac i zrzucac, wiec uwarzasz ze po wrzyceniu renderu ktory wypelnia cala karte graficzna nie jest jej bez znaczenia ile zostalo vram wolnego na te kalkulacje wlasnie ?

Jedyne na co potrzeba VRAM to pomieścić scenę i pomieścić render (do którego zapisuje wynik obliczeń). Do niczego więcej pamięć globalna nie jest potrzebna. Jeśli się zmieści scena i buffor zwrotny (wyrenderowany obrazek 2d) jest bez znaczenia ile pozostało wolnego, bo pamięć globalna nie jest wykorzystywana jako cache. Do tego ma L1/local memory/shared memory (zwał jak zwał - PC/OpenCL/CUDA ;p) która jest w każdym SM i jest to pamięć niezależna od global memory. Dodatkowo jest pamięć L2 dostępna na całe już na całe GPU (ale dalej jest to zupełnie osobna pamięć nie wliczana do VRAM).

 

ps. link wciaz nie dziala :)

To podam link do innej strony gdzie jest ten obrazek http://www.spot3d.com/vray/images/gpu_chart2.png

[kitamo]

Kurcze gdzies mialem testy gtx580 2GB vs gtx580 3GB i na tej drugiej render smigal znacznie szybciej a tez lecialo na cuda badz ocl.

musial bym sprawdzic jak po odpaleniu CUDA znika ram na karcie i tyle

[rice]

Tu jest jakis haczyk czy one tyle kosztuja?

http://allegro.pl/nvidia-geforce-gtx560ti-1024mb-1gb-okazja-gw-fv-i2434223600.html

[Tomo]

Rice tyle pisze to tyle kosztuje ;] to używka jeżeli do gpgpu to ma tylko 1gb na pokładzie no i czy sama wydajność jest dobra w porównaniu do 480 które za 700zł widziałem a o 50% vramu więcej mają to sporo a nie wiem czy vray rt obsługuje dzielenie rendera na części sprawdzę to napisze.

 

Co do keplera gtx 680 jest on już obsługiwany przez Ariona :D testy powinny więc być niebawem ale widziałem filmik 4x680 i jakoś mi się wydawało wolne te albo skopane ustawienie w arionie. Znajdę jakiś konkret to linka wrzucę :)

 

[ATTACH=CONFIG]86614[/ATTACH]

Edytowane 24 Czerwiec 2012 przez Tomo