Skocz do zawartości

Rekomendowane odpowiedzi

  • Odpowiedzi 35
  • Created
  • Ostatniej odpowiedzi

Top Posters In This Topic

Napisano

Nowy proces technologiczny i liczby imponujące ale czekam na niezależne benchmarki. Ciekawe kiedy te karty zejdą poniżej tysiąca pln. Wtedy bym się skusił. ;)

Gość Chrupek3D
Napisano

ja mam 672 rdzenie cuda i nic nie śmiga, ani Octane, ani Cycles... dlatego zastanawiam sie nad sprzedażą jednej karty.

Napisano
ja mam 672 rdzenie cuda i nic nie śmiga, ani Octane, ani Cycles... dlatego zastanawiam sie nad sprzedażą jednej karty.
A jaką masz kartę? Pracujesz na Linuxie?
Napisano

@RUNNER18: Niższa częstotliwość o 40%-50%, więcej rdzeni upakowane w SIMD, poobcinane schedulery i jeszcze masa innych spraw sprawia, że 768 to znacznie zawyżony odpowiednik i często będzie ustępować nawet 512 rdzeni z 580 w obliczeniach jak:

http://media.bestofmicro.com/I/5/331133/original/luxmark.png

 

Ogólnie ta karta to krok wstecz w obliczeniach i nie zmienia tego nawet to, że to powinno być 660, a 680 miał być trochę lepszy chip GK100, który teraz jest planowany na 780 jesienią, jednak główne cechy z GK104 pełnemu Keplerowi zostaną i będzie miał podobne wady tylko mniej odczuwalne.

Napisano

Chrupek3D ja mam 192 i mi smiga...

 

Co do tych benchmarkow to slabo mnie obchodza te z Open CL, chcialbym zobaczyc jak dziala cos co wspiera "zamkniete i zle" CUDA ;) A jak juz porownuja to moze choc karty o podobnej ilosci pamieci by wzieli.

Napisano

@Nezumi: Testy CUDA wyjdą podobnie względem 580. Nowa arch po prostu bardzo słaba w obliczeniach (Nvidia zrobiła tu przeciwny ruch do tego co AMD w GCN).

 

Co do pamięci to nie do końca rozumiem o co Ci chodzi - więcej pamięci nie przyspiesza renderingu tylko pozwala na większe tekstury, rozdzielczość i siatki - w testach liczy się co najwyżej przepustowość pamięci (tu 680 ma podobnie jak 580 ze względu na wyższe zegary, ale mniejszą szynę, ale przegrywa bardzo z 7970).

Napisano

czyli do renderowania bardziej wydajna i opłacalna jest seria 400/500 niż ta 680 ? no to niezły klops w takim razie zrobili a miałem nadzieje że będzie to coś fajnego ...

Napisano

@jacenty: OpenCL to api do obliczeń na różnych urządzeniach i głównie wykorzystywane do obliczeń na GPU (bo dzisiejsze GPU mają wydajność ponad 3 TFLOPS, a 4x rdzeniowe SandyBridge czy konkurencyjne procki od AMD mają wydajność 0.25 TFLOPS). Nie patrz na testy jak Sandra i podobne, bo dla Ciebie zapewne są one bezsensowne - jedynym który może Cię interesować to pierwszy LuxMark jeśli zamierzasz renderować w LuxRender i uzyskać render wielokrotnie szybciej niż na CPU.

Co do Max/Maya to jest tam iRay tworzony przez Nvidię (no dobra, przez Mental Images, który jest własnością Nvidii) i on może renderować na GPU... ale w tym wypadku tylko na kartach Nvidii, jednak prawdopodobnie 580 będzie tu lepszym wyborem.

Co do innych programów/rendererów w których powinna Cię obchodzić wydajność CUDA/OpenCL to możesz jeszcze korzystać z Indigo, Arion, Blender (renderer Cycles korzysta z CUDA i OpenCL, a dodatkowo zaraz pojawią się nody liczone w OpenCL), ale poza grafiką również fizyka (PhysX liczy na CUDA czy za niedługo Bullet będzie korzystał z OpenCL, więc przyspieszy to wypiekanie fizyki), a jeśli montujesz animację np. w Sony Vegas to też wydajność OpenCL powinna Cię interesować ;].

 

A jak się to ma do OpenGL? Oba są rozwijane przez Khronos Group i mogą ze sobą się komunikować i przyspieszać w przyszłych wersjach programów działania w Viewporcie lub renderingu (współdzielenie bufforów i tekstur, oraz operacje na siatce bezpośrednio na karcie, bez blokowania CPU).

Alternatywą dla OpenCL jest CUDA czy DirectCompute (razem z Direct3D i innymi elementami tworzy DirectX 11 i nowsze).

Gość Chrupek3D
Napisano
A jaką masz kartę? Pracujesz na Linuxie?

 

na linuxie tez... mam dwie 460gtx.

Napisano

tomik8on69 - moze zsumowali godziny wszystkich pracownikow, na zasadzie ze jesli 10 osob pracowalo 8 godzin to zespol przepracowal 80 godzin. Bezsensowne ale fajnie brzmi. Marketing.

Powinni chyba napisac - zeby to mialo sens - "gdyby jedna osoba miala wykonac ta sama prace co wykonal zespol zajeloby to jej 1,8 milionów godzin". Ale nie brzmi to fajnie.

Napisano

Gdyby te osoby pracowały 24h na dobę to żeby przez pięć lat wypracować tyle godzin potrzeba 41 osób. Czyli pewnie coś koło 80-100 osób przez pięć lat pracowało około 10-12h na dobę na keplerem.

Biorąc pod uwagę czas potrzebny na przygotowanie nowej architektury i częstotliwość jej wydawania to w pewnym momencie na raz były prowadzone prace nad fermi, keplerem i maxwellem.

Napisano

@Tomala: Prace trwały zapewne więcej niż 6 lat (tak jak teraz już od jakiegoś czasu trwają pracę nad następcą Maxwella (następcy Keplera)). I nie bardzo można to przeliczyć na osoby, bo na początku pracuje kilkanaście/kilkadziesiąt osób i na kolejnych etapach dochodzą kolejne osoby i pod koniec kilkaset osób pracuje (a jak doliczy się marketing i inne działy to jeszcze więcej).

Napisano
ja mam 672 rdzenie cuda i nic nie śmiga, ani Octane, ani Cycles... dlatego zastanawiam sie nad sprzedażą jednej karty.

 

Czuję twój ból bo ja nawet nie moge zmusić rayfire do pracy na gpu a ponoć physx powinien. Sam kepler wyczes ogromny ale do nawet najcieższych gier wciaż starczy dziś jedna 590tka lub np 570 SLI w które sam mam zamiar sie za miesiac wyposażyć...

Napisano

@comander_barnik: PhysX sam nie powinien - PhysX daje możliwość obliczeń na CPU i GPU, ale to programiści aplikacji (w tym wypadku rayfire) decydują co gdzie i jak się ma liczyć, a na stronie rayfire nie widziałem informacji o wsparciu dla GPU z ich strony, więc wykorzystanie PhysX tu nie pomoże.

 

@Creator: Zamiast dziwić się podaj jak skonfigurowane masz te 2 karty - pod linuksem można ustawić to jako MultiGPU, SLI lub brak obsługi 2giej karty (tu zapewne brak konfiguracji i nie obsługuje 2giej wcale), a zarówno MultiGPU jak i SLI można jeszcze dodatkowo konfigurować (czy klatki w OpenGL mają być renderowane pół na jednej karcie, pół na drugiej, czy jedna klatka na jednej, a kolejna na drugiej, czy ma robić mozaikę, czy ma wybrać automatycznie).

Napisano
@Creator: Zamiast dziwić się podaj jak skonfigurowane masz te 2 karty - pod linuksem można ustawić to jako MultiGPU, SLI lub brak obsługi 2giej karty (tu zapewne brak konfiguracji i nie obsługuje 2giej wcale), a zarówno MultiGPU jak i SLI można jeszcze dodatkowo konfigurować (czy klatki w OpenGL mają być renderowane pół na jednej karcie, pół na drugiej, czy jedna klatka na jednej, a kolejna na drugiej, czy ma robić mozaikę, czy ma wybrać automatycznie).
Pouczasz mnie czy chrupka? Bo nie kumam.

 

I jeszcze co do Octane'a:

Octane Render does not support SLI. If it is enabled, then disable it to use multiple GPU's
Napisano
Pouczasz mnie czy chrupka? Bo nie kumam.

Ciebie, bo zamiast pisać standardowe i nic nie mówiące "dziwne... u mnie działa", wystarczyło napisać jak ma ustawić ;].

Napisano

@scyguo: Wątpię, że chodzi o nowe SDK, bo najnowsze wyszło niecałe 2 tygodnie temu, a nowszego nie ma nawet dostępnego w wersji beta dla zarejestrowanych programistów. Tym bardziej nie o to chodzi, bo Kepler wykonuje kod CUDA 2.1 (taki jak w 460/560 i niższych), więc jeśli kod produkowany przez kompilator w SDK działa dla 460 to będzie też dla Keplera. Problemem jest raczej tu nie SDK, a sterowniki i potrzeba po prostu poczekać na nowsze wydanie sterowników (lub przetestować na innych bo dla Windowsa już jest chyba 3x wersje sterowników dla Keplera - 301.10, 300.99 i przynajmniej jedna inna wersja dodawana do kart przedpremierowo, które bardzo możliwe dostali z kartą twórcy Octane)

Napisano

@Skoti: Jak zwykle masz rację. Ale poczekam z zakupem do czasu aż zobaczę, że działa na tym octane i cycles. No i ciekawe jak wypadnie w testach dla tych silniczków w porównaniu do fermi.

Napisano (edytowane)

@scyguo: też uważam, że powinieneś tak zrobić (poczekać na testy), tym bardziej, że szkoda przepłacać za Kepler kiedy zapewne będzie wolniejszy od Fermi w obliczeniach jak rendering (w testach wydajności raw jak sandra będzie kepler lepszy, ale to tak jak Radeon 5k był szybszy - wydajność raw, a poważniejsze obliczenia jak rendering/fizyka to 2 zupełnie odmienne sprawy).

 

PS. właśnie sprawdziłem i jednak (od wczoraj) jest nowe SDK 4.2 w wersji RC, ale z tego co zdążyłem wyczytać to 4.1 z 680 działa (o ile nie próbuje program na siłę wciskać wersji pobranej ze sterowników które mówią o CUDA 3.0 (dziwne, bo na http://developer.nvidia.com/cuda-gpus 680 ma Compute Capability na poziomie 2.1 ;p)), a nowe SDK 4.2 przy kompilacji do CC 3.0 sypie się i nie chce działać (więc lepiej użyć 4.1 i podać karcie wersję CC 2.1 lub poczekać na aktualizację sterowników (bo w tej chwili się nie chwalą obsługą 2.1 i wcześniejszych (mimo, że podobno je łykają i programy w CUDA działają (niefart, że Octane i Cycles sprawdzają obsługiwane wersje jak należy ;p)))).

Edytowane przez Skoti
Napisano (edytowane)

No wszystko fajnie , że jest rozwój technologiczny w kartach graficznych opartych na Fermi i GPU support.

 

Pytanie tylko kiedy aplikacje pozwolą oficjalnie i w pełni z tego korzystać bo póki co to zdaje egzamin przy renderingu na żywo w Vray czy innych , wymienionych tutaj.

 

Żeby z kolei zadziałała fizyka pod aplikacjami Autodeskowymi np. Maya ( nie zewnętrznymi pluginami) trzeba się wyposażyć na siłe w Tesle i Quadro co jest bardzo drogą inwestycją, sprytnie połączoną z polityką Nvidia Autodesk , niestety ;(

 

Na szczęście są już aplikacje niezależne, które zaczynają wspierać to GPu powoli niezależnie od polityki Autodeskowo - Nvidiowej.

 

Zaryzykuję nawet prognozę , że Autodsk będzie musiał zejść na ziemię (pewnie w dłuższej perspektywie czasowej) i zacząć wspierać GPU przy fizyce i pochodnych działających na zwykłych Geforcach opartych na układzie Fermi / Kepler.

 

Będzie do tego zmuszony jeśli nie chce stracić klientów na rzecz konkurencyjnych softów flagowych lub aplikacji / pluginów do Maya , które nie potrzebują tandemu Tesla / Quadro , żeby takie GPU wsparcie działało przy systemach fizyki , symulacjach , partiklach i pochodnych.

 

 

 

pozdro

 

czaps

Edytowane przez czaps
Napisano

@Skoti:

"Alternatywą dla OpenCL jest CUDA czy DirectCompute (razem z Direct3D i innymi elementami tworzy DirectX 11 i nowsze)."

Nie nazwałbym tego alternatywą w stosunku do OpenCL.

OpenCL można wykorzystać również w D3D; dodatkowo, nie jest prawdą to co napisałeś o DirectCompute - tego API można użyć już w D3D10.

Napisano
It's rumoured that "Big Kepler" is due in August. The GEForce 680 is based off the same architecture as the GEForce 560, but 4x the shaders with simpler hardware schedulers. The successor to the 580 is a much larger die, and will likely power the next gen Quadros and Teslas - especially given that SIGgraph is in August, and Nvidia traditionally launches the Quadros around that time. It will be interesting to see how much memory those pack, as the 6GB, 2.5GB and 2GB of the Quadro 6000, 5000 and 4000 were very large upon their release.

 

Z czego domniemuję, że ten Kepler z 680, to nie Kepler?

Napisano (edytowane)

@Matuzalem: Możesz mi powiedzieć gdzie napisałem, że OpenCL nie można użyć z D3D (inna sprawa, że współdzielenie danych z DX weszło dopiero od OpenCL 1.2, a wcześniej były tylko rozszerzenia Nvidii nie wspierane przez AMD).

DirectCompute jest częścią DX 11 i według Microsoftu może on działać tylko na kartach kompatybilnych z DX11. Nvidia trochę tu wychodzi przed szereg i daje sterowniki umożliwiające działanie na kartach z DX10 (bo wszystkie karty Nvidii z DX10 czyli od serii 8k wyczerpują wymagania DC). U AMD jest inaczej i możesz korzystać z DX compute tylko na urządzeniach DX11 (częściowo to ze względu na sprzęt, bo karty z DX10 HD2k i HD3k nie pozwalały na obliczenia, a HD4k mają spore ograniczenia jak chociażby brak lokalnej pamięci i emulują ją w globalnej w OpenCL, czego nie mogą robić w DC).

 

@SYmek: Kepler to ma być GK100 tak jak Fermi było GF100, a to co jest w 680 to GK104 czyli następca GF104 który był w Geforce 460. GK104 był przymierzany na 660/670, ale słaba wydajność w grach konkurencji (7970) doprowadziła do zmiany targetu i ze średniego segmentu podniesiono cenę i oznaczenie do hi-endu czyli 680 (bo wolniejszy 7970 to hi-end z wysoką ceną to i 680 może taki być i zarobić więcej na każdej karcie), a pełny kepler który miał być 680 przeniesiony został do 780 w Q3 tego roku (i ma mieć ponad 2 tysiące rdzeni).

Edytowane przez Skoti

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się



×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Wykorzystujemy cookies. Przeczytaj więcej Polityka prywatności