Keresés

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

  • Abu85

    HÁZIGAZDA

    Gborsnak igaza van. Itt most nincs semmi gond. Az egyetlen butítás a TIER_1 esetében a leíróhalmaz méretének kisebb limitje. Mivel az Intel nem fog új Haswell verziót tervezni, az eladottakat pedig pláne nem fogja cserélni, így meg kellett lépni.
    A többi változás viszont előrelépés. A fejlesztők a két konzolt fogják célozni. Ez a domináns faktor a multiplatform címeknél. És mivel úgyis low-level elérést kértek, így lesz annyi eszük, hogy felfogják mely hardver mennyi valós UAV-t támogat. Ezzel lehetőséget kaptak arra, hogy a konzolról portolt effekteket TIER_2 szinten is megoldják. Ez tiszta profit a PC-seknek. Ha meg sok teljesítménybe kerül, akkor egyénileg ki lehet kapcsolni. A korábbi modell sokkal nagyobb limit volt. Eleve meg sem jelent volna az az effekt, ami nem fért volna bele a limitekbe. Ez így sokkal jobb.
    A TIER_3 pedig effektíve nem változott, ott mehet a teljes eléré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 alevan #44 üzenetére

    Gyakorlatilag mindhárom PC-s low-level API ugyanaz, tehát nehéz egyedileg véleményt alkotni róluk. Az előnyeik nyilván vitathatatlanok. Erről az új 3DMark teszt is képet ad.

    (#51) Xmister: Annál is inkább, mert a Frostbite Team vezetője már mondta, hogy a Vulkan API-ra fókuszálnak. A DX12 részükről nem annyira fontos.

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

    Lecserélni nem, azért az pazarlás lenne. De ha új vásárlásról van szó, akkor a 280-ak helyett a 285-öt érdemes választani.

    A 8 vs 2 ACE ott számít majd, amikor a játék aszinkron compute-ot futtat. Ha sok az átlapolás, akkor természetesen számít, hogy jóval több a parancslista a 285-ben. Ezt már most láthatod a 3DMark új tesztjében. [link] - A 285 jobban skálázódik, mint a HD 7970, mert jóval több parancslistát támogat.
    Ez a gyakorlatban egy magas aszinkron compute terhelésű játéknál hozhat úgy +10-15%-ot a 285-nek.

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

    A Witcher 3-nak valószínűleg lesz Vulkan portja, hiszen jön SteamOS-re. Nyilván nem emulációval, vagy OpenGL-lel. Az öntökönszúrás lenne.
    A The Division DX12-t használ, míg a Mad Max az új Avalanche Engine-re épít, ami Mantle-t már támogat, tehát innen a Vulkan, vagy a DX12 könnyű célpont.
    A GTA 5 NDA-s, arról nem mondhatók semmit.

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

    Azért azt hozzá kell tenni, hogy ha valaki csak pár sorral egészíti ki az Xbox One kódot, akkor az nem lesz jó a PC-nek. Az azt jelenti, hogy a kód jól fog futni Hawaii és Bonaire GPU-kon, illetve a Kaveri APU-n és ennyi. Szóval optimalizálni kell a többi GCN verzióra is a memóriamenedzsmentet, aztán lehet menni a Fermi, Kepler, Maxwell variánsokra és az Intel IGP-kre.

    Ami az AMD-nek igazából előny, hogy a fejlesztők a GCN-t tanulják meg. Nem csak azért, mert ez van a konzolban, hanem azért, mert csak ezt lehet tanulmányozni. Az Intel és az NVIDIA nem engedi meg, hogy a programozók mélyen megismerjék a hardvereiket. A legtöbb optimalizáció a shaderek oldalán úgy történik, hogy a fejlesztők feltételezik, hogy minden GPU-architektúra úgy működik, ahogy a GCN, ami gáz. Joshua Barczak mindig tweeteli ezeket az Intel és az NV embereinek, hogy ha nem értenek egyet ezzel, akkor készítsék el a fejlesztőeszközöket, hogy a GeForce-okat és a HD/Iris grafikus vezérlőket is tanulmányozhassák. Ez valóban nagy probléma és már vannak mozgolódások az Intel részéről, hogy megadják a fejlesztőknek a lehetőséget, hogy a Gen7.5 és Gen8 hardverekre is optimalizálhassanak. Nem készítenek ugyan saját disassemblert, de ki akarnak adni egy leírást, amivel minden fejlesztő el tudja magának készíteni ezt az eszközt. És ez már egy előrelépés lesz. Arra is számíthat szerintem az Intel, hogy Joshua Barczak beépíti az Intelre vonatkozó támogatást a Pyramid programjába, amivel a kisebb fejlesztők is kapnának egy nem hivatalos, de lényegében működő Intel disassemblert.

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

    A konzol egy picit más. Az Xbox One D3DX mono API és a PS4 libGNM API is többet kínál annál, amit a DX12 TIER_3 szintje tud. Egyrészt nyilván az erőforrás használatát csak a memória limitálja, tehát ebből a szempontból a D3DX mono és a libGNM is ugyanaz, mint a TIER_3-as DX12. Lényegében minden erőforrásból végtelen áll rendelkezésre. Ami a különbség, hogy az Xbox One és a PS4 low-level módjaival az erőforrások is egységesek, vagyis nincsen egy rakás különböző puffer, amelyre különböző szabályok vonatkoznak. Egyetlen erőforrástípus van az Image, és az írható, olvasható, akár egyidejűleg is, akármilyen adattípussal, és cache-elhető. A PC-s API-kat figyelembe véve ez az a modell, amit a Mantle API alkalmaz. A DX12-ben és a Vulkan API-ban az alapértelmezett módban bizonyos erőforrásokra korlátozások vannak. Nem írható és olvasható mindegyik párhuzamosan, valamelyik nem cache-elhető, és az adattípusok szempontjából is vannak korlátok. Például a DX12-ben a TIER_3 szinten még mindig csak a single uint32 formátumot lehet egyidejűleg írni és olvasni. Ilyen felesleges limitációkkal konzolnál nem kell számolni, amivel elkerülhetők az adattípusra vonatkozó konverziós munkák. A Vulkan API egyébként tartalmaz egy opcionális kiterjesztést, ami a megengedi a ténylegesen korlátok nélküli erőforrás-használatot, valószínűleg ilyen majd készül a DX12-höz is.

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

    Az AMD által szponzorált játékok több tényező miatt rendelkeznek kisebb gépigénnyel. Egyrészt a Gaming Evovled nagyon magasra helyezi a minőségi lécet a fejlesztőpartnerek számára. Ennek van egy olyan hatása, hogy az AMD az olyan PC-re nem figyelő zsugori amatőrökkel, mint az Ubisoft és a Warner nem dolgozik. Már csak azért sem, mert ha egy partner nem éri el az AMD által igényelt minőséget, akkor nem kapják meg a pénzt, sőt nekik kell fizetni kártérítést, hogy az AMD rájuk pazarolta az idejét és a pénzét. Ennek megfelelően csak azok a fejlesztők keresik az AMD-vel a kapcsolatot, akik biztosak benne, hogy megvan az erőforrásuk minőségi PC-s portokat lerakni. Cserébe hozzáférnek az AMD tudásához, ami a port minőségéhez nyilván hozzájárul.
    A másik tényező, hogy bizonyos top fejlesztők még a kockázatokat is felvállalják, hogy ne kelljen az NVIDIA-val dolgozni. Azért látod azt, hogy a top kiadók megpróbálnak mindent házon belül megoldani, mert innen jön a minőség és a teljesítmény. A PS4-re megjelent The Order 1886 esetében vezető szerepe volt annak, hogy a kód összes sorát házon belül írták. Semmi egyedit nem csinál a motor, csupán azt az előnyt használja ki, hogy a teljes kontrollal minden effektet egymáshoz terveztek, célirányosan ütve ki a kisebb-nagyobb grafikai problémákat. Erre megy el több top kiadó és stúdió is, mert a teljes kontroll hozza a jövőben a minőséget és a sebességet. A GameWorks licencelését tehát lehetőség szerint ki kell zárni, mert maga a rendszer koncepciója zárja ki azt, hogy a végeredmény jó minőségű, illetve gyors legyen. És például az a kiadó akit az AMD nem lát a soraiban szívesen, mint az Ubisoft és a Warner, kénytelenek a GameWorks-re alapozni, vagyis a PC-s optimalizálás hiánya mellé még megkapják a GameWorks általános sebességbüntijét is, mert nem tudják rá optimalizálni a motort, ez ugyanis az efféle middleware-ek esetében lehetetlen.
    Ez a két tényező együttes hatása eredményezi azt, hogy az NV-s játékoknak magas a gépigénye. Ugyanakkor ezt az NVIDIA a legkevésbé sem akarja (mert a user inkább átmegy konzolra, minthogy minden évben kiadjon 150-300k-t a top VGA-ra), csak az aktuális stratégiájukkal nem lehetséges jobb minőség és sebesség.

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

    [link] - lehoztuk, hogy az előzetes specifikációkkal mit támogatnak a hardverek. Persze ahogy az aktuális hír is mutatja a specifikáció megváltozott, így a binding része a táblázatnak már módosult.

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

  • Abu85

    HÁZIGAZDA

    válasz Menthirist #124 üzenetére

    Az Intel sem, pedig itt van a kiterjesztés, amit OpenGL-ben támogat a GCN, Gen7.5 és Gen8. [link]

    Nem véletlenül hívják a Win 10-et Technical Preview-nek, a driverek pedig nem véletlenül alpha szintűek. Általában ilyen szokott lenni a fejlesztés. Ha valami még nem stabil az API-ban vagy van esély arra, hogy változik a specifikácók, azt nem támogatják, vagy ha igen a felhasználók felé akkor is letiltják.
    Ugyanez a command list rendszere a DX12-nek. Nem azért nem skálázódik hat szál fölé, mert rossz, hanem azért, mert nem stabil hat szál fölött. De hát ezért nincs rásütve a DX12-re a FINAL!

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

    Az előzetes specifikációban még nincs értékelve a feature level. Csak a 11_0 hozható létre, és ahhoz kérető optional támogatás. De mivel ezeknek jó része nem stabil, így még nem kérik a fejlesztők. Ma még az is gond az aktuális specifikációval, hogy hat szál fölé skálázódjon az API. De semmi gond amúgy. Ezeket a hibákat ismerik, és korrigálni fogják, mire rásütik a FINAL jelzést. Sajnos egy API fejlesztése ilyen. Vannak bizonyos funkciók, amelyek nem stabilak, de a végére azok lesznek.
    Egyáltalán nem lesz végleges a DX12 hat héten belül. Most nyúltak bele egy akkorát, hogy más részeit is át kell írni. Inkább majd ősz fele lehet szó véglegesítésről, vagy inkább tél, ha ennyire sűrűn változik majd a specifikáció.

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

    A DX12 is részben azonos a Mantle-lel. Az API-k egyes részeit elkezdték dokumentálni, és hát nem kevés az egyezés. [link]

    Az NV nem hiszem, hogy akar low-level elérést. Ők kardoskodtak azért a leginkább, hogy legyen DX11.3, mert azt sem az Intel, sem pedig az AMD nem akarta. Az NV nem örül annak, hogy a Microsoft elveszi tőlük a kontrollt, mert nem arra rendezkedtek be, hogy a jövőben a játékfejlesztők írják meg azt, ami ma a driverben van.

    Nem photoshop csak egy tervezet. Az MS a bekötési táblát például bemutatta a GDC-n és radikálisan módosította négy nappal később.
    A DX12 early specifikációban van, majd jön a provisional és a final.

    [ 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