CUDA już niebawem będzie dostępna dla procesorów x86

1. Jak zwykle Nvidia (autor: Sony Vaio | data: 22/09/10 | godz.: 10:39)
   wychodzi na przeciw użytkownikom i dla nich wprowadza nowe technologie na rynek. Za darmo dadzą nam fiziks. Oczywiście z racji lepszych procesorów Intela, na nich będzie to działało prawidłowo. Ciekawe co amd swoim podwładnym daje za friko.
   
   
2. @news (autor: Promilus | data: 22/09/10 | godz.: 10:41)
   Hahahaha. Bez przesady! Teraz nagle się obudzili?
   
   
3. CUDA (autor: ghost12 | data: 22/09/10 | godz.: 10:47)
   Obawiam sie ze CUDA na x86 bedzie takie samo jak phisix, czyli do niczego. A caly zabieg ma na celutylko to alby cuda nie zostala zastapiona OCL.
   
   
4. @ghost (autor: Promilus | data: 22/09/10 | godz.: 10:52)
   OCL celuje w coś innego. Nie w GPGPU i PC, a jeszcze szerzej. Nie bez powodu OCL wspiera Toshiba ze Spursengine. IBM z Cell i POWER. Motorola z PowerPC. AMD (i za niedługo intel) z x86. AMD, NV, S3 i PowerVR z ich GPU. No i jeszcze ARM. Nvidia do takiej wielkiej platformy to się z CUDA nigdy nie zbliży. Ale PC z CPU i GPU to i tak dość łakomy kąsek.
   
   
5. typowa reakcja na odwracanie się światka IT od CUDA (autor: Qjanusz | data: 22/09/10 | godz.: 11:02)
   i coraz większe udziały OpenCL
   
   Gwoździem do trumny będzie porównanie efektywności działania OpenCL i CUDA na x86
   
   Czy jest tu osoba, która nie wie jaki będzie wynik?
   
   nVidia jest zachłanna i chytra. Nie na rękę im będzie poprawna optymalizacja CUDA pod x86. Gdyby tak było, stracili by kartę przetargową do swojego, niezbyt udanego sprzętu.
   
   @sony
   "Za darmo dadzą nam fiziks" - ale przecież Ty masz fizyksa, ponieważ nie uznajesz innych producentów GPU jak nVidia
   Reszcie to do niczego nie potrzebne.
   
   
6. Trzy grosze (autor: pomidor | data: 22/09/10 | godz.: 11:24)
   CUDA była tworzona z myślą o GF. Z tego powodu zawsze będzie szybsza niż OCL, podczas pracy na GF. Nvidia jest najbardziej zaawansowana w całym GPGPU, i z tego powodu nikt się od CUDA nie odwróci. Jeżeli ktoś będzie chciał wyciągnąć maksimum mocy z GPU, pójdzie do Nvidia i CUDA. Mówię tutaj o poważnych zastosowaniach, gdzie GPGPU rzeczywiście jest przydatny. A jak ktoś wierzy w bajeczki o APU i OCL, które 'zrewolucjonizują korzystanie z PC', to trudno.
   
   
7. Pomidor (autor: ghost12 | data: 22/09/10 | godz.: 11:35)
   Tu sie zgodze. Ale profesjonalne zastosowaniadla CUDA to Quadro. Powiedz mi co daje "profesjonaliscie" CUDA w x86?
   
   
8. @ghost (autor: pomidor | data: 22/09/10 | godz.: 11:54)
   Nvidia wypuści CUDA-x86, aby ułatwić życie użytkownikom. Łatwiej będzie programistom pisać programy, bez konieczności kupowania GF. Lub też uruchamianie programu korzystającego z CUDA, gdzie moc zwykłego CPU wystarczy.
   
   
9. Nvidia software (autor: morgi | data: 22/09/10 | godz.: 12:46)
   oni maja tu ewidenta przewage, inwestuja w CUDAcznosc jak nikt inny.
   
   
10. pomidor (autor: Markizy | data: 22/09/10 | godz.: 12:46)
    cuda przenoszą dlatego na x86 żeby nie stracić całej kasy co w pompowali w tą technologie a teraz zaczyna odchodzić do lamusa, na rzecz OpenCL czy DC11.
    
    
11. @pomidor (autor: Mariosti | data: 22/09/10 | godz.: 12:48)
    Widać nie masz pojęcia o czym mówisz... CUDA nie będzie szybsza od OCL bo "została stworzona z myślą o GF" tylko dlatego że jest natywnym framework'iem gpgpu dla gf'ów tak samo jak Stream dla radeonów.
    OCL jest implementowany na gf'ach za pomocą CUDA a na radeonach za pomocą Stream'a, to nie jest oddzielny byt tylko po prostu standard (zapewne nie znasz znaczenia tego słowa).
    
    O ile w natywnym dla danej rodziny procesorów framework'u/języku można napisać program działający kilka procent szybciej niż w OCL'u(zakładając że implementacja OCL w nim jest cokolwiek warta) to i tak nie ma to żadnego sensu bo automatycznie zabieramy sobie w ten sposób kompatybilność z ogromną ilością urządzeń(co jest głównym powodem dla którego CUDA jako samodzielny byt nie ma długoterminowych perspektyw).
    
    Stream SDK 2.0 wydany w tamtym roku przez ATI wykorzystywał właśnie X86 do OCL'a(dopiero później dodano implementację korzystającą z gpu). Fakt że nvidia poczyniła ten krok wynika z tego że jest to na rękę użytkownikom którzy nie mają radeonów i nie widzą potrzeby instalowania sdk ati tylko po dla obsługi procesora (pojawienie się takiej implementacji CUDA dla x86 oznacza że pojawi się niebawem oparta o to implementacja OCL'a by Nvidia). Dzięki ICD dorzuconemu do specyfikacji 1.1 OCL'a już teraz można w jednym programie na jednej maszynie korzystać i z radeonów i gf'ów i x86 do rozwiązywania różnych pod problemów w programie.
    
    Nie rozumiem pomidor dlaczego piszesz taki bullhshit mimo iż nvidia jest jednym z członków grupy roboczej opencl'a, sama regularnie proponuje jego rozszerzenia, a przede wszystkim na bieżąco aktualizuje swoją implementację tego standardu.
    
    Jest jeszcze jedna korzystna rzecz która powinna wyniknąć z tego newsa czyli pojawienie się niezależnych implementacji PhysiX'a w cuda które spowodują że wykorzystywanie w tym celu zwykłego procesora x86 nie będzie wiązało się z żadnym spadkiem wydajności w porównaniu do wykorzystania gf'a.
    
    @Qjanusz
    W tej chwili implementacja OpenCL'a na x86 jest autorstwa amd więc siłą rzeczy będzie bardziej wydajna od konkurencyjnej nvidii (zakładając że zostanie wydana w związku z cudą na x86), ale tu znowu, jeśli szukasz najbardziej wydajnego rozwiązania tylko dla wielordzeniowych procesorów x86 to spójrz w stronę OpenMP, on jest w tym wyspecjalizowany...
    
    OpenCL nigdy nie będzie szybszy od natywnych framework'ów bo tu nie o to chodzi. OpenCL zapewnia elastyczność, jeden kod może bardzo optymalnie działać na każdym wspierającym go urządzeniu, i na ARM'ach i na x86, i na radeonach i na gf'ach i na cellach... W takiej sytuacji nawet kilka procent przewagi w szybkości działania nad programem napisanym w OpenCL'u nie jest żadną zaletą.
    
    
12. pomidor (autor: Dzban | data: 22/09/10 | godz.: 12:50)
    No i physX na buldożerze będzie śmigać.
    
    
13. @Mariosti (autor: Promilus | data: 22/09/10 | godz.: 13:00)
    Już teraz PhysX sprawdza through CUDA czy masz maszynę spełniającą minimalne wymagania (256MB Local RAM i bodajże 48SP wzwyż) więc akurat o GPU PhysX na CPU to możesz tylko pomarzyć.
    
    
14. @Promilus (autor: Mariosti | data: 22/09/10 | godz.: 13:13)
    Wykorzystanie implementacji dla gpu jest przecież niemożliwe.
    Chodzi mi o nową implementację na cpu w oparciu o CUDA dla x86 która nie byłaby pisana specjalnie jak najgorzej (jak to się dzieje obecnie gdy nie są spełnione warunki o których wspomniałeś), tylko z wykorzystaniem simd i wielordzeniowości.
    
    
15. @Mariosti (autor: Promilus | data: 22/09/10 | godz.: 13:16)
    Jest jak najbardziej możliwe, bo to tylko rekompilacja kodu z nowym SDK obsługującym CPU, ale tego i tak nie będzie bo Physx system software sprawdza jaki mamy sprzęt CUDA i w razie nie spełnienia warunków NIE pozwala na wykorzystanie lepszych efektów.
    
    
16. ... (autor: Aamitoza | data: 22/09/10 | godz.: 13:16)
    odpowiem pomidorowi to samo co odpowiedziałem morgiemu ;)
    
    Powiedź mi tylko. Co będzie lepsze implementacja x86 dla cuda w wykonaniu nvidia, czy implementacja openCL dla procesorów intela w wykonaniu intela? Lub implementacja openCL dla procesorów AMD w wykonaniu AMD? ;) Śmiem twierdzić, że to intel i AMD znają lepiej swoje architektury i potrafią stworzyć lepszą implementację. Wszystko rozbija się właśnie o to w jaki sposób dane API zostanie zaimplementowane - przykładem jest openGL. Jeżeli tylko producent się przyłoży i wykona porządną implementację, to działa ona równie dobrze, co dopieszczony DX. Podobnie może być z implementacją openCL na kartach AMD i Nvidia. Wtedy cuda straci sens, bo każdy producent dopieści implementację openCL na swoim sprzęcie i będzie to działać równie efektywnie co cuda, a dodatkowo na ogromnej gamie sprzętu - będzie można napisać jeden program i nie użerać się oddzielnie z wersją na ARM, na Power, na x86, czy na GPU. Do tego GPU jednego lub drugiego producenta. - bo odpali na każdym. Nie jak obecnie - napisz coś w cuda, a potem jeszcze raz z użyciem stream SDK... a potem jeszcze na x86 z wykorzystaniem najnowszych SSE/AVX. (nie biorę pod uwagę cuda x86, bo coś wątpię w efektywność tego rozwiązania).
    
    
17. Fizyks na x86? (autor: Qjanusz | data: 22/09/10 | godz.: 13:17)
    immposible pod każdym względem.
    
    A z resztą po co?
    To to już zaczyna wymierać, chociaż nigdy tak na prawdę nie dojrzało. Nawet zapaleńcy modujący stery nVidii tak, żeby uzyskać fizyksa na GeForce + rendering z Radka dali sobie siana. Po prostu nie ma rynku zbytu na takie hece. Developerzy też omijają to z daleka. Pytanie tylko ile kaski jeszcze nVidia chce stracić na wpompowanie w studio developerskie, po to aby zaimplementowani padło w konkretnym tytule, których co raz mniej.
    
    @Mariosti
    OpenMP to zupełnie inny target.
    
    
18. @Qjanusz (autor: Mariosti | data: 22/09/10 | godz.: 14:17)
    Nie zgodziłbym się, OpenMPI to inny target bo umożliwia dodatkowo obliczenia rozproszone. OpenMP na x86 ma dokładnie tą samą funkcjonalność co OpenCL na x86... z tą różnicą że w OpenMP łatwiej się programuje (kilka makroinstrukcji do starego kodu w cpp i już mamy dość wydajny program na wielordzeniowca).
    Oczywiście takie porównywanie miało sens ponad rok temu gdy OpenCL 1.0 nie miał implementacji na gpu... sam porównywałem ich wydajność na prostym algorytmie mnożącym macierze... ale gdyby teraz ten sam program napisany pod opencl'a odpalić na karcie graficznej kosztującej tyle samo co procesor... dalej o zaletach OpenCL'a powatarzać się chyba nie muszę ;>
    
    Co do PhysiX'a to mimo wszystko w sporej liczbie tytułów jednak się pojawił, urozmaica graficznie rozgrywkę znacznie bardziej niż tesalacja w stalkerze i skoro nie ma technicznego problemu aby wydajnie działał na x86 to dlaczego nie liczyć na to... Nvidia sporo kasy jednak pakuje w ten cały program TWIMTBP i patrząc na większość popularnych produkcji ciężko ich logo ominąć ;>
    
    
19. @up (autor: MateushGurdi | data: 22/09/10 | godz.: 14:23)
    Gry z logo TWIMTBP kojarza mi sie tylko z tym ze nie lubia Radkow i z reguly nie odbiegaja niczym od "zwyklych tytulow". A tak szczerze powiedziawszy to przeniesienie CUDA na x86 to glupota i skonczy tak jak katowanie procow PhysXem, pewnie tez bedzie gdzies jakis haczyk, jakies waskie gardzlo i Nvidia wyjdzie na rycerza w lsniacej zbroi rozdajacego za frajer swoja technologie. Inna sprawa ze w wydj formie jest gowno warta (patrz physx na x86)
    
    
20. @Mariosti (autor: pomidor | data: 22/09/10 | godz.: 14:58)
    Przy pomocy CUDA można lepiej wykorzystać GF, nawet gdyby OpenCL również był natywny. Dla Nvidii CUDA zawsze będzie numerem 1, ponieważ nic chcą się skazywać na pomysły konsorcjum OpenCL. Dzięki temu mogą swobodnie rozwijać GPU i CUDA o nowe pomysły, które dadzą im przewagę nad konkurencją. To w połączeniu z realnym wsparciem, sprawi że poważni ludzie u Nvidii będą szukać rozwiązań. Co do OpenCL i jego zalety w postaci niezależności (teraz już dużo mniejszej dzięki CUDA-x86), to trzeba poczekać aż pojawi się chociaż parę programów. Bez tego wnioskowanie że OpenCL wymiecie CUDA, to czysta fantazja.
    
    Rozumiem że dla niektórych idealistów, otwarte standardy to spełnienie marzeń, ale rzeczywistość jest inna. Właśnie zamknięte standardy są szybciej i bardziej rozwijane, wspierane, promowane i stosowane, niż te otwarte. W wielu przypadkach otwarte standardy, są tylko iluzją niezależności.
    
    
21. Zatem CUDA to... (autor: Duke Nukem PL | data: 22/09/10 | godz.: 15:04)
    100% gwarancja niezależności od sprzętu i oprogramowania Nvidii.
    To tak jak DX z Microsoftu to niezależność od Windows.
    Pomidor, kiedy Ci się skończyła data przydatności do myślenia?
    
    
22. @pomidor (autor: Promilus | data: 22/09/10 | godz.: 15:08)
    Nie pierdziel głupot
    "że poważni ludzie u Nvidii będą szukać rozwiązań"
    Poważni ludzie nie chcą się skazywać na jedną firemkę na glinianych nogach.
    "otwarte standardy"
    OCL to nie otwarty standard. Jest tworzony wyłącznie w obrębie KHRONOS GROUP (tak, tej samej co OpenGL). Cała ta jego 'otwartość' ma zupełnie inne znaczenie niż w open source.
    
    
23. @pomidor (autor: Mariosti | data: 22/09/10 | godz.: 15:15)
    Widzisz... im lepiej CUDA wykorzystuje gf'y tym lepiej OpenCL wykorzystuje gf'y bo OpenCL na gf'a jest zaimplementowany w CUDA właśnie. Konsorcjum rozwijające OpenCL'a jest współtworzone przez Nvidię i rozwój specyfikacji jest podzielony na wiele gałęzi z których najszybsza uniezależnia każdą implementację poprzez wprowadzanie natywnych instrukcji w kernelach... czyli de facto opencl w żaden sposób nie ogranicza prędkości rozwijania poszczególnych implementacji, w sposób naturalny powolny jest rozwój ogólnie wspieranej głównej specyfikacji ponieważ z oczywistych względów wymaga to poparcia wszystkich członków grupy (w zamian za to programy wg tej specyfikacji chodzą na każdym sprzęcie implementującym go).
    Co do oprogramowania... portowanie z CUDA do OpenCL'a jest banalne, jakbyś wiedział coś na ten temat to pisałbyś o "fantazjach".
    
    
24. @up x 3 (autor: pomidor | data: 22/09/10 | godz.: 16:55)
    @Duke NUKEM PL.
    CUDA-x86 już nie jest zależny od GF. To chyba jasne.
    
    @ Promilus
    Nvidia to mała firemka na glinianych nogach, bardzo ciekawe. Więc pokaż mi większą która zna się lepiej na GPGPU i GPU.
    OpenCL to jest otwarty standard.
    http://www.khronos.org/opencl/
    Coś Ci się pomyliło z open source, który nie jest żadnym standardem.
    
    @Mariosti.
    To zależy jakie usprawnienia zostaną dodane do GPU. Jeżeli usprawnią działanie shaderów, to i OpenCL na tym skorzysta. Ale jeżeli dodadzą np. wsparcie dla liczb dziesiętnych (Decimal Floating Point), to OpenCL automatycznie z tego nie skorzysta. Wówczas Nvidia szybciutko rozszerzy CUDA i już będzie gotowa do użycia. Zanim konsorcjum OpenCL zdecyduje się to wspierać, to miną lata. Nvidia wie co robi, bo już pewnie ma dość używania starej specyfikacji OpenGL i upychania wszystkich nowości w systemie rozszerzeń. Dopiero ostatnio łaskawie przyśpieszyli wydawanie nowych wersji.
    
    
25. Pomidor (autor: Aamitoza | data: 22/09/10 | godz.: 17:08)
    Widzę, że wierzysz w Cuda. - możesz to odebrać dwuznacznie, bo i taki ma to cel ;)
    
    
26. ... (autor: Aamitoza | data: 22/09/10 | godz.: 17:13)
    OpenCL jest wspierany przez Nvidię, AMD, Intela, IBM, S3, Apple, ARM, Via i wiele, innych firm. A Cuda? ;)
    
    To już w zasadzie zamyka sprawę.
    
    
27. @pomidor (autor: Promilus | data: 22/09/10 | godz.: 17:40)
    **Otwarty standard – standard, do którego pełnej specyfikacji dostęp nie jest limitowany prawnie, finansowo lub tajemnicą handlową firmy, która standard opracowała. Ponadto standard uznawany jako otwarty jest opracowywany, zatwierdzany oraz później ewentualnie modyfikowany przez porozumienie (organizację) zainteresowanych tworzeniem tego standardu podmiotów, działające niedochodowo i zapewniające członkostwo wszystkim zainteresowanym.**
    Członkostwo w KHRONOS GROUP trzeba sobie wykupić więc tak całkiem to nie zapewniają członkostwa wszystkim zainteresowanym. Oczywiście odpowiednio się na to przygotowali i "membership" obejmuje też i developerów (za free) tyle że oni praktycznie nic nie decydują, mogą jedynie sugerować co trzeba poprawić i co by się przydało. A, że to jest bardzo powszechne to praktycznie żaden otwarty standard w 100% nie spełnia założeń otwartego standardu :P
    "Nvidia to mała firemka na glinianych nogach, bardzo ciekawe"
    Sorry, ale to ty pierdzieliłeś o tym jak to rozwiązania nv są rozchwytywane w profesjonalnych zastosowaniach - tyle że nie masz pojęcia co to są profesjonalne zastosowania. NV nie ma nawet w 1% owych zastosowań - to co, gigant HPC? Rynku serwerów i baz danych? No właśnie nie...a chwiejna (widać po kursie akcji) jak wierzba. Jeszcze raz napiszę - żadna profesjonalna, szanująca się firma nie zwiąże się na śmierć i życie z jedną firemką i jej rozwiązaniami gdy ma bogatszą i pewniejszą alternatywę.
    "to OpenCL automatycznie z tego nie skorzysta"
    Taaa, tak jakby do OpenCL nie było rozszerzeń poza rdzenne funkcje. Daruj sobie swoje mądrości.
    "Zanim konsorcjum OpenCL zdecyduje się to wspierać"
    Blablabla... Z tego co pamiętam od 3 lat mieliśmy 4 pficjalne release OpenGL... z tego samego konsorcjum. Lista rozszerzeń zwiększyła się znacząco. W ciągu 1,5r mamy drugą wersję OpenCL. A za jakiś czas będzie trzecia. Więc twoje wywody są conajmniej śmieszne.
    "upychania wszystkich nowości w systemie rozszerzeń"
    Ależ oni nadal bardzo chętnie korzystają z rozszerzeń, bo to szybkie i wygodne.
    
    
28. Aamitoza (autor: morgi | data: 22/09/10 | godz.: 18:48)
    Z tym wspieraniem to jest roznie, a kto za to placi juz lepsze pytanie. Do porazki nikt sie nie przyzna, a sukcesem to jest samo istnienie, w wiekszosci pod publiczke.
    
    
29. Ja czegoś nie rozumiem (autor: Michał_72 | data: 22/09/10 | godz.: 18:51)
    Sensem CUDUW, Open CL itp było jak rozumiem wykorzystanie ogromnej mocy kart graficznych, marnujących się podczas banalnej obsługi grafiki 2D.
    
    Jaki jest sens przerzucania tych obliczeń na i tak dociążony CPU???
    
    
30. michał (autor: Aamitoza | data: 22/09/10 | godz.: 18:58)
    Sensem openCL nie było tylko przeniesienie obliczeń na GPU, a ujednolicenie API. To, że możesz napisać coś w openCL i odpalić to ma gpu różnych producentów i cpu opartych o różne architektury.
    
    
31. Michal (autor: morgi | data: 22/09/10 | godz.: 19:43)
    Nie przerzucenia obliczen, sensem miala byc adekwatnosc do wspolczesnych architektur oraz utopijna uniformizacja, haselka wielkie, wykonanie mierne, ale za wczesnie na kopanie dola, skoro te koncepcje i api sa stosunkowo swieze.
    
    
32. @morgi (autor: Mariosti | data: 22/09/10 | godz.: 20:31)
    Wykonanie nie jest mierne, jest bardzo dobre. Mamy do wyboru do koloru w doskonale działający implementacjach. Fakt że nie słyszałeś o oprogramowaniu które z tego korzysta wynika z tego że nie jesteś w tym zorientowany. Obecnie tylko specjalistyczne oprogramowanie dynamicznie rozwija się w OpenCL'u bo to był też najpilniej potrzebujący takiego rozwiązania odbiorca.
    //pod specjalistyczny mam na myśli obliczenia numeryczne, symulacje fizyczne, obrazowanie medyczne itp. To wszystko było możliwe do robienia w CUDA, ale ma swoje oczywiste ograniczenia sprzętowe które są jej główną wadą... a dodatkowo OCL może bez dodatkowego narzutu komunikować się OpenGL'em znacznie ułatwiając wizualne przedstawienie wyników obliczeń.
    
    @Michał_72
    Nie każdy problem algorytmiczny da się rozpisać w sposób efektywnie wykorzystujący gigantyczną liczbę rdzeni. W takich rozwiązaniach zwykłe procesory są znacznie szybsze. Możliwość w jednym programie w krytycznych momentach przerzucać obliczenia na najbardziej odpowiednie do tego układy jest nie do przecenienia.
    
    
33. Mariosti (autor: morgi | data: 22/09/10 | godz.: 21:38)
    CUDAcznosc cos tam ma, wykonanie jest do przyjecia, ale reszta to istnieje glownie w mediach, apu ma ten komercyjny falstart zrestartowac, chyba ze znowu skonczy sie na demkach.
    
    
34. @morgi (autor: trepcia | data: 22/09/10 | godz.: 22:19)
    A coś Ty miarko pola jest teraz tak negatywnie nastawiony do CUDA? Czyżby wyrzucany obornik dzisiaj tak Ci pomerdał w główce?
    Jak w kontekście AMD/ATI to piszesz jakie to CUDA niewidy.
    
    
35. @morgi (autor: kosa23 | data: 22/09/10 | godz.: 22:39)
    widziałeś tą reklamę? Uważaj na atrapy... to specjalnie dla ciebie hahaa
    
    
36. @Promilus (autor: pomidor | data: 23/09/10 | godz.: 00:20)
    - OpenCL jest otwarty. A twierdzenie że nie jest do końca otwarty, bo trzeba wnieść jakieś niewielkie opłaty administracyjne aby zostać członkiem... żenujące.
    
    - Nigdzie nie pisałem że GPGPU już zaraz przejdzie do serwerów i HPC, a dotychczasowe rozwiązania pójdą do lamusa. Pisałem że jak firma stwierdzi że potrzebuje rozwiązań na GPGPU, to pójdzie do Nvidii. A z tym wiązaniem się na wieczność z Nvidia, lub wpływem kursu akcji na ofertę firmy i traktowanie klientów - chłopie o czym Ty bredzisz ? Mega żenujące.
    
    - Udostępnianie nowych funkcji przez system rozszerzeń prowadzi do niekompatybilności, bo ciężko oczekiwać aby wszyscy wspierali funkcje które wprowadzi jedna firma. W tym przypadku OpenCL niczym się nie róźni od CUDA, jeżeli chodzi o niezależność od sprzętu. Zaś tworzenie programu wielowariantowego to prawdziwa zmora. Z tego powodu Microsoft zrezygnował w DX10 z device caps, i teraz jest na zasadzie 'wszystko albo nic'.
    
    
37. @pomidołek (autor: Promilus | data: 23/09/10 | godz.: 08:37)
    " z tym wiązaniem się na wieczność z Nvidia, lub wpływem kursu akcji na ofertę firmy i traktowanie klientów - chłopie o czym Ty bredzisz ? Mega żenujące."
    Jak nie potrafisz czytać ze zrozumieniem to przestań czytać w ogóle - na zdrowie ci wyjdzie. Jeśli ktoś teraz inwestuje swoje środki w cudaczność to musi być ABSOLUTNIE przekonany, że jego soft się będzie sprzedawał jak świeże bułeczki, a to oznacza również że jego klienci których musi być naprawdę wielu muszą mieć gejforsy... Sytuacja na rynku prezentuje się jednak inaczej. Większość aplikacji którymi chwali się nv na stronie cudaczności obecnie leci na klastrach wieloprocesorowych gdzie GPU jest i będzie tylko dodatkiem. Z tego choćby powodu OpenCL jest lepszym rozwiązaniem - bo natywnie wspiera platformy heterogeniczne. Ale ty o tym pojęcia najwidoczniej nie masz. Czasy filtrów w adobe czy kodeków media show espresso nv-only się skończyły. Nvidia ma coraz mniej softu wykorzystującego cuda only. Więc gdzie ty tą świetlaną przyszłość widzisz? Renderery piszą na OCL, silniki fizyki na OCL, kodeki na OCL, filtry do grafiki 2D również na OCL.
    Teraz dalej - nigdzie nie pisałem o wpływie kursu akcji na ofertę firmy - jesteś totalnym tępakiem jeśli uważasz inaczej. Pisałem o wahaniach akcji, wahaniach które ODBIJAJĄ się również tam gdzie technologia nvidii jest wykorzystywana bardzo szeroko - inaczej - tam gdzie firma zw. się właśnie na śmierć i życie z nv. Normalne... jak pajęczyna... zadrga pajączek nvidia to i wszystkie muszki do niej przyklejone też zadrżą.
    "bo ciężko oczekiwać aby wszyscy wspierali funkcje które wprowadzi jedna firma"
    Blablabla... zobacz ile rozszerzeń nvidii w OGL wspiera AMD... zobacz ile ekwiwalentnych rozszerzeniom nvidii wspiera AMD. A potem bredź dalej. Jak coś nowego będzie MS chciał pokazać to trzeba czekać na kolejną wersję, jak nvidia albo amd wprowadzą ciekawe rozszerzenia to są dostępne od strzału i dość często stają się rdzennymi funkcjami w nowej wersji OGL. Ale nikt nie musi czekać na nową wersję - bo ma do dyspozycji rozszerzenia. Np. bindless graphics nvidii. Tego na DX nie uświadczysz... może w DX13 ;)
    "W tym przypadku OpenCL niczym się nie róźni od CUDA, jeżeli chodzi o niezależność od sprzętu."
    Nie truj. Doom3 też czerpał pełnymi garściami z rozszerzeń nv, ale nie znaczy to że nie działał na AMD, S3, czy nawet Intelu, albo że wymagało to dużo bardziej skomplikowanego programowania - to nieprawda. Po to sprawdza aplikacja listę rozszerzeń by wiedzieć co można odpalić, a co nie. Tak samo działał Quake, tak samo Unreal... więc nie wiem czemu wg Ciebie nagle teraz jest to nie do przejścia, zacofanie i nie wiadomo co jeszcze. Oczywiście, że różne typy device w OCL się różnią i mają specyficzne funkcje, to chyba normalne. Np. masz device fission na multicore CPU, a nie masz na GPU. Z printf jest chyba dość podobnie. Ale jakoś nic nie przeszkadza pracować lux rendererowi na CPU only, GPU nv, GPU amd, czy wszystkim naraz...a to jest coś czego cuda nie potrafi i potrafić nie będzie.
    
    
38. Dziękuję @Promilus (autor: AmigaPPC | data: 23/09/10 | godz.: 10:04)
    takie właśnie podejście do sprawy powinno być w większości wpisów.
    Przyznaję, że rozjaśniłeś mi w bańce solidnie.
    
    
39. @pomidołek (autor: Promilus | data: 23/09/10 | godz.: 10:41)
    http://www.khronos.org/members/
    Co roku... taaa, koszta administracyjne ;) Nie chciałbyś takich kosztów przy zakładaniu własnego biznesu ;) A tu masz tyle za bycie "członkiem" khr
    
    
40. @Promilus (autor: pomidor | data: 23/09/10 | godz.: 11:57)
    Jak na razie to CUDA jest górą i cały czas się rozszerza, czy Ci się to podoba czy nie. Chyba tylko w swojej 'wyobraźni' widzisz jak wszystko zamienia się na OpenCL, bo fakty temu przeczą. Np tutaj
    http://www.mentalimages.com/...-mental-ray-38.html i w innych produktach.
    
    Wahania akcji nie mają wpływu na działanie firmy, ponieważ zawsze występują, nawet gdy firma się rozwija. Dalej brniesz w te brednie, i nie potrafisz - co oczywiste - tego logicznie wytłumaczyć. Intel, Microsoft, AMD i inni również mają spore wahania akcji, i z tego powodu ich klienci (dla Ciebie muszki) wcale nie drżą.
    
    W grafice istnienie - lub brak -jakiegoś rozszerzenia zazwyczaj ma niewielki wpływ na to jak jest postrzegana gra komputerowa, i nawet przy średniej ilości detali może być dobrą rozrywką. W obliczeniach natomiast, brak pewnej funkcji może mieć kluczowe znaczenie dla wydajności akceleracji - czyli głównego sensu stosowania GPGPU.
    
    Koszty OpenCL. Developers: Free. Mam nadzieję że Cię na to stać.
    
    Dobrze było by gdybyś się pozbył pokładów chamstwa, i postarał się rozsądniej przedstawiać swoje argumenty.
    
    
41. @pomidor (autor: Promilus | data: 23/09/10 | godz.: 12:08)
    Tak, tak... nie ma co jak zarzucać rendererem który wykupiła nvidia :P
    "
    Koszty OpenCL. Developers: Free. Mam nadzieję że Cię na to stać."
    Tępa strzałko, a co może developer robić? Wziąć sobie API i programować ^^ A gdzie wpływ na rozwój OpenCL? No nie ma :]
    "Dobrze było by gdybyś się pozbył pokładów chamstwa,"
    Dobrze by było gdybyś wyzbył się miłości nad wszystko do nvidii - wtedy można by porozmawiać o sprawach obiektywnie, ale że narzucasz swój subiektywny osąd to i ja dla równowagi narzucam swój. Jasne?
    "Wahania akcji nie mają wpływu na działanie firmy"
    Oh, inżynierowie nvidii pewnie akcjonariuszom, a dokładniej zarządowi nie muszą się ze swoich faili tłumaczyć. A to dobre.
    "ponieważ zawsze występują, nawet gdy firma się rozwija" oczywiście, natomiast 2x spadek wartości akcji po pokazaniu jeża to zupełnie nieskorelowany przypadek. I pewnie nikt na tym nic nie stracił.
    "tego logicznie wytłumaczyć"
    Logika nie jest TWOJĄ mocną stroną. Gdyby była dawno byś się przestał udzielać jako PR nvidii.
    
    
42. @up (autor: Promilus | data: 23/09/10 | godz.: 12:23)
    Swoją drogą VRAY RT GPU działa na OCL i wersja stabilna ma wyjść około grudnia 2010. Jak widać powoli aczkolwiek nieuchronnie OCL zyskuje wsparcie jako standard bardziej powszechny i przyszłościowy. Tylko totalny ignorant może twierdzić, że jest inaczej.
    
    
43. pomidor (autor: morgi | data: 23/09/10 | godz.: 13:53)
    CUDAcznosc i openy wszystko jeden pic na wode, dopoki chipy Intela z tym nie zrobia porzadku, czyli koniec gpgpu, albo lykniecie do cepa co uzyteczniejszych funkcji, co juz sie stanie. Nvidia widzi dramat w oczach, wymiekanie gpu, kart graficznych, analitycy tez wieszcza, ze to bedzie stopniowe wypieranie maluczkich, Nvidie dopadnie na koncu.
    
    
44. a ja nie wierzę w cuda :D (autor: mоrgi | data: 26/09/10 | godz.: 15:50)
    a ja nie wierzę w cuda :D
    
    ... a na pewno nie w takie :D