2. Fórumok
  3. Processzorok, tuning
  4. Az AMD az integrációnak rendeli alá fejlesztéseit

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

  • #122 Abu85 HÁZIGAZDA julius666 #121
    Új Válasz #122
    Ú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 julius666 #121 üzenetére

    Nem mi jósoljuk ezt, hanem a gyártók. Mi csak leközöljük, amit a gyártók mondanak, bemutatnak, vagy tanulmányban publikálnak. Lesz majd egy olyan cikk, amit nem a gyártók adataira építünk fel, és arra keres választ, hogy miért megy mindenki erre. Ehhez már több mérnökkel konzultáltam (zömében ARM-osokkal, ők a legbeszédesebbek ebben a témában, meg tapasztalataim szerint úgy általában is), és a rövid válasz itt a fizika törvényei, de nyilván ezt ki kell fejteni. Az AMD itt a legkevésbé beszédes. Még az NV-től és az Inteltől is kaptam választ a fizikai kérdésekre. Persze ebből nincs gond. Általánosan akarom a dolgot vizsgálni nem pedig gyártóspecifikusan, így az AMD véleménye nem érdekes. Főleg úgy nem, hogy az ARM, az Intel és az NV is egységesen a fizika határait jelölik meg elsődleges gondnak, és ezt több tanulmány is hasonlóan látja. Zömében olyan levezetéseket kaptam, hogy növelheted a tranyót a gyártástechnológiai váltásoknál, mivel erre lehetőséget ad a kisebb csíkszélesség, de a tranyók bekapcsolásához szükséges áram már nem csökken olyan mértében, mint amennyi extra tranyót építhetsz be egységnyi területet figyelembe véve. Ez konkrétan az alapprobléma. Erre kell megoldás találni, ami egyszerűen az, hogy a tranyókat beépítheted, csak arra kell ügyelni, hogy ne legyen mind aktív. Fred Pollack szabálya szerint jó megoldás itt a processzormagok komplexitásának csökkentése, és ezzel az egységnyi területre beépíthető magok számának növelése. Ezt az NV a GTC Asia 2011-en is megemlítette, hogy járható út, csak kivégeznék az egyszálú teljesítményt, amire azért még van igény. Ezért a másik opció a heterogén elv, vagyis meg kell őrizni pár processzormagot viszonylag erősnek, a jól párhuzamosított számításokat pedig sokkal egyszerűbb magokra kell bízni, melyek jelentősen kevesebb energiát emésztenek fel. Ezzel a gyártók reagáltak a fizika határaira. Nem tolták azokat ki, csak megint adtak maguknak pár évet, hogy jöjjön valami gyökeresen új gyártási eljárás. Innentől kezdve a dolgot a programozó oldaláról kell egyszerűvé tenni. Ez most a feladat.

    A HSA támogatója az AMD mellett az ARM. Konkrétumok is vannak, de ezek nem publikusak. Ezért lesz 2012 közepén az AFDS, ahol sok dolog publikus lesz. Addig csak az férhet hozzá, akik partnerei ennek az egésznek. Itt valószínű, hogy el kell intézni a formai dolgokat, mert nem biztos, hogy mindenkinek megfelel az a specifikáció, amit az AMD dolgozott ki. Mivel ez a felület már nyílt, és a fejlesztést is alapítvány végzi, így a tényleges specifikációkat úgy kell publikálni, hogy az végül minden érintetnek megfelelő legyen.

    A Xenos kompatibilis tesszellátor hasznos volt PC-n, mert az Xbox 360-ra lehetett vele dolgozni. Minden olyan multiplatform cím, ami Xbox 360-ra is elkészült, és ott tesszellációt használt az PC-re AMD hardveren lett fejlesztve. Zömében ezért készül a DX11-es játékok többsége az AMD Gaming Evolved partnerprogramja alatt. A HD 2000 óta minden GPU-ban van Xenos kompatibilis tesszellátor a DX11-es mellett. Az persze igaz, hogy a GCN architektúrába már úgy építették be, mint egy külön részegység, és nem mint a tényleges setup motor része. Ez a sebességre nem hat jól, mivel eléggé le van butítva a tranzisztorok spórolása miatt. A funkcionalitásban viszont ez nem számít, mert úgyis a fejlesztőknek készült.

    Az egész tesszelláció problémás DX11 alatt, mert a legbénább NoSplit megoldást használják. Azóta már van jóval jobb DiagSplit. Persze a Microsoft mentségére legyen mondva, hogy amikor a DX11 alapjait véglegesítették még csak a NoSplit és a BinSplit volt. Ezek közül tényleg a NoSplit az előnyösebb valós időben. Ettől függetlenül a problémák jelentősek, mert sok feladatott ró a tesszellálás a művészekre, és a hardverre is, de utóbbi a kisebb gond. Amíg a DiagSplit le nem váltja a régi motort, addig a virtuális textúrázás erősítése és a Disney PTEX formátuma lehet a megoldás a művészek munkájának megkönnyítésére. A DiagSplit előnyei ezzel minimálisra csökkennek, de azért marad még jó tulajdonsága, mert a quad-fragment merging hatékonysága ehhez a modellhez a legjobb, noha alkalmazható NoSplithez is.

    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