Új hozzászólás Aktív témák
-
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é.
-
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. -
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.
-
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.
-
#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.
-
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.
-
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.
-
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. -
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.
-
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.
-
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.
-
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.
-
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. -
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.
-
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.
-
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. -
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.
-
#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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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. -
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.
-
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á.
-
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.
-
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.
-
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.
-
Abu85
HÁZIGAZDA
-
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.
-
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.
-
Abu85
HÁZIGAZDA
Bármennyire is furcsa, de a monitorgyártókat a pénz érdekli. Van egy probléma, van rá egy ingyenes szabvány, és tessék azt használni. Ennyire egyszerű a gondolkodásuk. Persze, ha az NV szeretné a saját technikáját használni, akkor oda kell mennie a két legnagyobbhoz legalább, hogy kifizetnek minden R&D-t, ha hozzák a G-Sync kijelzőket. Így a gyártóknak megérne, még mindig probléma lenne a marketing elosztása, illetve a szükségesnél több termék fejlesztése, de nagyjából megtarthatnák a gyártók a meglévő nyereségüket, hiszen az NV a saját technológiájukra átvállalná a költségek nagy részét.
-
Abu85
HÁZIGAZDA
Mert tavaly még nem voltak számok, de ezek alapján mar tisztán látszik, hogy a G-Sync sorsa attól függ, hogy az NV fizet-e a Samsungnak és az LG-nek azért, hogy építsenek legalább évi 5-5 új kijelzőt rá. Erre egyébként meg van is esély, mert az NV-nek hátrányos lenne, ha a 3D Vision után befuccsolna egy új technikájuk azért, mert a monitorgyártók a saját érdeküket nézik. De ha pusztán az anyagi szempontok döntenek, akkor egyszerűbb csendben kivégezni, ahogy a 3D Visiont.
-
Abu85
HÁZIGAZDA
De lehet. A notis G-Sync nem használ modult.
Egyébként meg mindegy a dolog. Az Acer és az Asus a G-Sync utolsó bástyája. De gyorsabban fejlődnek a FreeSync megoldásaik. Szóval a dolog ott eldőlt, hogy a G-Sync támogatók többsége kihátrált. A következő körben támogatnia kell az NV-nek a szabványt, mert két partnerrel nem lesz több kompatibilis termék évi 2-3 monitornál, míg a FreeSyncből dömping lesz. Már most is az van, hiszen 12 bejelentett G-Sync monitor van/készül és 0 tévé. A FreeSync 20 monitornál és 4 tévénél tart. Akkora túltermelés lesz a FreeSyncből, hogy bőven 90:10 lesz a FreeSync:G-Sync raktárkészlet arány, ami nem sok jót jelent a G-Syncnek. Az NV-nek sürgősen meg kell győznie a Samsungot és az LG-t, akár úgy, hogy fizetnek azért, hogy adjanak ki G-Sync kijelzőket. Itt az a kérdés, hogy az NV-nek a G-Sync csak üzlet vagy inkább presztízs.
-
Abu85
HÁZIGAZDA
válasz
KAMELOT
#8774
üzenetére
Amennyire egységes a piac meglátása a jövővel kapcsolatban teljesen mindegy, mert mindenki ugyanarra megy, csak van akinek kevesebb pénze van arra, hogy nagyobb lépéseket tegyen. Például a Crytek is hasonlót csinál. A CryEngine a 3.4-es verzió óta PBR-es, plusz a 3.7-es verzióból már kidobtak minden károsnak tartott grafikai middleware-t.
Megfigyelhető, hogy a nagy GameWorks bástyának tartott UE4 is erre megy. Már egy ideje elszeparálják ezt a middleware-t a főverziótól, így keletkezik egy olyan hátrány, hogy ezek esetenként két verzióegységgel is lemaradnak. Ha nem veszik vissza őket a főverzióba, akkor az nyilván baj, mert nehézkessé válik a használatuk, de az Epic úgy érzi, hogy károsak. Érdekes egyébként, hogy az AndroidWorks ott van a főverzióban, csak azért, mert optimalizálható. -
Abu85
HÁZIGAZDA
válasz
gtamate2
#8769
üzenetére
Inkább a PBS/PBR határozza meg a grafika minőségét. A Frostbite 3-nak is volt PBR branch-e a Dragon Age: Inquisitionhöz, de az új Frostbite már alapból és teljesen PBR-es. A másik nagy változás, hogy az EA is rájött arra, amire a Sony, hogy ha mindent házon belül írnak, akkor el tudják fedni az egyes pipeline elemek gyengéit. Ez kis dolognak tűnik, de a végeredményben óriási jelentősége van. Azzal, hogy nulla grafikai middleware-t használnak (mindegy, hogy zártat vagy nyíltat) képesek lesznek minden grafikai problémát kezelni, mert koncepció szintjén úgy építették fel a rendszert, hogy tudták, hogy "xy" dolog probléma lesz, és ezek kezelésére "zw" dolgot építettek bele. Többet is ezt az utat fogják járni a jövőben. Drága dolog ez, de nézzél rá valamelyik új EA játék gameplay videójára.
-
Abu85
HÁZIGAZDA
Egyébként csak elmondom, hogy az NV hivatalos anyagában, amit nekünk küldtek ezek a játékok szerepelnek: Call of Duty Black Ops III, Tom Clancy’s Rainbow Six Siege, Balloon, Food Maker, Tiltbrush és Aperture. Utóbbi 4 VR (HTC VIVE).
A GameWorks szempontjából külön ki volt emelve a Gigantic című játék, hogy abban lesz! GameWorks. A többinél nem volt még csak említve sem.
Ez egyébként nem jelenti azt, hogy a Mirror's Edge Catalyst nem volt kiállítva, vagy a címet nem ejtette ki valaki a száján, de a hivatalos sajtóanyagban egy árva szó sem esik róla. -
Abu85
HÁZIGAZDA
válasz
gtamate2
#8763
üzenetére
Semmiféle utalás nincs a GameWorksre. De a WCCFTech az nem hírforrás, mert írnak annyi baromságot, hogy lefordulsz a székről. Maga a játék felhasználható reklámcélra, ahogy az AMD is felhasznál egy csomó EA játékot, de nagyon kontraproduktív lenne az EA-nek GameWorksszel lassítani a játékukat 3-4 hónap extra munka árán. Mond el, hogy mi előnyük származna belőle.
Az EA amúgy nem zárkózik el az NV-től, mert a múlt évben a Titanfall is NV-s játék volt, de abban sem volt semmi. Jó persze beígérték a HBAO+-t, de a végén nem volt kompatibilis a motorral, és hiába kapcsolták be, nem jelent meg. Mivel az effektet nem lehet átírni, így bukták, helyére ment a régi HBAO. A TXAA került bele fél évvel később. A TXAA-t szerintem az EA még megengedné, ha nem bénázzák úgy el, mint a Titanfallnál. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#8762
üzenetére
A régi NV-s effektek nagyon jók. A HBAO egy nagyszerű algoritmus, és azért választották, mert jobban paraméterezhető, mint a HDAO, így jobban hozzá tudják igazítani a motor igényeihez. Ez volt mindig a jó az NV régi effektjeiben, hogy széles spektrumon testre szabhatók voltak. Persze ennek van egy olyan átka, hogy tudni kell, hogy mit csinálj velük, hiszen kaptál egy olyan forráskódot, amibe nagyon bele kellett, hogy nyúlj, de hidd el egy Johan Andersson kaliberű programozónak ez inkább áldás, mint átok.
Két effektet ugyanarra a problémára nem éri meg kidolgozni. A legtöbben hülyeséget csinálnak akkor, amikor kitömik a játékot mindenféleAO-val. Sokkal többet érne, ha kiválasztanának egyet, és azt paramétereznék jóra. -
Abu85
HÁZIGAZDA
A Mirror's Edge Catalyst ugyanazt a Frostbite motort használja, mint amit a Need For Speed, a Star Wars: Battlefront, stb. Csak azért nem fogják a leképzőt nagyrészt átírni, hogy működjön rajta egy zárt middleware. Nem tudom kitől olvastad ezt, de ki van zárva, hogy a Frostbite Team eltölt azzal 4-5 hónapot, hogy megfeleltessék a motorjukat olyan shadereknek, amelyeket nem láttak még soha, és ezért nem is tervezték rá a motort.
Ha úgy gondolod, hogy a GameWorks csak egy checkbox, akkor nagy tévedésben élsz, sokszor a leképző felét át kell írni, hogy egyáltalán működjön, ami azért manapság jó 2000 sor, és még így sincs garantálva semmi, ahogy láthatod, hogy a leszállított HBAO DLL a Batman: AK-ban inaktív effektet eredményezett, tehát újra neki kell ülni a leképzőnek. -
Abu85
HÁZIGAZDA
válasz
gtamate2
#8755
üzenetére
De nem a grafikus motor teljesítményével volt probléma. Abban a Frostbite Team verhetetlen, de persze abból a büdzséből, amiből dolgoznak ez a minimum, hogy kihozzák ezt. Messze az EA költi ma a legtöbbet a motorra, és ez meg is látszik már azon, hogy a Frostbite technikailag mennyire elhúzott a piactól.
A Frostbite Team dolga alapvetően a motorfejlesztés, míg a problémamegoldás a DICE feladata. Az biztos, hogy a DICE-nál a BF4-gyel voltak problémák, de nem a grafikával és az optimalizálással, hanem a multival és a netkóddal. -
Abu85
HÁZIGAZDA
válasz
Locutus
#8753
üzenetére
A Nixxes és a Rebellion portjai, vagy az EA és a CodeMasters portjai, az Alien Isolation is elég jóra sikerült, de gyakorlatilag minden olyan fejlesztő portja, aki még nem tart ott, hogy a túlélésért küzdjön, így nem kell megfontolniuk, hogy mire költik a pénzt. Persze az élmezőnyben is vannak jobb portok, a legjobbak között. Ha ki kellene emelni párat, akkor a Sniper Elite 3 és a Civilization: Beyond Earth nagyon etalon kategória, figyelembe véve, hogy mennyire egyedi dolgok vannak bennük. Bizonyos technológiák szempontjából ezeknek a játékoknak fejlesztői felvállalták az úttörő szerepét. Ugye gondolok itt a Obscurance Fieldsre, illetve az egyedi tesszellálásokra. Kevesen tudják, hogy a Sniper Elite 3 az egyetlen program a világon, amelyen belül az összes felület tesszellálva van.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#8750
üzenetére
Nincs HDAO benne. Csak HBAO és SSAO van. A Frostbite 2/3 zömében az NVIDIA effektjeit használja, persze helyenként módosítva, mert nem volt ideális a leképzőhöz, de pont erre való a nyílt forráskód, hogy ha nem működik, akkor átírják úgy, hogy működjön. Az új Frostbite-ban már egyetlen új, NVIDIA által fejlesztett technológia sem lesz, mert abban a formában, ahogy kínálják az EA nem tudja jól integrálni.
Az EA stúdiói mögött marha nagy tőke van, és ezzel nem tud mit kezdeni az NV. Akármennyi pénzzel mennek oda igényelve azt, hogy "használjátok a játéklassítóinkat", nemleges lesz a válasz. Az EA-nek nem éri meg, mert sokkal kedvezőbb számukra, ha optimalizálni tudják a programot. -
Abu85
HÁZIGAZDA
válasz
daveoff
#8749
üzenetére
Ha üzletstratégiailag vizsgáljuk, akkor nem rossz a GameWorks, mert gyakorlatilag kihasználja azt, hogy sok a pénztelen kiadó és stúdió, akik úgy vannak vele, hogy úgysincs pénz a PC-s portra, mit számít, ha még optimalizálni sem lehet. Tipikusan ilyen a Warner, akitől olyan csodákat láthatunk, mint az MKX és a Batman: AK. Az NV-nél ezeket nem tudják promózni, mert szétbassza a saját felhasználóik agyát is, hogy 300K-s konfigra ilyen szar portot sikerült kiadni, ráadásul TWIMTBP logóval. Tehát ennek a modellnek megvan a maga hátránya.
Az AMD modelljének az az előnye, hogy a teljes nyíltság, nagyon jól optimalizált portokat hoz, viszont jóval kevesebb azoknak a fejlesztőknek a száma, akik mögött van tőke, és nem szükséges pénzért rontani a PC-s optimalizálhatóságot. -
Abu85
HÁZIGAZDA
Itt van az AMD grafikai middleware-je: [link] Sosem mondták, hogy nekik nincs olyanjuk, mint a GameWorks, csak azt mondták, hogy ők olyat kínálnak, amit optimalizálni is lehet. Régen az NV is ilyet kínált, azért is használ például a Frostbite 2/3 HBAO-t és FXAA-t. Ma inkább elzárják a kódot valamiért, és buktak is egy csomó partnert.
-
#8743
Abu85
HÁZIGAZDA
FollowTheORI
#8739
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#8739
üzenetére
Nehéz megmondani, hogy lesz-e benne DX12, mert a motor amit használnak alapjaiban 12 éves, tehát strukturálisan biztosan nem felel meg low-level API-khoz. Még a konzolokon is a magasabb szintű elérést használják.
Az Activision és az NV partnersége egyébként fontos mindkét cég számára, mert az EA meg összeborult az AMD-vel. Ők már nem csak olyan szerződéseket kötnek, hogy az AMD reklámozza a Star Wars-ot, hanem kizárólagosságra vonatkozó pontok is vannak, például a Star Warst csak az AMD-hez lehet kötni a reklámanyagokban. Az NV-nek erre reagálnia kellett, mert nekik is szükségük van egy brandre, amit ki tudnak rakni a kereskedők a reklámanyagokban.
-
Abu85
HÁZIGAZDA
Csak, hogy ezt kiegészítsem pár dologgal, elég komoly ez a probléma még az AMD médiapattogása nélkül is. A zárt middleware átka, hogy túl nehéz a beépítése a meglévő motorokba. Minél komplexebb az effekt, annál nagyobb az esélye, hogy nem fog működni. Egy szegény fejlesztőtől pedig nagyon nehéz elvárni, hogy írja át a motort csak egy effektért, erre se idő, se pénz, meg miért is nyúlna a motorhoz, ha működik. Erre nagyon jó példa, hogy az AC: Unity-ből kimaradt a GeometryWorks, vagy a Witcher 3-ből kimaradt a WaveWorks és a FlameWorks, vagy a Batman AK-ban egyszerűen a HBAO+ nem jelent meg a PC-s verzióban, pedig benne van. Ez mind annak a következménye, hogy az NV küldi a middleware-t, élesíti a fejlesztők, és ha nem működik, akkor baszhatják. A játék kiadása emiatt nem fog csúszni.
-
Abu85
HÁZIGAZDA
Ez nem feltétlenül ilyen egyszerű. Már nem mindenki látja annyira jónak ezt a GameWorksöt az NV-n belül sem. És nem arra gondolok, hogy a korábbi TWIMTBP zsenik (John McDonald, Timmothy Lottes, Cass Everitt, stb.) otthagyták a céget. Számold bele azt, hogy az egyetlen dolog, amivel ezt el lehet adni az a pénz. Viszont olyan fejlesztők szorulnak erre rá, akik nem nagyon törődnek a PC-s portokkal, mert így is szűkös az egész keret. Ezért szaporodtak el nagyon a rossz PC-s portok az NV oldalán, és nincs igazán lehetőség behúzni egy innovatív és jól optimalizált PC-s címet. Az már csak tetézi a bajt, hogy az AMD erre rájátszik ezekkel az üzenetekkel. Elég csak a bogár elültetése és az NV elvégzi a munkát a csomó fos TWIMTBP PC-s porttal.
-
Abu85
HÁZIGAZDA
rtuk a driverről szóló hírben is, hogy nagyrészt a gyorsulás a többletterhelés csökkenésének köszönhető. Leginkább az olcsó procikkal lehet érezni. Nálam például a Thief úgy jó 20%-ot gyorsult DX11 módban. Persze így is legalább kétszer gyorsabb a Mantle mód, de kétségtelen, hogy gyorsabb a DX11 mód.
A gyors proci mellett az extrát az új shader fordító formálódása hozza. Ez valamivel kevesebb regiszterhasználattal rendelkezik, illetve hatékonyabban gyilkolja meg az FXC optimalizálásokat, amely az AMD egyik nagy problémája a DirectX kapcsán. Az a D3D bájtkód nem jó, amit a Microsoft fordítója fordít. Több kárt okoz, mint hasznot. De ez általánosan igaz a stream rendszerekre, mert az FXC még mindig Vec4-es kódot fordít, miközben egyedül az Intel használ ilyen hardvert. Ezzel egy szimpla befordítás egy jó 50-60%-kal lassabb kódot eredményez. Ezért van olyan shader fordító az NV és az AMD meghajtóiban, amely előbb átír bizonyos dolgokat a D3D bájtkódban és aztán fordítja be. Ez a deoptimalizálási folyamat. Ezzel visszaszereznek némi sebességet, de nem mindent. Ez az Xbox One-ból látszik is, mert ott egy olyan fordító van, amely a shadert rögtön hardverre fordítja. Így ugyanaz a shader, ugyanazon a GCN hardveren 30-40%-kal gyorsabban fut. Jelenleg az egyik futó projekt a deoptimalizálási folyamat optimalizálása, mert nagyon sok teljesítmény elvész a D3D bájtkód kreálásának agresszív optimalizálásával.
Ezért lesz majd nagyon jó a SPIR-V és a Vulkan API, mert csak onnan tud majd nagyobb teljesítményt szerezni, hogy megengedi a fejlesztőknek az OpenCL használatát. Az erre írt fordítók sokkal hatékonyabbak, illetve a nyelv alapjai is tíz évvel újabbak, tehát az egész csomag modernebb, értsd nem a 2005-ös hardverekre tervezték. Már a SPIR-V működése is sokkal kedvezőbb a D3D bájtkódnál, mert nem Vec4-es kódot fordít, hanem a modern stream rendszerekhez igazodik, amit az NV és az AMD használ. És innen is nagyon szabad az optimalizálási irány, amíg a kód eljut a hardverhez. A Khronos teljes egészében megengedi, hogy a fejlesztők egészen a virtuális utasításarchitektúráig kontrollálhassák a fordítást. Ezzel ugyan a konzolos fordítási hatékonyságot nem érjük el, de maximum 3-5%-kal leszünk tőle elmaradva, ami a mostani 30-60%-hoz képest azért komoly előrelépés. A Vulkan egyébként elfogadja azt is, ha a fejlesztő nem is fordít a futtatási időben. A SPIR-V definiál egy olyan lehetőséget, hogy a programot offline fordítják le. Ezzel lehetőség lesz minden hardverre vISA binárist szállítani. Persze ez csak elméletben igaz, mert a hardverek virtuális utasításarchitektúrája védett, tehát a külvilág felé nincs specifikálva, de például a HSAIL igen, és számos motor SPIR-V bináris mellett szállít majd BRIG-et.
Ezek a váltások azért nagyon fontosak, mert a PC mindig fejlődni fog, tehát idővel az architektúrákat le kell cserélni. Az adott architektúra életciklusától függ, hogy a fordítót meddig optimalizálják. Az sem mindegy, hogy a fordítót mikor írták. Akkor, amikor a hardver még csak szimulátorban létezett, vagy akkor, amikor már ott volt a mérnökök kezében. A konzol azért tud fejlődni, mert az első fordítókat még a szimulátorra írják, tehát ezek hatékonysága nem olyan jó, de minden konzolgeneráció átesik egy olyan fejlesztésen, amikor 4 évvel a megjelenés után az SDK-t lényegében lecserélik egy modernebbre. Ez baromira megéri, mert 10 éves az életciklus, és adnak még 6 olyan évet a fejlesztőknek, amikor jobban kihasználhatják a hardvert. A PC-n ilyen nem létezik, mert jóval rövidebb az életciklusa egy generációnak, és konkrétan nem történt még olyan, hogy egy architektúránál a shader fordítót újraírták. Egyszerűen azért, mert mire az újraírásnak eredménye lenne már rég egy másik architektúra van a boltok polcain. Persze a fordító ettől még a régi architektúrán sokat gyorsítana, csak az már jó eséllyel nem vásárolható meg. Az AMD csinálja meg azt először, hogy mivel egészen pontosan fél tucat frissítést terveztek a GCN-re és ennek a felénél tartanak, a következő félhez át lehet írni a fordítóinfrastruktúrát, aminek előnye lesz az előző félnél is. Egyszerűen elkezdik egy picit konzolosítani a PC-t, mert egy olyan ciklussal, amikor az architektúra 2-3 helyett 6-7 évig marad, előnyösebb kihúzni a fordítóból a benne maradt teljesítményt. Erről szólnak majd a következő branchok.
Erre egyébként bőven át fog állni mindenki, mert abban az irányban, amerre a PC most megy előnyösebb a meglévő hardver ismerete, mint az új hardver kiadása. -
Abu85
HÁZIGAZDA
válasz
Xmister
#8683
üzenetére
Eigen. De ez a cikk még mindig nem írja le a valós problémát. Nevezetesen, hogy nem érdekli az NV-t, hogy jól fut-e a Radeonon, ez a csomag inkább arra kell, hogy az új generáció érkezésével a fejlesztő képtelen legyen az előző generációra optimalizálni. Ezzel szoftveres szinten el lehet adni a hardvert. És ezzel vissza is lehet hozni a régi, évenkénti frissítést, mert lehetőség lesz olyan szinten belassítani az egy éves VGA-t, hogy a felhasználók elgondolkodjanak a váltáson.
-
Abu85
HÁZIGAZDA
válasz
velizare
#8675
üzenetére
Akkor csak a Google volt béna, vagy én kerestem rosszul.
Mindegy a lényegen ez nem változtat. Ha egy fejlesztő írja le azt, hogy "the code of this feature cannot be optimized" az egyáltalán nem azt jelenti, hogy itt sok engedékenység lenne. Jó lenne tudni egyébként, hogy mi van a licencszerződésben, leginkább azt, hogy a forrást és a módosítást az NVIDIA mennyi pénzért engedi meg. Ha dollárszázezres nagyságrendet szabnak meg, akkor ez csak arra van, hogy rá lehessen mondani, hogy van forrás is, de hozzányúlni senki sem fog. -
Abu85
HÁZIGAZDA
Erről beszélünk egy ideje, hogy ez probléma. Ha a Hairworkshöz valaki minőséget akar hozzáadni, akkor nincs rá lehetőség, mert beleütközik az "as long as it does not lower performance on NVIDIA GPUs" kitételbe.
A forráskód kérhető, de az pénzbe kerül. A CD Projekt Red ezt mondta a Hairworksről: "... unsatisfactory performance may be experienced as the code of this feature cannot be optimized ..." - ezt azóta törölték a fórumból.Elég kemény, hogy az NV elismeri, hogy teljes kontrolljuk van a teljesítmény felett. Szabadon eldönthetik, hogy a Pascal érkezésével a Maxwell mennyire legyen alkalmas az új GameWorks effektekre, ami eléggé aggályos, már csak azért is, mert az NV-nek üzleti érdeke lesz a Maxwell lassítása, ahogy az most a Keplerrel történik. Szerintem ez egyáltalán nem egy jó irány.
-
Abu85
HÁZIGAZDA
válasz
Anubris
#8431
üzenetére
Az a baj, hogy nincs mire váltani. Az elmúlt 8 hónapban megjelent játékok nagy többsége fennakadt a GPUView tesztünkön. Ezzel határozzuk/határozom meg, hogy egy játék mennyire terheli le a GPU-kat, és a 30%-nál rosszabb terhelésűeket nem vesszük fel a tesztbe, mert azok optimalizálása sajnos nagyon hanyag. Nyilván a 30%-os terhelés is már egy elég alacsony érték, de ma azért szerintem elvárható, hogy a GPU-k teljesítményének a 30%-át hasznosítsa egy PC-s program, de elfogadom, ha másképp gondoljátok. Ehhez képest az új játékok normája 15-25% közötti.
Eközben két éve tucatszámra érkeztek az 40-50%-ra is terhelő programok. A GTA5 is éppen átcsúszik ezen a rostán, ha még ma is 40% lenne a minimum elvárt szintünk, akkor a GTA5 is elbukna rajta. -
Abu85
HÁZIGAZDA
válasz
daveoff
#8422
üzenetére
Az nem sokat befolyásolt. A GCN-ek előrelépését a 15.200-as branch hozta.
Kevesen értik meg, hogy egy hardver teljesítménye nem állandó. Sosem volt olyan a piacon, hogy egy architektúra itt volt három évig és még három évig biztosan itt lesz. Ergo minden meghajtót nagyjából csak 3 évre terveznek csupán azért, mert három év múlva már ott az új architektúra. Az AMD most azt csinálja, hogy három évre terveztek egy alap branchet, ami eddig tartott, és a következő három évre terveznek egy újraírt branchet, amiben megváltoztatják a meghajtó működését az előző három év tapasztalataira építve. Ennek az első meghajtója a 15.200-as sorozat. Most sorra le lesz cserélve a GCN szoftveres alapja, mert sokkal jobban ismeri már az AMD a saját architektúráját, mint három éve. -
Abu85
HÁZIGAZDA
válasz
MiklosSaS
#8420
üzenetére
Elég sokat segít neki a 6 GHz-es memória. Mi is meglepődtünk, hogy ez ennyit ér, de ennyit ér tényleg. Azt fontos kiemelni, hogy a közhiedelemmel ellentétben a 390X nem teljesen 290X átnevezés, hanem egy új steppingre épülő lapka, jobb PowerTune menedzsmenttel, és nyilván nagyobb memória-sávszélességgel. Ez az AMD szerint is hoz "up to 10%-ot" a 290X-hez képest, ami a mi tesztünkben is jelentkezett, nem ~10%-os mértékben, de jelentkezett.
A másik része a dolognak a 15.200-as driver branch. Az egy általános ~3-4%-os boost volt minden GCN-re. Ezért nem értettük, hogy miért nem ezzel a driverrel adták ki az új VGA-kat, mert a 15.150-es branch ennyivel lassabb is. -
Abu85
HÁZIGAZDA
válasz
velizare
#8396
üzenetére
Mert a CCC-ben aktívan a Perfect Pictures beállítások lényegében alapértelmezetten. Ezért a shaderek egy csomó post-processt számolnak még a gyorsított tartalomra. A Fury azért nem fogyaszt már annyit, mert ott ezeket a post-process funkciók átkerültek a hardverbe, így már nem a shadert terhelik, hanem egy a DSP-t.
A magas memória-órajel két monitorhoz azért kell, mert ha órajelet vált a memória, akkor a monitorokról egy pillanatra elmehet a kép. Ez nem lesz megoldva, mert HBM lesz minden kategóriában és ott meg eleve nincs órajelállítás.
-
Abu85
HÁZIGAZDA
A HUB legnagyobb előnye, hogy tranzisztorkímélő, miközben felkínálja a teljes sávszélességet a memóriavezérlő és a back-end között. Viszont ezt egyben kínálja fel, így leginkább a véletlen elérésben jó. HBM-mel már más előnye is van, mivel nagyon széles lesz a busz, és mondjuk 4096 bitet belül nehéz megoldani. HUB-bal elég a 4096 bites HUB, de crossbarral 8 512 bites es nagyon sok 256 bites keresztbusz kell.
-
Abu85
HÁZIGAZDA
válasz
Yllgrim
#8298
üzenetére
Akkor menjenek. Előbb-utóbb vége a dedikált GPU-k piacának. Ez sajnos megmásíthatatlan. Ezért koncentrálódik a mostani rendszer az áremelésre és a fejlesztések lassítására, mert addig is keresnek rajta, amíg még van min.
(#8303) Whysperer: Én nem akarok 4K-t meg 60-70 fps-t.
Nekem azért van PC-m, mert ez a munkám, de játszani mostanában főleg PS3-on játszok. Az a baj, hogy ha egyszer rálesel egy exkluzív játékra, akkor egyszerűen mindet akarod, mert annyira brutálisak ahhoz képest, ami ma a PC-ken van. Például a Dragon's Dogma: Dark Arisen. Valami ilyesmi adrenalinlöketet várnék a PC-s játékoktól is, több tonnás szörnyekkel és taktikus csapatharccal. Fáj, hogy ezt csak egy konzoltól kapom meg. -
Abu85
HÁZIGAZDA
válasz
mcwolf79
#8296
üzenetére
Az lehet, hogy van jelentkező, de az új API-k módosítanak azon, hogy miképp érdemes a termékskálát frissíteni. A következő években valószínűleg lesz egy pilot VGA minden generációban, ugyanis számolni kell azzal, hogy ha új architektúrát hoznak, akkor a játékokon sokkal rosszabbul teljesíthet, mint az elődje, mert a driver átkerül magába a játékba. Érdemes kihozni egy olyan előzetes fejlesztést, amely az új architektúrát tartalmazza. Ez az aktuális termékskálával együtt mehet, mert igazából piaci szerepe nem lenne. Viszont amíg megérkezik a nagytesó, addig számos játékot már optimalizáltak a pilot VGA-ra, és abból a nagytesó is profitál. Ez azért fontos, mert ha a nagytesó jön először, akkor annak lesz borzalmasan gyenge a teljesítménye optimalizálás nélkül.
-
Abu85
HÁZIGAZDA
Aki az AMD-nél dolgozik az szerintem már látta a programokat. Ebből a szempontból az AMD-nek nyilván lehetőségük van arra, hogy a DX12-t hype-olják, hiszen tudják, hogy mi várható. Ugyanígy az NV-nek és az Intelnek lehetősége van arra, hogy annyira ne foglalkozzon a DX12-vel.
Az árak alakulásában az játszik főszerepet, hogy ma már csak feleannyi VGA kerül eladásra, mint négy éve. Azért ez elég komoly visszaesés, és folyamatosan csökken a kereslet. Amíg ez nem fordul meg, addig az árak csak növekedni fognak. Ezért lassultak le a fejlesztések is, mert ma már nem akkora a piac, hogy értelme legyen másfél évente a teljes termékskálát lecserélni.
-
Abu85
HÁZIGAZDA
Igen a Thief támogatja PC-n, de csak a legutolsó javítással. A BF4 a PS4-en a pilot projektje volt az async shadernek. Ezután mindegyik PS4-es Frostbite 3 játék megkapta ezt a funkciót. A jövőben ez a funkció platformfüggetlen lesz a Frostbite-tal. A kísérletezés erre vonatkozóan állandó. Az a kérdés mikor kapcsolják be a funkciót.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#8258
üzenetére
A Witcher 3-nál opció a low-level mert rengeteg korábban beígért dolog a DX11 miatt maradt ki. A GTA5 esetében nehézkes mert XO és PS4 konzolokon sem low-level az elérés, szóval valószínű, hogy a motor strukturálisan sem megfelelő a DX12-re. Így azért a váltás egy jó fél éves munka lenne.
-
-
Abu85
HÁZIGAZDA
Gyakorlatilag ugyanarról a koncepcióról van szó. A Vulkan esetében is. Szerintem reális, hogy sokan várják. Csak a saját gépem példájára építve egy Dragon Age Inquisition DX11-ben nem megy 20 fps fölé, de ugyanazon a beállításon a Mantle nem megy 40 fps alá. Ezt kínálja a többi új API is. Naná hogy várja a játékos. Főleg akinek olcsó vagy régi procija van.
-
Abu85
HÁZIGAZDA
Az aszinkron compute-ot már a Frostbite 3 is támogatta, csak nem kapcsolták be egyik játékban sem, mert nagyobb fókuszt jelentett a memóriamenedzsment optimalizálása, és a validáció nagyrészt ennek az optimalizálásának a teszteléséből állt. De Johan már tartott korábban arról előadást, hogy a tiled gyorsítása aszinkron módban is elvégezhető a fények kivágási munkájával. Így csupán erre a feladatra vonatkozóan 80%-os gyorsulást értek el, de ez a feladat ma még nem teszi ki nagy részét a képfeldolgozásnak, tehát a végleges eredményre nagyjából ~10%-os boostot jelenthetett volna.
-
-
Abu85
HÁZIGAZDA
De. Egyik új EA játék sem a Frostbite 3-mal jön, hanem az új immáron számtalan verzióval, de a régi számozással ez Frostbite 4 lenne. A legfőbb előrelépés a PBR, de számos grafikai futószalagot lecserélnek hatékonyabb compute futószalagra. Változik a textúrázas, egészen pontosan a megatextúra streaming. Illetve kap egy új post process futószalagot, aminek a része egy új temporális analitikai AA. A deferred MSAA ugrik. Emellett megújul a multi-GPU mód, de azt nem tudni, hogy ez mennyire stabil. Lehet, hogy pár játékban marad az AFR, csak az a temporális AA-val nem annyira hatékony. Aszinkron DMA és compute lesz, ugye a DMA hozzáférés már most is aszinkron
-
Abu85
HÁZIGAZDA
Mit várunk versenyképesség alatt. A 380 gyorsabb, illetve a jóval nagyobb sávszélje. A 960 előnye, hogy kevesebbet fogyaszt.
A 380X nem feltétlenül szükséges, mert a 290 ott van 259 dollárért, annál nem lesz gyorsabb. Oda jönne a 380X és a 960 Ti. Az AMD ezt azért húzza el, hogy minél később legyen lemérve, hogy egyre több új játék kerüljön a tesztekbe a Windows 10-zel. Itt az NV fog előbb lépni, mert nekik nincs 259-ért termékük és nem várhatják meg az év végi játékdömpinget. Ha az AMD-n múlik elhúzza novemberig. Akkor jön a Star Wars Battlefront a Dual Fiji-vel. De legalább az új Need for Speedig érdemes kihúzni.
Azt nem árulták el, de az új EA játékokban már nem Frostbite 3 lesz. A következő variáns már PBR-es, sávszélzabáló, async shaderes/DMA-s cucc. -
Abu85
HÁZIGAZDA
válasz
daveoff
#8092
üzenetére
Mostantól a hétköznapi ember az egészet rosszul fogja tudni. Na meg kiderült, hogy a Maxwell 2 nem támogatja az aszinkron shadert. Oh wait, hiszen ennek megfelel. Valójában a legmagasabb bekötési szintet nem támogatja. Nembaj legalább a hétköznapi ember érti.
Olyan API-s legendák indultak el az elmúlt két hétben a magyar IT sajtóban, hogy az félelmetes. Egyáltalán mi az, hogy egyik GPU sem támogat minden DX12_1 szolgáltatást. Van ilyen, hogy DX12_1 egyáltalán?
Az lenne az igazság, hogy egyik hardver sem támogat minden DX12-es opcionális funkciót. A kötelező funkciókat mindegyik DX12-es hardver támogatja. -
Abu85
HÁZIGAZDA
válasz
Venyera7
#8080
üzenetére
A TIER_3-as szintet nyilván azért specifikálták, hogy később mindenki ezt használja. Azt nem tudni, hogy mikor, de egyértelműen ez a jövő, és az új generációs hardvereket is érdemes erre tervezni. Lehetőség szerint minél hamarabb, mert a low-level API-knál problémát jelent a teljes architektúra leváltása. Nagyjából két éven belül ez megtörténik.
(#8081) daveoff: Nem érhető el a BR-TIER_3 bekötés. A Maxwellnek nincs skalár egysége, amely a processzor beavatkozása nélkül el tudná intézni a bekötést. Lassabb igazából nagyon elhanyagolható mértékben lesz, mert ettől még bindless és a bekötés a mintavételezőbe történik. Ami hátrány lehet ebből, hogy nem minden effektet lehet megjeleníteni, ha elfogynak az erőforrások.
-
#8066
Abu85
HÁZIGAZDA
Petykemano
#8064
Abu85
HÁZIGAZDA
válasz
Petykemano
#8064
üzenetére
Az AMD a Zen CPU-it nem a játékosoknak csinálja. Megveheted játékra is, de ugyanabba a tokozásba lesznek APU-k, amelyek jobban kiszolgálják majd a játékosok igényeit.
A CPU erő az aktuális játékdizájnoknak nem kell. A limitek teljes egészében szoftveresek. Valójában egy totál belépő processzor minden játékra teljesen elég lenne, mert a szimuláció évek óta nem fejlődik. Az ipar nem az előrelépést tartotta szem előtt, hanem azt, hogy ugyanazt a szimulációs minőséget hozzák ki kevesebb processzoridőből. Szükség lesz majd úgy hozzávetőleg 2 évre, hogy az ipar a DX11 miatt leállított fejlesztéseket ténylegesen újrakezdje és befejezze. Ez tényleg magával hozza majd a modernebb AI-t, és egyéb szimulációkat, amit most a játékosok hiányolnak.
-
#8062
Abu85
HÁZIGAZDA
Petykemano
#8059
Abu85
HÁZIGAZDA
válasz
Petykemano
#8059
üzenetére
Nem, a DX12 lényege pont az, hogy a parancspufferek kreálása független, és akárhány szálra leosztható. Ez persze a motortól is függ, de a Nitrous ezzel a modellel 36 szálig lineárisan skálázódik, ami biztató ezekre az új API-kra nézve.
Ami itt a kérdés, hogy mivel lehet jobb eredményt elérni, mert lehet építeni négymagos CPU-t IGP-vel és nyolcmagos CPU-t IGP nélkül. A jelenlegi gyakorlati tesztekben azt látni, hogy az IGP elérhetősége többet ér, mint a kétszer több processzormag. Nem véletlen, hogy az IGP teljesítménye nő az új lapkáknál, míg a processzormagok teljesítménye inkább stagnál. Ez látható a Broadwell-K-n, a Godavarin és a Skylake-en is látható lesz. Lehet, hogy ezt még nem érti egy játékos, de a gyártók már látják, hogy a végső teljesítményt inkább az IGP határozza majd meg. -
Abu85
HÁZIGAZDA
A Windows 10 alatt az overhead nem javul. Azt az új API-k csökkentik. A régi API-k ugyanúgy működnek tovább. Persze az MS a WDDM 2.0 miatt lehetővé tesz wrappereket a DX12-höz, így bizonyos WDDM 1.3-ban nagyon korlátozó dolgok megkerülhetők. De ezt mindenki meg fogja kerülni.
A DX12 esetében a parancsfeldolgozás mindenkinek ugyanaz lesz. Az AMD-nek az előnye, hogy a GCN-es Radeonok a TIER_3 szinten futtatják a bekötést, ami többletterhelés nélküli, míg a kisebb szintek bizonyos funkciókat emulálnak, ami többletterheléssel jár. Minél kisebb a szint, annál több az emuláció.
Az aszinkron compute és DMA lényeges, mert nagyon egyszerűen kihasználható funkciók, és 15-45%-os gyorsulást kínálnak az azt támogató NV és AMD hardvereken.
-
Abu85
HÁZIGAZDA
Ja igen, az erősorrend az igazából különböző limitációkból adódik össze. Tipikus célja a tesztnek sorra terhelni mindent a maximumra, és előhozni a rendszerek limitjeit. Akárhol előjön egy limit az már rossz lesz a végső eredményre. A játékokban ezek biztosan nem így lesznek terhelve. A hasznossága azonban vitathatatlan, nagyon jól lehet látni belőle a rendszerek kiegyensúlyozottságát.
(#8055) Petykemano: Ha jönnek ilyen processzorok, akkor nem a játékok és a DirectX 12 miatt. Ez gyakorlatilag biztos. Erről pont az inteles cimbivel beszéltem a hétvégén, és az egyik legnagyobb húzófícsőrnek az IGP-k kihasználását tekintik a DX12-re dolgozó fejlesztők. Ennek többféle módja lehet, de a cél a kihasználatlan, sokszor 300-800 GFLOPS-os erőforrás befogása. Ezt nehéz lenne verni csak CPU-ból.
-
Abu85
HÁZIGAZDA
A 3DMark Overhead teszt komplexebb annál. Egyrészt nyilván nézi a parancsprocesszort, mert az egy fontos szempont, de maga a teszt procedurális, tehát minden ami megjelenik matematikai képletekkel lesz kiszámolva, tehát a GPU-t is terheli, mert compute shaderek futnak rajta, akár párhuzamosan. Ezzel számít a számítási teljesítmény és a sávszélesség is, illetve a compute parancsprocesszorok teljesítménye. Ez nem csak egy szimpla front-end teszt. Ráadásul az új verzió már nincs hat magra limitálva DX12-ben, mert kijavított az MS ezt a bugot.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#8013
üzenetére
Az informatikában minden nagyon gyorsan fejlődik, tehát ha egy évet csúszik egy projekt, akkor már van rá az eredetinél jobb képességű alkatrész is. Ezért nem akarja a Hynix a kockázatot felvállalni, mert nekik csak úgy éri meg, ha kifizetik, de ha nem sikerül a termék, akkor csak a gyártósor lesz meg, és a memóriákat vissza fogják mondani. De nyilván aki rendel azt kiszolgálják, szó sincs arról, hogy bárkit is korlátoznának, csak fizessék ki a rendelést. Ennyi kell a Hynixnek.
Az interposert nem az NV fejleszti, hanem a GloFo, Samsung, TSMC, UMC, stb. Attól függ, hogy kiét választják. Az AMD az UMC-t választotta például. -
#8012
Abu85
HÁZIGAZDA
Malibutomi
#8011
Abu85
HÁZIGAZDA
válasz
Malibutomi
#8011
üzenetére
A HBM1 most érhető el. Fogd fel úgy, hogy az AMD már működő megoldást szállít a piacra, míg a többieknek most van lehetőségük elkezdeni a tesztelést. Itt mindenki hátrányban van. Viszont a HMC jó példa arra, hogy a Hynix jól döntött, amikor mindenkit kizárt a fejlesztésből, mert az régebb óta készül és még mindig nincs. Tehát ennek a döntésnek voltak előnyei és hátrányai is.
Ha valaki HBM2 lapkát hoz ki, akkor Q4-ben kezdheti meg a tesztelést. A HBM1 és a HBM2 nem kompatibilis. Más interposer kell hozzájuk. -
Abu85
HÁZIGAZDA
válasz
CsonkaImo
#8005
üzenetére
A Fiji tape-outja a Tongával párhuzamosan volt, méghozzá 2013 végén. Az első implementáció nagyjából 1,5-2 év a tape-outtól számolva. A második kör nyilván a tapasztalatok miatt egyszerűbb.
Szerintem egy év múlva senki sem fog. A HBM2 kísérleti gyártása 2016Q2-ben esedékes és interposerek is Q2-Q3-ban jönnek. A tömeggyártás Q3-Q4. Ha mákjuk van akkor a 2016-os ünnepi szezon támadható. Az a baj, hogy nem rajtuk múlik. Hiába van kész a lapka a megjelenéshez kell az interposer és a memória is. -
Abu85
HÁZIGAZDA
válasz
Locutus
#8003
üzenetére
Az AMD az NV-vel semmit sem oszt meg a HBM-ről. Azt amit az AMD elvégzett magának mindenkinek végig kell járnia, mert senki sem tudja előre, hogy az adott rendszerüknek melyik implementáció a jó, nagy valószínűséggel az AMD-é biztos nem jó senki másnak. A HBM2-re pedig pont azért nem ajánlja a Hynix az ugrást a nulláról, mert simán elképzelhető, hogy egyik lehetséges implementáció sem lesz jó.
Itt a kockázatok megosztása a gond. A HBM1-nél ezek megoszthatók, így a Hynix elfogadja, ha valakinek nem sikerült. Egy csomó más HBM1-et célzó cégnek még el tudják adni a memóriát. A HBM2-nél már nem fogadják el, így ha lesz termék ha nem, a megrendelt memóriákat el kell vinni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Eközben két éve tucatszámra érkeztek az 40-50%-ra is terhelő programok. A GTA5 is éppen átcsúszik ezen a rostán, ha még ma is 40% lenne a minimum elvárt szintünk, akkor a GTA5 is elbukna rajta.
Nekem azért van PC-m, mert ez a munkám, de játszani mostanában főleg PS3-on játszok. Az a baj, hogy ha egyszer rálesel egy exkluzív játékra, akkor egyszerűen mindet akarod, mert annyira brutálisak ahhoz képest, ami ma a PC-ken van. Például a Dragon's Dogma: Dark Arisen. Valami ilyesmi adrenalinlöketet várnék a PC-s játékoktól is, több tonnás szörnyekkel és taktikus csapatharccal. Fáj, hogy ezt csak egy konzoltól kapom meg. 
Olyan API-s legendák indultak el az elmúlt két hétben a magyar IT sajtóban, hogy az félelmetes. Egyáltalán mi az, hogy egyik GPU sem támogat minden DX12_1 szolgáltatást. Van ilyen, hogy DX12_1 egyáltalán?
Ú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.
- iPhone 13 256GB 100% (1év Garancia) - ÚJ EREDETI AKKUMULÁTOR - AKCIÓ
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32/64GB RAM RX 7600 8GB GAMER PC termékbeszámítással
- Xiaomi Redmi Note 15 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- Samsung Galaxy Z Flip6 12/512GB - ÚJSZERŰ, Kártyafüggetlen, Kék - 1 év garancia
- Telefon felváráslás!! Xiaomi 13T, Xiaomi 13T Pro, Xiaomi 14T, Xiaomi 14T Pro
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest