Keresés

Hirdetés

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

  • Abu85

    HÁZIGAZDA

    válasz t72killer #1 üzenetére

    A játékok jellemzően GPU-limitesek, az kijelzők natív felbontásának növelésével még jobban azok lesznek. Itt a CPU nekik már nem segít, legalábbis nem 10-20%-os sebességnövelésekkel. Olyan jó 3-4x-es tempónövekedés kellene a jelenetszámítás oldalán, hogy újra CPU-limitesség váljon a dolog. CPU-val ez lehetetlen. IGP segítségével lehetséges, de még ha át is rakod rá a sortingot és a cullingot mint két egyszerűbb dolgot, akkor sem lesz 3-4-es boost tőle. Kétszeres persze kinéz.

    Programfüggő, hogy milyen a minőség. Bármin konvertálsz el lehet érni ugyanazt a minőséget. Egyébként a videókonvertálás nem fekszik annyira a GPU-nak, mert a sok adatpárhuzamos rész mellett van soros rész is. Ez az APU-k játszótere lesz, de még inkább a fix funkció+GPU. Energiahatékonyságban ez verhetetlen.

    (#2) ledgeri: Átírtam köszi. :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 D1Rect #21 üzenetére

    Paszta rá, kupak fel ... és mehet. A korábban megszokott forrasztás nem alkalmazható az Intel 22 nm-es node-ján készült lapkákon.

    [ 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 EvilSymbol #49 üzenetére

    Megint tombol a kihajtja-e mítosz. Emberek a játékok ma már GPU-limitesek. Ha raksz alájuk egy kellően erős procit (25k fölöttiek már azok) és a grafikát max-ra pakolod, a felbontás pedig Full HD közeli, vagy nagyobb, akkor totál lényegtelen a processzor, mert a GPU-limites lesz a beállítás. Vagyis gyorsabb processzorral nem fogsz sebességet nyerni, de gyorsabb VGA-val igen. Az új játékokban a GPU-limit már annyira kemény, hogy 1680x1050-ben is erősen előjön, vagy néha alatta is.
    A fejlesztőknek is feltűnt ez egyébként. Ők is beszéltek arról, hogy a programok egyre inkább GPU-limitesek. Inkább a vegyeslimitre kellene törekedni, de a jelenlegi irányok mellett ez lehetetlen. A Nixxes viszont már korábban felvetette, hogy ha a CPU-k teljesítménye a rettegett Utilization Wall miatt nem nő jelentősen, akkor ideje kihasználni a lapkákban lévő IGP-t, ezzel a rendszer CPU-limitessé tehető, mert a cullingot és a sortingot egy grafikus egység többszörösen gyorsabban csinálja, mint egy CPU. Ez egy értékes jövőkép, de az aktuális APU-knál az a probléma, hogy hiába a feldolgozásból eredő gyorsulás, ha azt elveszted az adatok másolásánál, mivel a CPU és az IGP még mindig különálló memóriaterületet használ.
    Jelen pillanatban tehát, ha maxon játszol és nagyobb sebességet akarsz egy játékban, akkor inkább GPU-ra költs. Ha lowon játszol, akkor költs processzorra, mert a low beállításokkal CPU-limitessé teszed a rendszert.

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

  • Abu85

    HÁZIGAZDA

    válasz EvilSymbol #54 üzenetére

    A BF3 az speciális eset több szempontból is. Egyrészt Bulldozerre optimalizálták, így még mindig, több patch ellenére is haklis benne a HyperThreading kezelése. Tehát ha nem akarsz akadozást, akkor azt érdemes kikapcsolni. Ezzel pedig a kétmagos Intel procikat ki is lőtted, mert kell a négy mag, ha már 12 szállal dolgozik a motor. A Core i5 az jó BF3-ra, mert eleve nincs HT, és négymagos is.

    (#55) fatallerror: Jövőre jöhetnek játékok így, mert a Kaveri APU kihúzza a legnagyobb méregfogat a CPU és az IGP megosztott memóriájával és címterével. A Trinity esetében esetleg opció a HSA-MMU, de az nem az igazi, mert attól még a CPU és az IGP memóriaterülete különálló.

    [ 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 #57 üzenetére

    A Haswell az nem lesz olyan integráció. Az Intel továbbra is marad a fizikainál, de nem lép tovább rendszerszintűre.
    A VGA-ról semekkorát. Azok a terhek rakhatók át IGP-re, amiket eddig a proci végez. Ebből sok van, de első körben olyan dolgokat kell választani, amelyek könnyen tesztelhetők, és biztos nem befolyásolják a játékmenet alapvető működését. Értékelhető opció tehát a frustum és az occlusion culling. Előbbi rengeteg vektoros számítást használ, míg utóbbi gyakorlatilag egy előrenderelés nagyon egyszerű objektumokkal. Ezek nagyon ideálisak egy IGP-nek. Utóbbi konkrétan renderelés, vagyis az IGP-nél aligha tudja bármi gyorsabban csinálni. A sorting szintén nagyon jól párhuzamosítható, de fontos a megosztott rendszermemória és a közös címtér, mert csak így lehet hatékony. Hasznos lehet még a tartalomkikódolás, amivel jobb streamelés jöhet, hiszen a játékok úgyis arra haladnak, hogy legyen kevesebb töltőképernyő.

    (#58) EvilSymbol: i5-öt vegyél az jó. Az i3-nál a mostanid jobb a BF3-ban, mert az amúgy is kioszt 12 szálat, ha van rá lehetősége.
    A HT problémája a BF3-nál áll fent. Ez az elején sokkal durvább volt, de pár patch aránylag rendbe rakta. Mindenesetre kisebb akadások még mindig vannak. A BF3-at a DICE elrontotta, mert az AMD-vel készítették a játékot. Ez nem baj, de a Bulldozerre optimalizálták, ami egy CMT-szerű többszálúságot használ. Ez még mindig nem baj, de az erre optimalizált kód nagyon rosszul működik az SMT-szerű többszálúságon, amilyen az Intel HT. Ez már baj. Az egészet egyébként nem lehet érteni, mert az SMT-re optimalizált kód viszont nagyon jól működik CMT-n, szóval nehéz felfogni, hogy miért Bulldozerre optimalizáltak. Persze elviekben valóban nem lehetett látni, hogy a HT nem tűri jól a kódot, de gyakorlatban megnézhették volna. Volt is publikus béta, ha egy valaki beküldi, hogy gyerekek ez nekem akad HT-vel, akkor biztos ránéznek. Vagy esetleg, ha az Intel figyel erre, mert nekik is kellemetlen ez. Az AMD és az NV azért küld embereket a fejlesztőkhöz, hogy azok a tesztelők felderítsék a hibákat. Ezt az Intel is megtehetné, mert nekik is lenne rá erőforrásuk, ők viszont úgy vannak vele, hogy a piacvezető szerep miatt úgyis Intelre optimalizálnak. Ez ma már nem így működik, mert a fejlesztéseket az AMD és az NV erősen támogatja, vagyis ahonnan jön a pénz és a hardver arra megy az optimalizálás.

    [ 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 miresz #63 üzenetére

    A HT az nem rossz. Teljesen normális SMT megvalósítás. Az egyetlen gondja, hogy a programozói oldalról pátyolgatni kell a lelkét, mert bizonyos kódokat nem szeret. Ezt észben tartva nincs baja.
    A CMT az máshogy működik. Annak eleve nem lehet gondja, mert a szálakhoz dedikált erőforrás tartozik. A HT-nél nincs dedikált erőforrása a szálaknak, hanem egymással versenyeznek érte.

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

  • Abu85

    HÁZIGAZDA

    válasz Löncsi #66 üzenetére

    Szerintem nem annyira tragikus a helyzet, mivel nem az áll fent, hogy egymást ütik a konkurens megvalósítások. Ha HT-re optimalizálsz, akkor a dedikált erőforrásokkal dolgozó rendszerek attól még jól fognak működni. Szóval logikus, hogy erre kell optimalizálni. Persze lehet, hogy még lesznek negatív példák a HT kihasználására, de szvsz egyre ritkábban.

    [ 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 Viktor77 #78 üzenetére

    A Bulldozer az 8 magos, vagy 4 modulos, de semmiképp sem 4 magos.
    A nyolc szál dedikált erőforrásokat kap, mintha 8 mag lenne a lapkán belül. Annyi a különbség, hogy jellemző, hogy az FPU-t ritkábban használják a programok, mint az integer clustert, így az FPU-t az AMD úgy tervezte, hogy ha a modulban az egyik szál nem használja, akkor megkaphatja az egészet a másik szál, ha esetleg az meg igényli. De ha mindkét szál használja, akkor pedig el lesz felezve, és mindkét szál megkapja a saját felét. Mivel a mai programok 99,99%-a nem használ AVX-et, így ez a rendszer úgy eredményez maximális kihasználást, hogy nem kell szálakhoz dedikálni egy sokkal szélesebb FPU-t az AVX miatt. Az SSE utasítások úgyis 128 bitesek, szóval egy 256 bites feldolgozó ezek mellett állandóan kihasználatlan.

    (#69) fatallerror: A Haswell az nem. Az Intelnek nincs meg a GPU-technológiája ahhoz, hogy a LOC/TOC magok közös címteret és koherens memóriát osszanak meg. Majd a Skylake esetében oldják ezt meg.

    (#72) T-bag: Azzal két probléma van. A súlyosabbik, hogy nem tudja senki, hogy mi az, de mindenki találgat. Ezzel igazából nehéz az elemzése is. Szóval előbb biztosan tudni kellene, hogy mi az a Crystalwell, mert van rá legalább három változat.
    A másik dolog, hogy a sebességen lehet javítani, de az igazi áttörés a heterogén éra szempontjából a megosztott rendszermemória. Ez veti ugyanis vissza a fejlesztéseket. A Trinity elég jól tudja hasznosítani a HSA-MMU-t, de akkor sem közös a címtér. Fizikailag akkor is különálló memóriája van a CPU-nak és az IGP-nek, vagyis ha kell valami az egyiknek a másiktól, akkor azt nem lehet úgy elérni, hogy behívom szimplán a memóriából. Az adatmásolás pedig drága, mert addig áll a munka. Szóval a rendszerszintű integráció csak úgy jöhet el, ha a CPU és az IGP közös címteret és teljesen koherens megosztott memóriát használnak. Ez a must have dolog az egészben, mert enélkül nem működik hatékonyan.

    (#77) Löncsi: Ez nem teljesen igaz. Vannak még játékok, amelyek 2-3 szálon dolgoznak, de a többség már elért a 4-6-ig. Az újak 8-at is használnak, vagy 12-t extrémebb esetben. A 4-8 szál jellemző már.

    (#70) EvilSymbol: Egyszerű. A skálázást a Dennard Scaling határozta meg régen. Ez a szabály 2003 óta egyre gyengébben muzsikál minden gyártástechnológiai váltásnál. Vagyis lehet egymagos processzort csinálni, csak fogyasztana vagy 500 wattot azzal a teljesítménnyel, amivel most mondjuk egy Core i7-3960X fogyaszt 130-at. A Dennard Scaling lényegében egy kihasználhatósági falba fut (ergo zsákutca), ami miatt a piac elfordult az egymagos termékektől, és elkezdtünk több magot pakolni a lapkákba. Mivel a Dennard Scaling egyre gyengébb, így két éve integráljuk az IGP-t is, mert már a magok számának növelése is zsákutcába visz. Mindenről a Dennard Scaling haldoklása tehet. Ma is tök jó lenne egymagos procival osztani, de a fizika törvényei lehetetlenné teszik. Ezért 2005 óta a homogén többmagos iránnyal skáláznak a cégek. Ennek is vége van azonban, így a cégek indulnak a heterogén többmagos irány felé, mert a teljesítményt skálázni 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 Viktor77 #78 üzenetére

    A Win 8 az nem sokat segít ennek, persze lesznek szituációk, ahol +10% hozható, mert valóban nagyon újszerű ez az elv. Az AMD ezzel a felépítéssel már arra készül, hogy ne fusson bele az Utilization Wallba. Ugyanez történt az Athlon XP és a Pentium 4 idején. Az AMD látta, hogy a Dennard Scalingra nem lehet 100%-osan építeni, ezért nem azt az utat járták, amit az Intel, mert féltek, hogy belefutnak egy skálázhatósági problémába. Az Intel belefutott, míg az AMD nem, így elég jól vették a többmagosítás akadályát is. Tulajdonképpen most ugyanettől félnek, mint pár éve. Igaz már többmagos a rendszer, de ettől továbbra is gond a skálázhatóság, ezért már eleve úgy terveznek, hogy az IGP beépítésével a CPU és a GPU kiegészítse egymást. A fizikát sosem sikerült senkinek sem megvernie, így valószínű, hogy most sem lesz másképp és az AMD már nem is próbálkozik ezzel, hanem már most mindent felraknak a skálázhatóságra, és az integrációra. Jelenleg úgy áll a helyzet, hogy két évvel hamarabb sikerül behúzni rendszerszintű integrációt, és a komplett szoftveres infrastruktúrát hozzá. Valószínű, hogy az ARM és a Samsung támogatásával ez az előny elég lesz ahhoz, hogy eldöntse a fejlődés irányát. Abból, hogy Johan Andersson a SIGGRAPH-on minden gyártót felszólított a HSA támogatására a fejlesztői oldalon az irány szintén el van döntve. Nyilván repi pontosan tudja, hogy kell egy vISA ahhoz, hogy a jövőben ne kelljen minden rendszerre külön megírni a programot, és azt is sejtheti, hogy a HSA-nál nyíltabb alternatíva erre nem lesz.

    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 #89 üzenetére

    Az Intel a közös címteret és a megosztott memóriát a Larrabee integrálásával oldja meg. A Larrabee és a GCN egy célt szolgál, csak az Intelnek nem sikerült olyan gyorsan megcsinálnia, mint az AMD-nek az ATI tapasztalatára építve. Egyébként való igaz, hogy eredetileg a Haswellbe tervezték a Larrabee integrálását, de tekintve, hogy a Knights Ferry-ben és még az az előtti verzióban sem működött jól, így inkább csúsztatják. Jobb csúsztatni, mint rosszul skálázódó terméket csinálni.

    [ 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 TaaT #92 üzenetére

    Nem ezt mondtam. Futni fog. Itt technikai részletekről beszélünk.

    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