Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Lényegében igen. Valójában persze a Mantle kell, de az a LiquidVR alapja.
Igazából nem ez az AMD igazi VR csodafegyvere. Fontos dolog, de a Latest Data Latch miatt olyan alacsony az AMD VR csomagjának késleltetése. Ez ugyanis lehetővé teszi, hogy a fejpozició közvetlenül a GPU-s számítás előtt legyen meg. Minden más VR rendszer a jelenetszámítás előttről szerzi ezt az adatot, és ez ad hozzá az egészhez úgy 5-10 ms-os extrát.
-
Abu85
HÁZIGAZDA
Szerintem a VR-nél ne keverjük a szoftveres problémát a hardveressel. Az AMD implementációjának azért olyan alacsony a késleltetése, mert a VR egy VR-re tervezett API-n keresztül működik. Az NV-nek csak a szabvány API-k maradnak, amelyeket nem terveztek olyan igénybevételre, amilyet a VR követel. Függetlenül attól, hogy a hardver mire képes, a szabvány API-k nem alkalmasak a megfelelő késleltetésre. Akkor lesz ez a VR alkalmas a legtöbb hardverre, ha a szabványos VR API-k elkészülnek.
-
Abu85
HÁZIGAZDA
Ki van zárva. Mondom, hogy lesz olyan gyártó, aki egyetlen egy Nano VGA-t szállít EU-ban. Az USA már három számjegyű mennyiségét kap, de a gyártók nem fogják odaadni a kereskedelmi forgalomba szánt termékeket. Akik sokat kapnak azok az OEM-ek, na ők aztán biztos nem adnak tesztre. Szóval az a pár darab lesz, amit az AMD tesztre szán, és azok kapnak, akiknek az olvasottsága magas. Akik esetleg kedveltek, de az olvasottsaguk alacsony, azok biztosan kimaradnak az NDA lejártára. Nyilvan itt az a probléma, hogy ebben a formában a kisebb oldalak vannak háttérbe szorítva a nagyobbakkal szemben. Arról például a TechReport nem tehet, hogy nem olyanok a forrásai, mint mondjuk tomnak. A TPU egészen mas kategória. Ők NDA-t szegtek régebben, és ezt manapság az AMD nem nézi el. Más Radeont sem kaptak már korábban. Ezen úgy tudnak változtatni, ha kifizetik a bírságot, ami nagyon durva pénz. Esetleg nagyon be kell puncsolni, és akkor talán újra megy a csomag.
-
Abu85
HÁZIGAZDA
válasz
wjbhbdux
#9895
üzenetére
Az aktuális tervekben egyetlen gyártó sem készít speciálisan Steam Machine PC-t. Alapvetően annyi lesz, hogy lesz pár alapgép és arra telepíthető Windows és SteamOS. A gép ugyanaz, de az előlapi logó eltérő. A legtöbb Steam Machine egyébként továbbra is Windowszal lesz szállítva, mert az MS egy rakás játékra Windows exkluzívitást kötött. Olyan játékokra, mint az új Tomb Raider. Ez azért nem kis tényező.
-
-
Abu85
HÁZIGAZDA
válasz
#85552128
#9888
üzenetére
Mert az OEM-ek vinnék már az ünnepi szezonra. Ahhoz, hogy meglegyen a kínálat novemberben, most rendelik le a készleteket. Ide megy majdnem minden Nano, mert a pici izmos lesz a menő karácsonykor, legalábbis az OEM-ek koncepciója szerint. A Nano pedig a legerősebb apró VGA.
-
Abu85
HÁZIGAZDA
Nincs pedig. Szinte mind a piacra megy. Kb. egy tucat kártya van tesztekre globális szinten. Ilyen helyzetben gyakorlatilag az olvasottság dönt, és ebben a TechReport nem olyan jó, mint mások, sőt kifejezetten rosszak. Egész Európába két számjegyű mennyiség érkezik a Nanoból a start hetére. Lesz olyan gyártó, aki csak egyetlen egy kártyát szállít le.
-
-
Abu85
HÁZIGAZDA
Az nincs megerősítve, hogy ki nyert, de az Imagination, az Intel és az AMD futott versenyt. Valszeg behúzta az AMD. Az Intelnek semmi esélye nem lehetett, mert nem vállaltak egyedi tervezést. Az Imagination valszeg jó esélyekkel indult, de többet érhetett, hogy hasonlítson a dizájn a két nagy konzolra.
-
Abu85
HÁZIGAZDA
Ez az egész bullshit. Az NV és az AMD rendelkezik keresztlicenc szerződéssel. Még ha le is jár úgyis megújítják. 3D Stacking technikával nem lehet ekkora teljesítményt kihozni. Ha az NV-nek nem lesz Pascalja 2016-ban, akkor az azért lesz, mert zéró tapasztalattal ugrottak neki a HBM2-nek. A Hynix többször is mondta, hogy előbb mindenki a HBM1-et implementálja.
-
Abu85
HÁZIGAZDA
A konzol is ugyanazt a leképzőt használja. Bár azt nem tudom, hogy melyik eléréssel, valszeg nem a low-levellel, de a JC3 már az lesz elvileg. Az meg nem akkora meglepetés, hogy Emil Persson ért hozzá. Ő eleg durva dolgokat csinált akkor is, amikor az ATI-nál dolgozott. Kb. olyan kaliber a srác, mint Johan Andersson.
-
Abu85
HÁZIGAZDA
Dehogy is. Ez már az új Avalanche motor, persze nem aktív benne minden, mert a fő projekt a JC3, de az alap ugyanaz lesz.
A Mad Maxet valószínűleg sietette a WB, de így is jól van optimalizálva. Később meg javíthatnak rajta a patchekkel, ahogy elkészülnek az új verziók a motorból.
-
Abu85
HÁZIGAZDA
Ez nem függ a CPU-magok számától. Maga a multi-engine sem függ össze a többszálú parancskreálással. Aranyszabály erre nincs, de jelenleg egy compute, egy grafikai és egy copy motor az ajánlott, vagy elterjedt. Később a compute motorok száma kettőre nőhet, de csak akkor, ha több regiszter lesz a GPU-kban, vagy a jobb IR-ek alapján (pl.: SPIR-V) ezek allokációja javul. De ma biztos nincs olyan program, ami egynél több compute motort használ.
Azt hiszem, hogy a PS4-es Dreams lesz az első, de az full compute, hiszen signed distance fields ray tracinget használ. -
Abu85
HÁZIGAZDA
Nem. A Nano is Fiji. Valójában egyik GCN3-as GPU-ban sincs nyolc ACE. Négy ACE van két HWS-sel. Az a lényeg, hogy egy HWS pontosan arra képes, mint két ACE, tehát lehet jelezni 8 ACE-nek vagy 4 ACE-nek és 2 HWS-nek is. A HWS extra képességei, mint a finomszemcsés preempció kezelése vagy a Quality of Services támogatása HSA, illetve LiquidVR alatt használhatók ki. Később ezekre majd lesz a szabványos API-kban is támogatás, hiszen a VR-hez kell a finomszemcsés preempció.
Technikailag csupán a DX12, Vulkan és OpenCL API-kre levetítve teljesen mindegy a blokkdiagramm. A 8 ACE és a 4 ACE+2 HWS is ugyanúgy 8 OOO logikás compute motort ad motoronként 16 parancslistával.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#9606
üzenetére
Az Intel a gen8-tól kezdve több compute parancslistát kezel, illetve a gen9 a Skylake-ben már képes mixált módra is, így képes egyszerre fogadni egy grafikai is több compute parancsot. Viszont az Intel ezt a képességét a driverben letiltja. Valószínűleg nem bíznak annyira a fejlesztőknek, mint az NV, hogy a hardverük miatt több path-ot írnak. Nem véletlenül olyan a DX12 amilyen. Ha a hardverben nem jó a multi-engine, akkor a driver ne jelezze vissza rá a hardveres támogatást, és akkor minden parancs a grafikai listába kerül. Ez pont azért van így felépítve, hogy a fejlesztőknek ne legyen szükséges architektúrákra butított kódot írni. Mondjuk egy Oxide megteszi, mert pénzesek, de szerintem lesz olyan, aki nem fogja extra munkában verni magát. Mondom ezt úgy, hogy szerintem az Oxide hozzáállása tényleg példás és követendő.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Szerintem te nem olvastad el a DX12 specifikációját. Ezért hiszed, hogy az aszinkron compute kikapcsolható. Ekkor ezt tegyük tisztába. A multi-engine a DX12 alap képessége. A feladatok jellege alapján ezek három motorba tölthetők: copy, compute és grafika. Így kell kötelezően írni egy DX12 alkalmazást. A fences használata, ami nem kötelező, de aki async kódot írt az biztosan használja. Innen az egész async compute csak úgy kapcsolható ki, hogy az eredeti kód mellé kerül egy olyan kód, ami a validátor javaslatai ellenére mindent a grafikai parancslistába tölt. Persze ez lényegében egyenlő a kikapcsolással, de ez nem olyan munka, hogy írnak egy sort a kódba, hogy OFF és kész.
-
Abu85
HÁZIGAZDA
Az AotS-ben csak annyit csináltak, hogy a validátor javaslatait ellenére van egy olyan path, ami minden feladatot a grafikai parancslistába tölt be. Semmi sincs igazából kikapcsolva, csak az NV kérésére írták egy validátoron hibazó szabványos kódot is. Ami azért extra munka. Nyilván puszi a hasukra érte, de a legtöbb fejlesztő a validátorra fog hallgatni. Az mondjuk megint marha jó kérdés, hogy a validátort az MS miért vette át egy az egyben az AMD-től. Tudhatták, hogy az a GCN-hez van igazítva, amikor visszajelez bizonyos problémákat. Honnan a fenéből tudja egy fejlesztő, hogy a validátor javaslata jót tesz-e a többi architektúrának. Még ha rá is jönnek a kiadás előtt, hogy nem, akkor sincs már idő lényeges módosításra. Ezért kedvezőbb a Vulkan, mert ott ugyan az AMD validátora az alap, de a nyílt specifikáció miatt lehet alternatív validátorokat fejleszteni.
-
#9583
Abu85
HÁZIGAZDA
huskydog17
#9563
Abu85
HÁZIGAZDA
válasz
huskydog17
#9563
üzenetére
Gondolom a Rise of the Tomb Raider olyan fejlesztés lesz, mint a Fable Legends. A PC-s port annyi lesz, hogy az Xbox One kód kap pár sor kiegészítést, és azt tesztelik. Az MS ezért hozza ennyire közel a konzolt és a PC-t szoftveres szempontból, hogy végtelenül egyszerű legyen portolni.
-
Abu85
HÁZIGAZDA
Nem kamuzott senki. A DX12 specifikációja azt követeli meg, hogy a multi-engine hardveres kezelése szempontjából a hardver képes legyen minimum egy copy, compute és grafikai feladatot egyszerre fogadni. Ennek a feltételnek a Maxwell 2 megfelel. Arra már nincs előírva specifikáció, hogy ezek a feladatok a hardverek belül is futhassanak egyszerre. Következésképpen az is elfogadott implementáció, ami nem hoz gyorsulást minden kódnál. Erre nincs is meg a lehetőség, mert nagy a fejlesztők szerepe. Az NV mindig is annyit mondott, hogy támogatják ezt a képességét, amikor erre irányult a kérdés, azt viszont sosem állították, hogy ennek a használata mindig pozitiv hatással van a sebességre.
-
Abu85
HÁZIGAZDA
A multi-engine kötelező funkció a DX12-ben. Ezért fogadja el rá az MS a szoftveres támogatást. Maga a validátor ki fogja adni a kódvalidálásnál, hogy mely feladatok vannak rossz engine-be töltve. Szóval itt nincs olyan, hogy nem támogatja a program. Maximum nem lesz ra szinkronizálás, de ettől egy adatfeltöltésre ki fogja adni a hibát a validátor, hogy nem a copy engine-ben van a feladat.
-
Abu85
HÁZIGAZDA
Látszólag a DX12 implementációk nincsenek normális szinten. Nagyjából megcsinálták őket stabilra, de sebesség egyelőre nincs bennük. De a stabilitás is kérdéses, abból kiindulva, hogy az ARK DX12 patch csúszik. Szóval itt a rendszer még közel sincs kész. Emellett az Oxide is írta, hogy még jönnek Win 10 update-ek a DX12-höz, és ha ez igaz (nyilván miért hazudnának), akkor maga az API sincs teljesen összerakva. Az Intel driverével pedig egyáltalán nem indul el az AotS, tehát vannak itt még gondok. Szerintem egy jó két hónap még kell ahhoz, hogy a DX12 implementációk jobban működjenek. Persze szerencsére ez régen sem volt másképp, szóval ezt valószínűleg mindenki bekalkulálta. Azt persze jó lenne tudni, hogy a meghajtók miket kezelnek teljesen és mi az, amit egyelőre csak stabilan támogatnak, de a sebességre nincsenek kigyúrva.
Igazából a Maxwellen is működik a DX12. A batch submission time jelentősen csökkent a DX11-hez képest, tehát maga az API a várakozásoknak megfelelően teljesít. A többi része a dolognak már implementációtól függ, és itt majd az NV-nek ezt ki kell vizsgálnia. De gondolom ők is tudják, hogy milyen optimalizálások nincsenek engedélyezve.
A lassulásnak egyébként lehetnek olyan okai is, hogy a DX12 változtat a működésen a DX11-hez képest. Egy csomó dolgot a driver már nem tud befolyásolni. Például a hazárdok kezelését, az erőforrások menedzsmentjét. A GDC Europe alatt volt egy előadás, ahol azt mondták, hogy az erőforrás-kezelés nehéz lesz, mert a motorra hárul a feladat, de csak egyszer kell jól összerakni és akkor oké lesz. Erre volt az a kérdés, hogy melyik architektúrára, és az MS-es csóka mondta, hogy a dokumentációk átvizsgálása után érdemes olyan irányt keresni, ami minden architektúrának úgy ahogy jó. Ez már hozhat egy olyan mértékű változást, ami csökkenthet a tempón, mert eddig a drivert ki volt gyúrva architektúraspecifikusan, míg most a programkód teljesen kiváltja, ráadásul a fejlesztőtől függ a teljesítmény is. Aztán az aszinkron compute nem csak egy DX12 only dolog. Hivatalosan az, de a DX11-nél nem a program, hanem a driver töltötte be a feladatot a parancslistába. Függetlenül attól, hogy az alkalmazás nem, a driver ismeri a hardvert, tehát ráhackelhető némi párhuzamosítás a rendszerre. Persze ez nagyon korlátozott lesz, mert szinkronizációt a driver sem tud tökéletesen biztosítani, de valamennyi sebesség nyerhető vele. Ilyen szempontból az NV DX11-es drivere elég jó volt, de ezt a kutatást teljesen kidobhatják, mert ilyenre a DX12 már nem ad lehetőséget. Ezzel az NV inkább sebességet veszít mint nyer. Szerintem több ilyen apró trükk van a DX11 meghajtójukban, aminek az előnyeit a DX12-vel teljesen elvesztik.
A jövőben egyébként nem gondolnám, hogy az NV megmarad annál a politikánál, amit most folytatnak. Láthatóan hátrányos a program oldali optimalizálásra, hogy a fejlesztők nem ismerik eléggé a GeForce-okat. Mindenképpen szükséges lesz a dokumentációk újbóli publikálása. Legalábbis más út egyelőre nem látszik, hiszen a hardvert nagyrészt az alkalmazás fogja vezérelni. -
Abu85
HÁZIGAZDA
válasz
#35434496
#9506
üzenetére
Az Ashes of the Singularity az. Egy csomó játékmód nem is lesz elindítható DX11 alatt. Nem lenne meg a sebesség a futtatáshoz.
(#9507) wjbhbdux: Lesz DX12 only játék. A Fable Legends és a Rise of the Tomb Raider. De újabban arról van szó, hogy a Gears of War felújításból is kiveszik a DX11 módot, mert csak időpazarlás lenne az optimalizálása.
(#9509) gbors: Az aszinkron compute-ot minden DX12-es drivernek vissza kell jeleznie. Ezen belül jelezni kell a program felé, hogy valóban ott van a képesség a hardverben, vagy pusztán a követelmények teljesítése érdekében jelzi a támogatást. Ez azért kell, mert tisztán aszinkron compute-ra írt kód esetében a szoftveres emuláció ronthat a teljesítményen, így a programba nem árt belerakni egy alternatív kódot is, ami csak natívan grafikai parancslistába dolgozik. A driver visszajelzése alapján az egyik opció kiválasztható. Az NV drivere azt jelzi vissza, hogy tudja a hardver ezt a képességet, és ez technikailag így van, de az API és a program már nem képes értelmezni, hogy a hardver belül hogyan tud futtatni párhuzamosan feladatokat. Szerintem itt az alapprobléma az, hogy az API-nak ezt a részét az AMD építette, és a Microsoft csak úgy átvette. A GCN stateless architektúra, tehát a compute feladatok futtatásához nem kell beállítani hardverállapotot, vagyis akármit is futtat a rendszer mellette biztosan futtatható több compute feladat. A Maxwell parancsprocesszora képes fogadni a compute és grafikai feladatokat, de a compute is hardverállapothoz kötött, ha a compute feladat már hardverállapotot igényel, mint a futtatott grafikai feladat, akkor állapotváltásra van szükség, ami előfordulhat, hogy lassabb, mintha soros lenne a végrehajtás. Valószínűleg az Ashes of the Singularity ebbe a hibába esett bele, olyan compute feladatot futtat a grafikai mellett, amire a Maxwell képtelen, annak ellenére, hogy elvben a támogatás hardveres szinten is megvan, legalábbis abban a formában, ahogy az API megköveteli. Ezt úgy orvosolták, hogy a programon belül kapott a rendszer egy tiltást, hogy Maxwellen annak ellenére se fusson aszinkron compute, hogy a driver erre a támogatást hardveres szinten jelzi. Ebbe a hibába egyébként sokan beleeshetnek, mert a DX12 és a Vulkan is logikailag úgy kezeli a hardvereket, hogy azok stateless compute képességgel rendelkeznek, tehát nincs lehetőség programkódban ellenőrizni, hogy milyen feladatokhoz milyen állapot beállítása szükséges. Ezért nem jó, ha egy hardvergyártó tervezi az API-kat, mert jó eséllyel nem gondol a konkurens architektúrák működésére. Most tulajdonképpen hiába felelnek meg az Intel és az NV új megoldásai a multi-engine képességnek, ezek a kódok esetleg lassíthatják a feldolgozást. Nem véletlen, hogy az Intel drivere szoftveres szinten jelez vissza támogatást, annak ellenére, hogy megvan a hardveres is. Valószínűleg az NVIDIA számára is jobb, ha általánosan letiltják ezt a képességet, mert nem tudják majd az összes stúdió kezét fogni, és kérni a program oldali tiltást. Ha pedig ez nincs, akkor a GeForce sebességet veszíthet.
De a driver is paraméterezhető. Ma a támogatás azért problémás, mert az aszinkron compute szinkronizációt igényel, de a kiadott meghajtók ebből a szempontból nagyon korlátozottak, és esélyes, hogy a szinkronizálás lekezelése helyett inkább befűzi a sorba az elvileg aszinkron feladatot. Persze nyilván a fejlesztőknek már vannak olyan meghajtóik is, amelyek nem így működnek. Az Oxide tapasztalatai nyilván ezekre épülnek.
Egyébként nem ők az egyedüliek, akik azt mondják, hogy a GCN ebben bitang jó. A Fable Legends fejlesztői is utaltak arra, hogy az AMD-nek ez az újítás nagyon fekszik. A kérdés, hogy ebben mennyi szerepe van annak, hogy a kódokat a konzolok miatt GCN-re írják, illetve ez mennyiben rontja a konkurens hardverek hatékonyságát. Valószínűleg a Maxwellnek abszolút nem ideális az, hogy a motorokban az egész multi-engine stratégiát a GCN-ek publikált paramétereihez konfigurálják. Jó lenne tudni, hogy ha a Maxwell dokumentálva lenne, és ezáltal tudnák a fejlesztők, hogy erre milyen konfiguráció kell, akkor ez a lassulás bekövetkezne-e, vagy gyorsulást hozna az aszinkron compute.(#9512) daveoff: A Frostbite mindenképp a Vulkan irányába megy. A WDDM 2.0 használatához nem feltétlenül szükséges a DX12, jó neki a Vulkan is. A Vulkan egyértelmű előnye az EA számára, hogy nekik a vezérplatformjuk a PS4, és arra lesz Vulkan. Nincs még bejelentve, de lesz. Emellett a Vulkan API-val képesek olyan piacokat is lefedni, amelyeket ma még nem tudnak. Például Linux (SteamOS) és Android. Emellett a Vulkan hatalmas előnye, hogy van SPIR-V támogatása, tehát nem kell magukat a HLSL-hez láncolni, ami azért egy elég öreg nyelv már. A konzolokon jobb shader nyelvek vannak, és a SPIR-V lehetővé teszi azokat a képességeket PC-n is, amelyek HLSL-ben nem használhatók ki, de a konzolon már igen.
-
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.
-
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. -
#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á. -
-
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.
-
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.
-
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.
-
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.
![;]](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.
- Macska topik
- HiFi műszaki szemmel - sztereó hangrendszerek
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- TCL LCD és LED TV-k
- Fejhallgató erősítő és DAC topik
- Samsung Galaxy A52s 5G - jó S-tehetség
- Xiaomi 15T - reakció nélkül nincs egyensúly
- Brave
- Battlefield 6
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- További aktív témák...
- PC bontás - Thermaltake ház, Fsp 650W, GIGYBYTE AB350M, AMD RYZEN 5 1600x, 16GB DDR4 3000, GTX 1080
- Hp NVidia RTX 2070 Super 8Gb Videokártya - HP L84981-001
- ASUS RTX 5090 32GB GDDR7 ROG ASTRAL OC - Új, Bontatlan, 3 év garancia - Eladó!
- Gigabyte AMD Radeon RX 9060 XT GAMING OC ICE 16GB(Bontatlan)
- ASUS ROG RTX 3060 OC 12GB GDDR6 jegelve nagyadam29-nek
- Általános igazgatóhelyettes tábla üvegből eladó
- Bomba ár! Dell Latitude E6440 - i5-4GEN I 8GB I 256SSD I 14" HD I HDMI I Cam I W10 I Garancia!
- 0perces! Samsung Galaxy Book5 Pro 360 2in1 Core Ultra 7 256V 16GB 1TB 16" WQXGA+ AMOLED TOUCH 1évgar
- GYÖNYÖRŰ iPhone 13 mini 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3293, 100% Akksi
- HIBÁTLAN iPhone 13 128GB Starlight -1 ÉV GARANCIA - Kártyafüggetlen, MS3917, 100% Akkumulátor
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest