Twoje PC  
Zarejestruj się na Twoje PC
TwojePC.pl | PC | Komputery, nowe technologie, recenzje, testy
M E N U
  0
 » Nowości
0
 » Archiwum
0
 » Recenzje / Testy
0
 » Board
0
 » Rejestracja
0
0
 
Szukaj @ TwojePC
 

w Newsach i na Boardzie
 
TwojePC.pl © 2001 - 2024
Środa 27 kwietnia 2011 
    

Gość z ARM prelegentem na konferencji AMD


Autor: Wedelek | źródło: Xbit Labs | 12:15
(78)
Na tegorocznej imprezie Advanced Micro Devices "Developer Summit (AFDS), która odbędzie się w połowie czerwca bieżącego roku swój wykład będzie mieć gość z konkurencyjnej firmy ARM. A będzie to nie byle kto, bo sam Jem Davies, który wygłosi prelekcję na temat OpenCL i rozwoju tego otwartego standardu w przyszłości. Według innego przedstawiciela ARM w tej kwestii spojrzenie na przyszłość w wykonaniu obu firm jest identyczne, a to właśnie otwarte i wieloplatformowe (CPU i GPU) biblioteki są przyszłością branży IT.

John Taylor z ARM zauważa że przyszłość należy do układów będących połączeniem GPU i CPU, jak SoC ARM oraz APU AMD, przy czym wiodącą częścią w tym przypadku będzie właśnie rdzeń graficzny. Taylor zauważa, że potencjał Llano, które dysponuje mocą obliczeniową 400 do 500GFLOPS jest znacznie wyższy niż w przypadku standardowych CPU Intela i AMD, które mają wydajność rzędu 100GFLOPS.

Wspominany na początku newsa prelegent Jem Davies to vice prezydent w firmie ARM, odpowiedzialny za nowe technologie i ich wdrażanie w produktach tej firmy.



 
    
K O M E N T A R Z E
    

  1. ocho... (autor: Seba78 | data: 27/04/11 | godz.: 13:59)
    czyżby to zaczątek pewnej koalicji? robi się ciekawie. czyżby mieli "sposób na intela"?
    Wygląda na to, że znaleźli słaby punkt rywala. Intel chyba jeszcze bardziej zapała chęcią kupienia nVidia.


  2. @Seba (autor: Promilus | data: 27/04/11 | godz.: 14:19)
    Koalicja jest już od jakiegoś czasu, a nazywa się KHRONOS GROUP.

  3. uuu, Khronos Group (autor: daver | data: 27/04/11 | godz.: 14:26)
    czyli OpenCL pod strzechami w 2048, rowno dwa lata przed rokiem Linuksa na desktopie ;)

  4. Taa, KHRONOS GROUP (autor: pomidor | data: 27/04/11 | godz.: 14:51)
    Organizacja znana z tego że przesadnie długo tworzy niszowe standardy, z których większość jest nie znana ani stosowana. Działają podobnie jak partia komunistyczna - wszyscy są za, każdy osobno przeciw. Później wychodzi z tego takie wsparcie jak OpenGL u ATI lub OpenCL u Nvidia.
    Co do APU, to AMD może sobie trajkotać o GPGPU, tyle że z tego wieloletniego trajkotania powstało raptem kilka eksperymentalnych aplikacji. Ale przyszedł intel z QuickSync w SB, i 80% tych aplikacji już nie ma przyszłości, razem z OpenCL i APU.


  5. @pomidor (autor: Promilus | data: 27/04/11 | godz.: 15:26)
    "Organizacja znana z tego że przesadnie długo tworzy niszowe standardy"
    Kłamstwo na kłamstwie. Od 2008 do teraz masz OGL 3.0, 3.1, 3.2, 3.3, 4.0 i 4.1 + odpowiednie OpenGL ES i WebGL, ale tego pałka zakuta nie zrozumie. Tego, że OGL ES jest w tabletach, smartfonach i konsolach przenośnych też nie... Niszowe rozwiązania, kutwa...
    OpenCL działa z kolei w środowiskach Linux, Windows, MacOS X na procesorach x86, POWER, Spursengine, Cell BE, ARM oraz GPU nvidia, amd oraz PowerVR. To tak dla kontrastu DirectCompute Vista&Win7 only oraz CUDA nvidia only. Brawo. Co za zaślepienie fanboyów.


  6. @pomidor (autor: trepcia | data: 27/04/11 | godz.: 15:29)
    "Organizacja znana z tego że przesadnie długo tworzy niszowe standardy, z których większość jest nie znana ani stosowana."
    Buahaha. Dawno się tak nie uśmiałem.
    Powiedz - jesteś taki głupi naprawdę czy tylko udajesz?


  7. Bardzo dobra postawa firmy AMD (autor: Qjanusz | data: 27/04/11 | godz.: 15:45)
    Ukierunkowanie na wspieranie otwartych standardów, oraz miła współpraca z konkurencją.
    Nieoceniona rzecz dla rynku i dla konsumentów.

    PestkoGłowe warzywa zostawcie w spokoju. Oni tak mają i po prostu tak muszą...


  8. @trepcia (autor: rainy | data: 27/04/11 | godz.: 15:52)
    Istnieje uzasadnione przypuszczenie, iż jest to pierwszy wariant, gdyż raczej trudno spodziewać się cudów po pomidorze.

  9. skąd się bierze to jełopstwo? (autor: Seba78 | data: 27/04/11 | godz.: 15:55)
    kto to kurwa jest ten pomidor?

    sytuacja zdaje się być ciekawa. Jak się okazuje, nigdy nie można być pewnym swojej przewagi. W jednej chwili przypadkowy wynalazek, alians, standard może odwrócić ukąłd sił na szachownicy. Oczywiście intel wyda każdą kasę aby nie dopuścić do tego lub stworzyć konkurencyjne standardy. Przyjemnie obserwować zmagania:) Szkoda tylko, że tak powoli to się dzieje:)


  10. @Seba78 (autor: Qjanusz | data: 27/04/11 | godz.: 16:05)
    intel wydał wagony pieniędzy i mnóstwo wysiłku żeby stworzyć coś na swoją modłę. Wspomnę chociażby:
    - EPIC
    - BTX
    - alians z RamBus (yebany i cwaniacki intel miał dostawać dolę od każdej sprzedanej kosteczki BusRamu)

    Pamiętaj, dobre rzeczy dzieją się wolno, natomiast gówniane upadają w mgnieniu oka.


  11. @Promilus (autor: pomidor | data: 27/04/11 | godz.: 16:15)
    Na stronie khronos jest 12 standardów, z czego 3-4 są w szerszym użyciu. Sztandarowe OpenGL i OpenCL zawsze powstawały po DX i CUDA. Jeżeli chodzi o używanie do DX ma 95% grafiki 3d, zaś CUDA 95 % GPGPU. Tak więc nie wysilaj się na wymienianie marginesu sprzętowo - software, bo to niczego nie zmienia. Komórki to inna sprawa, tu jest mowa o PC.

    @Seba78
    Pewnie dzisiaj jeszcze Cię ojciec nie prał.


  12. Pomidor, głupiś, oj głupiś... (autor: Kenjiro | data: 27/04/11 | godz.: 16:19)
    Właśnie stwierdziłeś, że 95% wszystkich urządzeń to pecety z Windowsem. Brawo, po prostu brawo. Idź, stuknij dyńką w ścianę, może ci pomoże, bo nic bardziej wysublimowanego nie da rady.

  13. @Promilus (autor: Qjanusz | data: 27/04/11 | godz.: 16:20)
    he he.... widzisz jak Ci pomidorek wybiórczo pestki powybierał? :D

  14. @pomidor (autor: Promilus | data: 27/04/11 | godz.: 16:28)
    "Sztandarowe OpenGL i OpenCL zawsze powstawały po DX... "
    Tiaa... primo jak istniał OpenGL to Gates sikał w majtki bo jego wczesne DXy do niczego się nie nadawały. Narzucili tempo przy okazji DX8, ale wtedyy OGL był pod opieką ARB, a nie KHRONOSa. Odkąd się nim zajmuje KHRONOS to OGL rozwija się szybciej niż DX.
    "Jeżeli chodzi o używanie do DX ma 95% grafiki 3d,"
    Bujda na resorach. Jeśli się ograniczysz tylko i wyłącznie do Windowsa to może prawie trafiłeś... może. To samo jeśli chodzi o twoje pitolenie o CUDA.


  15. @pomidor (autor: rainy | data: 27/04/11 | godz.: 16:30)
    Nie kompromituj się bardziej niż musisz: OpenGL jest starszy niż Direct X i nie jest przywiązany do "jedynie słusznej" platformy.

  16. Promilus (autor: daver | data: 27/04/11 | godz.: 16:52)
    "Tiaa... primo jak istniał OpenGL to Gates sikał w majtki bo jego wczesne DXy"
    I tu pies pogrzebany. Co zrobilo SGI? Dalo sie udupic przez MS, co pozniej zrobilo KG, gdy razem z XP udupil OGL? NIC! Takie fundacje maja sile przebicia bliska zeru, wiec nic tu sie nie zmieni. Role ARM tu jeszcze rozumiem, ale AMD? Widac sa tak ciency, ze musza sie posilkowac czym sie da, nawet potencjalnym konkurentem. Oni nawet nie potrafia porzadnie wspierac "wlasnych" standardow, vide OpenGL na Linuksie. Dla przykladu: Mozilla blacklistowala wszsytkie karty, z wyjatkiem NVIDIA dzialacymi na blopie. Long story short, snijcie dalej.

    Seba78, Intel nic nie musi wydawac, MS jest od tego. A w super kompach ma x86, czyli Larrabee, czy jak to sie tam teraz zwie.


  17. @daver (autor: Promilus | data: 27/04/11 | godz.: 17:13)
    OGL dopiero od 2006r. jest pod kontrolą KG więc nie wiem kurka czego oczekujesz?
    "z wyjatkiem NVIDIA"
    Z wyjątkiem nv na określonych sterach. I ładnie się im to czkawką odbiło bo Chrome ma stabilniejszy WebGL, przechodzący więcej testów i do tego szybszy. Hueh. I działa na radeonach, i działa na geforce. Żeby było śmieszniej opensource drajwery mają GLES wklepanego więc leci obsługa use-gl=egl :) Tak samo jak na kartach OGL4.1; Żeby było całkiem śmiesznie na XP FF4 wcale bezpośrednio nie korzysta z WebGL na GLES tylko i wyłącznie w soft. emu :P Czy to Radeony, czy GeForce. Taaaa...


  18. i co sie zmienilo w adopcji OGL (autor: daver | data: 27/04/11 | godz.: 17:47)
    od 2006?
    To, ze Google zrobilo implementacje, ktora nie "odlania" zbugowanych sterow nie usprawiedliwia AMD.

    Otwarte maja smieszna wydajnosc (chyba dopiero R600, czli antyk zbliza sie wydajnosciowo)... wiec sobie daruj.
    http://www.phoronix.com/...d_r600g_14apr&num=1


  19. @daver (autor: Promilus | data: 27/04/11 | godz.: 17:56)
    Może zanalizuj najpierw wykresy zanim rzucisz podobną bzdurę. R600g (sterownik do całej serii radeonów HD a nie HD2900) jest na poziomie 10-15% catalystów, to sterownik do R300 (9700-X1950) jest już na poziomie 80% catalystów a na nowym kernelu jest kilkanaście jeśli nie kilkadziesiąt % więcej. Openy z drugiej strony dużo lepiej wypadają na radeonach niż GF ze względu na udostępnioną dokumentację :) Zatem sobie daruj...
    "To, ze Google zrobilo implementacje, ktora nie "odlania" zbugowanych sterow nie usprawiedliwia AMD."
    Poczytaj dokładniej a nie wyrywkowo, wszystkie bez wyjątku stery są zbugowane. To, że nvidii są zbugowane mniej niż inne ich nie usprawiedliwia (idąc twoim tokiem myślenia). Masz widać jakiś uraz do AMD, nie wiem czemu... ale rozejrzyj się trochę i zbierz dostateczne info by w ogóle mieć szanse w dyskusji. Jak na dzień dzisiejszy piszesz prawie same bzdety.


  20. widzisz, (autor: daver | data: 27/04/11 | godz.: 18:06)
    pisalem z pamieci, czyli jest jeszcze gorzej.

    "Openy z drugiej strony dużo lepiej wypadają na radeonach niż GF ze względu na udostępnioną dokumentację"
    BUHHAHA, lepiej to wypada ale dla devow otwartych sterow (btw. udostępnioną NIEPELNA dokumentację). Uzytkownikowi ryba, chce mniec dzialajaca karte. Poza tym, o czym mowa, otwarte stery nie sa tworzone przez AMD.


  21. @daver (autor: Promilus | data: 27/04/11 | godz.: 18:09)
    Heh, oczywiście że nie PRZEZ AMD, ale z udziałem AMD. A jak chcesz bluzgać to sobie pobluzgaj po intelu od wielu lat aktywnie wspierającego MESA (teraz z Gallium3D).
    "udostępnioną NIEPELNA dokumentację"
    UVD nie musi być opisane, a oprócz niego nie ma nic co AMD zataja więc o co ci chłopie chodzi?


  22. może to początek jakiejś tam współpracy? (autor: Jarek84 | data: 27/04/11 | godz.: 18:12)
    http://www.eetimes.com/...to-drop-x86?pageNumber=0

  23. hehe (autor: morgi | data: 27/04/11 | godz.: 18:26)
    Moze to poczatek trudnej i nieuchronnej decyzji, x86 powinno zostac firmowym znakiem Intela, a firemka powinna isc w slady Nvidii i wybrac army, idealne rozwiazania jak chca brnac w taniosc i model fabless.

  24. x86 odchodzi do lamusa (autor: Qjanusz | data: 27/04/11 | godz.: 18:28)
    poważne firmy od softu i sprzętu przesiadają się na AMD64.

  25. #24 add (autor: Qjanusz | data: 27/04/11 | godz.: 18:42)
    i jeszcze słowo przypomnienia w kwestii jaka firma co powinna, w kontekście możliwości opracowywania standardów i nowych technologii:

    "Intel został więc zmuszony przez rynek do zaoferowania konkurencyjnych produktów zgodnych z AMD64."
    http://pl.wikipedia.org/wiki/AMD64


  26. morgi (autor: Gigant | data: 27/04/11 | godz.: 19:27)
    x86 jest znakiem Intela...
    x86-64 jest znakiem AMD...

    AMD powinno olać ARMa i dalej produkować to w czym są najlepsi... taki Bobcat miażdzy Cortexa A9 a co dopiero Buldożer ;)


  27. Promilus (autor: daver | data: 27/04/11 | godz.: 19:33)
    Udzial AMD dawno sie skonczyl, nikt z AMD ponoc nie macza w tym palcow.
    "UVD nie musi byc opisane", lol, wlasnie dlatego nie ma akceleracji avc vc-1. Wiec odpal kolejna gromnice i modl sie o akceleracje przez gallium, moze za rok, dwa.
    Pisze tylko to co sam wyczytalem od samych developerow, ktorzy wypowiadali sie na forum phoroniksa.

    Niczym nie roznisz sie od pomidora, z tym ze on chcac nie chcac ma sporo racji i oprocz OpenGL ES nic z w/w projektow nie jest "witalne". Reszta ma niepewna przyszlosc lub jest jak to slusznie zauwazyl pomidor "niszowa".


  28. gigant (autor: morgi | data: 27/04/11 | godz.: 19:39)
    x86 od Intela w dostawach to w tej chwili wartosc 30 billionow $, a firemka to niecale 3 kurczy sie huehue, x64 to jednocyfrowy zascianek.
    http://pc.watch.impress.co.jp/...cs/439/550/19.jpg


  29. @daver (autor: Promilus | data: 27/04/11 | godz.: 19:59)
    "wlasnie dlatego nie ma akceleracji avc vc-1"
    Kłamstwo! Gallium to XvMC i wspomaganie na shaderach (zamiast UVD), na fglrx jest dekodowanie przez VA API na UVD (XvBA).
    "Niczym nie roznisz sie od pomidora" A ty od Giganta albo sony gówno.


  30. morgi (autor: Gigant | data: 27/04/11 | godz.: 20:09)
    Raczej RISC się kurczy bo x86-64 ma z 70% rynku...

  31. gigant (autor: morgi | data: 27/04/11 | godz.: 20:19)
    Intel x86 rosnie, risc sie broni i moze i kurczy, napewno kurczy sie x64.
    Co do apu to komedyja, na co oni czekaja z tym wsparciem, podobno sprzedaja miliony chipow i nawet listy aplikacji nie podaja, tylko same belkotliwe okreslenia...my god
    'We began shipping Llano ... the most impressive processor in history, featuring a modern graphics architecture' - na jakiej podstawie taki tekst?
    'AMD and its partners pin a lot of hopes onto graphics capabilities of the A-series APUs. It is expected that the integrated graphics cores with up to 400 stream processors will offer performance that will by far exceed that of Intel Core i-series "Sandy Bridge" microprocessors and will thus attract attention of multimedia enthusiasts to the code-named Lynx desktop platform. In addition, AMD pins hopes onto compute capabilities of the integrated Radeon HD 6000-class graphics engine as well as applications that can be accelerated by stream processors in order to offer higher performance than competing offerings in general non-gaming applications.'
    wiazanie nadzieji ich nie wykarmi, a gdzie konkrety, aaa tak pogadaja na konferencji o ogolnikach.


  32. Promilus (autor: daver | data: 27/04/11 | godz.: 21:02)
    rofl, XvMC? buhahah, odrob lekcje. BTW. dobrze wiedziec ze przynajmniej w otwartych sterach sie dorobili, szkoda tylko, ze to technologia z poprzedniej dekady. Cos mi sie wydaje, ze wsparcie dla vc-1/avc poprzez vdpau i to tylko dla R600 niedawno ktos tam dopiero zaczal, wiec chwyc kolejna gromnice.

    Dekodowanie przez va-api w fglrx juz dziala czy "prawie" dziala? Z tego co wiem od userow ATI to nadal scierwo.


  33. @daver (autor: Mariosti | data: 27/04/11 | godz.: 21:13)
    OpenSource sterowniki do radeonów nie są amd tylko są społeczności i ona je tworzy, dlatego też są takie cienkie. Zamknięte fglrx'y są obecnie w wielu przypadkach bardziej wydajne od sterowników nvidii... masz to wyraźnie widoczne w testach właśnie na phoronix'ie.

  34. @daver (autor: Promilus | data: 27/04/11 | godz.: 21:30)
    Ty odrób lekcje.
    "i to tylko dla R600"
    Weź nie czytaj "po łebkach". Mowa jest o R600g (albo inaczej RadeonHD R600 Gallium3D Driver) czyli sterowniku do całej rodziny HD. Całej! A nie HD2900 only. Wbij do głowy, zapamiętaj i na przyszłość nie truj.
    "ze to technologia z poprzedniej dekady"
    Jak i DXVA, jak i VDPAU, jak i VAAPI. Pamiętasz kiedy wyszły? Ano w zeszłej dekadzie. PWNED!
    "Cos mi sie wydaje, ze wsparcie dla vc-1/avc"
    Full decode, częściowy offload jest cały czas przez XvMC właśnie. A lepszy częściowy niż żaden.
    "Dekodowanie przez va-api w fglrx juz dziala czy "prawie" dziala"
    Działa od dawna przez backend XvBA (od AMD) poprzez libsy splitted-desktop systems do VA API. Którego z kolei używa wystarczająco popularnych playerów by miało działać. VAINFO? Ano pokazuje VC-1 i H.264 full, filmy lecą żadnych zielonych ekranów itp.
    "Z tego co wiem od userow ATI to nadal scierwo"
    Znaczy, że to dupy a nie userzy linuksa skoro nawet tego nie potrafią zrobić.


  35. Mariosti (autor: daver | data: 27/04/11 | godz.: 21:35)
    juz chyba przerabialismy fglrxy i np przypadek z Mozilla? Testy Michaela mozna czesto miedzy bajki wkladac. Widzialem chyba 460tke i Uningine przy 9 klatkach w jego tescie co jest smieszne, na GTX275 mam kilka razy tyle. Z innego testu wyszlo mu, ze Compiz daje zajebistego kopa (sic!) w grach. LOL. Takze Michael niech sobie pisze newsy i dlubie PTS.

  36. Promilus (autor: daver | data: 27/04/11 | godz.: 21:41)
    XvMC - X-Video Motion Compensation - wygoogluj sobie noobie.

    Dawaj, pokaz jak np killa sampla dziala. Jestem ciekaw, rowniez na otwartych na karcie z serii 5xxx/6xxx


  37. zerkalem (autor: daver | data: 27/04/11 | godz.: 21:50)
    do wielkiego wora z problemami, jak co kilka miesiecy:
    http://phoronix.com/...-Something-On-Linux/page117 i co widze? http://img526.imageshack.us/img526/4807/uvd1.png

    i jeden z ostatnich komentow

    "I see the point of that, Zacate Hardware is very nice, but if you want a stable HTPC on linux, run (to nvidia) while you can."


  38. @daver (autor: Promilus | data: 27/04/11 | godz.: 22:19)
    "XvMC - X-Video Motion Compensation - wygoogluj sobie noobie"
    Sam jesteś noob bo najwidoczniej nie wiesz, że możliwości nie ograniczają się wyłącznie do MC. Możliwości mogą być rozszerzone jak xvmc-vld dla openchrome(otwarty sterownik dla unichrome s3) który akceleruje mpeg2 i mpeg4, albo prace typu http://bitblitter.blogspot.com/
    Jak widać robi to kolo właśnie do xvmc, a nie vaapi czy vdpau.
    "Dawaj, pokaz"
    Nie mam nic do dawania i pokazywania pokemonom zaręczonym z wikipedią.
    "Widzialem chyba 460tke i Uningine przy 9 klatkach w jego tescie co jest smieszne, na GTX275 mam kilka razy tyle"
    Na jakim systemie...


  39. lol (autor: daver | data: 27/04/11 | godz.: 22:26)
    XvMC to XvMC, jak sobie jeden z drugim brancha nazwal to inna histroria.

    Arch i XP, wydajnosc bardzo porownywalna (w granicach bledu pomiarowego), w jakis OS-owych syfnych gierkach na Archu mialem kilkanascie procent lepsze rezultaty.


  40. morgi (autor: Gigant | data: 27/04/11 | godz.: 22:36)
    Mam wyniki Fusiona w HyperPI... ;)
    http://i161.photobucket.com/...miahallen/llano.png

    Core i7 2600K 3.4GHz= 23s
    A8-3510MX 1.8GHz= 29s

    Intel jest 26% szybszy przy większym zegarze o 89%...

    Po podniesieniu zegarów do 3.4GHz dla A8-3510MX = ~16s


  41. @Promilus (autor: pomidor | data: 27/04/11 | godz.: 22:48)
    Z Twoich postów wynika że jesteś maniakiem komputerowym. Tacy ludzie posiadają komputery dla posiadania komputerów, aby sobie w nich pogrzebać, rano zrobić OC, po południu odblokować/zablokować rdzenie, wieczorkiem pogrzebać w Linuksie i zainstalować nowy sterownik lub go samemu skompilować, itd. Oczywiście taka zabawa z komputerem wymaga wiedzy, którą potem można wykorzystać na forach., i mieć z tego wszystkiego dodatkową satysfakcję Jednak uważam że takie traktowanie komputera (i samego siebie) to pewna dewiacja, marnowanie życia i czasu, na może ciekawe ale niepotrzebne bzdurki. Zastanów się nad tym.

  42. pomidor (autor: daver | data: 27/04/11 | godz.: 22:56)
    "maniakiem komputerowym"? buhaha, chyba maniakiem blogowym, wciska kity na lewo i prawo i dajesz sie nabrac?

  43. @pomidor (autor: Promilus | data: 27/04/11 | godz.: 23:05)
    Z twoich postów wynika że jesteś maniakiem intela&nv. ARM zły bo lepiej mieć monopolistę intela oferującego tosty w stylu P4 niż kilka średniaków z lepszymi z racji konkurencji pomysłami. LoL. Twój punkt widzenia (obarczony sarkazmem 'by me') z innego newsa. Jak ktoś pisze, że nv jest good bo jest bezproblemowa to CO robią wszystkie wątki na forum nv zaczynające się od "problem", "issue" albo "failure"? No ludzie złoci, tak trudne jest zachowanie choćby fasady obiektywizmu?
    "Jednak uważam że takie traktowanie komputera (i samego siebie) to pewna dewiacja, marnowanie życia i czasu"
    Ja uważam, że zjeżdżanie jedynej konkurencji na rynku CPU dla PC i jedynej konkurencji na rynku GPU dla PC oraz wielbienie tych "większych graczy" jest pewną dewiacją, marnowaniem życia i czasu na nieciekawe, niepotrzebne i rzadko poszerzające wiedzę tematy. Bo o ile zabawy z Linuksem dają rzeczywiste i bezpośrednie doświadczenie dot. systemu, sterowników i aplikacji (a nie "bo gdzieś wyczytałem" albo "bo ktoś powiedział") o tyle przekomarzanie się jak to AMD w kulki leci, jak to OpenCL jest niszowym rozwiązaniem (a skompilował chociaż helloCL?), jak to OpenGL jest niszowym rozwiązaniem itp. itd. nie daje żadnego przydatnego doświadczenia. Może to lubisz, twoja sprawa. Ja lubię przynajmniej spróbować użyć, albo dowiedzieć się coś więcej na temat sprzętu i softu o którym dyskutuję.
    @daver
    "Arch i XP, wydajnosc bardzo porownywalna"
    Tyle, że akurat o słabszej wydajności w UH w OGL4 względem DX11 (czyli typowo Vista/7 vs Linux) masz i tutaj:
    http://www.geeks3d.com/...ed-direct3d-11-opengl-4/
    Zatem nijak nie wychodzi złe testowanie tylko dupowata implementacja OGL w sterach (co odbija się na pingwinie). No, ale pojeździć i zarzucać komuś nieudolność to tak fajnie podbudowuje ego, co? :)


  44. @dobre keczup!! DX i CUDA 95% (autor: Arlic | data: 27/04/11 | godz.: 23:24)
    Nawet nie na windowsie, a co mówić i innych platformach.

    CUDA na windows ok. 15%?
    DX na windows 70%-65%

    A co mówić o innych systemach..
    Gdy by nie standardy open, DX by siedział na poziomie konsol...


  45. o czym Ty znow pitolisz (autor: daver | data: 27/04/11 | godz.: 23:25)
    http://www.phoronix.com/...s/sapphire_hd5830/5.png

    Zejdz na ziemie, czytaj mniej blogow. Nie trzeba byc specjalista by stwierdzic, ze ten test jest zjebany, ba on nawet nie pokrywa sie innymi, przeprowadzonymi przez tego samego goscia. To nie pierwszy i ostani taki przypadek w wykonaniu Michaela.


  46. @45. (autor: Mariosti | data: 28/04/11 | godz.: 00:07)
    Specjalnie sabotował sterowniki nvidii...

  47. a tam specjalnie (autor: daver | data: 28/04/11 | godz.: 00:22)
    testuje na fazie... ;) Nie takie kwiatki tam widzialem.

  48. @Promilus (autor: pomidor | data: 28/04/11 | godz.: 00:46)
    - Nie mam nic przeciwko ARM. Chodzi mi o to że trzeba mieć ok. 50% rynku aby rozwijać CPU na wysokim poziomie technicznym. Dlatego wolę obecną sytuację z silnym Intelem i słabym AMD (jako zawór bezpieczeństwa), niż 4-5 firemek typu AMD z zacofanymi technicznie produktami.
    - pisałem że U MNIE nv działa bezproblemowo, co jest faktem od zawsze.
    - AMD samo się zajeżdza. O ich skrzywionym podejściu do działalności już wiele razy pisałem, i nie będę powtarzał. Z tych samych powodów (a nie ich wielkości) jestem za Intelem i NV.
    - Nie pisz głupot że wszystko o czym piszesz, sprawdzałeś i testowałeś u siebie, bo to niemożliwe. Rozumiem że ta miłość do OpenCL powstała po skompilowaniu helloCL. Rzeczywiście, świetny powód aby się uznawać za znawcę OpenCL.


  49. @pomidor (autor: trepcia | data: 28/04/11 | godz.: 00:54)
    Promilus kiedyś pisał, czym się zajmuje i tego trochę było. Ale poczekajmy na samego zainteresowanego.

  50. @pomidor (autor: Promilus | data: 28/04/11 | godz.: 08:13)
    "Nie pisz głupot że wszystko o czym piszesz, sprawdzałeś i testowałeś u siebie"
    xorgowe sterowniki? Ano miałem i do compiza jeszcze starczały. fglrx cały czas mam, frontend w postaci vaapi do odtwarzania VC-1 i H.264 używam (tak, trochę ręcznej instalacji pakietów było, ale się udało) - problemów brak, green screenów brak, tearing itp. - brak (od tego jest Eliminacja zniekształceń albo vsync jak kto woli). OpenCL zarówno pod Linuksem jak i Windowsem testowałem. Łącznie z kompilacją programów w postaci źródeł (zatem nie hellocl tylko). I nie, nie ma miłości do OCL u mnie, natomiast potrafię go docenić czego ty najwidoczniej nie.
    "pisałem że U MNIE nv działa bezproblemowo, co jest faktem od zawsze"
    Tak jak u mnie radeon, bo nie ma takich problemów do których nie byłoby rozwiązania. Jakiś czas temu denerwowało mnie to, że JA nie chodzi na 10.5 i nowszych... narzekałem, narzekałem, a wystarczyło zmienić jasp.exe na quake3.exe, lol.
    "Z tych samych powodów" Tiaa... jak wielokrotnie sony i morgulcowi udowadniałem nv też ma wpizdu problemów, to że ty ich nie doświadczyłeś nie oznacza, że nv jest piękna i nieskazitelna (a raczej, że albo w aktualnym konfigu sprzęt-soft masz małe szanse na spotkanie się z problemami, albo tak się ograniczasz na kompie /sprawdzony zestaw gier/ że po prostu nie masz szans ich napotkać).
    "Rzeczywiście, świetny powód aby się uznawać za znawcę OpenCL"
    Nawet gdyby na skompilowaniu HelloCL się skończyło, to mam prawo uznawać się za większego znawcę GPGPU niż ktoś kto co najwyżej użył PhysX GPU.

    @daver - zobacz ten link który zapodałem, jest regresja? Jest. Jest CF z 6850 szybsze od 460sli w UH2.5? Jest. I co, tutaj też zarzucisz, że jest źle zrobiony test? I to nie blog a portal kolesia, który zrobił GPU Caps Viewer choćby (ale nie tylko). To, że ty uwielbiasz blogi przeglądać i przesiadywać na pudelku, nie oznacza że inni mają te same upodobania. Jak nie potrafisz rzeczowej dyskusji prowadzić, tylko zniżasz się do stosowania argumentum ad personam to baw się dalej, opinię na twój temat mam już wyrobioną i teraz konsekwentnie będę się tego trzymał. Ty JESTEŚ na poziomie sony gówno, parasrockera i morgulca.


  51. To że radeony są wydajniejsze od nvidi (autor: Arlic | data: 28/04/11 | godz.: 08:31)
    w OpenCL i OpenGL jest wiadome od dawna

  52. Ciekawe komentarze (autor: josefek | data: 28/04/11 | godz.: 08:48)
    AMD nie moze sobie pozwolic, zaden rynek zaniedbac ( zlodzieja-idioty Meyera juz nie ma), a kto powiedzial, ze nie mozna APU na jednym chipie z ARM polaczyc...

  53. . (autor: daver | data: 28/04/11 | godz.: 10:57)
    .

  54. @53 (autor: Jarek84 | data: 28/04/11 | godz.: 11:58)
    fakt regresja trudne słowo :]

  55. @daver (autor: Promilus | data: 28/04/11 | godz.: 12:02)
    Aaa, to ja mam się przyczepić do Michaela Larabel dlatego, że często gęsto HD4670 na Linuksie przegrywa z 8600GT? A może użyszkodnicy nvidii powinni popłakać się, bo często gęsto GTX460 mocno odstaje od 6850 czyli cenowego odpowiednika? Masz platformę sprzętową i wersję sterowników podaną. Sprawdź czy na testowanym sprzęcie będzie zupełnie inny wynik - jeśli tak uznam, że kolo specjalnie robi jakieś dziwolągi zamiast testów. A jak nie jesteś w stanie tego udowodnić to może przyjmij do wiadomości, że nie każdy test, nie każda platforma i nie każdy sterownik oddaje to co zauważasz u siebie. No, ale widać nie potrafisz czytać ze zrozumieniem i wyciągać wniosków. Temat z geeks3d dałem by pokazać, jak zwykła zmiana aplikacji testowej na wyższy numerek spowodowała spadek wydajności w OGL4.x (nawet nie na Linuksie) w przypadku obu producentów, przy czym znacznie większy u nv (względem DX11). Zły test? Zły sterownik? A może złośliwość testera? Hmm?

  56. . (autor: daver | data: 28/04/11 | godz.: 12:26)
    .

  57. @daver (autor: Promilus | data: 28/04/11 | godz.: 13:00)
    "jestes idiota czy tylko udajesz"
    Jesteś z gimnazjum czy tylko udajesz?
    "Widzialem chyba 460tke i Uningine przy 9 klatkach w jego tescie co jest smieszne"
    Test nie jest jego tylko artykuł. Sam test leci z automatu, jeśli akurat przy tropics, sanctuary i heaven wyszły rozbieżności to warto by zapytać autora dlaczego, a nie od razu zarzucać manipulację. Tymczasem na forum pytanie takie nie padło bo sprawdzałem. Masz zastrzeżenia to je zgłoś, ale nie dorabiaj sobie jakiś historyjek.
    "Regresji w sterownikach nie bylo"
    Nie o regresji między kolejnymi wersjami sterowników linuksowych pisałem, ale widać nie zajarzyłeś. To inaczej - komentarz 53. GTX480 - DX11 min 17,6fps, max 95,5FPS, OGL4 min 6,1, max 89,4fps
    W UH2.5 znowu DX11 te same wyniki, NV OGL4 prawie o połowę niżej + brak SLI. Zły test, zły sterownik czy zła wola testującego? Tak trudno odpowiedzieć? Bo właśnie to zarzucasz Michaelowi - jego błąd że nie starał się znaleźć przyczyny słabego wyniku w testach unigine bo jak TY pokazałeś są 'lekko' oderwane od rzeczywistości. Ale nie takie rzeczy zdarzały się na Tom's Hardware, PCLAB czy ś.p. egiełdzie. Tyle, że tam ewentualne rozbieżności były szybko alarmowane przez userów. Czemu zatem trujesz dupsko tutaj zamiast wklepać koment na phoroniksie to nie wiem.


  58. gigant @26 (autor: Aamitoza | data: 28/04/11 | godz.: 13:11)
    a jednak powialo z drugiej strony i teraz a9 nie jest na rowni z bobcatem, a to bobcat gniecie a9? A na myslalem, ze zmiana zdania zajmie Ci przynajmniej pol roku, a nie 2/3 dni.

  59. . (autor: daver | data: 28/04/11 | godz.: 13:54)
    .

  60. @daver (autor: Promilus | data: 28/04/11 | godz.: 14:19)
    Powściągnij hormony bo gotów DYD zajrzeć, i będziesz musiał robić rev2 ;)
    Albo... tak jak pisałem soniaczkowi żyłka ci pęknie i zrobisz kupę zanim zasiądziesz na porcelanowym tronie.
    "czyli nie musi recznie odpalac kazdej aplikacji i robic wykresow"
    Dokładnie, czyli jest taki a nie inny wynik, bo tak ten test przeleciał. A czemu tak a nie inaczej - to dopiero jest do wyjaśnienia, ale nikt nie raczył Michaela o to zapytać więc skoro piszesz "ale ja mam to w dupie" to czemu w ogóle rozpocząłeś ten wątek? :)
    "ostrzegalem tylko kogos wyzej przed niekompetecja Michaela"
    Niekompetencją byłoby gdyby ewentualne zastrzeżenia się pojawiły a on je olał. A skoro nikt go nie poinformował, że coś się nie podoba w wynikach to czego oczekujesz? Do magisterki robiłem symulacje w FEMM4.2, elektromagnetyzm. Cewka w płaszczu z Supermalloy mimo większej indukcyjności praktycznie tak samo przy 200Az przyciągała walec z czystego żelaza co w płaszczu z magnetycznej nierdzewki. Wyniki ładne piękne... tyle, że do dupy. FEMM nie ma pełnej ch-ki B-H każdego materiału, szczególnie w egzotykach jedynie w zakresie używalności (czyli -0.7:0.7T mniej więcej) - resztę sobie liniowo dorabia co powoduje przy wysokich natężeniach przekłamania wyniku. Nie zwróciłem początkowo na to uwagi. Nie zwrócił uwagi promotor (dr), ani recenzent (prof. dr hab.). Ach ta wszechobecna niekompetencja...
    "kiedys mi sie chcialo, sugerowalem, robilem reprodukcje i publikowalem" To trzeba było dalej robić, a nie narzekać na innych.


  61. @daver (autor: rainy | data: 28/04/11 | godz.: 15:37)
    Nie wiem co się z Tobą ostatnio stało, ale ilość żółci czy wręcz agresji (włącznie z używaniem wyzwisk/obelg). która wylewa się się z Twoich postów, jest po prostu nie do przyjęcia.

    Jak dla mnie, to za "występ" w tym newsie kwalifikujesz się jawnie na bana.


  62. Promilus, misiek drogi (autor: daver | data: 28/04/11 | godz.: 15:50)
    predzej kaktus mi wyrosnie niz bedzie "rev2", ten vortal zszedl na psy w momencie gdy takie skretyniale dzieciaki zaczely sie tu udzielac.

    Rainy, wybacz, mam zerowa tolerancie na debili, a o bana sie wrecz prosze. Zagladam tu juz tylko z przyzwyczajenia. Coz, 10 lat to jak druga natura, ale tesknic nie bede.


  63. @daver - bluzgiem czasami można rzucić, ale trzeba go ważyć (autor: Qjanusz | data: 28/04/11 | godz.: 15:53)
    tak jak rainy napisał, daj sobie deko na wstrzymanie, albo poluźnij pampersa...

    jeżeli nie masz kobiety to ją sobie w końcu znajdź. Jeżeli masz, to zdecydowanie ją zmień...

    ...taki mały off-top i już się nie odzywam.


  64. @daver (autor: Promilus | data: 28/04/11 | godz.: 17:43)
    "ten vortal zszedl na psy w momencie gdy takie skretyniale dzieciaki zaczely sie tu udzielac"
    Hueh, chyba przespałeś Sajrona, morgiego, sony, pararocker, gigant itp. :) Myślałem, że jesteś przynajmniej na poziomie Grave (umiarkowanie pro NV&intel) ale ty niestety pokazałeś się z najgorszej strony. Wszystko co AMD to złe. XvBA nie działa, Gallium R600g to sterowniki do HD2900 (only), XvMC robi tylko motion compensation czyli mniej niż Rage 128 (bo tak nazwa wskazuje), a do tego wszystkiego fanboy AMD siedzi na phoroniksie i sobie obcina dla zabawy słupki wydajności kart nv ;)
    "10 lat to jak druga natura" Po dłuższym czasie można rzucić palenie, to i odwiedzanie TPC też się da,
    "ale tesknic nie bede"
    Ja za Tobą też nie, heh. Ale nie martw się, ostatnimi czasy Gigant pojechał ostro a nie widziałem żeby już miał bana... może Ciebie też ominie :] Ewentualnie drobne ostrzeżenie... tak, żebyś się zachowywał jak kulturalny człowiek a nie kolo co dopiero z siłowni wrócił i zauważył, że mu koksy ktoś spłukał w WuCetku.


  65. racje Ty miec, za bluzgi przepraszam (autor: daver | data: 28/04/11 | godz.: 17:44)
    o cenzure sam DYD'a poprosilem.

  66. Promilus (autor: Gigant | data: 28/04/11 | godz.: 18:12)
    Nikogo nie pojechałem... wkurzają mnie takie goście pokroju amitoza,pccpu którzy myślą że są wszechwiedzący...

    Jeżeli marketing AMD kłamie ci prosto w oczy to jak ja mam sie zachowywać jako wielbiciel tej firmy? A amitoza,pccpu jako trole AMD nadal mi wmawiają, że moduły to nie rdzenie... hipokryci...


  67. @Gigant (autor: Promilus | data: 28/04/11 | godz.: 18:33)
    Pojechałeś po PCCPU i Aamitozie. Dobrze pisałeś o modułach = rdzeniach x86 w przyjętym tego słowa znaczeniu. Natomiast trochę zagalopowałeś się z single thread shared execution bo co prawda AMD podobny patent kiedyś opisywało, ale nikt nigdzie nie pisał że takie coś w bulldozer będzie istniało.
    To samo dotyczy 6 dekoderów Llano - brak potwierdzenia tych rewelacji, a wystarczy poczekać jeszcze te 2 miesiące zamiast bluzgać. Jak coś będziesz mógł napisać "i co ciołki - jednak ja miałem rację" i raczej nikt bana za to nie da.

    @daver - każdy może mieć gorszy dzień i mnie też się zdarzyło kilka razy, zobaczysz za parę dni Ci niechęć do odwiedzin TPC/chęć rozbicia komuś czaszki przejdzie... no, może i tak mnie dalej nie będziesz lubił, ale za to przestaniesz wyzywać od idiotów itp.


  68. Gigant (autor: PCCPU | data: 28/04/11 | godz.: 19:08)
    Od poczatku pisalem ze Modul to w rzeczywistosci Core. Chodzilo mi o to ze AMD marketingowo klastry INT bedzie promowac jako Core a Ty uparles sie ze wedlug manualu dla programistow AMD zmienilo zdanie i Moduly nazywa Core co prawda nie jest bo AMD planow co do nazewnictwa marketingowego niezmienilo.

  69. Gigant (autor: PCCPU | data: 28/04/11 | godz.: 19:16)
    Rowniez uparles sie ze Modul potrafi liczyc na dwoch klastrach INT pojedynczy watek gdzie w zadnym patencie odnoszacym sie bezposrednio do Bulldozera nie ma ani zdania. Owszem AMD moze i ma taki patent ale to nieznaczy ze w Bulldozer to rozwiazanie sie znajdzie. Bycmoze w ktorejs z kolei generacji Bulldozer AMD cos takiego zaimplementuje ale jeszcze nie teraz. A jesli nawet to bylaby rewolucja.

  70. PCCPU (autor: Gigant | data: 28/04/11 | godz.: 19:38)
    Litości trollu... Skąd wiesz jak AMD będzie promować Buldożera? Ten manual to niezła ściema... Naprzemienie nazywają compute unit z core aby niemożna było się połapać o co chodzi...

  71. AMD utajnia kilka rzeczy (autor: Gigant | data: 28/04/11 | godz.: 19:46)
    1. Dodatkowe 3 dekodery w Llano...
    2. Moduły to tak naprawdę rdzenie...
    3. Cayman ma 2048SP...

    Najlepsza ściema jest z tym zdjęciem Barcelony że to niby Cypress/Cayman...


  72. Gigant (autor: PCCPU | data: 28/04/11 | godz.: 19:54)
    Mozesz mnie wyzywac od min trolli ja do twojego poziomu sie niebede znizal. Co do marketingu to masz mase slaidow(jak i ostatnio pudelka na przyszle CPU BD) prosto od AMD w ktorych 4 moduly to 8 marketingowych Core. Ty ciagle o tym manualu ktory nie jest zadnym dowodem na to iz AMD postanowilo moduly nazywac Core.

  73. Gigant (autor: PCCPU | data: 28/04/11 | godz.: 20:04)
    Nawet niechce mi sie komentowac tego co napisales. Zreszta premiera Llano juz niedlugo a Buldozera jeszcze blizej wiec wtedy zobaczymy :-)

  74. Gigant (autor: PCCPU | data: 28/04/11 | godz.: 20:04)
    Nawet niechce mi sie komentowac tego co napisales. Zreszta premiera Llano juz niedlugo a Buldozera jeszcze blizej wiec wtedy zobaczymy :-)

  75. PCCPU (autor: Gigant | data: 28/04/11 | godz.: 20:05)
    no to nie komentuj, każdy ma swoje zdanie, nie zgadzasz się ze mna to nie ale nie rób ze mnie debila...

  76. Bulldozer (autor: PCCPU | data: 29/04/11 | godz.: 14:47)
    Te linki które podał morgi jednak świadczą tylko o wysokiej wydajności Buldożera. Według mnie testy w Cinebench 11.5 przeprowadzone były na max 1 Module(2 klastry INT). W Cinebench 11.5 jest opcja w menu Advanced benchmark po której uaktywnieniu w lewej górnej części oprucz "CPU" pokazuje się "CPU(Single Core)" i przyciśnięciu obok tej opcji test będzie przeprowadzony na jednym rdzeniu. Na tych zdięciach ta opcja jest wyłączona co wskazuje że test jest w multi Threads. Ale jest też opcja w menu "Preferences" w której wybieramy "Render Threads" i następnie zaznaczmy "Custom Namber of Render Threads" i ustawiamy ręcznie od 1 do max liczby wądków dla danego układu.
    Pierwsza opcja moim zdaniem to to że test był przeprowadzony na 1Module(2 klastry INT) lub 2 klastrach INT ale osobnych modułach.
    Przypomnę że dla Bulldozera wydajność kolejnych klastrów i modułów wygląda tak: 100%(100%+80%)+95%+95%+95% Założyłem że na jednym module i wyszło mi tak:
    Zambezi 4M/8T(8Core) 2.82GHz
    1M/1T - 1.67
    1M/2T - 3.18
    4M/8T - 11.79
    Oczywiście wydaje mi się że ta opcja jest najbardziej realna.
    Druga opcja jest zbyt optymistyczna i rysuje się następująco:
    Zambezi 4M/8T(8Core) 2.82GHz
    1M/1T - 3.18
    1M/2T - 4.72
    4M/8T - 17.52
    Druga opcja pokrywa się mniej więcej z tym http://www.youtube.com/...uOcs&feature=related co widać po zdięciach z przecieków z wcześniejszych postów również i w tym rankingu wyniki są z Cinebench 11.5
    Nie wiem jak jest w 3DMarku ale zakładam że też można wybrać liczbę wątków w teście. Co o tym myślicie?


  77. Up edit (autor: PCCPU | data: 29/04/11 | godz.: 14:48)
    http://www.youtube.com/...uOcs&feature=related

  78. Trzeba pamiętać (autor: PCCPU | data: 29/04/11 | godz.: 14:56)
    że moduł BD to około 67 Mln tranzystorów a rdzeń SB to ok 55 Mln tranzystorów więc poprawa wydajności na mm2 czy na wat jak i na MHz powinna być duża.

    
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ć.