Tylko tu nie chodzi o motywację, bo zapewniam, że wynagrodzenie mają godne, ale o finanse na kadrę i dodatkowych ludzi do pracy

@skoti48
Dokładnie o to mi chodziło.

Niestety reszta chyba źle zrozumiała mój komentarz. Chodzi o to, że:
1. Rynek kieruje się swoimi prawami.
2. Nigdy nie ma się nieograniczonych zasobów.

Firma która tworzy oprogramowanie ma budżet, może zatrudnić mniej lepszych programistów albo może zatrudnić za te same pieniądze więcej gorszych programistów.

Firma robiąca karty graficzne może zrobić GPU bardzo szybkie w korzystnych przypadkach i bardzo wolne w niekorzystnych (AMD), albo nieco wolniejsze ogólnie ale lepiej radzące sobie z przypadkami niekorzystnymi (NVidia).

Firma robiąca karta graficzne może skupić się na samym hardwarze i liczyć, że programiści skorzystają z jej sprzętu (AMD), albo skupić się po równi na hardware i software i sprzedawać karty o podobnej wydajności za większą cenę wykorzystując fakt że z jej gpu korzysta więcej programów. (NVidia)

Firma robiąca karty graficzne może częściej wypuszczać karty z mniejszymi zmianami, dzięki czemu jest mniejsze prawdopodobieństwo jakiś problemów czy opóźnień (AMD), albo robić większe rzadsze kroki i oszczędzając na tym, że potem ma mniej różnych platform do utrzymania. (NVidia).

Nie ma czegoś takiego jak wina, z jakiego punktu widzenia?
Tak ma właśnie być - wygodnie, po to kombinujemy w życiu z tym czy owym żeby było wygodnie i przyjemnie również w programowaniu. Fakt ta wygoda obniza jakość programu i jak karma wraca(patrz produkty microsoftu które napędzają rynek sprzętu) ale podstawowym kryterium jest potrzeba..kiedyś była potrzeba kombinowania dla każdego brakującego kB, wrzućmy nieco na luz

BTW. moja praca dyplomowa kilka lat temu, generator funkcyjny i do niego miernik częstotliwości na Atmelu AVR 8-bit, chyba 12 wyjść IO i 2kB ograniczenia w BASCOM demo, ale udało się..pełen kod miał 1900 z hakiem, raptem jeden rejestr przesuwny, jeden preskaler i od 0.5 do 20MHz pomiar, każde wywołanie sprzętowe dokładnie policzone ile cykli, dokładna korekcja cykli czekających przy wywołaniu przerwania itd..problem z dzieleniem rozwiązany przez tablice..jakoś dało rade ale drugi raz bym tak nie kombinował.

Cały cykl moich wypowiedzi odnosi się głównie do stwierdzenia, które padło w poście #171 - więc drogi skoti, należy rozróżnić providera narzędzi programistycznych wszelkiej maści oraz wpływu jego większej bądź mniejszej palety środków technicznych, presonalnych etc (wystarczy porównać w tej materi z mojego podwórka np MS, Oracle czy chociażby dla przykładu Embarcedero i ich support - tak zgadzam się z Tobą, że im więcej środków pieniężnych tym ich produkty są ogólnie rzecz biorąc lepsze) od producentów oprogramowania korzystającego z tych narzędzi. W przypadku tych drugich pracownikami są gorzej lub mniej 'zmotywowani' programiści o róznym stopniu zaangażowania w optymalne rozwiązanie problemu za pomocą narzędzi stawiając na optymalny efekt końcowy a nie na 'łatwość' jego osiągnięcia.

Nie zapominajcie że nVidia rządzi w segmencie kart profesjonalnych (Quadro) i chyba obliczeniowych też (Tesla). Oprogramowanie do takich kart kosztuje fortunę, a skoro nVidia ma więcej klientów to też więcej kasy z tego.

AMD rządzi tylko w segmencie zwykłych kart graficznych ukierunkowanych na gry, a tutaj nie ma jakiejś wielkiej potrzeby na oprogramowanie inżynieryjne.

Miejmy nadzieję, że sytuacja (tzn wsparcie dla programistów) się poprawi wraz z nadejściem Caymana, bo optymalizacja na 4-Way jest dużo prostsza niż na 5-Way.

Pod CUDA napisano wiele fajnych rzeczy, ale produkty nVidia-only raczej nie uzyskają wielkiej popularności u pojedynczych konsumentów. CUDA dobrze chodzą tylko na GeForcach, a OpenCL działa OK także na Radeonach czy procesorach typu x86. Niedługo zapewne OpenCL zagości/ już zagościł na PowerPC, ARM, SPARC, Cell itp itd

@Wibowit - na PPC IBM już implementację z tego co wiem zrobił, to samo ARM (zarówno proce jak i grafiki). Teraz intel zrobił alpha sdk ale tylko dla penryn wzwyż jeśli mnie pamięć nie myli. Toshiba dla Suprsengine też już chyba coś wypuściła. O SPARC nic nie wiem. TI chyba też zamierza(ło), ale czy coś z tego będzie to nie wiem.

Produkty nVidia only właśnie zyskują ostatnio sporą popularność i zwiększają przez to klientów ich kart (jeśli jakiś grafik chce renderować na karcie wybierze nVidię (Quadro najczęściej nie jest mu potrzebne więc kupi GeForce który jest dużo tańszy), jeśli gracz chce mieć daną grę wydajniejszą i z efektami fizycznymi, a obsługuje ona PhysX, to wybierze kartę nVidii...), a co do OpenCL to ostatnio widzę, jak właśnie powstaje sporo programów CUDA, które zastrzegają sobie, że wersję OpenCL, będą robić, jak wydajność OpenCL i CUDA będą porównywalne na kartach nVidii (bo one tylko w tych projektach się liczą, bo karty amd mają bardzo niską wydajność, więc odpadają, a im zależy na jak największej wydajności, więc z CUDA vs OpenCL wybierają CUDA). OpenCL wyprze CUDA - to jest pewne, a implementacje już są dla kart AMD, nVidi czy Via (intel będzie miał razem z sandy bridge), procesory x86 (amd, intel i wiele implementacji firm produkujących software, a nie hardware), PPC ma od IBM (razem z optymalizacjami dla jednostek wektorowych Cell), ARM ma implementacje od ARM (dla CPU i GPU), ale też od Samsunga czy Creative (właściciela ZiiLabs), ale to przejście na OpenCL nie będzie natychmiastowe i nie stanie się to niedługo jak mówisz, a właśnie raczej będzie to dłuższy okres czasu, bo póki co to Cuda zyskuje dalej popularność.


Łatwiej powiedzieć po prostu, że wymaga SSE4.1 (pewnie od tej wersji nie przypadkowo, bo SSE4.1 nie działa na prockach AMD, więc Intel zapewnia sobie, że ich implementacja zoptymalizowana pod SSE, będzie działać tylko pod ich prockami, a klienci AMD niech używają ich implementacji).

Podejrzewam że w wypadku OpenCL vs CUDA i PhysX powtórzy się sytuacja HD-DVD i Blu-Ray, nie ważne że wygrało gorsze(brak kompatybilności wstecznej, licencja jednej firmy) Sony musiało wygrać tą batalie za wszelką cene bo na tym oparli strategie, mieli zaplecze sporej ilości wytwórni i PS3! którego nośniki i funkcjonalność byłaby dużo mniejsza bez wsparcia filmów, obecnie 3D itp.

NVidia ze względu na strukture przychodów(najprawdopodobniej) musi walczyć o CUDA bo przepadnie z kretesem, mają asekuracje w postaci obsługi OpenCL ale wówczas mieli by sporą konkurencje i kolejna wpadka ala Fermi skończyła by się jej upadkiem. (utratą płynności finansowej - to wcale nie jest tudne do osiągnięcia)

I w obu przypadkach nie chodzi tylko o sprzęt ale o zyski ze sprzedaży licencji - czy się stoi czy się leży kaska się należy.

Od 30% do 50%
To znaczy, że realnie 25%
A to znaczy, że wystarczy na starego Fermiego. Na Fermiego bez Fermiego (GTX580) nie da rady.

Blu-Ray wygrał pomimo wsparcia HD-DVD przez wielkie firmy i korporacje, właśnie ze względu, że był lepszym rozwiązaniem (wsteczna kompatybilność nie jest ważna, a ważna jest pojemność - tym bardziej, jeśli myśli się o filmach 3D w dużej rozdzielczości).


Nvidia rozwija dalej CUDA, bo ten może rozwijać tak szybko jak chce dzięki czemu jest wydajniej i lepiej (dlatego ich wybierają), a OpenCL cierpi na bolączkę otwartego standardu gdzie zmiany muszą pasować też innym (tak samo jak z C++0x gdzie wyleciało z niego wiele rzeczy które autorzy C++ koniecznie chcieli w nim mieć (bo zmiany nie wszystkim przypadły do gustu)). Nvidia od początku bardzo wspiera OpenCL i praktycznie jest jego współtwórcą razem z Apple (Apple rozpoczęło pracę w oparciu o CUDA, a dokończył wiceprezes nVidii (prezes Khronos Group) - nie sam, ale on zarządzał jego rozwojem). nVidia wydała pierwsza sdk i sterowniki jak i podręczniki (razem z takimi jak przejść na OpenCL z Cuda), oraz zachęcała wszystkich programistów do przejścia na OpenCL lub CUDA niezależnie od wyboru (bo to nie AMD jest konkurencją nVidii, a nVidia widzi konkurenta w obliczeniach w obliczu intela i chce pokazać jak słabe są ich procki w obliczeniach - nie ważne z jakim api)

http://www.engadget.com/2005/09/19/blu-ray...ion-s-division/
http://www.pcworld.com/article/142584/hd_d..._a_history.html
Za HD-DVD stało Universal i Paramount Pictures
Za Blu-Ray stała większa ilość wytwórni(Warner Bros, Fox, Sony, Buena Vista) i większa ilość producentów sprzętu a to bardziej znaczące..co znaczy stała skoro jeszcze produkcja nie ruszyła na dobre? Poprostu wpisali się na członków by nie płacić haraczu później.

Masz racje - bezkompromisowa pojemność do 100GB zamiast 30GB i możliwość płytek RW - ale jaki to ma sens gdy nośniki optyczne i tak umierają? 3D rzeczywiście robi furore - czy reakcje rynku są inne? Poza tym co niby stało na przeszkodzie wypuszczać filmy 3D na HD-DVD
Teraz kodeki sa tak zaawansowane że na zwykłej płycie DVD zmieści się ten sam film w jakości HD a oba standardy wspierały to kodowanie
HD-DVD byłoby świetnym pomostem, przede wszystkim nie zmuszał do wymiany sprzętu, a jedynie dawał bonus w postaci HD jeśli się takiej zmiany dokonało, ponieważ mógł zawierać warstwe danych do odczytania na zwykłym DVD(bodaj na drugiej stronie nośnika). Po drugie dużo bardziej przyszłościowe i sensowne byłoby rozwijanie FMD, które dobre 10 lat temu ujrzało światło dzienne w prototypach, nie wymagało ani drogiego lasera ani dużych kosztów.

A tak przez pare lat będą nas karmić Blu-Ray podobnie jak karmią TN'kami LCD, zauważ że Blu-Ray ma pewien problem z upowszechnieniem się z prostego powodu - brak kompatybilności wstecznej. Wejdź do pierwszej lepszej wypożyczalni - półki niemal świecą pustkami bo właścicielowi nie opłaca się kupować dwa razy tego samego filmu gdy większość pożycza DVD..półka Blu-Ray to drogi gips i niekoniecznie się zwracający. Za pożyczenie HD-DVD w zasadzie nic nie trzeba by było dopłacać i mieć extra opcje dodatkowe w przypadku posiadania odtwarzacza...

teraz widzsz jaki interes mają w tym producenci..chcą doić nas jak krowy i tyle

Płyty HD-DVD były tańsze w produkcji, Blu-Ray wymaga specjalnych polimerów, prawdopodobnie również sam odtwarzacz czyniąc bardziej skomplikowanym i droższym. Głownym promotorem HD-DVD była Tohsiba współtwórca procesora konsoli PS3 - to tez ciekawe. A Sony również było członkiem HD-DVD promotion group podobnie jak Nvidia OpenCL - gdyby tego nie zaczęto tworzyć ktoś stworzyłby bez pieczy Nvidii



Po co stworzono OpenCL bóg raczy wiedzieć..pewnie dla powiększenia popularności obliczeń GPGPU, może dlatego że większość centrów obliczeniowych pracuje na unixach(CUDA jest tam obecne?) i ludzie je posiadający wolą to napisać niż zapłacić, trudno się w to zagłębiać bez wiedzy - nie mam takiej, tylko przypuszczenia.
Skoro było CUDA dlaczego osoba która stałą na czele tych prac tego poprostu nie otworzyła?

Za Blu-Ray stali producenci sprzętu, a za HD-DVD producenci softu (np. Microsoft)... wygrało bo tak wybrali klienci (nikt nie chciał kupować HD-DVD), a wsteczna kompatybilność jak najbardziej jest - nie w standardzie, ale producenci sprzętu ją wprowadzili i bez problemu odtworzysz w odtwarzaczach BR filmy DVD, a nawet Video-CD czy CD-Audio (mimo, że nie jest to wymagane przez specyfikację BR to w praktyce każde urządzenie BR jest wstecznie kompatybilny).


To, że filmy normalne na BR zajmują bardzo często 16-24GB (w wersji 2d) i po prostu by się nie mieściły i trzeba by obcinać wszystkie dodatki.



OpenCL stworzono, aby rozpowszechnić obliczenia równoległe, które działałyby na wszystkim (nie tylko na CPU, jak OpenMP, czy inne biblioteki, nie tylko na nVidii jak CUDA...). Dodatkowo nVidia od lat atakuje Intela za jego monopolistyczne zagrywki i chce upokorzyć procesory Intela, a najlepiej to zrobi, jeśli ten sam kod będzie działać zarówno na prockach jak i kartach (a jak programy przejdą na OpenCL to ludzie będą kupować budżetowe procki, a gpu HiEnd (i to nie tylko do gier, a do wszystkiego)).

@skoti - z kompatybilnością to chodziło o coś innego. Wyobraź sobie, że masz odtwarzacz DVD, wychodzą produkcje na HD-DVD i BD...kupisz HD-DVD i w sporej ilości przypadków możesz odtworzyć typowy format DVD z tej płytki na swoim odtwarzaczu, a po wymianie sprzętu w przyszłości ten film w lepszej jakości z zakupionej wcześniej płytki BD tego nie miało.

Nie SAME filmy. A dodatki mnie nigdy nie interesowały.

Bez przesady... GPU to ciągle akcelerator obliczeń... obliczeń! I ciągle potrzebuje CPU, w wielu przypadkach konkret CPU Inaczej zawsze jakieś ograniczenie się znajdzie i wszystkie teraflopsy pójdą w .....

W dobie nadchodzącego upadku nośników optycznych obawiam się, że jednak może się okazać ważna.

W centrach obliczeniowych pisze się programy w assamblerze bezpośrednio na sprzęt bez korzystania z jednak spowalniającego zewnętrznego API.

Ważne, że interesują ludzi w USA i wytwórnie filmowe ;p.


GPU potrzebuje CPU tylko do przekazania mu danych do obliczeń (nawet ARM temu sprosta ;p), a to, że niektóre programy słabo się rozbijają na wątki to właśnie dla nich właśnie nie są dobre nowe drogie procesory - dla nich najlepszy jest stary P4 z jednym, rdzeniem, ale o dużej częstotliwości. To może sprawić w przyszłości, że procesor będzie albo mało ważnym podzespołem, albo będzie bardziej opłacać się kupić starsze procesory (dziś opłacalne są nowe procki, bo na nich przeważnie robi się obliczenia które można liczyć na wielu rdzeniach).




A widziałeś kiedyś taki kod, czy po prostu takie masz stereotypy? W centrach obliczeniowych i ogólnie w wydajnych programach używa się języka C (bo nawet jeśli miałbyś 100x więcej czasu na pisanie w ASM nie napisałbyś wydajniej niż dzisiejsze kompilatory takie jak ICC i GCC), a w ASM pisze się jedynie wstawki szczególne dla procesora (SSE/SPE/AVX), bo z ich wykorzystaniem nie poradzą sobie kompilatory (w C/C++ nie ma czegoś takiego jak wektory i ciężko zoptymalizować kod i zgadnąć kiedy będzie można użyć SSE) - w wypadku OpenCL taka optymalizacja jest dziecinnie łatwa bo w przeciwieństwie do C na którym się opiera ma dodatkowe typy wektorowe operujące na 4x zmiennych (np. float4, int4...) i implementacje takie jak Intela czy IBM wykorzystują łatwo całą moc CPU za pomocą SSE/SPE - nie trzeba ASM, bo wystarczy format na którym wszystkie operacje będą robione w takich rozszerzeniach.