Keresés

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

  • Abu85

    HÁZIGAZDA

    válasz Taposo #1 üzenetére

    Szerintem senkinek sem a hibája, ha valamelyik programhoz nincs AFR támogatás. Annyira összetákolt hulladék rendszer ez a működés szempontjából, hogy nehéz hibáztatni bárkit is. Az csoda, hogy valahol még működik.

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

  • Abu85

    HÁZIGAZDA

    válasz BlackSoft #5 üzenetére

    Drámaian megváltozna a véleményed a DX/driveres AFR állapotáról, ha megnéznéd például a BF4-be épített Mantle AFR-t. Ég és föld a kettő között a különbség. Teljesen olyan, mintha egy bivalyerős kártyád lenne, holott kettő vagy három van. A GPU workload grafikonon még három VGA-val sincs röcögés. Nagyjából ezért akarunk szabadulni a mostani AFR-től, mert kontrollálhatatlan.

    Új lehetőségek nyílnának meg a program oldali kontrollal. A Frostbite 3 például már támogat 8 kártyás multi-GPU-t is Mantle alatt, és még annak az eredményét is jobbnak érzed az egy GPU-sná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 BlackSoft #11 üzenetére

    70 fejlesztő van benne a béta programban. Egy éven elül több Mantle játék lesz a piacon, mint amennyi DX11-es volt a DX11 megjelenése után egy évvel. Ma már keresni kell azt a fejlesztőt, aki nincs benne a programban.
    Jelen pillanatban úgy áll a dolog, hogy a DX12 megérkezéséig 25-35 játék érkezik Mantle-re. Nem számítva azokat, akik a publikus SDK-ra várnak, mert a béta programról lemaradtak.

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

    [link] - hivatalosan bejelentett.

    Nem hivatalos, de biztos:
    Új Mirror's Edge, Star Wars: Battlefront, új Mass Effect, új Need for Speed, Shadow Realms, Offworld Trading Company, Star Control, Homefront: The Revolution, Project SW (ez csak kódnév)

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

  • Abu85

    HÁZIGAZDA

    válasz BlackSoft #29 üzenetére

    Honnan jött ez a GTA5 Mantle dolog?
    Én nem akarok senkit megsérteni, de az hogy a Rockstar és az Ubisoft rendelkezik a Mantle SDK-val, és ez be van építve a motorba még nem jelent aktivált Mantle rendert. A Mantle tényleg nagyon jó arra, hogy optimalizálják a DX rendert.
    Ha ilyen listát készítünk akkor majdnem mindegyik játék felírható 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 BlackSoft #32 üzenetére

    A pletykákat nem biztos, hogy érdemes felvenni. Elhiheted, hogy én is hallok sok dolgot, aztán mégse írok róla.
    Valószínű, hogy számos pletyka alapja, hogy létezik az OEM-eknél egy lista, hogy milyen motorok része már a Mantle. Ez valóban igaz, és ott szerepel a Frostbite 3, a Nitrous Engine, a CryEngine (3.5), a LORE, az Asura, a Cobra Engine, a Chrome Engine 6, és igen ott a R.A.G.E. is. Nyilván aki egy kicsit is érti a dolgot tudja, hogy a Mantle egy független backend, tehát egyszer beleírják a motorba és onnantól kezdve az bármelyik játékban egy pipával aktiválható. De sokan a motort akarják vele optimalizálni, és nem feltétlen azért rakták be, hogy használják. Az a furcsa helyzet állt elő a piacon, hogy a motor optimalizálásához szükséges adatokat DX11 alatt nem látod. Mivel nincs adatod róla csak beletörődni tudsz, hogy valami nem jó, de nem lehet tenni ellene. A Mantle ezeket a problémás részeket láthatóvá és kijavíthatóvá teszi. Az elvégzett optimalizálásoknak ugyanúgy pozitív hatása lesz akármelyik független backendre.

    (#33) X Factor: A Frostbite 3 azért ilyen nagy Mantle támogató, mert ők egy egyedi problémának a részei. Ezt maguk idézték elő, de most már mindegy. Tehát a motort úgy írták meg, hogy nagy figyelmet szenteltek annak, hogy a grafikus driverek működését akadályozzák. Egyszerűen értik, hogy felesleges azokat a munkákat még egy felületnek elvégezni, amit már megcsinált a motor. Csak a driver akadályozása, egészen pontosan az adatoktól való direkt elzárása stabilitási problémát idéz elő. Egyszerűen az alkalmazás kivághat a desktopra. Ezért mondja az AMD/Intel/NVIDIA és még a Microsoft is, hogy senki ne csináljon ilyet. Értik, hogy kell az a 30-40-50% plusz, amit sebességben ezzel a megoldással lehet hozni, de onnantól kezdve, hogy bevetik nem lehet tudni, hogy a driver vagy az API mikor omlik össze. Éppen ezért ragaszkodik a Frostbite 3 esetében az EA a Mantle-höz, mert DX11 alatt egyszerűen maga a motor működése nem képes garantálni a futtatott játék stabilitását. Erre csak Mantle alatt tudnak garanciát vállalni. A Frostbite 3-as játékoknál, ahogy BF4-nél is a DXGI_ERROR_DEVICE_HUNG hiba erre vezethető vissza. Azért fordul elő még ma is, mert a javításhoz ki kellene venni a motorból olyan optimalizálásokat, amelyek 30-50% mínuszt okoznak a teljesítményben. Az EA számára tehát a Mantle támogatása kötelesség, mert csak ezzel az API-val lesz stabil az összes érkező játékuk. Amíg be nem építik a DX12-t persze, de addig egy csomó program használja még a Frostbite 3-at.

    (#41) SylverR: Az Unreal Engine-nek nem sok köze van az új Mass Effecthez. Minden komolyabb EA játék Frostbite 3-at használ majd. Ez alól csak az EA Sports részleg a kivétel. Egyébként az Unreal Engine 4 a közösségi fejlesztésre is épít. Ha valaki akarja, akkor rakhat bele Mantle támogatást. Akár az AMD is, mert ők is licencelik. Az AMD csak nem foglalkozik vele, mert az Epic célpiaca az Android és az iOS lett, így a PC-n elérhető Mantle számára annyira nem fontos tényező az Unreal Engine 4-be épített támogatás, de ha kész a publikus SDK, akkor egy felhasználó is megcsinálhatja és megoszthatja a kódot a GitHubon. Így került bele a motorba a TressFX is. Ez a közösségi fejlesztés előnye. Olyasmi irányba mennek, mint a Unity.

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

    A multi GPU-s kártyák összeköttetése nem különb, amit most használnak két külön GPU-hoz 4K-ra. Minden játékhoz írnak speciális profilokat. Ahol ez kihagyható, az az XDMA-s Hawaii.
    Figyelnek a problémára. Az, hogy a Hawaii-ba XDMA-t építettek azt jelenti, hogy tudják hol a limit. Ugyanakkor időbe kerül, amíg ezt az AMD a teljes termékskálára alkalmazza, vagy amíg az NV bevezet hasonló megoldá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 TTomax #59 üzenetére

    Hogy a két GPU hosszá legyen kötve a PCI Express buszhoz. Más előnye nincs. Vannak olyan alaplapok, ahol a két PCI Express van úgy felszerelve, hogy mindkettő a PLX mögött van. Ugyanaz az eredménye.
    Ennek a problémának a megoldásához mindenképp kell a lapkába egy belső vezérlőblokk, ami képes a multi-GPU-s dolgokat vezérelni. Ezért került a Hawaii-ba az XDMA blokk, amellett, hogy a CF híd eltűnt. Ennek az az előnye, hogy az általános AFR rutint meg tudod írni az XDMA-s konfigurációkra, tehát maga a multi-GPU még a játék kiadása és a specifikus driver érkezése előtt tesztelhető a fejlesztők számára. Például vannak olyan multi-GPU-s VGA-k, mint a Radeon HD 6990/7990, GeForce GTX Titan Z stb. amelyeken a CF és az SLI a fejlesztés alatt álló játékokon nem üzemel. Így marha nehéz ám ezekre optimalizálni, hogy nem látod az eredményt. De például két Radeon HD 7970-en vagy két GeForce GTX Titan Blacken már látod. Pedig a két hardver elvbe ugyanaz, mint az egy NYÁK-ra épített. Nagy vonalakban ez a baja a CF/SLI-nek. Marha rossz az a QoS, amit a fejlesztőknek biztosít. Gyakorlatilag a multi-GPU úgy üzemeltethető, ha a motort addig fejleszted, hogy működjön vele, de közben a fejlesztők számára sokkal kedvezőbb lenne magát a multi-GPU-s működést megváltoztatni a motor szintjén. Nyilván nem kell magyarázni, hogy miért jó az, ha valamit optimalizálsz és nem hónapok múlva derült ki, hogy az jó-e vagy sem.

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

    Az XDMA mindig a PCI Express buszon keresztül dolgozik, ahogy az összes egy-NYÁK-os cucc. De az XDMA akkor is működik, ha nincs speciális profil a termékhez. Nem érted a fejlesztők gondját. Írnak egy motort, megpróbálják az SLI/CF-hez igazítani, és a megjelenés napján kiderül, hogy amit írtak nem működik. Ez arra vezethető vissza, hogy amikor írták az optimalizálást, akkor még nem volt driver. Az XDMA blokk annyit tesz, hogy azt már a fejlesztés közben is ellenőrizhetik a fejlesztők. Ergo arra sokkal jobban tudnak optimalizálni, mert le tudják ellenőrizni, hogy a kód működik-e.

    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