AMD zaatakuje rynek kart graficznych dla profesjonalistów
Autor: Wedelek | źródło: Nordic Hardware | 12:03
(29)
W ostatnich dniach na łamach TPC możecie przeczytać całe mnóstwo aktualności związanych z AMD lub Nvidią, co jest wynikiem prawdziwej ofensywy tych dwóch konkurujących ze sobą firm. Do owej konkurencji firma z Sunnyvale postanowiła dodać jeszcze więcej pikanterii ogłaszając, że ma zamiar mocno utrudnić życie kartom konkurenta na rynku urządzeń profesjonalnych. Trzeba przyznać iż jest to nie lada wyzwanie gdyż po pierwsze to Nvidia dotąd o wiele częściej wygrywała w walce swoimi układami Tesla o serca klientów niż AMD, a po drugie architektura Fermi pomimo iż miała niezbyt udany debiut w 40nm procesie produkcji, to jednak od początku była projektowana z myślą o GPGPU.
Zadanie jest więc dość trudne jednak producent Radeonów nie zamierza się poddawać i na pole bitwy wysyła dwa swoje akceleratory z serii FireStream oznaczone numerkami 9370 i 9350. Mocniejsza z kart graficznych (z wyższym numerkiem) jest wyposażona w 4GB pamięci RAM typu GDDR5 i charakteryzuje się wydajnością 528 Gigaflopów w przypadku obliczeń podwójnej precyzji i 2,64 teraflopów w pojedynczej precyzji zużywając przy tym maksymalnie 225 wat. AMD FireStream 9350 natomiast oferuje 2GB pamięci GDDR5 i 400 Gigaflopów przy obliczeniach podwójnej precyzji oraz 2,0 teraflopów w pojedynczej precyzji. Pobór mocy to maksymalnie 150 wat. Oba układy są zgodne z jedenastymi bibliotekami Microsoftu -DirectX oraz DirectCompute. Czerwoni "wojownicy" od AMD zadebiutują w trzecim kwartale 2010 roku. Ich cena pozostaje tajemnicą.
K O M E N T A R Z E
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ą.
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.'
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.
@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?
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..
... (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.
@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
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
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...
@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.
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...
niech walczy... (autor: Qjanusz | data: 24/06/10 | godz.: 22:21) bo na tym poletku akurat AMD odstaje od konkurencji.
@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ń
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 ;).
@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!
@up he he (autor: Qjanusz | data: 25/06/10 | godz.: 11:25) "Teksańska masakra piłą mechaniczną" ;-)
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." '
@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.
@morgi (autor: Promilus | data: 25/06/10 | godz.: 14:58) developer drivers to tak jak preview u amd więc nie czaruj.
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.'
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ć ????
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.
... (autor: Qjanusz | data: 28/06/10 | godz.: 11:06) i zasmażka...
ucieczka na wstecznym...
beton zmienił formułę. To już trzecia chyba :-)
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
@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.
D O D A J K O M E N T A R Z
Aby dodawać komentarze, należy się wpierw zarejestrować, ewentualnie jeśli posiadasz już swoje konto, należy się zalogować.
W ostatnich dniach na łamach TPC możecie przeczytać całe mnóstwo aktualności związanych z AMD lub Nvidią, co jest wynikiem prawdziwej ofensywy tych dwóch konkurujących ze sobą firm. Do owej konkurencji firma z Sunnyvale postanowiła dodać jeszcze więcej pikanterii ogłaszając, że ma zamiar mocno utrudnić życie kartom konkurenta na rynku urządzeń profesjonalnych. Trzeba przyznać iż jest to nie lada wyzwanie gdyż po pierwsze to Nvidia dotąd o wiele częściej wygrywała w walce swoimi układami Tesla o serca klientów niż AMD, a po drugie architektura Fermi pomimo iż miała niezbyt udany debiut w 40nm procesie produkcji, to jednak od początku była projektowana z myślą o GPGPU.