AMD zaatakuje rynek kart graficznych dla profesjonalistów

1. Nie dziwię się (autor: Teriusz | data: 24/06/10 | godz.: 13:03)
   Zwłaszcza, że AMD współpracuje z twórcami platformy OTOY, gdzie takie karty świetnie się tam spiszą.
   
   http://www.otoy.com/
   
   
2. No moga se probowac (autor: morgi | data: 24/06/10 | godz.: 15:09)
   'In the GPU computing space, though, Nvidia has some noteworthy advantages, including ECC protection throughout its memory hierarchy, a true L2 cache, and what is probably a more robust set of development tools than those produced so far by AMD's Stream initiative. ECC support will likely open doors for Nvidia in large supercomputing clusters that AMD can't yet open, and the Fermi architecture's additional computing features could allow it to achieve higher performance and superior efficiency when running certain algorithms.'
   'the topic of software development tools for Stream-capable GPUs, Harrell sounded more confident than in our past forays into this area. She claimed AMD has a substantial investment in tools with third parties now, and she expects it to bear fruit in the form of product announcements later this year.'
   
   
3. Problem tkwi w czym innym (autor: MacLeod | data: 24/06/10 | godz.: 15:48)
   Mocny sprzet jest, ale support AMD dla klienta/firmy ktory kupil profesjonalne Fire, mozna zawrzec w jednym slowie "brak".
   Dokladnie tak samo jest w przypadku produkcji gier.
   
   
4. @MacLeod (autor: Promilus | data: 24/06/10 | godz.: 16:00)
   A po co producent kart zgodnych z API ma cokolwiek wspierać. Jest API, jest SDK - to ma wystarczać. Kiedyś wystarczało, teraz tylko firmy wyciągają lapska po kasę...a musisz wiedzieć, że producentów GPU i różnych architektur było więcej...był PowerVR, było 3DLabs, był Matrox, SiS, S3, Intel nawet. Tseng, 3dfx, rendition. I gdzie ta wielka współpraca producentów układów z producentami gier?
   
   
5. Mac (autor: piobzo | data: 24/06/10 | godz.: 16:04)
   co przez swoja wypowiedzi chciales powiedziec? co rozumiesz przez support?
   btw to samo mozna o NV powiedziec...
   
   a mialem 4 karty ati wiec zastanow sie co chcesz powiedziec... i czy aby nie naciagniesz prawdy...
   
   morgi z kad ten cytat? ni dawaj gowna na pokaz publiczny..
   
   
6. ... (autor: 7eki | data: 24/06/10 | godz.: 16:11)
   Nvidia całkowicie oddała się idei GPGPU i właśnie ma swoje pięć minut. AMD nie zrobiło w tej kwestii jeszcze nic konkretnego i paradoksalnie nadal pozostaje konkurencyjne wobec oferty nvidii, w teorii potencjałem architektury terascale nie zostawiając konkurencji żadnej przewagi, a w praktyce jednak ciągle utykając z powodu braku porządnego SDK i niechęci ze strony programistów wiernie oddanych standardowej architekturze. Nvidia podała im rękę. Teraz pora na AMD. Nie wierzę, że AMD mając ze sobą dużo większy bagaż doświadczenia i wsparcie ze strony ekipy odpowiedzialnej za x86 pozostawi ten rynek tylko na pastwę nvidii.
   
   
7. @7eki (autor: Promilus | data: 24/06/10 | godz.: 18:07)
   A o tym, że powstała już specyfikacja OpenCL 1.1 to słyszał? A o tym, że zarówno nv jak i amd pracują w grupie khronos nad tą specyfikacją to wie? OCL 1.0 powstało i obaj producenci je wspierają, teraz kolej na 1.1
   
   
8. Promilus (autor: morgi | data: 24/06/10 | godz.: 18:43)
   Nie rozsmieszaj ludzi, jest pelno otwartych potworkow i jakos nie wystarcza, chyba ze im ten 1% czy tez +/- blad statystyczny wystarcza. Jesli nie zostanie podane na tacy, a przynajmniej nie przestawione wymierne korzysci z zastosowania to nikt rozsadny nie ruszy palcem.
   piobzo
   Wez se wklej do wyszukiwarki, a tak lenistwo?
   http://techreport.com/discussions.x/19141
   
   
9. Dokłądnie (autor: Wedelek | data: 24/06/10 | godz.: 18:47)
   Otwarte standardy to przyszłość, która powinna zniszczyć ich zamknięte odpowiedniki dla dobra wszystkich. O ile świat byłby piękniejszy gdyby był jeden standard 3D a zamknięty PhysX nie istniał. Zresztą również DirectX nie jest dobry, bo działa tylko pod Windows... Jeśli ktoś tego nie czuje, to niech pomyśli co by było gdyby nie USB. 20m portów w budzie, a każdy dla zaledwie kilku producentów...
   
   
10. @morgi (autor: Promilus | data: 24/06/10 | godz.: 19:46)
    ja wiem że twój malutki móżdżek nie obejmuje takich zagadnień, ale OCL akurat:
    1. ma wsparcie gigantów
    2. przynosi wymierne korzyści
    Więc wkuj sobie do łba - nie pierdolić o czymś o czym zupełnie nie ma się pojęcia.
    
    
11. Promilus (autor: morgi | data: 24/06/10 | godz.: 20:36)
    Rozwin te korzysci, ja moge np. wymienic silnik graficzny ogl od idsoftware, normalnie gier na palca rak zmiesci...
    
    
12. niech walczy... (autor: Qjanusz | data: 24/06/10 | godz.: 22:21)
    bo na tym poletku akurat AMD odstaje od konkurencji.
    
    
13. @morgi (autor: Promilus | data: 24/06/10 | godz.: 23:00)
    zacznijmy od tego, że nie potrafisz rozróżnić nawet OpenCL od OpenGL (a pewnie i OpenVG).
    Korzyści OpenGL - gry z zaawansowaną grafiką nie tylko na vista/win7 ale również XP, 2003, 2000, Linux (opcjonalnie). Druga rzecz - nie trzeba czekać na kolejną rewizję API - można dokładać własne rozszerzenia do istniejącej specyfikacji. Tego w DX nie uświadczysz. Przy okazji - z OGL ES na zwykłego w miarę szybko przejdziesz, a DX (i to nie do końca) jest tylko w xpudle - multiplatformowość to domena OGL, a nie DX. Jak widać twoje srutu tutu nic nie zmienia, każda gra która poszła na maca albo linux to choćby na PC była w DX to na tamtych platformach już nie. To samo telefony,, smartfony, palmtopy, konsole -- tam nie ma dx. Więc zastanów się pałko zanim wyskoczysz z gównianymi wnioskami.
    Teraz korzyści z OpenCL:
    1. można w razie czego wykorzystać samo CPU - użytkownicy CUDA nie mogą.
    2. działa na ibm power, Cell BE, x86, rv770, cypress, g80 wzwyż, czyli dużo więcej sprzętu niż C for CUDA czy icc - i to naraz
    3. świetnie skaluje wydajność wraz ze wzrostem ilości rdzeni czy urządzeń
    
    
14. @Promilus (autor: elecctro | data: 25/06/10 | godz.: 08:34)
    i pozamiatane.
    
    
15. @Promilus (autor: AmigaPPC | data: 25/06/10 | godz.: 09:54)
    Amen.
    
    
16. Promilus (autor: morgi | data: 25/06/10 | godz.: 10:21)
    Zyjesz w swiecie snu, najpierw ATi mialo CtM, podparte Brookgpu, a te na opengl, teraz przelawirowali na opencl, ktore w jasnym stylu wspieraja glownie producenci gpu, ale Nvidia ma i tak lepsza wydajnosc w CUDAcznosci. Teraz ktos wciska kit, ze crossplatformowka bedzie super deal, bo na wszystkim ma hulac, tylko jak to dziala topornie i nie ma jasnego sponsora. Wymieniles ogolniki, a ja chce zobaczyc konkretna korzysc, zysk, firme, ktora tlucze kase na tym, programy, narzedzia, a nie demka, syntetyki, ktore mozna uzyc,
    BTW.
    Co sie dzieje z ati i stream, gdzie kurde wsparcie dla ocl 1.1, gdzie te nowe achievementy, no chyba 'later this year', jeszcze maja czas, moze trza nowa serie wydac najpierw ;).
    
    
17. @morgi (autor: Promilus | data: 25/06/10 | godz.: 10:40)
    primo - gówno wiesz. Brook ma backendy do directx (hlsl), opengl (glsl) i właśnie cal - nie sprawdzałeś to nie pierdol. Wystarczy ściągnąć, skompilować narzędzia a nie pierdolić bez ładu i składu jak połamany
    secundo - nie pamiętam by apple, ibm, freescale itp. to byli producenci gpu - a aktywnie wspierają OCL.
    tertio - wymieniłem to co uważałeś że tego nie ma, to nie ogólniki tylko konkrety - to że twój kurzy móżdżek tego nie jest w stanie ogarnąć to nie moja wina.
    quarto - gdzie to wsparcie nv dla ocl 1.1? Przecież debilu dopiero specyfikację ustalili!
    
    
18. @up he he (autor: Qjanusz | data: 25/06/10 | godz.: 11:25)
    "Teksańska masakra piłą mechaniczną" ;-)
    
    
19. Promilus (autor: morgi | data: 25/06/10 | godz.: 14:50)
    Same ogolniki, wymien choc kilka prosze ciebie, bo wsparcia to udzielaja na mityczna skale i gdzie to uzycie na crossplatformie.
    ati nie nadaje sie poki do powaznej rozgrywki, niestety CUDAcznosc jedyny partner pod uwage, jak mozna mierzyc sie na stream, nie ma ECC to fail...
    
    'Unlike AMD's more wait-and-see attitude, NVIDIA appears to be fully committed to bringing error protection to GPU computing. According to Andy Keane, general manager of the GPU computing business unit at NVIDIA, it is not a matter of if, but when. From his point of view, ECC memory is a hard requirement in datacenters. "We have to respond to that by building that kind of support into our roadmap," Keane said unequivocally. "It will be in a future GPU." '
    
    
20. cd. (autor: morgi | data: 25/06/10 | godz.: 14:55)
    Nvidia i ocl 1.1
    hehe w najnowszym sdk i oczywiscie developer drivers, no ale myslalem, ze o tym wszyscy wiedza.
    http://www.ozone3d.net/...gtx480_gpucapsviewer.jpg
    
    
21. @morgi (autor: Promilus | data: 25/06/10 | godz.: 14:57)
    NV też nie ma ECC, ma tylko gównianą namiastkę. Gdyby ecc można było tak prosto emulować w zwykłej pamięci to intel i amd nie bawiliby się w 72 bitowe moduły ECC dużo droższe od zwykłych, a jak widać inaczej się nie da. Więc jak już wcześniej napisałem NIE PIERDOL.
    Gdzie to nie-mityczne wsparcie dla CUDA? Gdzie te tony akcelerowanych programów i narzędzi? Nie ma? Wszyscy wielcy mówią wait and see? Nooo, to już wszystko jasne. Jesteś hipokrytą próbującym wpierdalać się w tematy o których nawet szczątkowej wiedzy nie posiadasz.
    
    
22. @morgi (autor: Promilus | data: 25/06/10 | godz.: 14:58)
    developer drivers to tak jak preview u amd więc nie czaruj.
    
    
23. Promilus (autor: morgi | data: 26/06/10 | godz.: 12:11)
    Namiastki sa, oni dobrze wiedza, ze w Fermi musieli poprawiac wiele, zeby dorownac Intelowi i jak wyszlo z tdp wszyscy wiedza. Mimo wszystko dedykacja jak mialo sie Nehalem vs. Gt200, roznice nie sa takie duze, a doswiadczenie i mozliwosci na przyszlosc moga sie nieco roznic.
    http://delivery.acm.org/...61&CFTOKEN=50783980
    'In this paper, we analyzed the performance of an important set
    of throughput computing kernels on Intel Core i7-960 and Nvidia
    GTX280. We show that CPUs and GPUs are much closer in performance
    (2.5X) than the previously reported orders of magnitude difference.
    We believe many factors contributed to the reported large
    gap in performance, such as which CPU and GPU are used and
    what optimizations are applied to the code. Optimizations for CPU
    that contributed to performance improvements are: multithreading,
    cache blocking, and reorganization of memory accesses for SIMDification.
    Optimizations for GPU that contributed to performance
    improvements are: minimizing global synchronization and using
    local shared buffers are the two key techniques to improve performance.
    Our analysis of the optimized code on the current CPU
    and GPU platforms led us to identify the key hardware architecture
    features for future throughput computing machines – high compute
    and bandwidth, large caches, gather/scatter support, efficient synchronization,
    and fixed functional units. We plan to perform power
    efficiency study on CPUs and GPUs in the future.'
    
    
24. ad. (autor: morgi | data: 26/06/10 | godz.: 12:16)
    Nie wal niedowiarka, pod CUDAcznosc troche tego jest.
    http://www.nvidia.pl/object/cuda_app_tesla.html
    
    
25. Oooooooooooooo (autor: AmigaPPC | data: 27/06/10 | godz.: 00:22)
    to Intel ma GPGPU ????
    
    O ile wiem to nie ma nawet GPU bez GP - więc komu niby nVidia ma dorównać ????
    
    
26. Wszystko to raport PRACE (autor: morgi | data: 27/06/10 | godz.: 18:39)
    Dla fanow moze za ciezki kaliber, ale tam sa oczywiste fakty, homogeniczne platformy sa ok, daleko z tylu heterogeniczne, podobnie jak ich wsparcie programistyczne, polecam raport.
    'Technical Report on the Evaluation of Promising Architectures for
    Future multi-Petaflop/s Systems'
    
    'the performances
    of the accelerators are highly dominated by the host-accelerator bandwidth. Presently
    none of the accelerators are directly connected to the processor fabric, i.e., HyperTransport
    for AMD processors and Quickpath for Intel processors. If that would be the case, the
    bandwidth would be much more favourable and the node memory would be directly accessible
    by the accelerators which would reduce the transfer overhead dramatically. One may expect
    this to occur in the near future, say 1 to 2 years.
    The memory bandwidth within a node and, where appropriate, the host-accelerator transfer
    speed from a node are one of the decisive factors for the performance of a node or nodeaccelerator
    combination. Where the internal node bandwidth can be measured in the 20 GB/s
    realm and a sub-μs latency, for instance, latencies for host-accelerator data transfers are in the
    hundreds of μs (see, e.g. the host-accelerator bandwidth experiment on the Petapath system)
    while the effective bandwidth will be significantly lower than the nominal bandwidth provided
    by PCIe Gen.2, i.e., 8 GB/s except for very large block data transfers.
    However it is a matter
    of fact the vast majority of application codes is written under the assumption of homogeneous
    cores. Re-writing these codes from scratch is not feasible since the development time for
    many large-scale applications is in the range of decades/ten years and more. So in order to
    keep application codes maintainable in the presumably hybrid multi-Petascale era, programming
    models are needed which are able to handle the heterogeneity of compute cores while
    keeping the impact on the programmer side as low as possible.
    New codes could be written using new languages
    that allow transparent use of different accelerators (e.g., OpenCL, StarSs, Rapidmind). However,
    the survey on new languages carried out in PRACE found that most of these languages
    and tools are still too immature to be used in an HPC environment.
    Applications using only SP floating-point arithmetic can experience a substantial
    speedup. But also for this case any performance boost is very much dependent on the actual
    match of the characteristics of the algorithm and the device. The programmability is still not
    ideal, especially when aiming at very high performance and non-trivial codes.
    Finally it is important to be aware that the power consumed by today accelerators is significant
    even when they are idle. Therefore mechanisms to reduce the idle power of these devices
    to a large extend are of major importance for future accelerated systems.
    
    
27. ... (autor: Qjanusz | data: 28/06/10 | godz.: 11:06)
    i zasmażka...
    ucieczka na wstecznym...
    
    beton zmienił formułę. To już trzecia chyba :-)
    
    
28. hehehe (autor: Xymeon_x | data: 28/06/10 | godz.: 14:46)
    Promilus pozamiatał TROLLa a ten w rewanżu wkleił tekst po angielsku którego nie rozumie i nir potrafi przetłumaczyć..... jak zwykle zresztą kiedy ktoś zagoni go w kozi róg i udowodni całkowitą niewiedzę..... Morgi mistrz ctrl+C... ctrl+V bez zrozumienia LOL
    
    
29. @morgi (autor: Promilus | data: 28/06/10 | godz.: 15:52)
    cienki leszczu - nie pierdol o czyms czego nie rozumiesz
    Z listy aplikacji cuda to co chwilę widzę matlab plugin, i co ciekawsze ciągle ten sam. Jak wejdziesz w cuda zone masz dokładnie to samo...obrazków 100 z czego jest różnych tylko 20. Na cuda jest kilka specyficznych produktów (renderery, jakiś soft do geologio-sejsmologii <olej, gaz> ... i niewiele więcej) - a to nie tony oprogramowania i duża jego dostępność.
    Co do różnic wydajnościowych to kolesie trochę po bandzie pojechali. Prawda jest taka, że różnice wydajności przy zoptymalizowanym kodzie są nie tak znaczące (collatz conjecture, crunch3r, slicker, gipsel - powstała aplikacja na gpu to była wielokrotnie szybsza od tej na cpu, potem zajęli się optymalizacją tej na cpu i różnica stopniała...ALE... jak zoptymalizowali to na GPU to znów różnica wzrosła). Różnica jest mała w przypadku : gpu unoptimized a cpu optimized! A żaden developer nocy zarywał nie będzie optymalizując kod CPU gdy może szybciej napisać lepiej działający program bez dłubania tyle że na GPU. Tu się liczy tylko efekt końcowy i kasa. W momencie gdy autor vraya siedziałby nad wstawkami asm do renderera to kolesie z mentala robiliby kolejną wersję dla gpu mając ładną premię od nv - nie wspomnę że producenci dużych programów wykorzystujących owe silniki renderujące wybraliby do kolejnych wersji szybszy i tańszy. czyli akcelerowany przez GPU.
    
    Co do platform heterogenicznych to również jesteś w błędzie, w końcu roadrunner to konkretny heterogen! I jakoś długo był na czele! A nawet teraz wyparł go nebulae z teslami...3 konkretne heterogeniczne platformy w top10 a ty pierdolisz że są daleko z tyłu. Co za nieudacznik.