Keresés

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

  • Abu85

    HÁZIGAZDA

    válasz MPowerPH #203 üzenetére

    Nem a rendelésen múlik. Akkor sem közölhetünk semmit, ha veszünk egyet.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz Mozsa #212 üzenetére

    Ők sem közölhetnek. Ezeknek meg lesz a jogi következménye. Ez számunkra nem járható út. Mi tartjuk magunkat a szerződéshez.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz adalbert1 #215 üzenetére

    Minden termék startja úgy működik, hogy van egy szerződés, amit alá kell írni. Ez a belépő ahhoz, hogy kaphass terméket, és azt tesztelhesd a megjelenés előtt. Ezenkívül megkapsz minden segítséget az adott gyártótól a teszt elkészítéséhez. Sajtóanyagok, kérdésekre válaszok, stb. Az NDA garantálja elméletben, hogy a termékről semmi sem jelenik meg a megjelenés előtt. Ezt az NDA-t viszont meg lehet szegni. Nem illik, és nem is ajánlott, de ki lehet rakni egy cikket az NDA lejárta előtt. Sajnos az olvasókért folytatott harcban ezt néhányan bevállalják, de ennek mindig lesz szankciója.
    A dolog egyébként elég normálisan van megoldva, csak van aki nem akarja betartani a szabályokat.

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

  • Abu85

    HÁZIGAZDA

    No para srácok lesz Ivy, de nem most. Később viszont mindenki megveheti. Majd lesz róla egy csomó bemutató, teszt, hír. Addig türelem. :R

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

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #406 üzenetére

    Egy szilíciumostya egészen elképesztő hőmérsékleteket is kibír. A maiak 120°C-on is elvannak. Nagyjából 130-140°C jelent problémát. A 100°C például Ultrabook szabvány, vagyis maximum ennyin mehet a proci és a dGPU. Persze mehet kisebb hőtermelés mellett is, de sajna sok gyártó kihasználja a lehetőségeket. Nyilván a hűtés nem valami komoly egy vékony gépben.
    A csíkszélességre a feszültség van kedvezőtlen hatással. De ez sem általános dolog. A gyártástechnológiák különbségétől is nagyon függ.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz fatallerror #408 üzenetére

    Arról, hogy hol merre mi mennyi nem tudok nyilatkozni. Majd megnézzük. :)

    Gondolom az ominózus oldalak feltöltötték a bankszámlát a büntire. ;)

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

  • Abu85

    HÁZIGAZDA

    válasz fatallerror #410 üzenetére

    Nem mondhatom meg, hogy mink van/lesz. Majd kiderül. :) Minél több termékre szeretnénk mérést.

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

  • Abu85

    HÁZIGAZDA

    válasz 04ahgy #513 üzenetére

    A main VGA mindig aktív. A PCI Express vezérlőnek fogadnia kell a jelet, ami feléleszti, ha jön a terhelés. Semmilyen átkapcsolás nem lövi le teljesen a VGA-t, csak nagyon alacsony fogyasztási szintre állítja. Ettől 2-4 wattot még enni fog.
    Az elméleti oldalon van értelme a koncepciónak, de amilyen problémákat hoz maga a muxless átkapcsolás, mint például a játékokban csökkenő teljesítmény, vagy a kétdriveres vezérlés drasztikusan megnövelt hibalehetőségei ... hát meggondolandó.
    A koncepció és az ötlet egyértelműen dicséretes, de a gyermekbetegségek komolyak, és szoftveres átkapcsolással leküzdhetetlenek. Hardverest pedig Virtuval nem lehet alkalmazni, mert más az IGP és más a GPU gyártója, vagyis mindenképp két driver kell.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz Klikodesh #877 üzenetére

    Viszont cserébe az IGP sokkal jobb lett. :) Ez volt az Ivy lényegi fejlesztése. Két oldalon elemeztük is, hogy szépen ki lett gyúrva. Az általános számítások felé viszi az Intel.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz Klikodesh #881 üzenetére

    Látom, de csak a teljesítményt mérik. Fura, hogy architektúra mélységeit eddig máshol nem láttam. Pedig nagyon fontos változások voltak, amiket mérésekkel talán nem lehet kimutatni, ezen sokat dolgoztam, hogy megszerezzem az adatokat.

    Az IGP sokkal fontosabb volt. Az Intel is látja, hogy megáll a skálázás. Egyszerűen az IGP biztosítja a további teljesítményt. Azt nem mondom, hogy ez egy szuper IGP. Vannak még hibái, de azt kell nézni, hogy honnan indultak. A Gen6 egy ezer sebből vérző szar volt, most pedig a sebeket bekötözték, és skálázhatóvá tették, emellett felokosították is, hogy ne legyen gondja a programok, illetve a játékok általános gyorsításával sem. OpenCL-lel és C++ AMP-vel már ott a lehetőség a fizika számítására az IGP-n. Minden extra GHz-nél többet ér ez a teljesítményben, és a fogyasztás sem lesz magas.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz Klikodesh #903 üzenetére

    Az IGP-t mindenki erőlteti. Az AMD annyiban különbözik a többiektől, hogy hamarabb meglátták a Dennard scaling végét. Éppen ezért a reakciójuk is gyorsabb volt mindenkinél, amellett, hogy nagyon leegyszerűsítették ezt a kérdést az ATI felvásárlásával. De a lényeg mindenkinél ugyanaz. A skálázhatóságnak vége, a processzormagok számát nem tudod növelni, a teljesítmény oldalán pedig +10%-ért vért kell izzadni évről-évre. A megoldást erre a gondra a GPU hordozza, mert ezek az egységek jóval kisebb energia mellett képesek egy operáció elvégzésére, mint egy processzormag.
    Ha a skálázás biztosítható lenne a processzormagok fejlesztésével, akkor az Intel sem gondolta volna újra a grafikus architektúrát az Ivy-ben egy Tick lépcsőnél. A változásokkal azonban kockáztatni kellett, mert a CPU oldaláról nem lehet normálisan skálázni a teljesítményt. Ennek az IGP az egyetlen reálisan elfogadható módja. Van másik, amit a Pollack-féle szabály ad, de ott ki kell végezni az egy szálon elérhető teljesítményt. Itt a jövőben valószínűleg lesznek visszalépések, de a nem komolyak. A Pollack-féle szabály drasztikus visszalépés mellett lehet életképes. Ez Atom szintű magokat jelentene, amit viszont nem tartanak túl jó ötletnek a gyártók ... szerencsére.

    A GPGPU-s alkalmazásokat nem kell keresni, csak észrevenni. Az Intel 150 alkalmazásról beszélt, míg az AMD nagyjából 200-at támogat, ami képes az IGP erejét valamilyen módon hasznosítani. Nyilván a különbséget elsősorban a Stream okozza, ami az AMD saját technológiája, de ennek a fejlesztését már a cég leállította, így mindent visznek át OpenCL-re. Persze pár Stream alkalmazás megmarad, de annyira nem lényeges ez. A fejlesztés alatt álló programokat át fogják írni egy támogatott platformra.

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

  • Abu85

    HÁZIGAZDA

    válasz Klikodesh #906 üzenetére

    Mindenki érdeke, hogy a skálázódás fenntartható legyen. Az Intelé is, mert annál nincs rosszabb, hogy az AMD-n baromira jól fut, de náluk sehogy. Ezért nyitnak ők is. Az, hogy mennyire komolyan gondolják az Ivy mutatja. Egyszerűen egy Tick váltásnál képesek voltak áttervezni a GPU-architektúrát. Ez nagy kockázat ám.

    Az AMD már régóta támogatja a szoftverfejlesztőket, hogy Open64 compliert használjanak. A játékfejlesztők már meg is hallgatták őket ezzel kapcsolatban. Sok AAA kategóriás játékhoz ezt használják. Ez annyira nem nagy előny láthatod.

    Az OpenCL és a CUDA az nehéz. Nem kétséges, hogy ezen változtatni kell. A C++ AMP valamivel könnyebb, de korlátozottabb is. A változást egyébként az hozhatja, ha szimplán natív C++-ban lehetne programozni a GPU-t. A Larrabee ilyen lett volna, illetve az AMD a GCN-nel nagyon erősen ebbe az irányba lépett. A vISA lesz ennek a kiterjesztése. Ugyanez megvan az Intel és az NVIDIA oldalán is. Az AMD HSA-jának annyi az előnye, hogy a specifikációi nyíltak lesznek, így az ARM és az ARM-ra építő cégeknek ez lesz az egyetlen lehetséges alternatíva, mert az Intel és az NV megoldása zárt.

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

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #910 üzenetére

    Tri-Gate mellett eleve kizárt volt. Ez nem olyan egyszerű, hogy az előd tudta, akkor ez is. Alapvetően mások a tranzisztorok, más területekre vannak optimalizálva.
    A fejlesztés van a rendszerben. Több is mint azt egy Ticktől várni lehetett volna. Nem annyira tuningolható léggel, mint a Sandy, de nagyságrendekkel jobb az IGP, ami az Intelnek fontos, hiszen így már nem probléma a GPGPU-s gyorsítás az alkalmazásokban. A keserűség szerintem nem megalapozott. Véleményem szerint nagyon szépet fejlődött az IGP, ahol arra szükség volt, és ez jelenti az Ivy előnyét a Sandy-hez képest. Ezt még nem látod az alkalmazásokban, de ott az OpenCL támogatás, ami kész és lesz C++ AMP is, hiszen a DirectCompute 5.0 adott. Szépen ki lehet használni az IGP általános számítási képességeit, hiszen az erőforrást és a pénzt a fejlesztésbe belerakták, így kamatoztatni is érdemes.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #916 üzenetére

    Csak a VGA-d közvetlenül nincs a processzormagok mellett. Sok feladatban borzasztóan limitáló a PCI Express busz. Ma szándékosan úgy írják a programokat, hogy ebből ne legyen baj, mert a fejlesztők ismerik a rendszer korlátjait, de az IGP-k mellett erre nem kell figyelni. Az AMD az Intel megoldása is pár nanoszekundum késéssel képes adatot feldolgozni, majd visszaadni. Erre az AMD-nek már van Zero Copy támogatása, és gondolom az Intel is dolgozik hasonlón, ha már a hardvert ennyire kigyúrták a GPGPU-ra.
    Lehet, hogy még nem látod, de sokkal többet fog érni az általános számításra képes IGP, mint az 5 GHz-es tuning. Azzal, hogy az Intel végre aláírta ezt a fejlődési irányt biztosan.

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

  • Abu85

    HÁZIGAZDA

    válasz HSM #912 üzenetére

    A HD 4000 sokkal gyorsabb. A HD 2000 nagyjából a felét tudja. Szóval érdemes 4000-et venni.
    Pont erről írtam a harmadik oldalon. Az Intel kigyúrta az IGP-t GPGPU-ra. A Sandy buta volt. Ez már nem az, és jobb is a felépítés. Grafikában vannak limitáló tényezők, mint a gyenge ROP és a viszonylag gyenge setup rész, de az EU-k az IGP-n belüli L3-mal eléggé komálják majd a számításokat. A szálkezelés sokkal jobb lesz, így a co-issue képesség is sokszor használható majd ki szerintem. OpenCL támogatás már van. Ezt persze még fejleszteni kell, de ez csupán szoftveres kérdés. A C++ AMP támogatás még nincs bejelentve, de a DirectCompute 5.0 megy, szóval ez is csak szoftveres kérdés. Sőt, ez gyakorlatilag kvázi támogatás, mert csak engedélyezni kell, amikor itt a felület.

    Az Intel látva a skálázási problémákat elvitte a fejlesztést az IGP irányába. Lényegében ez az Intel első igazi APU-ja. Követik az AMD-t ebben az értelemben. Mivel mindenkire vonatkoznak a fizika törvényei, így mindenki ugyanazt a következtetést vonja le a Dennard-féle skálázási szabály kihalásával a homogén többmagos processzorok skálázása is megállt. Kvázi ugyanaz a probléma mint az egymagos processzorok hattyúdalánál, csak most több a megoldandó gond, de lépni kell, mert a skálázódás nem tartható fent. Erre a cégek egységesen a heterogén módon programozható lapkákat látják megoldásnak, ami logikus, mert a grafikus vezérlő a jellegéből adódóan sokkal kevesebb energiát igényel egy operáció végrehajtásához. A Dennard-féle skálázás nélkül lényegében az a cél, hogy az operációk végrehajtása kevesebb energiát igényeljen, mert a gyártástechnológia fejlődése már fizikai határokat feszeget, így az ingyen ebédnek lőttek. Moore törvénye él, mert egységnyi méretbe több tranyót lehet pakolni a csíkszélesség váltásoknál, de ez semmit sem ér, ha a bekapcsolásukhoz szükséges energia nem, vagy csak alig csökken. Innentől kezdve a chiptervezőknél pattog a labda. A gyártástechnológia fejlődésében nem bízhatnak, így a tervezés szintjén kell növelni a hatékonyságot. Ezt lehet a Pollack-féle szabállyal csinálni, vagy ha nem akarják kivégezni az egy szálú tempót, akkor a heterogén éra marad. Egyelőre az utóbbit választották a cége okkal, így a fejlődés erre megy. Innentől kaptak egy pöttyös labdát a szoftverfejlesztők is, hogy ideje brutál mód párhuzamosítani, akár úgy hogy átdobálják a feladatokat a CPU és az IGP között, vagy a program nem fut majd gyorsan. Ezt persze majd dobják vissza, hogy ez így nem jó, mert a mai integráció lényegében csak fizikai jellegű, de az architektúrákat egymáshoz kellene tervezni, hogy ne kelljen felesleges másolgatásokat csinálni a rendszermemóriában. Ezt a labdát a cégek nyilván elfogadják, és az integráció új generációját már úgy tervezik, hogy architekturálisan is egymáshoz illő komponensekből álljon a lapka. Lásd Kaveri APU, mint a következő evolúciós lépcső. Ugyanezt fogja mindenki másolni. Az Intel is, csak a Larrabee leszármazottja még nincs olyan állapotban, hogy bevethető legyen.

    Elég sok dologra használható az IGP. Már az Intelé is elég okos. A peak FLOP teljesítmény az nem annyira erős, de jól etethető, így az átlagos tempója jó lehet. Persze ez függ az algoritmustól, de maximum a co-issue mód nem használható, az elsődleges vektor viszont etethető. A mire pedig a fejlesztőkön múlik. Nyilván lehet fizika számítására. Egyelőre a DiRT 3 használ ilyet a látványra DirectCompute 5.0-val, de lehet játékmenetre is. Vagy ott az AI gyorsítása. A Shogun 2 a Llano APU-n, illetve a Brazos platformon az AI-t az IGP-vel számítja. Persze ez nem általános kód, hanem egy CAL-ban írt dolog, vagyis semmi máson nem fut, de van OpenCL, lesz C++ AMP, így ezek a lehetőségek megnyílnak.

    A másik rész itt az általános programok területe. Ott az új WinZip 16.5, ami OpenCL-lel gyorsítja a feldolgozást. Ez egyelőre csak AMD-n működik, de a kód megvan, így kellő tesztelés után az Intel és az NVIDIA OpenCL driverére is engedélyezik. A WinZipben tisztán látszik az APU előnye. Az AMD Vision APU-kkal a gyorsulás mértéke 70-120% lehet terméktől függően. Sima VGA-val a PCI Express korlátozó, így ott a gyorsulás jóval kisebb. Nyilván az Ivy Bridge-es teszt még várat magára, de amint engedélyezik le lehet mérni, hogy mennyit gyorsul. Valószínűsítem a 60-70%-ot, mert az algoritmus hatékonyan futtatható ezen az IGP-n. Például az AMD TeraScale (aka VLIW) architektúráján a WinZip kódja nem olyan hatékony. Ez tipikusan abból ered, hogy az AMD ezt az architektúrát játékra tervezte, így sok helyen kompromisszumot kötöttek. A GCN architektúrán már nagyon hatékony a WinZip kódja. Például lehet venni egy 256 bites AES kódolást. Ezt lemértem a HD 5850-en és a HD 7850-en. Elméleti TFLOPS-ok tekintetében a HD 5850 jobban áll, de a HD 7850 mégis 3,8x gyorsabban futtatja az előbbi feladatott. Erre mondtam, hogy a peak FLOP érték nem biztos, hogy irányadó. Azt sem mondom persze, hogy nem, de ez nagyon függ a futtatott algoritmustól és az architektúrától.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz Pubszon #934 üzenetére

    A Windows 7 több grafikus drivert is elfogad. Innentől kezdve telepítheted a drivert az Intel IGP-jéhez is. Ettől még nem kötelező egy kijelzőt rákötni. Elvan az natúran magában.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz Pubszon #936 üzenetére

    Megmondod neki, hogy mely eszközöket használja.

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

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #940 üzenetére

    Ezek alapján az iparág legjobb szakértőit dolgoztató Intel, AMD, NVIDIA trió tévúton van a jövővel kapcsolatban. De még az ARM-os gyártók is.
    Szvsz most kellene egy céget alapítani, és kötni az ebet a karóhoz ... hiszen a többmilliárd dolláros fejlesztési pénzeket elköltő cégek egységesen rosszul lőtték be a jövőt. Talán meggazdagodnánk egycsapásra. :) Meg is van az elméletem. A tokozásra egy olyan lapkát ültetünk ami fizikai értelemben nem a mi dimenziónkban lesz. Ezzel a mi fizikánk törvényeit felülírhatjuk úgy ahogy akarjuk. Nem is értem, hogy ez a többieknek miért nem jutott eszébe. :) Mennek egy teljesen értelmetlen jövőkép felé, amikor sokkal kézenfekvőbb megfejteni a negatív energia titkát.

    Nem akarlak megbántani, de az Intel/AMD/NVIDIA/és a többiek mérnökei okosabbak nálad. Sőt szerintem a fórumunkon fellelhető legtöbb embernél is. Mindezt a legnagyobb tisztelettel állítom. Hidd el ők tudják, hogy milyen problémákkal szembesül a chipgyártás és mi a megoldás rá.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #942 üzenetére

    Egy dologra gondolj. Egyszer ugyanezekkel a problémákkal szembesült a chipgyártás. Igaz, hogy nem voltak annyira súlyosak mint ma, illetve a Dennard scalling is csak a zátony felé közelített, és nem futott rá mint most, de mégis elég volt ahhoz, hogy a csodás 10 GHz-es processzorok jövőképéről letérjünk a többmagos processzorok irányába. Kijöttek a holmik, de idő kellett ahhoz, hogy a programozók kihasználják az extra magot. Erre jöttek a megoldások pl.: pthreads, illetve később az OpenMP. Nem azért váltottak a programozók mert olyan marhára könnyű több szálra optimalizálni, hanem azért mert rá voltak kényszerítve. A versenyhelyzet kényszerítette őket, hogy a programokat versenyképessé tegyék a konkurens megoldásokkal.
    A helyzet ugyanaz mint pár éve, csak most teljesen megállt a Dennard scalling. Erre nem lehet már építeni. A teljesítményt tehát alig növekedő tranzisztorszám mellett kell előhúzni. A gyártók egységesen a GPU-ban látják a megoldást. Erre is vannak programozási megoldások. Régen a shaderekkel szenvedtek a kalandozók, és úgy kellett felépíteni a programot, mintha egy grafikus alkalmazás lenne, de mára van OpenCL, illetve C++ AMP. Ez nagyjából egy elfogadható szint. De kell egy egyszerűsítés, ami a következő lépés lesz. Ez a natív C++ támogatás. Itt nézheted az AMD GCN architektúráját, ami már támogatja, de ugyanúgy támogatni fogja az NVIDIA és az Intel későbbi megoldása is. Az Intelről már lehet is elképzelésed, hiszen a Larrabee alapjaira építik a jövőjüket, de még nem áll kész az implementálásra.
    Ugyanígy a programozók helyzetéről. Nem lesz könnyebb programozni. Ugyanúgy utálni fogják, mint a több szálra optimalizálást, de a hardverek skálázhatósága ebbe az irányba biztosított, így ez már nem választás kérdése.
    Valószínű, hogy a heterogén érában is elérjük a határokat, ahogy eddig is, de addigra remélhetőleg történik valami gyártástechnológiai áttörés.

    Lehet, hogy te ebben nem hiszel, és ehhez jogod van, de azt nem lehet vitatni, hogy a gyártók miben hisznek. Gondolhatod, hogy kielemezték a helyzetet, illetve a lehetőségeket, és úgy jutottak arra az álláspontra, hogy a gondokra a lehetséges megoldás a GPU integrálása. Nem kell, hogy tetsszen ez a jövőkép, de ez lesz.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz Valdez #943 üzenetére

    Feltelepíted az IGP-re a drivert, és nem kötsz rá kijelzőt. A driver betölt a Windows 7 indulásakor. A képen a Windows 7 arra a GPU-ra rakja ki, amire a kijelző van kötve. A sorrend az mindegy. Ahol ez számít az a Windows előtti állapot, de a legtöbb alaplap kínál lehetősége a GPU-k sorrendjének meghatározására. Megkéred, hogy a PCI Express porton keressek a GPU-t, ha ott megtalálja, akkor azon lesz kiküldve a kép.
    A driver betöltése után minden erőforrás megjelenik. Az IGP-n persze nem lesz kijelző, így az csak úgy ott lesz.
    A programtól függ, hogy az OpenCL hogyan van implementálva. De elméletben mindent be lehet fogni munkára.

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

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #948 üzenetére

    Van már egy elméleti cikk születőben a miértekről. Az NVIDIA és az ARM erről beszédes, így sok dolgot megtudtam. Manapság az Intelnek is megeredt a nyelve a heterogén éráról.

    Tesztelni fogunk programokat. OpenCL-eseketés DirectCompute 5.0-sakat. Amint itt lesz a Trinity erről lesz egy átfogó elemzés az Ivy Bridge mellett is. Addig nem, mert a programokat meg kell szerezni. Egyeztetni a fejlesztőkkel, hogy adják ide tesztelésre, ha meg nem, akkor a gyártóktól kell elkérni. Végső megoldás meg a vásárlás, amit annyira nem szeretnénk, de ha nincs más mód, akkor az is ok.

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

  • Abu85

    HÁZIGAZDA

    válasz Overlocker #1000 üzenetére

    Erről kérdeztem az Intelt. Azt mondták, hogy úgy működik az Ivy, ahogy eredetileg eltervezték. Ne foglalkozunk azzal, amit az az idióta OBR ír. Ezt szó szerint így írták, hogy idióta. :) Nincs semmiféle feszültségprobléma. Terhelés mellett az Ivy például kisebb feszültségen üzemel, mint a Sandy. Idle-ben nagyobb a feszültség, de ez a Tri-Gate miatt van így. Ez technikailag csökkenti a szivárgó áramot a nem aktív áramkörökön, és hatékonyabb az aktív tranyók működése. De ez nem a feszültségből ered, hanem a planáris és a FinFET különbségeiből.

    A melegedés pedig a lapkaméretből ered. Mivel kisebb helyen távozik a hő, így ugyanolyan hőelvezetés mellett, az egységnyi hőleadás nagyobb hőmérsékletet eredményez. Természetesen a feszültség emelésével ez rosszabb, de ez általánosan így van.

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

  • Abu85

    HÁZIGAZDA

    válasz radi8tor #1025 üzenetére

    Jó a 77 watt, az tartható. A gyártóknak van 95 watt leadva. A következő körben ez lesz a plafon, így az alaplapokat erre kell tervezni.

    Szerk.: HSM megelőzött, de a lényeg tisztázva van.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz subaruwrc #1009 üzenetére

    Szerintem ne hívjuk 2D-snek, meg 3D-snek. Ez egy baromira rossz elnevezés. A marketinges marhák találták ki, mert a 3D menő, de nagyon nagy hülyeség. Van planáris, amit sokan használnak. Az Intelnél az új az Tri-Gate ... illetve utóbbi elfogadott neve a FinFET.
    Értem a koncepciót, hogy meg kell magyarázni az embereknek, de szerintem ez felesleges. Az 1.0-s júzer ugyanúgy nem érti a 3D-t, mint ahogy a Tri-Gate-et, vagy a FinFET-et

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz Overlocker #1036 üzenetére

    Az Intel ezt azzal magyarázza, hogy a gyártók más speckókat kaptak, és ezek vannak feltüntetve a dobozon. A következő körben a Haswellből a legnagyobb 95 wattos lesz. Most 77 watt a hivatalos.
    Pontosítsunk. A melegedés max a tuningosokat fogja érdekelni. :) Az átlagfelhasználókat jobban izgatja, hogy teljesen új benne az IGP, ami új lehetőségeket nyit meg a fejlesztők előtt a grafikus rész általános számításokra való használata során.
    Csak a tuning részét tekintve a dolognak teljesen igaz, hogy a Sandy jobb.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    válasz g@bo #1124 üzenetére

    Az Ivy az OpenCL és DirectCompute képes IGP miatt időtállóbb. Az Intel soha nem látott erőket vet be az OpenCL terjesztésére. Ha ez bejön, akkor a Sandy itt nem sokat ér.

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

  • Abu85

    HÁZIGAZDA

    válasz slayer007 #1130 üzenetére

    Az Intel IGP-jét ne használd erre, ha nagyok az elvárásaid (főleg ne Full HD-re). Ilyen igényekkel az AMD IGP-je felé vedd az irányt. De amúgy a Trinity A10-5800K is nagyjából annyit fog tudni, mint a 9800GT-d. Az új játékokban lesz gyorsabb a fejlettebb architektúra miatt.

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

  • Abu85

    HÁZIGAZDA

    válasz slayer007 #1132 üzenetére

    Ezeket az igényeket nem fogja teljesíteni a HD Graphics 4000. Ez az IGP nem rossz, de főleg általános számításra alapoz. A grafikát gyenge setup és a ROP lehúzza.

    [ 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