Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Az AotS ugyanúgy lesz leprogramozva mint egy másik DX12-es alkalmazás. Máshogy nem lehet DX12 programot szállítani. Az persze különbség lesz, hogy melyik motor milyen grafikai, compute és copy futószalagokat futtat, de ezeket ugyanúgy kell kezelni DX12-ben. Máshogy az API nem is fogadja el.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#8947
üzenetére
Az AotS esetében a bekötés nem probléma. A legtöbb jelenetnél az adatfeltöltés lesz a limit. A motor 60 fps sebesség mellett másodpercenként 3 GB-nyi adatfrissítést hajt végre a processzor kalkulációi alapján direkten áttöltve az eredményeket az L1 gyorsítótárból a GPU memóriájába. Ezért fog majd konzolon meglepően jól futni, mert ott az IGP egyszerűen csak kiolvassa az adatot a CPU L1 gyorsítótárából és kész.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Szerencsére direkten lehet másolni a DX12-ben az L1 gyorsítótárból a GPU memóriába. De igen nagyjából arról van szó, amit leírsz. Ez fogja leginkább limitálni a teljesítményt. Annyira persze nem kritikus, de kimutatható.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem jön demó. Csinálsz egy Stardock accountot, és meg lehet venni a preview-et 50 dollárért. Ehhez lesz majd hozzáférés augusztus 25-én. A média számára a letölthetőséget ma írják jóvá.
(#8963) daveoff: Még nincs jóváírva a letölthetőség. Pár órát még várni 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
Ren Hoek
#8968
üzenetére
Benne van a benchmark a játékban. Megveheted ma és örökre a tied a program, persze letölteni majd csak augusztus végén tudod. Olyan lesz, mint az early access a Steamen. Nem kell később megvenned a végleges játékot. Folyamatosan frissül a kód.
Azt hiszem van 100 dolláros hozzáférés is, ami valamivel többet ad, beleszólhatsz a fejlesztésbe, ha jól láttam.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pedig igaza van. Ez egy olyan teszt lesz, amit az új API-khoz terveztek, tehát alapvetően nem a hardverekre van kihegyezve, hanem arra, amit az új API-k kínálnak. Ettől még hardverteszt is, de a Microsoft elsődlegesen azért rajong érte, mert a DX11 benne nagyon gatya, és a DX12 brutálisan lealázza. Ez minden hardver esetében így lesz, és ez segít eladni a Windows 10-et.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ezt ti magyaráztátok bele. Ez a motor arra készült, hogy megmutassa az új API-k fontos képességeit. Igen ezekben jó a GCN (pl.: multiengine), de ez nem jelenti azt, hogy ezt a tesztprogramot a GCN-re írták. Valójában egy tök szabványos program, aminek a fejlesztésében mindenki részt vett.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Olvasd el, amit írtam. Ott arról volt szó, hogy a GCN3 jobb, mint a GCN2, mert a parancs processzorai fejletebbek.
Amit viszont meg kell érteni, hogy az Oxide felvállalta a reformot, hogy felépít egy olyan motort, ami radikális előrelépést jelent, és a több évnyi munkájukat lealacsonyítjuk egy GCN techdemó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
#85552128
#8983
üzenetére
Lesz igen, de tartalmazni fog bizonyos korlátozásokat. Jelen pillanatban a DX11-et, a DX12-t és a Mantle API-t támogatja, de az év végén támogatni fogja a Vulkan API-t is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Semmit sem állítottam a teljesítményről, de igen az AotS nem egy sávszélbarát program, mert annak, hogy nem maximum 8, hanem sok száz shadow casting fényforrás van benne, az nyilván fájni fog a mai hardvereknek. De a Nitrous fejlesztésének a célja az volt, hogy olyan területre merészkedjenek, ahol előttük még nem járt senki. És ezt nem igazán a hadverek teszik lehetővé, hanem az új API-k. Ezért fontos ez a program.
Ha nem lennének új API-k, akkor ez a program nem született volna meg, függetlenül attól, hogy a hardverek megjelentek volna.(#8986) TTomax: Eddig is tudta a piac, hogy az aktuális technikákról való továbblépést a filmes CGI technikák jelentik. Csak az volt a kérdés, hogy melyik stúdió lesz az, amelyik mer arra költeni, hogy felhúzzon egy teljesen új motort erre. Az Oxide volt az, és erre kellene koncentrálni, mert elhihetitek, hogy nem egyszerű feladat olyan utat járni, amit még senki sem taposott ki. Ehhez képest csak egy GCN techdemóként gondolunk erre a programra, amire nem szolgált rá. Ennek a fejlesztésként sokkal nagyobb szerepe van.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Olyan is lesz, ami el sem fog indulni DX12 nélkül. Több is.
Nem valószínű, hogy az új API alapfunkcióinál többet fognak használni a játékokat, de pont ezek a funkciók lényegesek(#8990) gbors: Az egészen pontosan egy szimulált adat arra vonatkozóan, hogy mennyi extrát hoz a HBM ahhoz képest, mintha GDDR5-tel lenne szerelve a Fiji.
Egyébként nem viccelek, de a fogyasztás is nőni fog. Aki ott volt a GDC-n az Oxide standon hallhatta, hogy milyen két 290X, ha 70%-on mennek a ventik. Eléggé melegedni fognak a VGA-k.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A konzolokat és a PC-ket is teljesen másképp fogják programozni a következő években, mint például ma. A fejlődés lehetősége igen jelentős, mert lassan átírják a motorokat arra, hogy a CPU-ról egyre több feladat a GPU-ra költözzön. A SIGGRAPH-on már egészen érdekes koncepciók kerültek elő, amelyek nagyon aktív projektek. Persze nincsenek még bevetve, mert nincs rá kész az alapul szolgáló motor, de 2016-2017 környékén már látható lesz az eredményük. Ezeket az újításokat majd PC-be is mentik át, ahogy zajlik a GPU-k integrációs folyamata.
(#9025) kovsol: Azért volt. Az Xbox One eredeti API-ja így is sokkal lassabb, mint a PS4 low-level API-ja. Persze más kérdés, hogy a fejlesztők többsége egyiket sem használja. Nem megfelelő az elavult motorstruktúra hozzájuk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azért tegyük hozzá, hogy a programozói kapacitás egyértelműen a konzolokra van csoportosítva, tehát a PC-nek alapvetően az lenne a jó, ha a konzolok képességét másolnák. Viszont előkerült a SIGGRAPH-on is, hogy még mindig vannak olyan dolgok, amelyek konzolon elérhetők, míg PC-n nem. A DX12 nagyszerű előrelépés, de még mindig vannak hiányzó funkciók. Nincs GPU-s dispatch, rendezett atomi operáció, template támogatás a shader nyelvre, crosslane swizzle, stb. A Vulkan API ezek jó részét még behozza, vagyis az év végére tovább záródik az olló. Ez nagyszerű lesz a PC-nek. A következő év azzal fog telni, hogy minden gyártó csináljon Vulkan 1.0 és OpenCL 2.1 implementációt, mert ezekkel a két konzol képességeinek nagyon-nagy része lefedhető szabványosan.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A core specifikációkat nagyrészt támogatják az elérhető hardverek. Itt igazából az a kérdés, hogy a gyártók meddig készítenek támogatást, mert az AMD és az NV visszamehet a TeraScale 2 és a Fermi generációig is, csak nem biztos, hogy megéri. Bizonyos, hogy a Vulkan esetében inkább az húzza majd meg a határt, hogy mire írható értelmes sebességű implementáció. Ebből a szempontból leginkább a 2012-től elérhető hardverek lehetnek támogatottak.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#9033
üzenetére
Ha emulációra van szükség, akkor az igen CPU oldali többletterheléssel jár.
(#9034) imi123: Egyelőre érjük el azt, hogy a PC tudásban nagyjából felzárkózzon a konzolokra. Az már egy nagy fejlődés lesz az egész iparnak, mert rengeteg konzolos optimalizáció átmenthető lenne. Utána majd lehet szépen tovább haladni. Valószínűleg ez egy hosszabb folyamat lesz, de 2017 környékére bizonyosan sok lesz a konzol és a PC között a hasonlóság, ahogy tör előre az integrációs folyamat PC-n.
Semennyire. A DX11 API nem multi-engine.
[ 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
daveoff
#9058
üzenetére
De ez a demó az Unreal Engine 4 fő leképzőjét használja. Mivel ez a motor ultramobil fejlesztés, így a PC-s leképző gyakorlatilag semmilyen optimalizálást nem kap. Ezért olyan ramaty manapság minden UE4 játék teljesítménye, Hatred például. Nincs rá pénz, hogy normális PC-s optimalizálást építsenek be. Azok az UE4 programok jól mennek, amelyek a mobil piacra szánt leképzőt használják, azt folyamatosa javítják, és már nagyon gyors. Szerintem ez majd csak jövőre változik meg, amikor a mobil fejlesztések lényegében beérnek, és lehet némi pénzt rakni a PC-be is. De azt ismerni kell, hogy az UE4-et licencelők 90%-a a mobil leképzőt használja, tehát nem véletlen, hogy ezt optimalizálják.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Yllgrim
#9062
üzenetére
Már ki van küldve az AotS teszt a médiának. Nekünk is. Szóval nem sokat kell már várni. Szerintem mi a héten már csak elkezdeni tudjuk, de más oldalak lehet, hogy előrébb járnak.
(#9064) daveoff: Az UE4 esetében egy ilyen programnál majdnem mindegy, hogy DX12-es vagy DX11-es. Szerintem még nem DX12-es. Majd később egyébként teljesen általánosan javul az UE4 teljesítménye, ahogy bekerülnek a fontosabb optimalizálások.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Leghamarabb egyébként AotS teszt este lehet. Nem mondhatom meg mikor, mert az NDA lejárta is NDA-s, de nagyjából akkor, amikor elkezd lemenni a nap.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Eredményeket sajnos még én sem tudok olyat nem közölt senki.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#9072
üzenetére
Az AMD nem csinált profilt DX11-hez. Ezt külön kihangsúlyozták, hogy felesleges, mert a DX12 úgyis gyorsabb, így mindenki abban fog játszani. Egyébként ez még tovább fog gyorsulni, mindenkinek, ahogy kezdik megismerni az API-t. Lesz még némi OS frissítés is, ami szükséges a multi GPU mód beépítéséhez, illetve az MSAA-t is engedélyezni lehet később. Ma is, de egyelőre csak a GCN-en működik használhatóan, erre majd kell még optimalizálás.
De első körben nagyon szépen látszik a DX12 hatása. Ezt nagyon jó, hogy megmutatja ez a teszt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#9079
Abu85
HÁZIGAZDA
DeckardCain
#9075
Abu85
HÁZIGAZDA
válasz
DeckardCain
#9075
üzenetére
Ugye korábban mondtam, hogy ez a motor az L1-ből másolja az adatot a GPU-ba. Ez a legnagyobb limit a feldolgozás során, és az FX-eknek nincs integrált PCI Express vezérlőjük, vagyis náluk ez a limit jobban kijön, mert jóval hosszabb az adatmásolás útja.
A normál APU-k már integrál PCI Express vezérlővel rendelkeznek, ott ez nem lenne akkora limit.(#9077) kovsol: Most attól, hogy ráoptimalizálnak arra a 10-20%-ra ami kinyerhető, a gyorsulás mértéke gyakorlatilag nem változna jelentősen. A GCN-nek a DX11 egy limit, és ezt teljesen kiüti a DX12.
A procik szempontjából az IGP lesz a fekete ló, amint bekerül a multi-adapter.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egyébként szerintem ez a DX12 mód még simán lehet gyorsabb, mert a Mantle mód az AMD DX12 eredményeinél is lényegesen jobbakat produkál. Szóval azért ezekben az eredményekben még bőven benne van, hogy a DX12 csak most lett kész, gyakorlatilag pár hetesek rá a driverek, stb. Az sem kizárt, hogy számos Mantle-ben működő optimalizálás még DX12 alatt nem is működik, de később, ahogy fejlődik a motor ezeket rákapcsolják. Szóval nem véletlenül alpha. Idővel szépen bele lesz építve a DX12-be a Mantle extrái. Vegyük figyelembe, hogy a Futuremark DX12-es tesztje is lassabb volt az első verzióval a Mantle-nél, de fél évre rá felzárkózott.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Mindig elfelejtjük, hogy a DX11-nél az MS sosem ajánlott olyan drivereket, amelyek 2000 batchnél többet tudnak 60 fps-sel, és erre jó oka volt a cégnek, mert ha egy meghajtóinfrastruktúra fölé megy, akkor onnantól kezdve az AI és a gameplay innováció ki van végezve, mert a processzoridő nagy részét viszi el a grafika. A DX12-ben pont ezt a problémát kezelték a gyökerénél szimplán úgy, hogy kidobták a fenébe a teljes grafikus kernel driver infrastruktúrát.
Csak kérdezd meg a topik játékosait, hogy mennyire várnak már valami AI innovációt. Nem szakemberek ők, nem tudják, hogy ez ma azért lehetetlen, mert a DX11 kernel driver infrastruktúrája lehetetlenné teszi a processzoridő 80%-ának elérését, viszont a DX12-ben pont lehetséges lesz.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ráduplázni DX12-ben nem fog, hiszen a D3D bájtkód nem változott meg. A DX12 elsődlegesen azon változtatott, hogy közelebb vitte a működést a GCN típusú hardverekhez, hogy ne kelljen emulálniuk a bekötést, stb. Most persze a többi hardver emulál, kivéve a Skylake.
Az Oxide-nak nem számít, hogy dokumentálják-e az architektúrát. Dan Baker mögött komoly szaktudás van, hiszen elmondhatja magáról, hogy nem csak elsőként, hanem konkrétan egyedüliként rakott össze működő deferred context motort, illetve egyedüliként implementált Reyes-féle leképzőt valós időben, ami még több száz shadow casting fényforrást is kezel. Neki egy hardver visszafejtése nem téma, csak időbe kerül. A dokumentáció hiánya leginkább a kisebb tudással rendelkező programozókat fogja negatívan érinteni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Teljesen normális, hogy a driverek az évek során fejlődnek mindegyik oldalon, és ezzel a korábban kitesztelt tuningok gyakorlatilag instabillá válhatnak. Ez a jövőben is így lesz. Ezért nincs garancia a tuningra sehol. Valójában egy dologról van szó. Olyan, hogy stabil tuning nem létezik. Stabilnak hitt tuning van.
(#9104) rocket: Az AMD írta mailben, hogy a DX12 volt az optimalizálási fókusz, annak ellenére, hogy ez az AotS verzió még játszható DX11-ben is. Ugye ebben a preview buildben a legkisebb pálya van benne a legkevesebb egységgel. A végleges verzió bizonyos játékmódokat már el sem enged indítani DX11-ben. Brad Wardell írta régebben, hogy a 4K sem aktiválható ezzel az API-val.
A Project Carsnál mondtam régebben, hogy az übershaderek nagyon regiszterpazarlók.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Valójában nem memóriatömörítés ez.
Az új Catalyst némi memóriaoptimalizálást használ, ami bizonyos játékokra rá van gyúrva profilokkal. Magának a WDDM 1.x felületnek az a gondja, hogy nagyon sokáig tart benne törölni. Valójában a játékok közel sem igényelnek 4 GB VRAM-ot. A Mordor jó példa, hiszen a high textúra konzolon 500 MB alatti helyet foglal, de PC-n már 2,5 GB-ot. Tehát 2 GB-tal fizetünk csak azért, mert szar a WDDM 1.x. Az AMD az újabb Catalystekben ezen dolgozik, hogy a béna alaprendszer kevésbé fájjon, és erre vannak különböző alternatív menedzsmentek az AMD saját WSI felületén keresztül. Nem jutunk el vele a konzolos, vagy a későbbi WDDM 2.0 szintre, de jobb, mint a WDDM 1.x-re bízni az ellenőrzést.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A DX11.3 már benne van Windows 10-ben. Azért nem esik szó róla, mert nincs még rá normális implementáció. A Microsoft szerint a gyártók a DX12-re koncentráltak, és inkább eltoltak a DX11.3 implementációkat, hogy biztosan legyen DX12 a Windows 10 startra. Az sem biztos, hogy mindenki készít rá teljes implementációt, mert a fejlesztőket egyelőre a DX11.3 nem érdekli, mivel gyakorlatilag csak a typed UAV loads és az FP16 a reálisan kihasználható extra. A Volume Tiled Resources lett volna a lényeges dolog, de elrontotta a Microsoft azzal, hogy nincs a DX11.3-ban normális 3D-s textúraformátum, illetve az ASTC kilövésével a DX12-ben sem. Amire a fejlesztők igényt tartanak azok pedig kimaradtak a DX11.3-ból, mint például az execute indirect.
[ 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
daveoff
#9201
üzenetére
Pont ez a lényeg az új API-kkal. Csökkenjen a többletterhelés, hogy a felszabaduló processzoridőre jobb AI-t, fizikát, gameplay szimulációt lehessen írni. Ezzel például a PC is kaphat olyan AI-t, ami eddig csak a konzol exkluzív játékok sajátossága volt.
Ahol a DX11 és DX12 különbsége nagy, oda nem is jön majd DX11 programkód, mert konkrétan nem menne a DX11 3-5 fps-nél többel, vagyis erőforrást is felesleges pazarolni rá. Több olyan program is jön, amiben szimplán nem lesz DX11 mód.
Amúgy is a fejlesztők 99,9%-a nem egy olyan zseni, mint Dan Baker. Az, hogy ő tud alkotni DX11 alatt valamit, egyáltalán nem jelenti, hogy más képes rá, vagy még fontosabb kérdés, hogy egy kiadó finanszíroz-e egy programozónak tisztán két évnyi DX11 optimalizálást. Na ugye.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A DX12 kódban a Nitrous még nem teljes. Nem véletlenül van mögé rakva az alpha, mert két szálra van limitálva a több szálú parancskreálás. Nyilván van egy csomó dolog a motorban, ami még nincs rákapcsolva, de tuti működni fog, mert az AMD saját API-jával működik. Eleve a DX12 implementációk csak öt! hetesek, és nem is stabilak. De ezek fejlődni fognak az elkövetkező fél évben, már csak azért is, mert vagy egy tucat DX12 update jön még a Windows 10-hez.
(#9212) schawo: Van benne AI, csak a mostani szinkronizálás ma még soros feldolgozásra kényszeríti a rendszert. Nyilván nem véletlen, hogy a legkisebb pálya lett megmutatva kevés egységgel. Ide elég ez a készültségi szint, és már látszik rajta a DX12 előnye. Az MS pedig örül, hogy végre kirakhat valamit az ablakba.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egy mítosz miatt az iparág nem dobja el a megszokott API-kat és kezd eszeveszett költekezésbe, mert nem egy, hanem rögtön két új API érkezik.
Az, hogy a Stardock képes annyi pénzt biztosítani Dan Bakernek, amennyit csak akar, egy rendkívül kivételes helyzet az egész iparágon belül. Nincs még egy olyan programozó, akinek megengednék, hogy két évet optimalizáljon DX11-re, amikor jobb eredményt hetek alatt kihozhat DX12-vel.Egyébként úgy is fogalmazhatunk a DX12-ről, hogy ha lenne hozzávetőleg 4 évnyi optimalizálási idő minden PC-s portra, akkor nem lenne szükség rá. De sokszor 4 hónapjuk, vagy rosszabb esetben 4 hetük sincs a fejlesztőknek optimalizálni, mert jövőre jön az új rész, és azt el kell kezdeni nagyban fejleszteni. Így már egészen durva igény mutatkozik a reformra.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Valószínűleg arra gondol, amiről az Oxide, illetve a Square Enix is beszélt még 2013-ban az APU13-on, hogy ezek miatt az agresszív DX11-es driverek miatt játékötleteket dobnak a kukába, mert lehetetlenné válik a leprogramozásuk a folyamatosan csökkenő, felhasználható processzoridő miatt.
A Nixxesses gyerek mondta, hogy a DX11-ben minden elmélet. Kiszámolod, hogy elég lesz-e az erőforrás, de fogalmad sincs, hogy a driver mennyi processzoridőt fog elvenni a program elől. És ez kellemetlen a megjelenés előtt, amikor elvben jó minden, de jön egy driver, amitől rossz lesz, és jön az, hogy xy effektet ki kell venni, mert már nincs arra idő, hogy átírd a szimulációt az új driverhez. Ezt szünteti meg úgy a DX12, hogy a kernel drivert kivágja a rendszerből, így nem kell félni az új driverektől.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#9243
üzenetére
Pontosan. Van egy olyan része az egésznek, ami az eredmény, de a színfalak mögött nem csak a nagyobb fps-t nézik, hanem azt is, hogy jó-e a PC-s piacnak, ha elveszik a fejlesztők elől azt a lehetőséget, hogy jobb AI-t, teljes rombolást fejlesszenek. Esetleg egy PC-s port eljusson arra a szintre, amivel tele vannak a Sony exkluzív címek, hogy tényleg brutálisan szétverhető, akár mozgó környezet, és az AI is olyan, hogy bekerít, meg dobálja vissza a gránátokat, vagy ketten folyamatosan lőnek, a harmadik meg dob egy gránátot, a negyedik a sziklafalon mászik mögéd, hogy kirobbantsa a menedéked, szóval ezek a tipikus Uncharted jelenetek. És ez egy komoly kérdés az egész iparnak, hogy megéri-e ettől az élménytől megfosztani a PC-s játékosokat, csak azért, mert szebb lehet a grafika.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Csak meg kell érteni, hogy az új API-k célja a lehetőség megteremtése a PC-s hardverek kihasználásra. Grafikában is lesz változás, de nagyrészt a játékmenetben lesz megtapasztalható a fejlődés. Persze ez nem lesz áldozat nélküli, de nem véletlen, hogy ingyenes a Windows 10-re való átállás, hogy az MS nyugodt szívvel mondhassa azt, hogy adjátok ki a játékot DX11 port nélkül, ahogy ők is fogják tenni pár érkező programjuknál.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#9258
Abu85
HÁZIGAZDA
Interceptor
#9257
Abu85
HÁZIGAZDA
válasz
Interceptor
#9257
üzenetére
Igen. Azt hiszem a COD 2-ben is, de ebben nem vagyok biztos. Viszont jó lenne, ha ezekre újra lenne erőforrás.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pont ez a baj ezekkel, hogy program oldaláról nem lehet szabályozni. Pontosan ez az oka annak, amiért mind a négy új API teljesen kidobta ezt a működési modellt. A Microsoft is megtanulta a leckét, hiába mondja meg, hogy mit tart ideálisnak, ha egy gyártó nem követi, akkor teljesen felborul minden. És a gyártók nézőpontja is érthető, szétszednék a PC-t a rajongók, ha látnák, hogy a konzolok megverik grafikában, de egy átlag user nem annyira képzett, hogy megértse miről kell így lemondania. És ez egyáltalán nem jó a usereknek.
Aztán persze az sem ideális szerintem, hogy add oda az egészet a fejlesztőknek, hogy boldoguljanak vele. De tulajdonképpen ez a két lehetőség van, és az egyik lehetőség elbukott, tehát marad az alternatíva.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
velizare
#9316
üzenetére
Inkább úgy lenne érdemes fogalmazni, hogy a parancskreálás jelenleg két szálra van még korlátozva. A többi része a motornak skálázódik tovább, csak nyilván a parancskreálás a limit.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pedig a modell hibája. Ha ez nem ad lehetőséget a szabályozhatóságra, ilyenkor az implementációnak sincs lehetősége erre.
Nyilván az egészen egyértelmű, hogy a mostani modell nem működik, tehát egy másik irányt kell választani. Persze el lehetett volna azon gondolkodni, hogy egy olyan köztes modellt dolgozzanak ki, amivel szabályozni lehet a driver munkáját, de soha senki sem csinált ilyet, tehát nem tudjuk, hogy működne-e. A konzolon viszont a teljes szabályozást már csinálják a fejlesztők, és az működik. Szerintem a kérdéses és egy már bizonyított modell közül mindenki az utóbbit választaná.Korábban írtam, hogy ez a motor az L1 gyorsítótárból sok adatot másol a VRAM-ba, és ez érzékenyen érinthet olyan processzorokat, amelyeknek nincs integrált PCI Express vezérlőjük.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Te tényleg elhiszed, hogy egy hajszálnak 300-400 szakaszból kell állnia? Vagy, hogy szükséges egy nem látható geometria a felszín alá kvázi mikropoligonokkal? Vagy, hogy közel 10000 háromszögből kell állnia a teljesen sík felületeknek?
Egyébként nem azt akarom mondani, hogy ez rossz stratégia. Ma választásokat nyer a politikai elit az alacsony IQ-ra építve. Miért ne lehetne egy gyártónak is kihasználni azt, hogy a felhasználó buta? A legtöbb ember úgy sem akarja beismerni, hogy átverték, tehát továbbra is győzködni fogja magát, hogy márpedig valami oka biztos van annak, hogy sokkal többet számol a program, mint kellene. Logikus magyarázatot nem fog rá találni, de az a lényeg, hogy saját magát meggyőzze, hogy nem verték át. Legrosszabb esetben a fejlesztőre tolja a felelősséget.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az AotS az iskolapéldája annak, hogy miképp lehet független tesztet készíteni. Dan Baker még viccelődött is a Twitteren arról, hogy onnan tudod, hogy a teszt "fair", ha mindenki más miatt pöccent be rád.
[link][ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mindegyik gyártó károg. Egyedül a Microsoft és az Oxide elégedett. De majd később, ahogy javul a DX12 kód, és ahogy kezdik megtanulni a gyártók a működést egyre nagyobb lesz az elégedettség.
(#9340) rocket: A Crytek anyagi helyzete össze sem hasonlítható az Oxide-dal. És ez meglátszik az optimalizáláson is, amiben még mindig hihetetlenül jók, de érezni lehet, hogy a CryEngine 3.4-től kezdve az optimalizálás eltolódott a dokumentált Intel és AMD architektúrák felé.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#9349
üzenetére
Nagyrészt a programon múlik a működés, de például az allokációért, a shader fordításért, illetve a multi-engine esetében a fences kezeléséért még ma is a driver felel. A shader fordító az kb. ugyanaz, mint a DX11-es, szóval azon persze lehet javítgatni, de kvázi kész. Az allokáció viszont érdekes, mert a drivernek kell eldöntenie, hogy 64 kB-os, vagy 4 kB-os blokkokat használjon az adott pufferhez. Nem biztos, hogy ma jól döntenek a driverek, és ezen csak tapasztalattal lehet javítani. Végül a fences azért fontos, hogy az aszinkron feladatokat a driver tényleg jól időzítse, vagyis ténylegesen párhuzamosan fussanak a hardveren belül. Ma ez se feltétlenül működik jól.
A befolyás megszűnt, de ettől még pár dologról a driver dönt. De nyilván nem lehet a program hibáit driverből korrigálni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A DirectX 12 és a Vulkan pontosan ugyanazt a validátort használja, amit az AMD a Mantle-re fejlesztett. Ez kiszűri ezeket a hibákat is, legalbbis a GCN-en biztosan. Itt majd az lesz a gond, hogy az AMD a validátor fejlesztését nem adta át a Microsoftnak és a Khronosnak, tehát magát a rendszert különállóan csatolják a DirectX 12 és a Vulkan API-hoz, vagyis a fejlesztést kizárólag az AMD végzi, és nem valószínű, hogy foglalkoznak majd azokkal a hibákkal, amelyek a GCN-t nem érintik. Ezért pörögnek nagyon az érintettek azon, hogy legyen egy nyílt forráskódú validátor is, aminek a fejlesztéséhez már hozzá is fogtak. Ennek majd sok előnye lesz, hiszen nem túl produktív az a piac, ahol a konkurensek validációs problémáira csak az AMD tud megoldást, ha akar persze. Az is hülye volt a Khronosnál és a Microsoftnál, aki ezt így elfogadta, mert az AMD simán mondhatja, hogy a validátor működik, mert GCN-en működik a program, még ha máson hibázik is. Ezzel senki sem tud majd mit kezdeni, mert a fejlesztőnek is nyűg lesz az egész program működését manuálisan lemodelleznie, hogy fényt derítsen a hibára. Az jó hír, hogy a Vulkan támogatni fog alternatív validátorokat, tehát az alapul szolgáló AMD-s rendszer mellé becsatolhatnak a programfejlesztők saját rendszereket.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem az a baj, hanem, hogy egy hozzászólásra építi fel az egészet, ami ráadásul sok helyen nem is pontos.
Az async shaderre még mindig csak a Thief az egyetlen PC-s példa. Bár az AotS támogatja, mert a DirectX 12 alapból megköveteli a multi-engine működést, de a driver dolga, hogy ezeket felfűzze a különböző parancslistákba, majd időben futtassa. Egyetlen kiadott driver sem képes még erre, tehát a hardver előtt az elvben async DX12 kód mindenképp sorba lesz fűzve. Később majd lesznek persze olyan driverek, amelyekkel már ez a konstrukció működni fog.
Az async shader kapcsán két példa van előttünk. A konzolos játékok és a PC-ből a Thief. Tehát tulajdonképpen mondhatjuk, hogy működik a rendszer egy bizonyos hardverre, illetve architektúrára levetítve, és ezt nem csak én mondom (nyilván példa van rá), hanem Max McMullen is mondta a SIGGRAPH Q&A szekción, hogy egy architektúrára vonatkozóan az async shader tökéletes megoldás. De mi van több architektúrával? És itt jön elő az igazán nagy nehézség, mert két architektúra már másképp működik, illetve ahhoz, hogy tényleg nagy előnye legyen az async shadernek a mai korlátozott motorokban, nagyon kell bújni a dokumentációkat, hogy mi engedhető meg a hardveren és mi nem. Ebből a szempontból a DX12 multi-engine specifikációja legalább jól van összerakva. Minden programozó kötelezően multi-engine kódot ír, és majd a driver eldöntheti, akár egyéni profillal, hogy azt a kódot tényleg több motoron keresztül küldi rá a hardverre, vagy inkább korlátozza egy motorra. Ezért volt jó döntés az, hogy a copy motor kiterjesztése a compute motor és ennek a kiterjesztése a grafika. Ha a hardver nem tud async copy-t, akkor a driver ráküldheti a compute motorokra, ha ezt sem tudja, akkor végső esetben ott a grafikai feladatok parancsmotorja. És ez nyilván a gyártók felől úgy is elbírálható, hogy a hardver esetleg tudja ezeket a képességeket, de az async kód lassulást hozna, akkor inkább az adott játékra megszüntetik az async copy és compute lehetőséget, így minden parancs a grafikus parancslistába megy.
Ennek szerintem elég nagy jelentősége lesz, mert a legtöbben a kötelezően multi-engine kódot az Xbox One-hoz fogják szabni, tehát az időzítés, illetve a shaderek regiszterhasználata ehhez fog igazodni. Viszont ez nem mindegyik gyártónak jó. Például az Intelnek nagyon nem, és az eddigi adatok alapján az NVIDIA-nak sem, tehát nekik kell egy kerülőút, hogy legalább a programkód lassító hatását ki tudják ütni a driverekkel. Aztán később az Intel és az NV is hozni fog egy stateless compute architektúrát, out-of-order logikával dolgozó compute motorokkal. Ebből a szempontból a DirectX 12 működését érdemes lekövetni, ha már a Microsoft ennyire az Xbox One-ra szabta a rendszert.
[ 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
daveoff
#9412
üzenetére
Lehetséges az UE4-gyel. Ennek a motornak legendásan szar a DX11-es PC-re írt leképzője. Ez egy jó alap lesz arra, hogy megtudjuk mit tud a DX12 rosszul optimalizált motorral, mert eddig low-level elérést csak optimalizált motorokkal láthattunk.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#9473
Abu85
HÁZIGAZDA
FollowTheORI
#9468
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#9468
üzenetére
Az UE4 más játékban is ilyen, szóval a teljesítményprobléma forrása a motor. Ennek a motornak nem az API-val van gondja, hanem azzal, hogy két leképzőt támogat. Egy forward opciót a mobilba és egy temporal deferred alternatívát a DX11-hez. Mivel az UE4-et AAA projektekhez a nagy kiadók már nem licencelik, így a mobil leképző kapja a fókuszt, míg az alternatív leképző optimalizálása egyelőre nagyon rossz. Természetesen az Epicnek is korlátozottak az anyagi erőforrásai, így olyan helyre invesztálnak, amely eladást hoz számukra. A DX12 annyiban jelent könnyítést, hogy az UE4 DX11 kódja meglehetősen limitált, mert a PC kapja a legkisebb fókuszt és ezen belül a legnagyobb probléma, hogy az erőforrásokat hogyan hozzák létre úgy, hogy ne legyen nagyon korlátozott a teljesítmény. Nyilván DX11-ben nem lehetséges a futtatási időben létrehozni azokat, de DX12-ben már igen, és itt pont szereznek annyi előnyt, amennyivel a DX11-es leképző rendkívül gyenge sebességét előremozdíthatják. Ennek persze az lesz a hátránya, hogy a DX11-es kódot már sosem rakják normálisan össze, mert nincs értelme hónapokat eltölteni ennek az optimalizálásával, amikor van DX12, és ott az erőforrás-kreálás sokkal kedvezőbb formában megoldható. Innen egyébként nekik nagyon egyszerű lesz a DX12-vel sebességet hozniuk, mert a DX11 kód hibáit ki tudják ütni. Ezért is lesz érdekes ez a patch, mert ez lesz az első projekt, ahol a low-level váltást nem tökéletesre csiszolt DX11 leképzőkhöz hasonlítjuk, hanem egy olyanhoz, amely meglehetősen rossz optimalizálással rendelkezik.
De az is látszik, hogy még a DX12-ben sem fókusz a PC. Az UE4 csak a kötelezően támogatandó dolgokat kezeli, mint a többszálú parancskreálás és az aszinkron DMA/compute, illetve lesz multiadapter mód, hogy az IGP teljesítménye hozzáadódjon a dGPU-hoz, de sajnos a hagyományos több GPU-s rendszerekre (2-3-4 ugyanolyan VGA) már nem lesz támogatás. Valószínűleg ezt már túl költségesnek érzik, hogy specifikus multiadapter implementációt írjanak 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
daveoff
#9487
üzenetére
Valójában ez a játékoktól is nagyon függ. A Kepler főleg azokban a játékokban szenved, amelyek GameWorksösek (nyilván aktívnak kell lennie a GameWorks effekteknek), vagy nincsenek optimalizálva független parancskiosztásra, vagy nagy regiszterigényű über-shadereket használnak. A Keplerre nagyon specifikus shader kell, mert ez az architektúra multiprocesszoronként négy dispatchet használ hat felfűzött streamre. Ha a shaderben nincs benne, hogy a program felfűzhet független utasításokat is, akkor minden Kepler GPU elveszti a rendelkezésre álló feldolgozók 33,3%-át. Ezen még ront az, ha rossz a regiszterallokáció, mert azzal további feldolgozók veszhetnek oda.
A legtöbb fejlesztő egyébként figyel erre, pontosan tudják, hogy hol szenved a Kepler, és elég tapasztalat van arról, hogy ezt kezelni tudják. Akkor lehet probléma, ha a Keplert direkt elvéreztetik, hogy a Maxwell előnye nagyobb legyen. Nyilván van az a pénz, amennyiért ezt egy fejlesztőstúdió bevállalja, és még az NV is hajlandó kifizetni. Ez ellen nem lehet mit tenni. Alapvetően a média felelőssége az, hogy az ilyen játékokat ne rakja be a tesztcsomagokba, mert ez egy korábbi architektúra teljesítményének mesterséges kolátozza valamilyen okból. Erre egyébként elég jól fel lehet figyelni. Ha vannak olyan helyzetek, ahol egy GTX 960 úgy teljesít, ahogy egy GTX 780, akkor az minimum gyanús, és ilyen például a Witcher 3 és a Project Cars bizonyos beállításokkal. Ez persze még mindig nem jelenti, hogy az NV pénzt adott a Kepler optimalizálásának hiányáért, de valamiért ez hiányzik a programból, és a TWIMTBP logók miatt az sem lehet indok, hogy valamelyik alávaló gaz konkurens keresztbe akart tenni.[ 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
daveoff
#9494
üzenetére
Nem valószínű, hogy a kiadás pillanatában lesz DX12. Maximum egy patch-csel. Maga a játék egyébként támogat DX11-ben nem létező funkciókat, mint a multi-draw indirect, de ez nem szabványos rendszer. Azt sem tudni még, hogy tartalmaz-e a program OpenGL interoperabilityt, hogy ez NV-n és Intelen is működjön, mert enélkül csak az AGSL3 üzemképes Radeonokra. De maga a motor jól optimalizáltnak tűnik, szóval nem lesz ebből gond. Különösen jót tett a fejlesztésnek, hogy rengeteg kód D3D bájtkód manipuláció, tehát nem csak szimplán HLSL-ből lefordított, hanem még kézzel szerkesztett is.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Épített vízhűtés (nem kompakt) topic
- Automata kávégépek
- Ingatlanos topic!
- Szimpatikusnak tűnik a T Phone új generációja
- Ukrajnai háború
- Mini-ITX
- Galax GeForce RTX kártyák jönnek a szűkösebb házakba
- Vezetékes FEJhallgatók
- Xbox Series X|S
- Sony Xperia 1 V - kizárólag igényeseknek
- További aktív témák...
- lenovo DU9033S1 Onelink Pro Dock TÖBB DARAB Töltő nincs benne az árban
- Új Gyári Lenovo 65W Notebook adapter USB-C csatlakozóval
- iPhone 14 PRO - Arany - Gyönyörű
- iPhone 14 PRO MAX - 2026.10ig Garancia - Független
- Microsoft Surface Book 2in1 Érintős Szétszedhető Laptop Tablet 13,5" -60% i5-7300U 8/256 QHD+ Win 10
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen