Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Az EULA-ban világosan le van írva, hogy az AMD mire vállal felelősséget és garanciát. Amikor feloldja a user a tuningmodult, akkor ezt el kell fogadni. Sokkal többre vállalnak garanciát, mint bármelyik 3rd party tuningprogram. De természetesen hardvertől függő dolgokra nem. Ebben az órajel és például a ventifordulat paraméterezése is benne van. Ellenben arra van garancia mindenhol, hogy a gyári hűtés szoftverkonfigurációja működni fog.
Olvassatok el egyszer egy ilyen EULA-t.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#20530
üzenetére
Csak nem 3rd party programból kértem.
(#20532) mcwolf79: A tuningprogramokra és tuningmodulokra a cégek különböző felelősségeket vállalnak Ezért javaslom az EULA-k elolvasását, hiszen az segít megérteni a különbségeket.
Az AMD azért vállal többet a 3rd party programoknál, mert gyári modulról van szó, tehát képesek úgymond garantálni azt, hogy a kártya automatikus ventilátor szabályozása működőképes marad. Ezt például egy 3rd party program nem garantálja. De az is igaz, hogy egy módosítás működését már egyik EULA sem garantálja. Ugyanakkor az AMD modulja úgy van beállítva, hogy vannak határok, amelyek biztosítják a reális működési lehetőségeket. Például a memóriaórajel esetében annak olyan hibák, amikor a magasabb órajeltől csak pár 30-40 cella esetében lesz probléma, amit az EDC mondjuk nem képes korrigálni. Ilyenkor a tuning stabil lesz, de 2-3 órával a játék indítása után megjelenhetnek képi hibák. Na most az AMD erre alkalmaz úgynevezett paraméterezési limiteket.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#20538
üzenetére
Elsősorban azért előny, mert minden változásra azonnal lehet reagálni a tuningmodullal. Egy 3rd party alkalmazás erre nem képes, így ha változás van a meghajtóban, akkor minimum egy hetes átfutási idő van, mire arra egy programfrissítés érkezik.
A másik előny, hogy a tuningmodult azt tervezi, aki a hardvert tervezte, vagyis olyan funkciókat tud előhozni, emire egy 3rd party alkalmazás fejlesztője képtelen lenne. Ilyen például a Wattman ventilátorszabályozása, ami akusztikai limitre is paraméterezhető. Ilyen például elméletben megoldható lenne Pascalon is, csak túl kevés az információ a hardverről, hogy bárki megfontolja ezt a funkciót.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#20540
üzenetére
Ha a memóriaórajelre gondolsz, akkor az nem bug, hanem pár visszajelzés kezelése. A memóriatuning problémás, aminek az az oka, hogy a memória a VGA-n akkor is stabil marad, ha amúgy már nem az. Gondolj a memtestre. Nem addig tuningolod a rendszermemóriád, amíg az OS már be sem tölt, hanem addig, amíg a memtest nem jelez hibát. Na most egy VGA-n a cellahibák nem jelentenek semmit. Akár 100 cellahibával is tök jól elvan a hardver, de a játékokban, 8 GB-os VGA-knál jellemzően 4-6 órás játék után előjönnek a grafikai hibák. Amennyiben erre vonatkozóan a tuning miatt nőttek meg a bejelentések a support felé, akkor lépni kell, hogy ezek a grafikai hibák eltűnjenek. Az elsődleges lépés, hogy limitálod az órajelet, és redukálódik a cellahibák száma.
A felhasználók 99,99%-a képtelen felfogni, hogy az egyes részegységek tuningjánál hol a határ. Nincs megfelelő eszköz arra, hogy a VRAM-ot ilyen formában kimérd, és nagyon sok tuningoló nem fog 4-6 órákat játszani egy olyan specifikus játékkal, ami végre betalál egy tuning miatt hibássá vált cellát.Ez egyébként egy oktatási probléma. Egy gyártó számára sokkal nehezebb a felhasználóiknak elmagyarázni a hardverek működését. Sokkal realistább elfogadni, hogy a user hülye és nem tudja, hogy hol a memóriatuning határa. Következésképpen korlátozni kell a tuninglehetőségeit, mert el fogja árasztani a supportot fals hibabejelentésekkel, ugyanis jellemző, hogy a user a tuningot sosem vallja be. Úgy érzi ez nem fontos adat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#20531
üzenetére
A legtöbb mai asztali GPU eleve nem tipikus IMR, hanem egy TBR-IMR keverék. Persze más mértékben. Az korábban is ismert volt, hogy az NV nagyobb teret ad a TBR-nek, és kisebbet az IMR-nek, mint mondjuk az AMD. Az Intel pedig nagyon a klasszikus IMR-hez közelít, de ott is van tiling optimalizálás.
A legutolsó klasszikus IMR dizájn az AMD-nél a Terascale, az Intelnél a Gen6, míg az NV-nél a Fermi volt.
Az oka ezeknek az átmeneteknek az, hogy a klasszikus TBR és IMR ma már nem kifizetődő, mert a klasszikus IMR eszi a sávszélt, míg a klasszikus TBR borzalmasan gyenge a háromszögek számának növekedése mellett. Ellenben persze a hibrid konstrukciók között nagy különbség is lehet, hiszen szabad utat ad a mérnököknek.
Ugyanígy az ultramobil piacon is egyre kevésbé divat a klasszikus TBR, és elkezdtek menni az IMR felé, mert elkezdtek számítani a háromszögek.Az előnyök és a hátrányok egyébként megmaradnak. Minél inkább a TBR felé megy egy dizájn, az annál inkább hátrányos lehet a rendkívül sok háromszög raszterizálásánál, lásd Hitman. De eközben minél inkább IMR felé megy egy dizáj, az annál inkább eszi a sávszélt. Lásd Fiji.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Hozzátenném még, hogy vannak olyan vélemények is, hogy szoftveresen kell a problémát kezelni. Lásd az Intel, ahol igazából úgy tekintenek a problémára, hogy jobb kivágás kell, illetve jobb memóriavezérlés a szoftverben. A mobil piacon hasonló szemléletű az Imagination, ahol szintén úgy gondolják, hogy a TBDR nagyon jó és a gyengeségeit szoftverből kell kezelni.
Az alapproblémát az adja, hogy nincs univerzálisan jó konstrukció. De még csak nincs is egyetértés abban, hogy az egyes negatívumokat miképp lehet kezelni. Például a TBR felé azért indul el a legtöbb cég, mert nem tudják értékelhető formában kezelni a raszterizációt a sok nem látható háromszögnél. Ezeket pedig úgy lehet kivágni, ha felállítanak egy sorrendet és akkor már tudják, hogy melyik látszik. De ugye pont az AMD mutatott erre a Polarisban egy másik konstrukciót, ami IMR mellett még a raszterizálás előtt kivág egy rakás nem látható háromszöget. Tehát vannak problémák és számtalan, teljesen más előnyöket és hátrányokat biztosító félmegoldás ezekre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#20552
üzenetére
Nem tudom mennyire bug, hogy ez a driver 2400 MHz helyett 2050 MHz-et ad limitnek. Ezt kézzel írják be, vagyis valakinek át kellett írni, hogy más legyen a limit. Ez szándékos, maximum a következő driverben visszaállítják, ha annyira akarják a júzerek.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
#20600
Abu85
HÁZIGAZDA
Petykemano
#20599
Abu85
HÁZIGAZDA
válasz
Petykemano
#20599
üzenetére
Gondolom az MS a legolcsóbb átállást választotta, vagyis nem kérte az AMD-től, hogy tervezzék újra az egész lapkát. Valószínűleg benne van a szerződésben, hogy az AMD milyen átállásnál milyen árakat szabhat meg, és úgy kérte az MS a váltást, hogy ne növekedjen túl nagyon a lapkák ára.
Tekintve, hogy az így készült 16 nm-es lapka kb. 50 mm2-rel nagyobb, mint lehetne normális tervezés esetén, valószínű, hogy az AMD csak egy 28 nm-ről portolt dizájnkönyvtárat használt. Ezt más bérgyártóhoz nehezebb lett volna portolni.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#20619
Abu85
HÁZIGAZDA
Petykemano
#20617
Abu85
HÁZIGAZDA
válasz
Petykemano
#20617
üzenetére
A Sony nem váltott. Nagyon nehéz kiigazodni a szerződésen látatlanba, de úgy néz ki, hogy az AMD csupán lapkaverziókra köt OEM szerződést. Ez azt jelenti, hogy minden új lapka külön semi-custom megrendelésnek minősül, külön szerződéssel. Emiatt az MS és a Sony számára mindig az első verzió marad a legolcsóbb, mert annak az árát nem tárgyalhatja újra az AMD.
Másikra: [link]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem GCN4 lesz a Vega, hanem GCN5. Legalábbis a driver szerint. Mert a GCN4 az ASIC 130-as, míg a Vega ASIC 135-ös. Eddig ugye 110 volt a GCN, 120 a GCN2 és 125 a GCN3.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#20719
Abu85
HÁZIGAZDA
#Morcosmedve
#20717
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#20717
üzenetére
Az igazsághoz hozzátartozik, hogy a GCN4 ISA lényegében megegyezik a GCN3 ISA-val. Inkább a körítés változott (PDA, új ROP, új gyorsítótárak, instruction prefetch, stb.). A CodeXL-ben is GFXIP 8.1-ként van jelezve, miközben a GCN3 GFXIP 8. A Vega már GFXIP 9-es. Itt már a GCN4 alap köré építik az új ISA-t. Szóval ez most ilyen kétmenetes átállás lett. A Polaris az eddigi ISA mellett felújított mindent, míg a Vega megújítja a maradékot. Szerintem amiatt nincs nagyobb Polaris lapka sem, mert az ISA memóriamodellje a GFXIP8-ban a Fiji kialakításáig skálázható. Új memóriamodell kell, hogy mondjuk 4096 shadernél többet belerakjanak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
lezso6
#20720
üzenetére
A patch az nem segít rajta. Le kell butítani, hogy ha csökkenteni akarják a fogyasztást. Ki kell venni belőle a GDS-t, a QoS-t, egy rakás konzolon használt utasítást, stb. Ezekkel csökkenthető a fogyasztás. Csak ugye most ez nem célszerű, mert a QoS működtetni az MxGPU-t. A GDS kell az SM6.0-ban a Global Ordered Append függvénycsoporthoz, anélkül ez csak ~ezerszer lassabban működhet, mert a VRAM-ba kell dolgozni. A szintén SM6.0-s Wave Scan/Prefix szintén egy utasítás GCN-en, míg más hardveren sokkal több ciklus lefuttatni. Persze ezeket ki lehet venni, csak sokkal lassabb lesz az SM6.0 implementáció, pont akkor, amikor kelleni fog.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#20732
Abu85
HÁZIGAZDA
#Morcosmedve
#20722
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#20722
üzenetére
Ez bonyolultabb. Nézd úgy, hogy a GDS egy nagyon gyorsan elérhető memória a lapkán belül, gyorsabb bármelyik gyorsítótárnál és a Global Ordered Append csoportból a GlobalOrderedCountIncrement függvénnyel megoldható a wave-ek sorrendben történő futtatása. Ehhez azonban az kell, hogy a multiprocesszorok ne futtassanak egy wave-nél többet egy feldolgozótömbön. Az AMD azért implementálja a hardverben így, mert a sorrend egy belső memória alapján lesz kialakítva, ugyanis mindig lesz egy look-up, hogy melyik wave jön. Ha minden look-up kimegy a memóriába, akkor az akármilyen memória mellett eléggé megöli a sebességet. Emellett járulékos veszteség az is, hogy a mai SIMT architektúrák úgy fedik el a memória késleltetését, hogy több wave-et futtatnak, de most a sorrendbe rendezés miatt csak egyet futtathat minden feldolgozótömb, vagyis itt is buknak egy csomót. Erre vezette be egyébként a GCN4 az utasítás-előbetöltést, hogy a szükséges adat már akkor ott legyen valamelyik a multiprocesszor gyorsítótárában, amikor a kérés megtörténik. Emiatt nem kell a memóriáig menni, amivel visszanyernek egy csomót az elméletben elbukott késleltetésből.
A fogyasztás a mérnökök számára nem egy célparaméter. Amit nekik észben kell tartani az a hatékonyság. Ilyen formában nyilván egy GDS+utasítás-előbetöltés a leghatékonyabb, mert gyakorlatilag GlobalOrderedCountIncrement függvény mellett is a lehető legkisebb lesz a késleltetés. Például van egy programod, ami fut 200 fps-sel, de szeretnéd a wave-eket sorrendben futtatni, akkor a GlobalOrderedCountIncrement függvény ezt GCN1/2/3-on megteszi úgy 150 fps mellett, GCN4-en megteszi 190 fps-sel, míg ha a memóriához kell kimenni, akkor ugyanez 30 fps-re csökkenti a teljesítményt. Így már egészen átalakul a hatékonysági sorrend. Ilyen formában egyébként az adott effektet már érdemes a GlobalOrderedCountIncrement függvény nem hatékonyan kezelő hardvereken tiltani, de nyilván a szabványba érdemes belerakni, mert a Microsoft is tudja, hogy a többi cég is fejlődik, tehát egy-két generáció és támogatni fogják. Valószínű egyébként, hogy több shader modell 6.0-s wave ops intrinsics függvényt maga a Microsoft akar, mert megy a vita arról, hogy a mostani specifikáció mennyire jó-e az Intelnek és az NV-nek. A wave scan és prefix kb. semennyire. Az AMD-nek ezekre direkt utasítása van, míg a többieknek semmi. A WaveBallot sem valami előnyös 64 bites maszkolással. A GCN-re ez illik, míg a többire nem. De áthidalható gondokról van szó. Az igazi probléma a Global Ordered Append csoport lesz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#20770
üzenetére
Volt még a Tonga is, illetve a Carrizo variánsok, valamint az Iceland.
A támogatás és ptimalizálás az explicit API-kban nem olyan, amilyenre gondoltok. Annak ellenére, hogy a hozzáférés a hardverhez sokkal közvetlenebb, még mindig nem annyira alacsony szintű, hogy számításba kelljen venni a GPU-kat. A Mantle részben ilyen volt, de annál egy picit magasabb szintre helyezték a működést a DX12 és a Vulkan API-ban. Tehát effektíve nem annyira lényeges, hogy van GCN1/2/3/4 is, mert azokat DX12/Vulkan alatt el lehet fedni. Az egyetlen kivétel a multi-engine kezelése, amely bizonyos körülmények között finom paraméterezést igényel, de ott sem a GCN1/2/3/4 számít hanem az, hogy mire képesek az ACE-ek, HWS-ek, a GMU-k, vagyis a független parancsmotorok. Nyilván számít, hogy a hardver mennyi független parancslistát kezel, mivel a compute motorokat a driverből kell etetni, míg a grafikai parancslistáról az OS gondoskodik. A driver előtt persze még viszonylag sok lehetőség van arra, hogy egy compute parancsot hova pakol be, de a meghajtók ha tehetik új parancslistába töltik be, és ott már elég nagy különbségek lehetnek. De ugyanakkor az AMD ezért ragaszkodik a GCN2 óta a 64 parancslistához és a 8 különálló parancsmotorhoz, hogy a fejlesztők ezt célozva igen nagy hardverbázist képesek lefedni. A GCN1 ebből persze kevésbé jól profitál a 2 parancslistájával, de működni működik. Rosszabb esetben a driver dönthet úgy, hogy a compute parancsot beküldi az OS grafikai parancslistájába. A GeForce-ok például így csinálják szinte minden DX12-es játékban (kivéve a Pascalt az új Tomb Raiderben).
Aztán ezt a történetet még bonyolítják azok a lehetőségek, mint a priority flag, ami definiálva van a DX12-n belül. Egy fejlesztő egy compute parancsot jelölhet magas prioritásúnak, és akkor azt a drivernek úgy kell beraknia a független parancslistákba, hogy azonnali végrehajtás történjen. Ugyanakkor itt vannak specifikációs lékek, ugyanis a priority flag mehet közvetlenül az OS grafikai parancslistájába is, vagyis nem kötelező a driverben implementálni ezt a képességet. Az AMD-n kívül nem is implementálta más. Bizonyos programokban ezért van letiltva minden más hardverre az aszinkron compute. Nem állítja be a driver a magas prioritást, ezért berakja az azonnali eredményre kijelölt munkát a sorba, a munka eredményét igénylő számítás pedig csak áll, amíg a parancs lefuttatásra nem kerül. Valószínűleg ezt a kerülőutat a Microsoft szándékosan hagyta benne a specifikációban, hogy kifejezetten rossz "egyszálú" teljesítménnyel rendelkező hardvereknél a gyártóknak ne kelljen erre a gyengeségre kötelezően implementációt készíteni. Szóval a drivernek van jelentősége csak nem annyi, mint régen.Aminek sok jelentősége van az a memória vezérlése és a bekötés kialakítása. Na ez már nagyon trükkös. Főleg úgy, hogy a Microsoftnak és a Khronos Groupnak létezik egy ajánlott konstrukciója rá, de a gyártók nem mindenhol értenek azzal egyet. Egyedül az AMD ajánlja pontról-pontra ugyanazt, amit a Microsoft és a Khronos Group. Az Intel a bekötés és erőforrások menedzselésénél egyetért az API-kat szállító konzorciumokkal, de a memória vezérlésénél már nem. Az allokáció tekintetében a VRAM felbontását az MS és a Khronos Group is kicsi szeletekre javasolja, lehetőség szerint a legkisebbekre, ami még hatékony az adott motorral. Ugyanezt írja elő az AMD is. Az Intel pont a nagyobb szeleteket kedveli, ahogy az NVIDIA is. Az NV-nek ez a terület a Vulkan API-val olyannyira problémás, hogy külön hoztak rá egy kiterjesztést, amivel dedikált allokációk alakíthatók ki. Ráadásul a bekötés és erőforrások menedzselésénél sem azt javasolja az NV, amit a Microsoftnak és a Khronos Group, hanem a gyökeres ellentétét. A GeForce-okkal ez működik hatékonyan. Egyébként az NV ajánlott modelljeinek is megvannak a maga hátrányai, lásd az új Tomb Raider DX12-es módját. Nem véletlen, hogy a Microsoftnak és a Khronos Group nem ezeket ajánlja a fejlesztőknek, mert általánosan nem hatékonyak. Máshogy kell kezelni az eltéréseket, és ezek a gyártók közötti ajánlásbeli eltérések sokkal nagyobb problémát fognak okozni, mint a gyártón belüli apróbb különbségek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Dyingsoul
#20808
üzenetére
Az Oculus SDK-ban, illetve a gyártói SDK-kban. A HTC Vive ezeket nem képes kihasználni, mert legalább másfél évvel van szoftveresen az Oculus mögött. A SteamVR ebből a szempontból a gyártói SDK-kra támaszkodik, de a tesztelt játékban csak VRWorks aktív, míg a LiquidVR nem. Az Unreal Engine 4 a VR implementációjában a PC-t figyelembe véve amúgy is eléggé le van maradva, mivel a mobilra gyúrnak, így az async timewarp leginkább androidon működik csak. PC-n az adott runtime dönti el, hogy aktiválja-e vagy sem, de jellemzően nem teszi meg, mert a legtöbb esetben csak problémákat okoz a legtöbb hardveren. Az is fontos, hogy az UE4-nek egyedül a mobil leképzőjét írták tiled rendszerűre, tehát ott tud általánosan működni az async timewarp. A PC-s leképezőre egy-két ember van ráállítva, mert a licencelőket nem igazán érdekli a PC.
Ma teljesen játékfüggő az, hogy melyik hardver a jobb, mert egyes motorok csak a VRWorks-öt, míg mások csak a LiquidVR-t támogatják. Amelyiket támogatja az adott játék az a hardver nyer.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#20810
üzenetére
Az életképes megoldás az attól függ, hogy a szoftver mit használ belőle. A VR-ben a hardver erejét nagyrészt a szoftver szolgáltatja. Nyilván abszolút nem véletlen, hogy Hollywood 100%-ban AMD-re épít, ahogy az sem, hogy Boeing is Radeon Pro Duókat használ VR szimulációkhoz, mert sokkal hatékonyabban használható VR-re az a hardver. De a VR a tartalomfogyasztásra jelenleg rendkívül töredezett. Van két különálló runtime (SteamVR és Oculus), amelyek között ráadásul eleve hatalmas a szakadék. Aztán van két gyártói runtime (VRWorks és LiquidVR), amelyek a headsetek runtime-jainak egyes részeit képesek hatékonyabbra cserélni, illetve lehetőséget adnak a két GPU-s módra. És van egy VR API (Mantle), ami lehetőséget ad az LDL-re.
Egy játékfejlesztő számára az általános szabvány hiányában ezekre kell támogatást építeni, külön-külön. Tekintve, hogy ez nem egy kritikus piac, így a legtöbb Early Access játék nem különösebben épít a gyártói runtime-okra, és használják azt, amit az adott motor kínál. És ez jelenleg elég kevés, mert a legtöbb általánosan licencelhető motor mobilra fókuszál.Az UE4-nek van egy nagyon alapvető timewarp támogatása, illetve kihasználható a VR SLI.
A Unity-nek van már PC-re async timewarp támogatása, de csak Oculusra, és nem használható még a mutli-GPU.
A CryEngine általánosan támogat minden headset runtime funkciót, viszont gyártói szinten csak a LiquidVR van implementálva, a multi-GPU-t csak AMD-re támogatják.
A sebesség ma attól függ, hogy a játék melyik motort használja, mert az implementálásban eltérő fázisában vannak.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Valószínűleg egyik sem. A VR-rel igazából nincs probléma, ahogy a hardverekkel sem. A gond a nagyfokú töredezettség. De ez a gond igazából csak az Early Access címeknél gond, mert mire egy program végleges lesz, addigra mindenre szokott lenni támogatás. Relatíve kevés szopással jár az Rift, mert ott az Oculus a saját áruházát nagyon erősen ellenőrzi, így nem engedik meg, hogy az általuk megszabott minimum követelmények alatt felkerüljön egy program. A Steam ebből a szempontból sokkal megengedőbb, de nekik muszáj is, mert az Early Access címeknél nem várhatják el, hogy működjön. Egyszerűen ha működő Early Accesst tudna egy fejlesztő felrakni, akkor nem lenne szükség az Early Access-re.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#20817
Abu85
HÁZIGAZDA
bertapet11
#20814
Abu85
HÁZIGAZDA
válasz
bertapet11
#20814
üzenetére
Már minden nagyobb stúdió tér át Pro Duóra. Épp az idei VRLA-n volt szó róla, hogy a filmstúdiók számára a legnagyobb gond, hogy az SDK-k kötött API-khoz kapcsolódnak, és ezeknél az API-knál az input assembler lépcső módosíthatatlan. Tehát a stúdióknak egy saját API-t kellene fejleszteni a rendszerükhöz, ami viszont jelentős probléma lenne a tartalom terjesztésénél. A Radeon Pro Duo előnye itt az, hogy a LiquidVR kicseréli a szabványos input assemblert a Mantle input assemblerjére, és az így kapott tartalom kompatibilis lesz a szabványokkal is. Amíg ezt a problémát csak a Mantle tudja kezelni, addig nem nagyon tudnak másfele menni a filmstúdiók. Ugyanakkor persze kísérletezhetnek egy rakás dologgal emellett. Ellenben jó hír, hogy a Microsoft és a Khronos is dolgozik a szabványos megoldásokon, de ezek 2018 körül jönnek, és addig nem áll le a piac.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mellé tettem a véleményem.
Minden piac így indul be, kell a killer app.
Nagyon sok függ a programtól a rosszullét tekintetében. A gyártók csak a lehetőséget tudják felkínálni ezek enyhítésére, de a programba kell őket beépíteni. A PC-n a töredezettség a minőségellenőrzést nagyon bonyoluttá tesz, így rövidebb távon valószínűleg eléggé korlátozott lesz az a PC-s felhasználóbázis, akiket a VR meg tud szolítani. Közöttük is többségben lesznek a VR hátizsákot vásárlók.
Valószínűleg a legnagyobb piacot a mobil és az AIO VR szerzi meg, illetve a PlayStation VR.(#20819) miklosss2012: Vannak bizonyos géptípusaikban beágyazott AMD cuccok. Az Airbusban A380-ban is. De ezek nem a repülésért felelnek, hanem a fedélzet szórakoztatásáért.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Dyingsoul
#20826
üzenetére
Vannak motorok, amelyek lefedik az összes funkciót. Ilyen a Serious Engine, az Asura, a Nitrous. A probléma ezekkel az, hogy rohadt drágák. Szintén vannak olyan példák is, ahol a fejlesztő alaposan átgyúrta a licencelt motort. Például a CCP Games az UE4-et. A VR-re vonatkozó részét 100%-ban átírták a már megjelent Eve: Valkyrie-hez.
Az Early Access miatt gondolom az UE4 main branch-et egészítette ki a tesztjáték fejlesztője. Ezt onnan lehet tudni, hogy van VR SLI. Na most ez a VR SLI-s branch MRS és VR SLI-t használ, tehát a GeForce-ok számára lehetővé válik, hogy a képnek csak a közepét számolják teljes felbontással, a szélét pedig felezve vagy negyedelve. Ez jelentősen gyorsít a sebességen. Ugyanilyen lehetőség van a LiquidVR-ben is. Persze nem muszáj ezt használni, de a bekötött branchekből nem szedhető ki. Viszont az UE4-ből alapvetően igen, mert az Eve: Valkyrie sem használ MSR technikákat, hanem teljes felbontáson számolja az egész képet.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ehhez hozzátenném, hogy egy Early Access játékról van szó. Érdemes lenne az eltéréseket végleges játéknál megnézni. Ha ragaszkodunk az UE4-hez, akkor az Eve: Valkyrie alatt.
Nyilván a fragmentált piac nem jó, de még egyszer hangsúlyozom, hogy Early Access a tesztjáték. Nem várhatod el, hogy minden be legyen építve alpha készültségi szinten. Végleges játékokban azért olyanok nem igazán lesznek, hogy x vagy y sokkal jobb. Főleg az Oculus áruházában.A PH-n elég sokat írtunk az egészről, hogy az AMD rendszerének mi az előnye. És ezt nem én mondtam, hanem David Kanter az Oculusra hivatkozva. [link] - ettől függetlenül nyilván ez nem alpha programokra vonatkozik. Az egészet én csak megmagyaráztam. [link]
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem nyers fps. MRS! Ezzel lehet gyorsítani a feldolgozást 50%-kal, mert nem kell minden területet teljes felbontáson számolni. A VR SLI+MRS egy branch része, ráadásul kikapcsolhatatlanok az UE4 alapverziójában. Az AMD itt ott veszít, hogy a teljes képet teljes felbontáson számolja, és nem tudja az oldalát felezetten vagy negyedelve számolni. Ahhoz, hogy tudja be kell építeni a LiquidVR-nek ezt a módját.
Timewarp mindenképpen van SteamVR+UE4 alatt, mert 90 Hz-en is túl sok a fejmozgás és a bemenet között eltelt idő. Aszinkron timewarp nincs. Az Oculus runtime nem teszi kötelezővé a timewarpot.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#20841
Abu85
HÁZIGAZDA
huskydog17
#20839
Abu85
HÁZIGAZDA
válasz
huskydog17
#20839
üzenetére
Most volt a VRLA. Ott volt róla szó, hogy Hollywood teljes egészében LiquidVR-t használ a tartalomkészítésre. Nyilván Pro Duóval, mert más VR-re fejlesztett kártya nem létezik. Nekik ugye fontos, hogy speciális meghajtókat kapjanak, illetve az is lényeges, hogy az AMD létrehozott melléjük egy irodát LA-ban, amivel nem csak telefonos supportot biztosítanak azonnal, hanem személyeset is. Bármi gond van, egy órán belül ott van egy technikai csapat.
R&D-re egyébként használnak mást is, az egy olyan terület, ahol a kutatásokat nagyrészt egy gyártó segíti, és egy darabig az adott gyártóhoz lesz kötve az egész.A VRLA-nak volt egy üzleti része, ahol számos orvosi cég jelent meg, illetve a Boeing, akik beszéltek arról, hogy nekik az erő hiányzott a VR szimulációhoz, de már nem hiányzik.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#20850
Abu85
HÁZIGAZDA
huskydog17
#20843
Abu85
HÁZIGAZDA
válasz
huskydog17
#20843
üzenetére
A VRLA-n volt az egyik beszélgetésen. Abban, ahol arról beszéltek, hogy mennyire jól tette az AMD, hogy rakott egy központot Hollywood mellé, mert minden stúdiónak az volt a baja, hogy a legközelebbi technikai támogatás egy napnyi útra volt legalább. Emiatt minden egyes gond után egy napnyi kényszerszünet következett. Tekintve azt, hogy a VR új terület, kb. heti két gond merül fel, ami minden projekt előzetes elkészültének idejét 40-50%-kal növeli meg, hacsak nincs a segítség egy órányira. Az nem számít, hogy piszok sok cég van, az számít, hogy a gondokra egy órán belül van személyes technikai segítség. Ez számít a stúdióknak is.
Nyilván ugyanezt meg tudja tenni az NV is, és kihozhatnak egy VR-re szánt professzionális VGA-t is. De még egyiket sem tették meg, tehát a stúdióknak ma nincs választása.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
Locutus
#20852
üzenetére
Az NV-t is érdekli ez a terület, csak nem tudnak mindent lefedni. Az a problémájuk, hogy amíg az AMD le tudja cserélni a szabványos API-k input assembler lépcsőjét, addig ők nem képesek rá, mert nincs egy saját API-juk, amivel azt helyettesíteni tudnák. Emiatt nem koncentrálnak a szükségesnél jobban ide, mert bizonyos eljárásokat nem tudnak megvalósítani a nem VR-re tervezett szabványos API-k kötöttségei miatt.
(#20853) hpeter10: A GRID-nek semmi köze a VR-hez.
Az AMD bevétele pár száz Radeon Pro Duo eladásától nem ugrik meg. Ez csak egy másik piac előkészítésére jó. Amikor a VR mozik kialakulnak, akkor tudnak nagyobb hardvereladást generáli.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#20856
Abu85
HÁZIGAZDA
#Morcosmedve
#20855
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#20855
üzenetére
Nem tudnak. A VR nagyrészt egy szoftveres probléma. Két dolog hátráltatja ma a tartalomkreálást. Egyrészt a technikai támogatás távolsága, de ez logisztikai kérdés, csak oda kell települni a cégek mellé. A másik egy sokkal nagyobb gond, ami a VR-re tervezett API hiánya. Se a Vulkan, se a D3D12 nem ilyen API. Az input assembler lépcsője még mindig olyan kötöttséget igényel, hogy a kamerapozíció a jelenetszámításból lesz átemelve, és az nem változhat. A VR ezzel szemben azt igényli, hogy ez változzon meg. Itt jön képbe az, hogy az AMD-nek van egy saját Mantle API-ja, amivel API interoperabilitással megváltoztatják a kamerapozíciót, és onnantól kezdve már nincs baj a szabvány API-kkal sem. Ezt rajtuk kívül senki más nem tudja megtenni. Az előnye ennek, hogy nagymértékben növelni tudják a produktivitást, mivel jelentősen csökkentik a tartalomkreálásra használt szoftverek amúgy igen magas késleltetését.
Szintén fontos tényező még, hogy a LiquidVR SDK nyílt forráskódú. Tehát ha van valami egyedi igény, akkor megcsinálják egy hónap alatt és nem kell hónapokig tárgyalni az igény beépítéséről, amiből talán egy év múlva lesz valami.
A cégek csak a produktivitást választják, mert jóval hamarabb kész lesz a projekt. Hónapokat lehet nyerni vele, ami a kiadásoknál igen jelentős tétel.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#20860
Abu85
HÁZIGAZDA
#Morcosmedve
#20857
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#20857
üzenetére
Egyelőre nem sokat. Nincs VR-re tervezett professzionális hardver, zárt az VR SDK, és nincs VR-re tervezett API az aktuális szabványok hiányainak foltozására. Nyilván ez lehet az oka annak a logisztikai kérdésnek is, hogy nincs egy fő "támaszpont" sem a filmgyártás központja mellett.
Van viszont egy Titan X, de ez nem olyan gyors VR-re, mint a Radeon Pro Duo, és nincs professzionális támogatás hozzá. Persze sosem mondta az NV, hogy ennek a VR a célpiaca, mindig is a gépi tanulást hangsúlyozták ki.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
velizare
#20861
üzenetére
Táblázat itt: [link]
(#20862) vitko: Ezek a gyártói csomagok nem feltétlenül szükségesek a működéshez. Extrákat biztosítanak. Mindegyik olyan játék, amely elkészült és megjelent, de extrákat igényelt, támogatja az AMD és az NVIDIA runtime-ját is. Például EVE: Valkyrie, Chronos, The Climb. Persze más-más dolgokat használnak a gyártói csomagokból. Például az NV-éből az MRS-t, hogy a képkocka szélét ne kelljen teljes felbontáson számolni. Az AMD-s párját ennek nem használják, viszont használnak LDL-t.
A professzionális hardver a tartalomkészítőket érdekli. Az egy másik ága volt a vitának. Tartalomfogyasztóknak ez nem kell.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
imi123
#20864
üzenetére
Inkább az volt a baj, hogy alig volt akkor optimalizálva. Nyilván promóanyag kell, tehát felvették az aktuális állapotot. Túl sok jelentősége nincs.
Sokkal jobb lesz, mint az új Tomb Raider port, aminél azért nem nehéz jobbat csinálni. De jobb lesz a Hitman portjánál is. Eleve az a csapat csinálja, akik a Hitman portját segítették. Egyébként a Tomb Raider csapata most PS4-re portol, egy darabig ők nem csinálnak mást.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#20955
Abu85
HÁZIGAZDA
bertapet11
#20954
Abu85
HÁZIGAZDA
válasz
bertapet11
#20954
üzenetére
Az API-nak nem sok köze van rendszermemóriára vonatkozó követelményekhez. Az erre vonatkozó igény leginkább az aktuális konzolok miatt növekszik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#20973
üzenetére
A Steam is ugyanazon a szinten marad, mint a Windows Store-os, azzal a különbséggel, hogy nem UWP, hanem Win32 API-t használ, illetve kap egy DX11 backportot. A DX12 kód azonban ugyanaz, és az már nem változik. Elég sokat javítottak rajta, legalábbis azokat a dolgokat, amelyek a fejlesztőkön múlik. Ami pedig nem rajtuk múlik, azon nem tudnak javítani.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#20980
üzenetére
Már a DX12 port sem bughalmaz, mert ki van javítva a kezdetek óta. Minden benne maradt probléma nem az alkalmazás oldalán keletkezik.
Azért nem láttad a DX12 előnyét, mert az két oldalról jelent extrát. Egyrészt jelentősen csökkenti a processzor terhelését, de ez 4,7 GHz-re tuningolt i7-tel CPU-val mindegy, főleg egy olyan játékban, mint a QB. Ellenben mondjuk nekem nem, mert én megérzem a játékokban az A10-7850K-t. Viszont DX12-vel jelentősen javul mindenhol a teljesítmény. A másik az aszinkron compute, ami neked 980 Ti-vel megint mindegy, mert az NVIDIA egyetlen játékban sem engedélyezi ezt a képességeit a te kártyádra. A Pascal-ban is csak az új Tomb Raiderre. Ellenben mondjuk nekem sokat ér, mert 10-20%-os boost jön tőle R9 285-tel. Ezek mellett én még azért érzek általános előnyt, mert a legtöbb játékot a Microsoft ajánlásai szerint fejlesztenek, és ezekkel az ajánlásokkal az AMD ajánlásai megegyeznek, míg mondjuk az NV ajánlásai eltérnek, sokszor jelentősen. Utóbbit a fejlesztők nem igazán fedik le. A Doom és a Hitman tartalmaz NV-specifikus alternatív kódot is. A Microsoft játékai például abszolút nem, mert a Microsoft arra szeretné sarkallni a hardvergyártókat, hogy ha valami nem működik nekik a DX12-ben, akkor ne alternatív erőforrás-használatra buzdítsanak, hanem javítsák meg a hardvert az új generációban.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#20986
üzenetére
Már most olyan a DX12, amilyennek lennie kell. Hozza azokat a lehetőségeket, amiket a Microsoft ígért. Az i7 is jelenthet előnyt például az olyan játékokban, mint az AotS vagy a TW: Warhammer. Ezeknél van elég rajzolási parancs, hogy érződjön a skálázódás a több szálra. Egy QB alatt egyszerűen nincs, hiába skálázódik, akkor sem fog jelentős hatékonyságbeli előnyt hozni, mert relatíve kevés a rajzolási parancs. Pár százalékot jelent persze, de drámai különbség ma leginkább stratégiai játékokban van. Ezek azok a játékok, amelyek DX11 alatt már nagyon küszködtek. Ez borzalmasan látszik a Civilization BE alatt. Nem DX12, hanem Mantle, de ugyanaz a lényeg. DX11-gyel nem létezik olyan számítógép még ma sem, ahol a játék vége felé, amikor már felfedezted a térképet értelmes, értsd nem kávészünet jellegű lépésidőt lehet generálni, illetve ha kérsz egy teljes térkép zoom outot, akkor konkrétan 10-15 fps az eredmény. Mindegy milyen gépet raksz alá! Ugyanez Mantle-ben jelentősen jobb lépésidővel jön, majdnek négyszer-ötször jobbal, illetve a zoom out is simán megy 40-60 fps-sel. Szinte nem is esik a teljesítmény. Ugyanezt tudná a DX12 és a Vulkan, illetve majd tudni is fogja a Civ 6 alatt. Egy akciójátékban ilyet már azért nem fogsz tapasztalni, mert itt már léteznek az API-k, így eleve nem fognak DX11-et használni, ha használhatatlanságig csökkenne a teljesítmény. Ezek érthetően alakulnak így, mivel jellemző az iparra, hogy egy stratégiai játék jelenetkomplexitása mindig a legnagyobb, mivel kevés trükközésre van lehetőség. Ha nincs elég kraft, akkor nem csinálhatsz kisebb szobákat, szűkebb utcákat, stb. Nagyon kevés lehetőséged van arra, hogy bármilyen tervezésbeli trükkel sebességet nyerj. Ezért a legtöbb stratégiai játék az elmúlt évtizedből leginkább a kamerát limitálta, illetve rengeteg stúdió konkrétan tiplizett innen, mert annyira nehézzé vált az ilyen játékok fejlesztése, hogy inkább egyszerűbb stílusok után mentek. Ebből látszik, hogy a DX12 és a Vulkan nagyon jól működik, és nagyon jó hír, hogy a stúdiók jönnek vissza stratégiát csinálni.
A DX12 és a Vulkan átmenete egyébként sokkal inkább hardveres probléma, mint szoftveres. Mindkét API-nak igen kötött a működése, tehát van egy hatékony erőforrás és parancs kezelés, amihez jó lenne tartana magát mindenkinek. De vannak hardvergyártók, amelyek számára ez nem kifizetődő, mert még nem tudtak jó hardvert tervezni az igényekhez. Jelenleg a fenti, világos előnyöket leszámítva, azért érzitek töredezettnek az élményt, mert a fejlesztők számára nehéz ideális döntéseket hozni a hardvergyártók számára, ugyanis eléggé eltérnek a hardverek. Erről itt írtam egy bővebb hsz-t. [link] - tényleg csak ennyi a gond. És nem a parancslisták kezelése, mert az kiváltható azzal, hogy ha a driver nem tud dönteni, vagy nem akar, akkor elküldi az OS-nek a parancsot és az OS lekezeli automatikusan. A gondot a memória vezérlése és a bekötés kialakítása jelenti, mert baromira nem lehet úgy programozni, hogy Microsoft és a Khronos ajánl valamit, az AMD pontról-pontra ugyanazt ajánlja, aztán az NVIDIA ennek a gyökeres ellentétét, míg az Intel bekötésben követi a szabványalkotókat, de memóriakezelésben az ellentétét ajánlja. Ez így baromira szar a fejlesztőknek, mert ideálisan kell három kódút, hogy minden gyártót lefedjenek. Ráadásul azt is bele kell kalkulálni, hogy például az NVIDIA bekötésre és erőforrások menedzselésére tett ajánlata számos korlátot idéz elő magában az API-ban, mert nem lehet akármilyen formátumot betölteni az RS-be DX12-ben. Eleven nem arra találták ki az RS-t, hogy direkten tároljon SRV/UAV/CBV-ket.
Jelenleg a leginkább alkalmazott modell az, hogy a fejlesztők a Microsoft és a Khronos ajánlásait követik a bekötésre és az erőforrásokra, de megpróbálnak az ideálisnál nagyobb allokációs szeletekkel dolgozni a memóriára. Emiatt van az is, hogy a DX12-ben nő a memóriaigény a DX11-hez képest, de ha nem így dolgoznának, akkor az nem lenne jó az NV-n és az Intelen. A különbség jól látszik, mert például az új Tomb Raider PC-n 512 MB-os allokációs szeletekkel dolgozik, míg konzolon 64 MB-ossal. Egyébként az 512 MB elég sok. Inkább 128 MB vagy 256 MB az átfogó PC-re, az ideális pedig 64 MB. Szóval ma a hardverek oldalán az egész rendszer pokolian töredezett, és ez nehézzé teszi a fejlesztéseket. De a DX12 és a Vulkan még így is megéri, bár nem egy program inkább úgy készül, hogy kiválasztanak egy célarchitektúrát és arra írják meg a kódot. Ha nem azzal az architektúrával rendelkezel, amit kiválasztottak, akkor hátrányban leszel.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#21004
Abu85
HÁZIGAZDA
Petykemano
#20999
Abu85
HÁZIGAZDA
válasz
Petykemano
#20999
üzenetére
A hardverek nem oldanak meg mindent. Amire szükség lenne a GAB és az ARB számára az egy hardver oldali egységesítése előírása. Ez sokat segítene a fejlesztőknek abban, hogy milyen kódot írjanak az alkalmazásba. Erről egyébként szó van a háttérben. Ugyanakkor egy ilyen egységesítés lassú folyamat, mert egyes cégeknek az architektúra teljes leváltásával járna. Rövidebb távon ez gond, hosszabb távon persze megoldja magát a probléma, mert igazodni fog mindenki az API-k működéséhez. Ez már látszik is, mert a GCN mellett az új Bifrost Mali is nagyon jól illik a Vulkan ajánlásaihoz. De a Rogue is ilyen az Imaginationtől.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az látszik egyébként, hogy nagyon sok múlik a fejlesztőkön a DX12-ben. A legjobb minőséget az Ashes of the Singularity jelenti, de ott nulláról írták motort, illetve a bevonták a fejlesztésben az összes gyártót. Jó minőség még a Hitman, a Total War Warhammer, illetve a Quantum Break. A Forza és a Gears of War közepes, de utóbbi régi alapot használt, így sok volt a korlát, míg a Forza csapata PC-n szűz volt. A legrosszabb minőséget a Rise of the Tomb Raider képviseli. Sok helyen a DX11 kód is gyorsabb, a memoriaigénye indokolatlan. Nem véletlenül nem ajánlja az MS, hogy nagy legyen az allokációs szelet, illetve azt, hogy UAV és SRV legyen direkten a root signature-ben. Tipikus idióta hozzáállás azt feltételezni, hogy az API fejlesztője rosszul tudja, hogyan működik igazan hatékonyan a rendszer.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#21009
üzenetére
Jól működik a leképező. Átgondolt a szinkronizálás, szép az allokációs stratégia, kevés az idle buborék, átgondolt a multiengine implementáció. A legújabb patch mellett pedig már támogatva van a két új swapchain API is, így már nem gond a v-sync és a variálható frissítés.
Persze. Megnéztem a játékot, de csak a legújabb verziót. Azt elemeztem, mert gondolkozunk azon, hogy benne lesz a tesztekben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#21012
üzenetére
Pedig igazából elég jól néz ki. Ennél jobb volumetrikus fényekkel nem igazán lehetett még találkozni. Eléggé szép a shimmering hatás elmosása is.
Nyilván a volumetrikus fények eléggé megterhelők, és ezekre nem véletlen dolgoztak ki olyan módszert a játékban, hogy a shadow mapokkal párhuzamosan lehessen őket számolni, mert nagyon sokáig tart a számolásuk. Sajnos az igaz, hogy ha befutsz egy olyan területre, ahol sok a volumetrikus fény, és nincs hozzá aszinkron compute-od, akkor nagyon durván lemegy az fps. [link] - erre itt fel is hívták a figyelmet. Az NV drivere nem engedi, hogy a számítás párhuzamosan történjen a shadow mapokkal. Szépen beküldik a parancsokat az OS parancslistájába. Ez nem a játék hibája, hiszen láthatod, hogy a 970-nel hasonló teljesítményű 390 70-80%-kal gyorsabb. A DX11 sem fog ezen javítani, mert ott eleve nincs párhuzamos feladatfeldolgozás.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Inkább az a kulcstényező, hogy vannak a leképezésnek nagyon tipikus problémái, amelyeknek ma már vannak megoldásai. A kérdés az, hogy a megoldásokat érdemes-e használni, vagy érdemes megtartani a problémákat mondván, hogy a játékosok már megszokták a shimmeringet. A Quantum Break úgy döntött, hogy a leképezőnél kezelik a shimmering jelenséget, így egy Full HD-s képkocka négy HD-s 4xMSAA-s képkocka temporális projekciója. Ennek az előnye a nuku shimmering, de hátránya, hogy mozis, elmosott hatást kelt, ami a máshoz szokott játékosoknak nem jön majd be. Ugyanakkor az nem technológiai gond, ez volt a dizájn szempontjából a célkitűzés. Sajnos jelenleg nincs olyan technológia, amely minden leképzésre vonatkozó vizuális problémát kezel, így vagy az egyik, vagy a másik halmazát fogja kezelni egy elgondolás.
A CPU-limit kitolása minden program oldalán a legfontosabb szempont. Főleg azért, mert ma már nem egymagos processzorok vannak, hanem négy vagy több. Muszáj olyan API-t kínálni, amivel ezek a magok kihasználhatók. És ehhez kellenek az új API-k, mert a régi API-kkal a parancsátadás egy szálra volt korlátozva, ami akkor is erősen limitáló volt, ha a parancskreálás esetleg több szálon történt meg. Mivel a jövőben semmi esély arra, hogy hirtelen jönnek a 15-20 GHz-es egymagos procik, így a többszálú parancskreálás biztosítása egy kulcstényező ahhoz, hogy az eddigieknél több rajzolási parancsot adhassanak ki a fejlesztők. Az, hogy csökkent a többletterhelés is, egy olyan fejlesztés, amit érdemes volt bevállalni, mert úgysem lehetett megőrizni a kompatibilitást a korábbi API-kkal. Ilyen formában érdemes nagyot fejleszteni, hogy legyen muníció évek múlva is.
Az aszinkorn compute jövője nem kérdéses. Mindegyik DX12 és Vulkan alkalmazás használja PC-n. Emellett ahogy nő a GPU-k bonyolultsága, annál több idle buborék keletkezne abból, hogy soros a pipeline-ok feldolgozása. Egy GPU mindig is heterogén rendszer volt, és az egységek számának növelésével a munkájuk összehangolásának hatékonysága csökken. Mondjuk egy GCN a 10 wavefront/CU SIMD-del el tud menni ~6000 shaderig, de ez az a határ, ami után már érdemes növelni a wavefrontok számát, és az nem lehetséges a jelenlegi memóriamodellel. Az NV már a Kepler óta warp limiten van, mert 64/MP-nél többet nem kezel a Fermi dizájn. ~4000 shaderig sem tudnak elmenni, mert hiába rakják bele a több shadert, az architektúra nem skálázódik tovább, ugyanis nem tudnak 128 warpot futtatni a jelenlegi memóriamodellel. Persze az Intelnél látjuk, hogy van olyan megoldás, mint mondjuk a gyorsítótárak hizlalása, de ez csak a probléma kezelése lenne mindkét oldalon, mintsem valós megoldás, mert eszi a tranzisztorokat. Ahogy megyünk számban az egyre nagyobb skálázódás felé, annál inkább kell az aszinkron compute, hogy a hardver egyáltalán skálázódjon. Nem viccből építették bele tehát az API-kba. Az persze igaz, hogy a gyártók az alaparchitektúrát tekintve más fejlődési fázisnál tartanak. Az AMD itt csak azért jó, mert az alapjuk 2012-es, míg az NV-é 2009-es, az Intelé pedig 2010-es. Ennek megfelelően az alapokat rendre 2008, 2005 és 2006 körül dolgozták ki. Az AMD-nek szerencséje volt, hogy belecsúsztak a 2007-es évbe, amikor rengeteg kutatás volt arról, hogy mi a jövő. Az NV és az Intel is láthatta ezt, de ekkor már késő volt, mert nem tudtak változtatni a fejlesztéseken. A Fermi módosítás például 2012-re tolta volna a megjelenést, ami ezen a piacon vállalhatatlan volt. Szóval amint lesz egy nagy váltás az NV-nél és az Intelnél, azonnal meglesz oldva a multiengine konstrukció hatékony támogatása.A Doom nyilván érdekes, de nem szabad elfelejteni, hogy amit mi szegmentálódásnak hívunk (AMD shader intrinsics és NVIDIA shader intrinsics), az a fejlesztők szemében egységesítés (GPUOpen a közös PC és a konzol kutatásokért). Ebben vitathatatlan szerepe van az explicit API-knak is, mert ahhoz, hogy a PC-re és a konzolokra közös legyen a fejlesztés minden szempontból közös lehetőségek kellenek, legyen az API, shader függvények, dokumentáció, stb.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem a befürdésről van szó, hanem a lehetőségekről. Ma nem lehet úgy megoldani a problémákat, hogy minden maradjon jó minőségű. TXAA, vagy más temporális projekció mindegy, mert a cél minden esetben a filmes hatás. A filmeken is nagyon durván alkalmaznak elmosást.
Nyilván lebutítható a játék a rajzolási parancsok tekintetében, de mondjuk úgy lenne jó a CPU-limit kitolása, hogy a konzolon és a PC-n is elérhető legyen ugyanannyi objektum a kijelzőn, lehetőség szerint hasonló LOD, és hasonló árnyékminőség mellett. Mivel a konzolok jóval többet tudnak rajzolni, mint a PC-k, így az egyetlen lehetséges irány a PC-s API-k cseréje volt. Nem hiszem, hogy bárkinek a fején átkúszott az a gondolat, hogy tartsuk meg az aktuális API-kat, és akkor PC-re meg korlátozzák a látótávolságot. Meg lehet csinálni, csak nem célszerű.
+10-20% azért elég jó. Az persze igaz, hogy jelen formában leginkább GCN-only.
A legtöbb mai játékban az async compute úgy van kialakítva, hogy a shadow mapok számítása mellé legyen betolva valami compute feladat. Ezt semmilyen más formában nem lehet megcsinálni. Akármilyen hardveren malmozni fognak a shaderek, mert a shadow mapok számítása ROP limitált. A GPU-k heterogén jellege miatt számos grafikai futószalag olyan, hogy nem igazán bántja a shadereket, amelyeken ezekben az időszakokban lehet futtatni bármilyen compute futószalagot.
A fejlesztők problémája nem kifejezetten az, hogy az async compute nehéz, hanem az, hogy általánosan jól megírni nehéz úgy, hogy működjön minden hardveren. Ezért írják ma meg nagyrészt csak GCN-re, mert túlságosan eltér a többi hardver a konzoltól, hogy az arra kialakított futószalagokat jól át lehessen hozni PC-re.
Vannak más játékokról is fejlesztői adatok, hogy az async GCN-ekkel mennyit hoz:
Hitman 5-10%
Warhammer 5-15%
Doom (8xTSSAA) 10-20%
Quantum Break 10-15%Más játékokra nincs pontos adat, de tudni lehet, hogy a Forza 6, a GoW és az új Tomb Raider alatt is számít pár százalékot, illetve a Thief és a Sniper Elite 3 alatt is. Mindegyik utóbb említett játékban túl kicsi az átlapolt munka, de az előnyt jelent így is.
Az AotS-en az async compute-nak nincs akkora értéke ma. 5-10%-os pluszt jelent, de az aktuális motorverzióban még nincs aktiválva a texel árnyalás és a raszterizálás átlapolása. Csupán némi post-process fut az új képkockával párhuzamosan. Ennek a fejlesztésnek az az elsődleges problémája, hogy a működéshez szét kell választani a texel árnyalást a raszterizálástól. Ez DX11 alatt nem lehetséges, tehát abban a frissítésben, ahol ezt bevezetik legacy státuszba kell helyezni a DX11-es kódot, mert onnantól kezdve túl sok munka lenne az eltérő API-k karbantartása.Ez leginkább ma már külön fordítót jelent. A legtöbb stúdió, jelen esetben az ID nem ír ennyi shadert. Van egy saját nyelvük, amit több shader nyelvre fordítanak. Ezen belül is nyelvük kezel egy rakás olyan függvényt, amit a PC-s shader nyelvek nem. Ergo nekik kell írni egy alternatív fordítót a PC-hez, hogy ezeket a különbségeket kezeljék. Bármennyire is furcsa, ez nekik sokkal inkább teher, mint olyan shader kiegészítésekre fordítani a kódot, amelyek kezelik a shader intrinsics függvényeket.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#21031
Abu85
HÁZIGAZDA
huskydog17
#21028
Abu85
HÁZIGAZDA
válasz
huskydog17
#21028
üzenetére
Az API-nak semmi köze ahhoz, hogy a Quantum Break mennyire jó játék a kritikusok vagy a felhasználók szemében. Nem a technológiával játszanak, hanem a játékkal.
A DX11-től ne várjatok csodát, mert ez alapvetően egy DX12-es motor, ami viszonylag sokat nyer a DX12-től. A DX11 csak elindíthatóvá teszi a játékot Windows 7-en is, de más előnye nem lesz. Sőt, inkább elvesz a sebességtől, mert nem tudja majd párhuzamosan számolni a volumetrikus fényeket, amelyek a képszámítás nagy részét teszik ki. Nem tud majd másolni sem a temporális projekcióhoz anélkül, hogy a másolás idejére ne állítaná le a GPU-n a munkát. Ez ugye azért van, mert a DX11-ben csak szinkron copy van definiálva.Az alapján amit láttam a játékból technikailag igen rendben van. Megnéztem GPUView-vel. A függetlenségünket egy játék nem befolyásolja. A különbség a vélemények között az, hogy én megnéztem a programot a profilózokkal, illetve utánanéztem az alkalmazott leképezőnek, míg más esetleg nem.
Ezt a 10 éves lemaradást egy olyan programra írod, amely a piacon egyedüliként használ texel árnyalási módszert. Ez az az árnyalási fajta, amire a Pixar animációs filmek épültek. Érdemes elolvasni a texel árnyalás előnyeit. Idei Eurographics paper: [link] - egyre több motorban találkozunk majd vele. Nyilván a Nitrous annyiban előnyben volt, hogy eleve a nulláról építkeztek, tehát volt lehetőség a legjobb árnyalást választani. A többieknek azért nehezebb lesz a váltás, mert számottevő problémát jelent majd a assettekkel való kompatibilitás megőrzése. Emiatt például a szokásos deferred és forward irányok mellett jönnek majd az extrém leképezők, amelyek már bevetik például a deferred texturázást is (az Eidos Dawn motorja erre megy el). Hosszabb távon viszont az objektumtérbe érdemes vinni az árnyalást. Itt elő lehet venni a Quantum Break-et megint, mert a saját leképezőjükkel pont azokra a problémákra akartak reagálni, amelyekre a Nitrous reagált, vagyis a textúrák stabilitását akarták jelentősen javítani. Ha tehették volna, akkor ők is mentek volna az objektumtérbe, de túl nagy változást igényelt volna a motorban. Ez az ami sokaknak nem tetszik, mert annak ára van, hogy a textúrák stabilitását utókezeléssel éred el. A Nitrous előnye ezekből adódik össze. Szinte minden egyes leképezéssel kapcsolatos jelentős problémára olyan megoldásokat kínál, amelyek nem hoznak magukkal jelentős mellékhatásokat. Ezért ez a motor az, amit ma leginkább követnek a stúdiók kutatásai.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem. Öt DX12-es játékot akarunk a következő körbe, és mellé öt DX11-est. A DX12-esek közé menne a Quantum Break. Mivel ma négy DX12-es játékot tesztelünk, így ez extra lesz. A DX11-esekből nem tudom, hogy melyik marad és melyik megy. Azt nem én intézem. Az biztos, hogy a Doom az egyik DX11-es játék helyére kerül. Az is lehet, hogy a Civ6 és a Deus Ex kerül be a DX12-esek közé. Mivel nem akarunk három stratégiát ezért az AotS vagy a Warhammer megy.
Ez lesz nagyjából az ősz. Míg télen átállunk teljesen DX12 és Vulkan játékokra.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#21036
üzenetére
Nem tudom, hogy melyik DX11-es játék megy vagy marad. Azt nem én döntöm el. Nekem mindegy, hogy melyik megy.
(#21037) gbors: Igen az a terv, hogy záros határidőn belül áttérjünk az új irányra. Mi voltunk az elsők a médiában, ahol csak DX11-es játékokkal teszteltek, és szeretnénk mi lenni az elsők, ahol csak explicit API-val tesztelnek. Minden szempontból ez az ideális, mert így jóval hamarabb tudunk az olvasóknak jövőbiztos teszteket készíteni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Quantum Breakben nyilván nem kapcsolható ki. Annak a motornak a jellegzetessége, hogy nem támogat normális textúraszűrést, tehát mindenképpen kezelni kell a textúrák stabilitását. Ha kikapcsolhatóvá tennék, akkor az nagyon zizegős képet eredményezne.
A legtöbb fejlesztő nem teszi kikapcsolhatóvá az async compute-ot. A játékok között egyedül az AotS-ben kapcsolható ki. Más formában a meghajtóba kell egy olyan profil, ami a compute parancsolat az OS-nek küldi tovább. De csak azért, hogy lehessen mérni a különbséget nem csinálnak olyan meghajtókat, ami mindkét működési módot tartalmazza.
Igazából a legtöbb játékban ez nem GCN-onlyra van megírva. Egyszerűen az NV meghajtói nem a GMU-k parancslistájába, hanem az OS-ébe töltik be a parancsot. Kivéve a Pascal és a Rise of the Tomb Raider. Volt régen olyan kód, ami direkt gyártóspecifikus volt, de ma már ezt kiszedték mindegyik programból. Jobb ezt a meghajtókkal kezelni, mert ha a program oldalán kezelik, akkor például örökre kizárják az NV-t a gyorsulás lehetőségéből. Érthetően ezt nem akarják.És ez itt a probléma az egésszel. Van a konzolról egy fordító, ami fordít HLSL XO nyelvre, és azt a fordítót percek alatt kompatibilissé lehet tenni az AMD shader kiterjesztéseire. Majd onnan mehet a SPIR-V fordítás. Ezért egységesítés ez a fejlesztők szemében. A szabványos SPIR-V-re sokkal nehezebb dolgozni a konzolhoz írt fordítóknál.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#21080
Abu85
HÁZIGAZDA
Petykemano
#21077
Abu85
HÁZIGAZDA
válasz
Petykemano
#21077
üzenetére
Nem így van.
Az a lényeg, hogy mindig van egy hangos kisebbség, akiknek valami sosem tetszik, de valójában azt, aminek hangot adnak, sosem tudják bizonyítani. Hiába kéred, hogy emeljék ki a problémás részeket az írásokból. Ennyi. Ha valaki nem csak károg, és hoz valamiféle értelmes dolgot, akkor azt nyilván mindenki meghallgatja, még én is. (#21079) miklosss2012: Már le is tesztelték a srácok. Szerintem hétfőn megjelenik, de én szabin vagyok szóval erről nem dönthetek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Az AMD azért vállal többet a 3rd party programoknál, mert gyári modulról van szó, tehát képesek úgymond garantálni azt, hogy a kártya automatikus ventilátor szabályozása működőképes marad. Ezt például egy 3rd party program nem garantálja. De az is igaz, hogy egy módosítás működését már egyik EULA sem garantálja. Ugyanakkor az AMD modulja úgy van beállítva, hogy vannak határok, amelyek biztosítják a reális működési lehetőségeket. Például a memóriaórajel esetében annak olyan hibák, amikor a magasabb órajeltől csak pár 30-40 cella esetében lesz probléma, amit az EDC mondjuk nem képes korrigálni. Ilyenkor a tuning stabil lesz, de 2-3 órával a játék indítása után megjelenhetnek képi hibák. Na most az AMD erre alkalmaz úgynevezett paraméterezési limiteket.
Ú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 14 PRO - Arany - Gyönyörű
- iPhone 14 PRO MAX - 2026.10ig Garancia - Független
- Microsoft Surface Book 2in1 Érintős Szétszedhető Laptop Tablet 13,5" -60% i5-7300U 8/256 QHD+ Win 10
- Lenovo Thinkpad T490, 14" FHD IPS, I5-8365U, 16GB DDR4, 256GB SSD, WIN 10/11, Számla, garancia
- Féláron! Új Dell XPS 13 9315 Prémium Érintős Profi Ultrabook 13,4" -50% i7-1250U 16/512 UHD+ Iris Xe
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs