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

• #203 Prof addikt lenox #201

  Új Válasz 2012-10-03 00:52:36 #203

  Ú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

  

  Prof

  addikt

  válasz lenox #201 üzenetére

  Én is pont ezt kérdeztem, aprón g840+7750 =35k.

• #207 attiati veterán lenox #201

  Új Válasz 2012-10-03 01:04:03 #207

  Ú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

  

  attiati

  veterán

  válasz lenox #201 üzenetére

  +1

  Időtálló foglalatnak tűnik az LGA1155, fogyasztás is jó, ára is hasonló.

  erre nekem valaki plíz

  [ Szerkesztve ]

• #214 Oliverda félisten lenox #201

  Új Válasz 2012-10-03 01:30:24 #214

  Ú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

  

  Oliverda

  félisten

  válasz lenox #201 üzenetére

  Éppen lehet, de szerintem borítékolható, hogy CPU-ban a G550-et az A8 és az A10 is eléggé verni fogja. A 6670 okán nagyjából az mostani tesztben szereplő szingli VGA-s eredményeket kapnánk, ergo az A10-nél jobb lenne a 3D-s megjelenítési sebesség. A teljes rendszer fogyasztása magasabb lenne, valamint egy plusz zajforrás lakozna a konfigban a VGA személyében. Nagyjából ennyi.

  [ Szerkesztve ]

  "Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

• #382 Abu85 HÁZIGAZDA lenox #201

  Új Válasz 2012-10-03 15:07:44 #382

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz lenox #201 üzenetére

  A játékokra meglehet csinálni, de OpenCL-re ezt nehezebb megoldani. Az a baj, hogy hiába van úgy kialakítva a szabvány elviekben, hogy gyártófüggetlenül működjön, a gyakorlatban ez nem mindig működik. Én Intel CPU+AMD GPU mellett az AMD OpenCL driverét használom a procira is, és most tesztelgetem az OpenCL alkalmazásokat, és nem tudom mindben az összes funkciót normálisan megnézni. Eközben, ha átrakom az Athlon mellé a Radeont, akkor pöcre megy minden fagyás nélkül, és ugyanúgy csinálom. Az Intel OpenCL CPU driverével már nem fagy, de nem is kapom meg pár programban az OpenCL-es gyorsítás lehetőségét.
  Egyelőre baromira képlékeny az egész. Ennek úgy kellene jól működnie, hogy minden gyártó biztosítja a hardveréhez a megfelelő OpenCL drivert és a cégek ebből a szempontból összedolgoznak, hogy ne legyenek problémák. Emellett nem ártana, ha nem csak az AMD segítené ezeket a fejlesztéseket, mert így a tesztelés is baromira egyoldalú. A Corel is mekkora támadásnak volt kitéve, hogy a WinZip gyorsított tömörítése csak AMD-n fut, miközben elmondták, hogy ez azért van így, mert az Intel és az NV nem segített nekik, hogy jól működjön a termékeiken. Én úgy gondolom, hogy alapvetően itt a legnagyobb baj azzal van, hogy van három cég, melyek másképp állnak hozzá az OpenCL-hez, és nincs igazán megegyezés. A fejlesztő, aki OpenCL-ben akar írni programot rá van kényszerítve az AMD támogatására, mert az NVIDIA számára a CUDA fontosabb, míg az Intelnek az OpenCL nyűg lesz, ahogy GPU-s gyorsításra akarják használni. Akkora az ellentét, hogy szerintem itt rövid időn belül nem lesz változás. A C++ AMP hozhat egy kis fényt. Az nem közvetlenül az OpenCL ellenfele, de ettől még jó, mert az egyszerűbb dolgokat egyszerűbben megoldhatod a bonyolultakat pedig nehezebben. Utóbbi rossz, de pontosan ezért nem tekinthető az OpenCL igazi kihívójának. Inkább egy más megközelítése a GPU-s gyorsításnak. A gyártói támogatás oldaláról pedig jóval egyszerűbb az egész, mert DC5.0-s drivert kér és kész.

  (#371) juzer78: Igazából azt csinálják, amit leírtál. A skálázást készítik elő. A korábbi K10 architektúra a Bulldozer tudásával jóval nagyobb lett volna, vagyis több tranyót igényelne, és nagyobb lenne a fogyasztása. Ezért tértek át az új megvalósításra, mert az jobban illik az integrációhoz, és a mobil irányt figyelembe véve a fogyasztása is jóval kedvezőbb. Idle-ben a Piledriver az élmezőny. Ezeket nem a gyártástechnológiai fejlesztés hozta össze, hanem a tervezés. A modernebb gyártástechnológia már csak elenyésző fogyasztás csökkentét hoz, minden váltás egyre kisebbet. 20 nm alatt úgy számolnak a cégek, hogy konkrétan semennyit nem lehet majd nyerni. Nyilván belekalkulálva az aktuális véleményeket, teljesen normális, hogy áttértek a moduláris dizájnra, mert enélkül rengeteg energiát pazarolnának. Helyette a skálázhatóságra helyezik a hangsúlyt, és a chip tervezésénél próbálják meg "kikerülni" a fizika törvényeit. De ezt már mondtam, hogy mindenki ezt csinálja. Az AMD-nél azért látod ezt ennyire agresszíven, mert megvették az ATI-t, és így 2 évvel hamarabb meg tudják oldani azokat a gondokat, amelyekre a legtöbbet 2015 után fognak reflektálni. Az NVIDIA az a cég, amely hamarabb képes a rendszerszintű integráció irányát felvenni. Ha egy picit kockáztatnak, akkor 2014-ben simán megcsinálják ugyanazt a Maxwell APU-ban, amit az AMD 2013-ban a Kaveriben. Nyilván az Intelnek 2015 a leghamarabbi opció a Larrabee integrálására. Az ARM és az ultramobilos társulat is ekkora készül el az új generációs IGP-kkel.
  Az, hogy az Intel EM64T-nek hívja még AMD64. Az AMD-től licencelik. Elnevezhetik, ahogy akarják, de ettől a technológia tulajdonosa az AMD.

  (#376) juzer78: A HSA elsősorban nem a haszonszerzésre megy rá, hanem a könnyebb programozásra. Az egy olyan egységes infrastruktúra, amiben a fejlesztőknek egyszer kell megírniuk a kódot, és az garantált, hogy minden hardveren - legyen az HSA-t támogató, vagy nem támogató - futni fog. Ezért alapítvány dirigálja, mert alapvetően szükség van egy ilyen kezdeményezésre, mert a fejlesztők nem fognak minden hardverre külön optimalizálni.
  Az az előny, hogy egyszer megírod, és mindene fut módosítás nélkül hatalmas előny. Nem kérdés a fejlesztőnek, hogy megéri. Miért nem érné meg nekik. Sokkal kevesebbet dolgoznak a programon, és sokkal több hardveren fog futni, mintha külön optimalizálnák az egyes termékekre.
  A HSA 1.0 az kész. Ott van a munkacsoportnál, és arra várnak, hogy a Samsung és a TI rábólintson. Persze eközben a fejlesztőkörnyezetek készülnek, így az AMD már kiadta a CodeXL bétát, amibe majd ha el lesz fogadva az 1.0-s szabvány, akkor bekerül a támogatás. Addig OpenCL-es és C++ AMP-s programot lehet írni, és azok automatikusan profitálnak majd a HSA runtime megjelenéséből, ami 2013-ban kerül kiadásra.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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