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 - 2021
Wtorek 30 kwietnia 2013 
    

Standard hUMA, czyli współdzielona pamięć w APU


Autor: Wedelek | źródło: HotHardware | 08:11
(44)
Jednym z najważniejszych wydarzeń minionego roku było utworzenie fundacji HSA, czyli organizacji non-profit, skupiającej inżynierów z kilku firm działających w branży IT, których zadaniem jest wypracowanie standardów obowiązujących na rynku układów APU i ułatwiających programowanie obliczeń równoległych. HSA powstało z inicjatywy firmy AMD, która kilka godzin temu zaprezentowała osiągnięcia założonej przez siebie organizacji. Owym osiągnięciem jest standard hUMA, który do układów APU dodaje pamięć współdzieloną zarówno przez część GPU, jak i CPU.

W dużym uproszczeniu chodzi o to, by IGP i rdzenie x86/ARM mogły korzystać z tej samej pamięci podręcznej, tak jak ma to miejsce w procesorze montowanym w PlayStation 4 (zapis i odczyt danych przez oba układy). Dzięki takiemu rozwiązaniu, połączonemu z dynamicznie alokowaną pamięcią, obliczenia mogą być wykonywane szybciej dzięki wykorzystaniu potencjału GPU i CPU, a do tego implementacja kodu jest łatwiejsza.

Nie od dziś wiadomo przecież, że GPU potrafi przetwarzać niektóre dane o wiele szybciej niż tradycyjne rdzenie CPU, ale powierzone mu zadania muszą być zlecone właśnie przez CPU, co wymaga ciągłej wymiany informacji pomiędzy tymi dwoma elementami. Obecnie panujący standard NUMA, zakładający występowanie oddzielnej pamięci dla CPU i GPU wydłuża czas potrzebny na obliczenie danych, bo te trzeba nieustannie przesyłać pomiędzy GPU, dwoma oddzielnymi pamięciami i CPU, a co za tym idzie przepustowość podsystemu pamięci staje się „wąskim gardłem”. Co gorsza aby wykorzystać potencjał GPGPU programista musi się uporać z implementacją kodu, który jest bardziej skomplikowany niż gdyby jego program korzystał z samego tylko CPU.

Dlatego też obecnie idea GPGPU nie jest zbyt popularna, choć na tym polu wiele zmieniło się już na lepsze. AMD wraz z pozostałymi członkami HSA, czyli ARM, Imagination Technologies, MediaTek Inc; Samsung Electronics,Texas Instruments (TI), Apical, Arteris Inc; MulticoreWare Inc; Sonics, Symbio oraz Vivante Corporation, ma nadzieję na szybką zmianę tego trendu. Programistów skusić ma przede wszystkim znacznie wyższa wydajność GPU, co najlepiej obrazuje jeden z poniższych slajdów. Warto również nadmienić, że obecnie wykorzystywana w Radeonach architektura GCN od początku była tworzona z myślą o GPGPU.


 

    
K O M E N T A R Z E
    

  1. No nareszcie cos (autor: mbe | data: 30/04/13 | godz.: 09:57)
    sie ruszy w tym temacie. GPGPU to przyszlosc.

  2. Ciekawie to wygląda :-) (autor: loccothan | data: 30/04/13 | godz.: 10:10)
    Wiecie co chłopaki ja widzę to tak że jest to duży krok do przodu (oraz zauważcie że cos tu jest na rzeczy bo PS4 cos takiego utylizuje tylko z GDDR5 ! a AMD zapowiedziało nową architekturę na bazie tej z PS4 do PC lol) i pozatym jest to Open Projekt (czyli jak linux i OpenGL i OCL !!) czyli jest to Bardzo przyszłościowe i nie jak u innych Dojna Złota Kaczka (wiecie zamknięte i z-Focusowane na $$$ ) Moim zdaniem brawo dla AMD za inwencje twórczą i teraz trzeba czekać aż Standard się Ułoży wśród Programistów i zaczniemy sycić !
    I proszę bo na innych Web-Infach straszny Hejt od wyznawców sekty intela poszedł ! U nas niechaj tak nie będzie ! Prosiłbym o wasze przemyślenia i marzenia na temat tego hUMA od AMD bo jest tu wielu chłopaków i dziewcząt co się znają na rzeczy. PZDR


  3. nie ma rewolucji (autor: RusH | data: 30/04/13 | godz.: 11:09)
    czyli cache GPU jest wspoldzielony z cache CPU, biorac pod uwage ze w APU jest wspoldzielony kontroler pamieci to az dziwne ze tego nie zaimplementowali od poczatku

  4. @03 (autor: angh | data: 30/04/13 | godz.: 11:41)
    nie, cache nie jest wspoldzielone. Jedynie przestrzen adresowa jest synchronizowana. I jest to pewna rewolucja - dotychczas tekstury byly sczytywane przez cpu do ramu i kopiowane do pamieci gpu - teraz nie jest to potrzebne. Oszczednosc jest dramatyczna.

  5. locococo, cos ci sie, misiek, pogmeralo z tym hejtem (autor: daver | data: 30/04/13 | godz.: 11:46)
    Bo akurat Intel robi nieporownywalnie wiecej dla Linuksa i FLOSS, w ogole, niz AMD. W samym kernelu gdzies tak 5x wiecej w roku 2012. Przypomnij mi, kiedy to AMD pogonilo wiekszosc swoich developerow Linuksa? W tym roku czy pod koniec ubieglego?

  6. 5@. (autor: loccothan | data: 30/04/13 | godz.: 14:16)
    nie wiem, ale wiem ze AMD tez jest Spoko i tyle ! Chciałbym zeby były normalne dyskusje na temat (zawsze mozna się czegoś nauczyć nowego, każdy ma jakąś wiedzę i ja jestem skłonny słuchać i się uczyć o to mi chodzi w postach) wtedy naprawdę jest świetnie jak wszyscy którzy maja jakaś wiedzę się wypowiadają i rozwija się dykusja. PZDR

  7. chcialabym, chciala... (autor: daver | data: 30/04/13 | godz.: 15:59)
    Wiec po co byl ten trolling? W ten sposob merytoryczne dyskusje sie nie rodza.

  8. 3 faktycznie (autor: RusH | data: 30/04/13 | godz.: 16:51)
    cache jest tylko spojny
    wspolna przestrzen adresowa jest za darmo dzieki wspolnemu kontrolerowi pamieci


  9. a może.. (autor: loccothan | data: 30/04/13 | godz.: 17:51)
    Będzie dzielona nie tylko pamięć główna DDR3 ale również proc dostanie mozliwość ugryzienia kawałka szybkiej GDDR5? to by było niesamowite dopalenie mozliwości proca, do tego jeszcze z 12 rdzeni SteamRoller i mamy przełom na miarę instrukcji od AMD tzw. AMD64 później przemianowane przez Itela na x86-64. Co wy na takie cudo?

  10. loccothan przemianowane bo jak to by wyglądało (autor: Sławekpl | data: 30/04/13 | godz.: 18:50)
    w specyfikacji np. i7, że chipzilla produkuje procki "pod" AMD, przecie fanbojom by żyłki popękały xD

  11. 107 miesiecy na tpc, Slawku (autor: daver | data: 30/04/13 | godz.: 19:03)
    i nadal bawi Cie trolowanie?

    "AMD64" is the name chosen by AMD for their 64-bit extension to the Intel x86 instruction set. Before release, it was called "x86-64" or "x86_64", and some distributions still use these names. Intel refers to its AMD64 implementation as "Intel64" previously named "EM64T"
    http://wiki.debian.org/DebianAMD64Faq

    lub

    "Prior to launch, "x86-64" and "x86_64" were used to refer to the instruction set. Upon release, AMD named it AMD64.[3] Intel initially used the names IA-32e and EM64T before finally settling on Intel 64 for their implementation. Some in the industry, including Apple,[4][5][6] use x86-64 and x86_64, while others, notably Sun Microsystems[7] (now Oracle Corporation) and Microsoft,[8] use x64 while the BSD family of OSs and the Debian[9] Linux distribution use AMD64."
    http://en.wikipedia.org/wiki/X86_64


  12. he he (autor: loccothan | data: 30/04/13 | godz.: 19:56)
    ja jeszcze dodam z EuroGamera o budowaniu kompa na przyszłość --> polecam artykuł --> http://www.eurogamer.pl/...a-nadchodzaca-generacje

  13. skoro polecasz, to zapewne sie orientujesz (autor: daver | data: 30/04/13 | godz.: 20:30)
    Jakich tworcow, czego, i ilu sie pytali? Jakies cytaty autorytetow w tym temacie?

    "Zapytaliśmy więc twórców, jaki procesor jest obecnie najbardziej perspektywicznym rozwiązaniem. O dziwo, pomimo przewagi Intela, wszyscy wskazali na AMD FX-8350"

    Tu masz video z ich "testu" http://www.pcgameshardware.de/...enchmark-1056578/ w ktorym rzeczywiscie 8350 jest szybszy o ~12% od 3570. W fpsy rzadko jednak grywa sie bez przeciwnikow. Gdy takowi sie jednak pojawiaja 8350 jest wolniejszy od 3570 o ~30% (z fpsem na granicy plynnosci, w parze z GTX 680) http://pclab.pl/art52489-13.html

    Locococo, ja bardzo bym chcial, by oni mieli racje. Oznaczaloby to powrot konkurencji, na caly czas waznym rynku, z korzyscia dla wszystkich - nie tylko graczy. Fakty jednak nie sa optymistyczne dla architektury buldka, na ktorej, nota bene, konsole sie nie bujaja.


  14. daver (autor: Markizy | data: 30/04/13 | godz.: 22:33)
    nie dziwie się dlaczego wskazano na FX, ponieważ nowe konsole będą bazować na jaguarach według wszelkich znaków na niebie, dodatkowo pomimo że rdzenie będą te słabsze to jednak od tych FX (zegar i wydajność takt w takt). Konsola będzie miała specjalny system tylko do gier, a wiadomo gry na pc będą w pewnym sensie emulować konsole (chociaż złe słowo tu dobrałem). Ważnym faktem jest że konsola dostanie 8 rdzeni które będą mogły się wspomagać mocą igp przy pewnych obliczeniach. I tutaj to procki z PC mogą polegnąć, bo standard hUMA zobaczymy w przyszłym APU ale on dostanie maks 3 moduły a pewnie 2.

  15. daver to doczytaj jeszcze kto miał pierwszy (autor: Sławekpl | data: 1/05/13 | godz.: 09:18)
    procesor obsługujący 64 bity, jak chipzilla po swojemu to zrobiła (nadal produkuje procesory z tym bublem na zamówienie) i o wymianie patentowej dotyczącej rozwiązań w procesorach x86
    145 miesięcy sugerowałoby sceptyka o to kolejny hejter, który wierzy we wszystko co przeczyta, byś się wstydził :P
    w podręcznikach do informatyki AMD wcale nie jest wymieniane, nawet w najnowszych wydaniach, redagowałeś któryś?


  16. Slawku, no wlasnie, doczytaj sobie (autor: daver | data: 1/05/13 | godz.: 13:01)
    AMD mialo pierwszy 64-bitowy procesor dla x86 (~40 lat po pierwszych procesorach z 64b rozkazami), a mowa byla o okresleniu rozszerzen dla x86 (nazewnictwie, swita?).
    Widze, ze to nie tylko troling, ale takze elementarny brak wiedzy.


  17. daver a o dzieleniu rozkazów czytał? (autor: Sławekpl | data: 1/05/13 | godz.: 13:46)
    widzę 100% hejtu i 0% wiedzy :P

  18. rozwin, do czego zmierzasz? (autor: daver | data: 1/05/13 | godz.: 14:01)
    bo nie chce mi sie uderzac w kolejna dygresje. Ciezko mi z toba rozmawiac, bo masz problem ze zrozumieniem slowa pisanego, pozwole sobie strescic temat, cytujac:

    loco
    >>AMD64 później przemianowane przez Itela na x86-64

    slawcio
    >>przemianowane bo jak to by wyglądało w specyfikacji np. i7, że chipzilla produkuje procki "pod" AMD, przecie fanbojom by żyłki popękały xD

    ja
    >> "Prior to launch, "x86-64" and "x86_64" were used to refer to the instruction set."

    slawcio
    >> daver to doczytaj jeszcze kto miał pierwszy procesor obsługujący 64 bity


    Wybacz, misiek, ale cos nie tegez z twoim pojmowaniem.


  19. daver tiaa weź się zaplastykuj xD (autor: Sławekpl | data: 1/05/13 | godz.: 14:15)
    ...

  20. Widze, ze zakonczylismy temat (autor: daver | data: 1/05/13 | godz.: 14:21)
    Mam nadzieje, ze sie czegos nauczyles.

  21. daver tia, że są ludzie do których nic nie trafia (autor: Sławekpl | data: 1/05/13 | godz.: 14:25)
    i klawisze są więcej warte :P

  22. lol, wiecej, poprosze (autor: daver | data: 1/05/13 | godz.: 14:30)
    moze jakies epitety?

  23. daver ..... (w kropki wstaw sobie jaki chcesz) xD (autor: Sławekpl | data: 1/05/13 | godz.: 15:41)
    ...

  24. lol (autor: loccothan | data: 1/05/13 | godz.: 17:40)
    lol

  25. slawek, daver (autor: mbe | data: 1/05/13 | godz.: 19:25)
    Nie wiem o co wy sie klucicie.

    Pierwszy procesor z instrukcjami 64 bitowymi zrobilo AMD.

    Intel tez chcial przeforsowac swoj standard ale ten mial wiecej wad i jeszcze wiecej wad. Programisci wybrali standard AMD bo byl prostrzy i mniej zawodny. Intel swoj standard moze nawet nazwac super shit_64 a i tak zawsze doinstalowywany jest AMD64.

    AMD64 w dalszych latach "wspolpracy" AMD z intelem stal sie karta przetargowa. Obecnie jest tez taka karta w fundacji HSA bo jako jedyny nie jest techmologia ktora przejmie intel po zerwaniu warunkow umowy na x86. AMD64 mozna tez uzyc w prockach ARM.


  26. mbe (autor: Markizy | data: 1/05/13 | godz.: 19:47)
    pierwsze procesory dla szarego człowieczka zrobiło AMD, ;) ogólnie 64bitowe procesory istniały wcześniej ale nie były szeroko stosowane.
    http://pl.wikipedia.org/wiki/Itanium było wcześniej jednak nie dla mass.


  27. lomatkozcorka (autor: daver | data: 1/05/13 | godz.: 19:53)
    do szkoly, won! Ile razy "poprawialem" ci tego samego byka? Stracilem rachube. http://sjp.pl/k%B3%F3tnia

    Nastepnie sobie poczytaj, mlody czlowieku, zamiast wypisywac bzdury.

    en.wikipedia.org/wiki/64-bit_computing#64-bit_processor_timeline
    http://en.wikipedia.org/wiki/X86_64
    http://en.wikipedia.org/wiki/X86_64#AMD64
    http://en.wikipedia.org/wiki/X86-64#Intel_64

    http://en.wikipedia.org/wiki/Technical_standard
    http://en.wikipedia.org/wiki/Implementation


  28. mbe nie przekonasz, żaślepiony fan nawet nie czyta (autor: Sławekpl | data: 1/05/13 | godz.: 20:29)
    pełnego tekstu na który sam się powołuje, cytat z pierwszego linka
    "The original specification was created by AMD..."


  29. a gdzie napisalem cokolwiek, co przeczyloby temu (autor: daver | data: 1/05/13 | godz.: 20:49)
    lub ujmowalo AMD zaslug w tej kwestii? Poprawiam tylko totalne pierdoly, ktore wypisujecie z braku podstawowej wiedzy.
    Nie mierz innych swoja miara. To, ze mam cierpliwosc poprawiania niedouczonego fanatyka nie oznacza, ze siedze w przeciwnym obozie.


  30. 13@Daver (autor: zgrzejan | data: 1/05/13 | godz.: 21:27)
    Jesli wolisz testy na pclab od zdania tworcow gier ktorzy PS 4 zapewne juz maja.W dodatku testy te pisane przez czlowieka ktroy wszem i w obec udowadnia ze Atom to proc porownywalny z Brazosem,nie uznaje zadnych innych efektow fizycznych oprocz NV,i publicznie wysmiewa technologie fizyki AMD.
    To wiesz ...moze przestan sie udzielac tu i idz na PCl?


  31. To nie jest test (autor: daver | data: 1/05/13 | godz.: 22:58)
    tworcow gier. Jesli masz link do testu innego niz welcome to the jungle, wyciagajacy inne wnioski, to bardzo chetnie zweryfikuje swoje zdanie.

  32. @up (autor: zgrzejan | data: 1/05/13 | godz.: 23:09)
    Artykul oraz link z komentarza 12 jest na temat przyszlych technologi czy produkcji.Wiec co ty chcesz? Przepychanki w benchmarki?

  33. o czym ty do mnie? (autor: daver | data: 1/05/13 | godz.: 23:39)
    Art powoluje sie na test jakiegos niemieckiego magazynu (pcgameshardware.de), ktorego rezultaty pokrywaja sie z pecelabowymi na mapie welcome to the jungle. Wiec jesli zarzucasz labowi stronniczosc, poprosze o inny test, ktory podwazalby wnioski laba na innych mapach.

    Komentarz do wnioskow Linusa Blomberga wyslalem wczoraj. Z powodu problemow z jakims tam skryptem poszedl sie bzykac lub sie jeszcze pojawi (patrz na liczbe komentarzy przy tytule newsa i liczbe faktycznych postow). Long story short, nie chce mi sie pisac tego ponownie.


  34. daver jak chorągiewka albo nie umiesz sklecić (autor: Sławekpl | data: 1/05/13 | godz.: 23:49)
    logicznego zdania, skoro nie ujmujesz AMD zasług to o co Tobie chodzi?
    AMD podaje bez zmian w nazewnictwie zestawy instrukcji, chipzilla tego nie robi, a może masz zdjęcie jakiegoś pudełka z ich procesorem gdzie jest wymienione AMD64 i udowodnisz mi, że się mylę :E


  35. czlowieku... (autor: zgrzejan | data: 1/05/13 | godz.: 23:51)
    jestes tak samo uparty jak mbe tylko w inna strone.Facet podaje linka na temat wyboru sprzetu pod przyszle produkcje z wypowiedziami ludzi ktorzy benda je tworzyc.
    A ten nieszczesny test pokazuje tylko ze ta tendencja(rzeczywiscie narazie na jednej mapce) bendzie sie rozwijac na korzysc AMD.Rozumiesz slowo terazniejszosc a przyszlosc?


  36. Problemem jednak jest wydajnosc pamieci (autor: pandy | data: 4/05/13 | godz.: 20:27)
    jako takiej - albo pamiec musi posiadac cechy pamieci dwuportowej albo mamy waskie gardlo i wydajnosc takiego systemu jest nizsza.

  37. @pandy (autor: Promilus | data: 4/05/13 | godz.: 21:35)
    Nie opowiadaj bzdur. W czym będzie gorzej niż intel z igp lub poprzednie APU? Przecież w każdym przypadku IMC jest zupełnie osobnym układem i zarówno igp jak i każdy pojedynczy rdzeń x86 są klientami dla kontrolera pamięci więc i tak jest przełączanie między układami. Tylko porównaj teraz jak program na CPU może pobierać i modyfikować dane IGP na intelu, na starych APU i na APU z hUMA. Tu jest różnica i nie ma żadnego pogorszenia wydajności. Jest za to wygoda a w niektórych wypadkach właśnie wzrost.

  38. @Promilus (autor: pandy | data: 5/05/13 | godz.: 17:19)
    Wybacz ale bzdury opowiadasz sam. Pamieci maja skonczona przepustowosc i jesli masz jedna pamiec ktora musi dzielic swoja przepustowosc pomiedzy dwa podsystemy przetwarzania danych to z automatu ogranicza to dostepna dla kazdego podsytemu wydajnosc pamieci o co najmniej polowe.
    UMA ma wlasnie tego typu ograniczenia - jesli jeszcze ta sama amiec uzywana jest do genracji sygnalu wideo to juz ma 3 podsystemy ktore dziela sie wydajnoscia pamieci. Nie ma nic za darmo.


  39. @pandy (autor: Promilus | data: 6/05/13 | godz.: 11:53)
    Czy w Ivy bridge masz współdzielenie? Masz! Masz hUMA? Nie masz! Czy w obecnych APU masz współdzieloną pamięć? Masz! Czy masz hUMA? Nie masz! To skąd wzięło się u ciebie, że hUMA powoduje pogorszenie przepustowości? hUMA nie ma nic do przepustowości, to tylko ewolucja już istniejących rozwiązań by CPU miał bezpośredni dostęp do danych GPU (i vice versa) gdzie obecnie odbywa się to poprzez utworzony w pamięci iGP bufor (apu), nie wiem jak w przypadku intela, ale podejrzewam, że tam przez cache (mała przestrzeń). Więc w każdym tym przypadku masz jednakowy wpływ na przepustowość, z tym, że w przypadku hUMA absolutnie kończysz z kopiowaniem danych między pamięciami CPU i GPU bo jest to zbędne - to jest jedna pamięć i wystarczy przekazać wskaźnik do obszaru. Nie sztucznie wykreowany bufor. To jest właśnie tyle i tylko tyle. Nie dotyka jednoczesnego dostępu do pamięci bo nie od tego jest. I nijak nie wpływa na przepustowość. Jak nie rozumiesz, że dotyczy to układów zintegrowanych (cpu + gpu) których cechą TAK CZY INACZEJ jest współdzielenie pamieci to nie moja wina.

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