Új hozzászólás Aktív témák

• #68 Löncsi őstag Abu85 #67

  Új Válasz 2012-06-14 11:21:16 #68

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Löncsi

  őstag

  válasz Abu85 #67 üzenetére

  Lehet, nem tudom, 2 év múlva kiderül. De akkor a speciális igények miatt gondolom nem lesz megint átjárás PC/konzol között ahogy most is van.

• #61 Taragas aktív tag Abu85 #60

  Új Válasz 2012-06-14 00:35:24 #61

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Taragas

  aktív tag

  válasz Abu85 #60 üzenetére

  Hát akkor lehet temetni a diszkért piacot. Pedig volt benne lehetőség, hogy APU+dVGAval alkossanak... De ezt már nem fogjuk megérni. Ezek után nem csodálkoznék, ha bejelentenék, hogy nem lesz dual graphics támogatás a trinitynél sem már, mert minek.(főleg ilyen átnevezett 6670-el ). Bocsi az offért, de egyre jobban kezdek csalódni az egészben.

• #59 Taragas aktív tag Abu85 #58

  Új Válasz 2012-06-14 00:24:31 #59

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Taragas

  aktív tag

  válasz Abu85 #58 üzenetére

  De eddig nem arról volt szó, hogy ezzel vonja be mint coprocesszort az amd, a diszkrét a kártyákat? Legalábbis ez nyilatkozták eddig.
  ne akarjuk elfelejteni annyira a diszkrét kártya piacot okés?

• #57 kisza25 félisten Abu85 #48

  Új Válasz 2012-06-13 23:27:18 #57

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  kisza25

  félisten

  válasz Abu85 #48 üzenetére

  az zsír, akkor még egyjó ideig maradhat ez a lapos, csak húzzanak bele a programozók, ne keljen annyit várnom, mint a stream processing, vagy gpgpu-ra tulajdonképpen ez is az, csak egybeépítve a cpuval

• #56 huskydog17 addikt Abu85 #55

  Új Válasz 2012-06-13 22:15:35 #56

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  huskydog17

  addikt

  válasz Abu85 #55 üzenetére

  Elnézést az értetlenkedésért, de a dVGA-k esetében miért nincs értelme? Sokkal több kakaó van bennük? Esetleg a PCI-E busz miatt keletkező nagy késleltetés a hátráltató tényező? (Csakhogy tiszta legyen a kép.)
  Elméletben a dVGA-knál is lehetne hozni ugyanazt a sebességet, mint az integrált termékek esetében?

• #54 huskydog17 addikt Abu85 #52

  Új Válasz 2012-06-13 22:05:42 #54

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  huskydog17

  addikt

  válasz Abu85 #52 üzenetére

  Köszi a kiegészítést!

  A diszkrét VGA- közül akkor tehát az Evergreen szériától (AMD oldalon) felfelé már gond nélkül mennének a HSA alkalmazások, csak lassan ha jól értem. Milyen hardver szükségeltetik ahhoz, hogy a HSA-ban (pl. BOLT) megírt alkalmazások a full speed-en menjenek? Itt említetted, hogy a Llano esetében hiányzik egy úgynevezett MMU. Ez pontosan mit takar és mekkora sebességvesztéssel jár?

• #51 huskydog17 addikt Abu85 #50

  Új Válasz 2012-06-13 21:52:40 #51

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  huskydog17

  addikt

  válasz Abu85 #50 üzenetére

  Az már világos, hogy a Java-hoz hasonlítható leginkább. A Java RE azonban minden CPU-n gond nélkül megy. A HSA is ilyen lesz vagy ehhez lesz valami spéci hardverkövetelmény? Az eddigi infók alapján nekem az jön le, hogy a HSA működéséhez az OpenCL API teljes körű támogatása elengedhetetlen. Tehát a HSA-nál a CPU továbbra is mindegy, de mellé kell egy OpenCL-t támogató VGA/IGP?

  A táblázatból több minden van, ami nem világos. Például:
  A Serial CPU gondolom a hagyományos CPU módot takarja, vagyis itt kizárólag a CPU számol. Mellette a következő két oszlop neve sem mond semmit. Az OpenCL-nél az első változatnál a -C kapcsoló mit jelöl?
  Ha jól értelmezem a grafikont, akkor az OpenCL -C a leggyorsabb mód, de a HSA Bolt esetében több lépcső kimarad, gondolom innen a sebességlöket.

• #46 lenox veterán Abu85 #39

  Új Válasz 2012-06-13 20:57:44 #46

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  lenox

  veterán

  válasz Abu85 #39 üzenetére

  Nekem johet, koszi.

• #40 kisza25 félisten Abu85 #21

  Új Válasz 2012-06-13 16:43:28 #40

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  kisza25

  félisten

  válasz Abu85 #21 üzenetére

  akkor, ha jól értelmezem amit írtál már a Llano APU is támogatja? mert akkor ha szerencsém lesz mikorra cserélném a lapost, addigra nyerhetek még egy kis időt HSA-ra épülő programokkal

• #37 dezz nagyúr Abu85 #27

  Új Válasz 2012-06-13 15:39:49 #37

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz Abu85 #27 üzenetére

  "Többségüknek közvetlenül nem, de a HSAIL teszi lehetővé nekik, hogy ne kelljen hardverre optimalizálni."

  Persze, de ezt írtam én is.

  A többihez most egyéb elfoglaltság miatt nem írok, majd este.

• #29 DRB senior tag Abu85 #27

  Új Válasz 2012-06-13 14:52:32 #29

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  DRB

  senior tag

  válasz Abu85 #27 üzenetére

  Azt hogy API csak úgy általánosságban értettem(vagy valami ilyesmi ), pl, mint hogy egy program nem fér közvetlenül a hardverhez(GPU-hoz, CPU-hoz, stb) hanem "valamin" keresztül(nem a driver), pl dx, vagy .net, vagy mitom' én még mi. Ilyen értelemben ez is így működik? Ha jól veszem ki a válaszod igen, de mondom nem vagyok programozó, így ha kérhetnék kicsit még hétköznapibb megfogalmazást, csak az fog megvilágosítani.

• #28 lenox veterán Abu85 #20

  Új Válasz 2012-06-13 14:47:05 #28

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  lenox

  veterán

  válasz Abu85 #20 üzenetére

  Amugy akkor szerintem az lehet a megfejtes, hogy ha egyseges cimter van, akkor ahhoz kepest jobb a teljesitmeny, mintha nem hasznalnak a gpu gyorsitast, mivel akkor tobb projektnel eri meg gpu gyorsitast alkalmazni.

  Olyan szempontbol nem lenyegtelen, hogy ez az aktualis technika, ami gyorsan valtozik, szoval azert, mert 2 evvel ezelott valaki mondott valamit, aminek alatamasztasara csinalt egy merest, az ma mar egy masik allitas, vagy hasonlo, de mas kornyezetben megfogalmazodo allitas alatamasztasara nem biztos, hogy alkalmas. Egyebkent azt a reszt azert gondolom vetted, hogy rakhatsz a pcie buszra dugott gpu memoriajara is egyseges cimteret, attol gyorsabb nem lesz, igy ez a ket dolog, nevezetesen az egyseges cimter es hogy pcie buszra kell-e dugni az accelerator kartyat teljesen fuggetlen dolog, tehat az egyikre hivatkozni, hogy a masikra vonatkozo allitast tamasszunk ala, ez teljesen ertelmetlen.

  Amugy visszaterve az elozo peldara, 2 evvel ezelott opencl-lel olyan 1.5-2 GB/sec koruli effektiv mem-gpu mem bandwidth-t lehetett elerni, es egy dual proc workstation-ben olyan 9-10 GB/sec effektiv memory bandwidth-t, kb ilyen arany latszik a linkelt grafikonon. Jelenleg egy Z800 workstationben kb. 5.5-6 GB/sec mem-gpu mem bandwidth-t lehet elerni, meg mindig 9-10 GB/sec memory bandwidth mellett, szoval a bottleneck joval kisebb, mint amit a grafikon mutat. A PCIE3-at meg nem mertem ki, de elvileg kb. duplazodik a sebesseg. A mem bandwidth pedig olvasasra 15 GB/sec, irasra 6 GB/sec dual proc SB-nel, szoval amig ez a problema meg nem javul, addig bizonyos esetekben egal, mas esetekben pedig 30% a performance hit a PCIE busznal, ha megjavul, akkor gondolom allando 30% lesz. De ez mar regen nem az, mint a kezdeti 2 vs 10. Persze latency meg mindig van, ami alkalmazastol fuggoen vagy erdekes, vagy nem, amiket en csinalok, azoknal foleg nem, az Adobe-nal is foleg nem.

  Az egyseges cimter, meg koherens memoria meg killer feature, de nem teljesitmeny szempontjabol, illetve csak ugy teljesitmeny szempontjabol, hogy olyanok is hasznalnak altala gpu gyorsitast, akik amugy nem tennek.
  Kivancsi leszek a stacked memory-ra, de nekem valahogy nagyon nehezen elkepzelhetonek tunik, hogy 64 MB cache-t csinaljon valaki, pedig az mar nagyon-nagyon minimum.

  dezz: Kivancsi leszek, ha igy lesz, akkor szuper lesz, de nekem hirtelen nem jut eszembe jobb otlet, minthogy cache-sel lehet ezt ertelmesen megcsinalni, akkor meg a cache mennyisege hatarolja be a jol megoldhato feladatokat.

• #22 vanhalen senior tag Abu85 #21

  Új Válasz 2012-06-13 12:42:25 #22

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  vanhalen

  senior tag

  válasz Abu85 #21 üzenetére

  Szoftverekre értettem a "terméket" Bocs, ha félreérthető volt

• #15 lenox veterán Abu85 #6

  Új Válasz 2012-06-13 11:41:06 #15

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  lenox

  veterán

  válasz Abu85 #6 üzenetére

  Ok, en ezt mashol mas mondatokkal latom, meg ahol ez a mondat van, ott vesszo van a performance es a portability kozott, szoval szerintem 'performance portability' egyutt nincs.

  Amugy akkor ez egy tevedes. A memcached key lookup nyilvan akkor mukodne jol diszkret gpu-n, ha nem kell odatranszferalni, nem tudom ki csinalta a grafikont, de ennek igy semmi ertelme sincs, meg 5870, az mikor volt mar?

  A kovetkezo lepes nem a chipre integralt gyors memoria lesz? Ahhoz gondolod, hogy pcie buszon fog menni az adat a main memorybol? Szerintem erdemes tul latni a marketinganyagon. A pcie busz okozta bottlenecknek nem az egyseges cimter a megoldasa, azt pcie busszal is meg lehet oldani, es majd csodalkoznal, hogy hol gyors, hol meg lassu a programod, annak megfeleloen, hogy hova tudtad foglalni a buffered. Ujra el lehet vitatkozni ezen, de az teny marad, hogy gyors memoriat csak megfelelo meretu cache-sel lehet valamennyire kivaltani, ami draga, ugyhogy nem valoszinu, hogy elterjed. Ha pedig van gyors memoria, akkor azt megkulonboztetve kell kezelni a lassutol, legalabbis ha performance-t akar az ember. Ha portability fontosabb, akkor persze lehet egyseges.

Új hozzászólás Aktív témák