Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5979
üzenetére
A gépigényre gyúrni az EA-nek megint egyszerűbb. A Dragon Age: Inquisition a Frostbite aktuális verziójának utolsó nagyobb címe. Ez azt jelenti, hogy a 3-as főverzió már eléggé optimalizált, hiszen az első játék óta másfél évet lehetett polírozni. A Red Engine új, szinte polírozás nélküli rendszer.
Majd az EA is át fog állni a következő nagyobb Frostbite frissítésre. Talán nem 4 lesz a neve, de az NFS és a SW: Battlefront már ezzel jön. -
Abu85
HÁZIGAZDA
válasz
#85552128
#5964
üzenetére
És most hasonlítsd össze az EA és a CDPR készpénzállományát és fejlesztői lehetőségeit.
De amúgy ja egyetértek, a Dragon Age: Inquisition-t grafikailag nem sikerült lenyomni, csak ez pénzkérdés inkább, mintsem technikai.Egyébként nem vagyok benne biztos, hogy az elkövetkező két évben bárkinek is esélye lehet a PC-n az EA által követett újszerű fejlesztési modell mellett. Egyszerűen a váltásokra marha sok pénzt mozgósítottak, és marha jó a szakemberi gárda a Frostbite mögött. Leghamarabb a Square Enix tudja őket befogni, de ők is lassabban kapcsoltak, és alapvetően több erőforrást kell majd mozgósítaniuk.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5926
üzenetére
Azóta csúnyán eltelt 7 év. 7 éve jó volt, ma semennyire nem az. Valószínűleg 7 év múlva a DX12-re is azt mondjuk, hogy limitál, és jön a következő lépcső. Biztosan megmondom most, hogy a DX12 sem tart örökké. De az elkövetkező fél évtizedre jó lesz. Addig pedig van idő újat fejleszteni.
-
Abu85
HÁZIGAZDA
Nem is kell, hogy összekapcsolva legyenek, bár szinkronizáció azért van. De elég, ha egy rosszul kialakított API és a kernel driver nem engedi a programszálakat hozzáférni az amúgy szabad erőforrásokhoz.
Ez tudom, hogy nagyon mellbevágó dolog, hogy a PC ennyire pazarló platform lett, de ez van. Viszont nem véletlenül alakult úgy, hogy két év alatt egy komplett reformot végigvittek az érintettek a teljes rendszeren.Amikor arról beszélünk, hogy a DX12 micsoda előrelépés a DX11-hez képest, akkor az jön elő, hogy milyen jó ez a DX12. Valójában ezt úgy kellene felfogni, hogy milyen rossz a DX11. A DX12 csak rendbe hozza, amit már rég rendbe kellett volna hozni.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Szándékosan belinkeltem azt a részt, ahol erről beszél.
Ez egyszerű. Attól, hogy nincs kernel driver még a feladatokat el kell végezni. Az alkalmazásnak explicit elérése van a GPU felé, de ez csak azt jelenti, hogy meghatározhatják, hogy mit csináljon a hardver, de a parancskiadáshoz már szükséges egy driver, ami például lefordítja a szoftver queue-t a hardver nyelvére, stb. Ez a user driverben fog látszódni, még akkor is, ha az alkalmazásban van rá a kód.
-
Abu85
HÁZIGAZDA
Miért lenne irreleváns? Az iparág két legjobb fejlesztője magyarázza, hogy mi a gond a DX11-gyel. Ők a GAB tagjai, pontosan tudják, hogy mi a helyzet. Azért ne őket hibáztasd, hogy azt mondják amit én, valószínűleg azért teszik, mert 15-25 éves tapasztalatuk birtokában képesek megállapítani, hogy mi a probléma a DX11-es modellekkel.
Mert a driver soros feldolgozásra kényszeríti a rendszert. Ez a nagy problémája a rendszernek. Hiába van ott még 7-9-11 szabad mag a soros feldolgozás miatt nem érhetők el.
Tökéletesen ábrázolták, te értelmezed rosszul. A kernel driver eltűnik, ahogy az MS is lerajzolta. Nem veszi át a feladatát a user mode driver. A program lesz, ami átveszi a munkát. A videóban erről is beszélnek.
-
Abu85
HÁZIGAZDA
[link] - ez segít megérteni, hogy miért nem hozzáférhető az a temérdek processzoridő.
Sajnos ezt nagyon rosszul érted. A user mode driver valójában csak allokációval foglalkozik. Eldönti, hogy a programnak 4 vagy 64 kB-os lapokat foglaljon le például, illetve végzi a valós idejű shader fordítást. Az ami régen a kernel driver feladata volt, mint a hazárdok kezelése vagy például a memóriamenedzsment teljesen átkerül a programba. A fejlesztő fogja ezt vezérelni. Ezért hívjuk ezeket explicit vagy low-level API-knak, mert a munkát a programozó határozza meg és nem egy driver. A fentebb linkelt videó erre is kitér.
-
Abu85
HÁZIGAZDA
Miben? Mert a hozzáférhető processzoridőben sajnos az. Hiába vannak erős hardvereid, ha nem nyúlhatsz büntetlenül hozzájuk.
Az nem úgy működik. Valójában az a processzoridő hozzáférhetetlen, mert a meghajtó soros munkára kényszeríti a programot. Hiába van ott elméletben, ha nem férhetsz hozzá.
A user mode driver egy shader fordító, illetve egy alapvető vezérlőcsomag. Nem látja el a kernel driver feladatát. A fejlesztőnek kell megírnia azt a programon belül. Nyilván ez is hozzájárul ahhoz, hogy nő a processzor kihasználásának hatékonysága, mert eltűnik minden olyan rendszer, amit nem profilozhatsz. Ma ha valami nem működik, nem tudnak a fejlesztők beleírni a driverbe. Ez okoz sok gondot. A jövőben ez nem lesz gond, mert lényegében nem lesz driver, a saját kódod pedig tudod javítani.
-
Abu85
HÁZIGAZDA
A multiplatform játékokat eleve úgy tervezik, hogy minden célplatformot figyelembe vesznek, és az egyes szempontok szerint a leggyengébb platformelemekre lőnek. A DX11-ben a PC-n van a legkevesebb befogható processzoridő, így a szimulációt ehhez igazítják.
Nem az NV a probléma, hanem a DirectX 11 és az agresszív kernel driver. Ezért kezeli a Microsoft ezt a problémát úgy a DirectX 12-ben, hogy eltünteti a rendszerből a kernel drivert.
Az NV-nek nyilván az a lényeg, hogy a grafika legyen jó, az nem számít, hogy a játékmenetben az előző generációs konzolcímek is lealázzák a PC-t. Abban viszont igaza van a Microsoftnak, hogy a grafika skálázható, míg az AI nem, tehát ha egy játékot nem tervezel úgy, hogy a PC-t is számításba veszed, akkor az probléma lesz a portolásnál. -
Abu85
HÁZIGAZDA
Nem szerintem, hanem a Microsoft szerint.
Szerintem az egész rendszer úgy ahogy van rossz, ha a gyártók nem képesek betartani a szabályait. Gondolom ezért veszi el a kernel drivert a Microsoft a DirectX 12-ben, hogy a gyökerénél tűnjön el az alapprobléma. Ezzel az a gond is eltűnik, hogy a kevés valós processzoridő miatt nem lehet komoly AI-val konzolra tervezett játékokat PC-re portolni.Az is fontos, hogy az első dolog, ami fejlődni fog a DX12-vel az az AI. Megvannak az algoritmusok. Nem állt le a fejlesztés, csak nincs meg a számítási kapacitást hozzá PC-n, de nem a hardver, hanem a grafikus driverek miatt.
Kevin Floyer-Lea low-level leírásában is ott van ez: "Ability to increase the CPU budget for other systems like AI". -
Abu85
HÁZIGAZDA
Minden multiplatform játékot multiplatformnak terveznek. Veszik minden esetben a legszűkebb keresztmetszetet és arra terveznek. Ha a PC ebben benne van, akkor tudják, hogy a szimuláció korlátozott, mert kevesebb valóban felhasználható processzoridő áll rendelkezésre. Tehát ez már be van tervezve.
A Halo 3 a Microsoft címe, ahogy a Halo és a Halo 2 sem jött Sony gépekre, úgy a Halo 3 sem volt tervben. De Windows-ra ki akarták adni, mert az első két rész is jött PC-re, de nem volt meg az erőforrás hozzá PC-n. Az AI-t kellett volna butítani, de nem tették meg. Aztán mivel a processzoridő évről-évre csak csökkent, így lelőtték a projektet.
A Capcomtól tudom, hogy hasonlóan járt a Dragon's Dogma is. Talán egy remasterre van esély.
-
Abu85
HÁZIGAZDA
válasz
stratova
#5886
üzenetére
A full deferredet semmiképpen, mert a PBS-re az a legjobb. Igaz, szétzabálja a sávszélt, de megvan a maga előnye.
Low-level API-nak annyi az előnye, hogy eltűnik a driver. Tehát a program a teljes processzoridőt megkapja és szabadon felhasználhatja.
A problémát maga a driver okozza. Ezért nincs kernel driver DX12 alatt. Minden új API így oldja meg ezt a gondot. Ez az MS megoldása. A DX11 meg így marad. Nem tudnak vele mit kezdeni.A példákkal az a baj, hogy az MS is itt hasalt el. Lefuttatták a teszteket és szuper volt. De egy játék nem csak rajzolás, hanem szimulációs munka is, és ott már negatívba megy a sebesség. Ezért kért meg mindenkit az MS egy éve, hogy ne használják. Inkább skálázzák le a grafikát.
-
Abu85
HÁZIGAZDA
A Microsoft már magára vállalta a felelősséget. Amikor bemutatták a DirectX 12-t, akkor elmondták, hogy DX11-ben használt modell egy totális tévút, és mindenkit lebeszélnek azóta róla. A probléma egyébként jelentős. Minden évben azt tapasztalták a fejlesztők, hogy jönnek az új processzorok, és eközben csökken az elérhető processzoridő. Ez nem jó irány sehogy sem.
Ha olvastad, amit írok, akkor az Intel drivere ebből a szempontból a legjobb. Az AMD a két végpont között lavírozik.
-
#5880
Abu85
HÁZIGAZDA
Malibutomi
#5875
Abu85
HÁZIGAZDA
válasz
Malibutomi
#5875
üzenetére
Ez egy ballansz probléma. Mennyi processzoridőt igényel a játék és mennyit vesz el a driver. A mai multiplatform címek szándékosan rendkívül butítottak a játékmenet szempontjából, hogy maga a szimuláció kevés processzoridőt igényeljen, és az NV driverének is legyen elég szabad erőforrás. Az AMD és az Intel drivere ezzel biztosan jó lesz, mert kevesebb szálat futtatnak.
(#5877) Szaby59: Ez a lényeg. Azért kapcsolod ki, mert nagyon zabálja a géped, pedig valójában ugyanehhez a minőséghez nem kellene ennyi veszteség. És akkor már átgondolnád, hogy mást kapcsolj ki például.
A Frostbite 3 egy deferred MSAA technikát használ. Minden render targetet leszűr, vagyis más játékokhoz mérten az MSAA munkája 4-5x-ös.
-
Abu85
HÁZIGAZDA
A Halo 3 azért nem jött PC-re, mert nem volt elég processzoridő a driver szálak mellett. Ekkor volt az, hogy az MS összehívta a cégeket, hogy ez így nem lesz jó, mert hiába jönnek a jobb processzorok a reálisan felhasználható processzoridő az egyre agresszívabb driverek mellett inkább csökken. Ezért nem látsz AI innovációt évek óta. Egyre kevesebb rá a büdzsé.
Szinte mindegyik exkluzív ls komolyabb konzolos játék AI-ja és fizikája túlmutat a PC-s szinten. Az AI szempontjából különösen durva a The Last of Us és a Dragon's Dogma. A fizika szempontjából az Uncharted 3. -
#5874
Abu85
HÁZIGAZDA
Malibutomi
#5872
Abu85
HÁZIGAZDA
válasz
Malibutomi
#5872
üzenetére
A D3D driver egy komplex probléma. Amit sokan nem vesznek figyelembe, hogy itt nem csak a megjelent játékokat nézik a cégek, hanem a megjelenés előtt állókat is. Alapvetően az Intel D3D drivere a legjobb. Messze az látszik a legrosszabbnak a tesztekben, de reálisan felhasználható processzoridő jut a programnak. Az NV drivere a másik véglet. Iszonyatosan zabálja az erőforrást, míg az AMD drivere a kettő közötti átmenet.
Hogy ez miért fontos? Bizonyos konzolra írt játékokban az AI és a fizika komplexitása a PC-s játékokon túlmutat. Viszont a D3D driverek miatt ezeket nem lehet PC-re portolni, mert túl sok erőforrást elvesznek a driverek. Ezért kér a Microsoft thin drivert, mert a grafikát képes skálázni a fejlesztő, de az AI-t és a játékmenetre ható fizikát nem. -
Abu85
HÁZIGAZDA
válasz
#85552128
#5869
üzenetére
És lám kiderült, hogy ezért tudják megcsinálni, mert ugyan felfogod, hogy konkrétan veled csesznek ki, de egyszerűen elfogadod, hogy ez így jó, és hogy ez egy szép jövő lesz. A teljesítményigényes és gyenge minőségű effektek jövője. Eközben keresel minden lehetőséget, hogy kontráz, aminek konkrétan semmi köze ahhoz, hogy a HairWorks jóval több teljesítményvesztést okoz annál, mint amennyit igazából kellene, hogy okozzon.
Nem értem mi az, amitől egy felhasználó annyira jól jár, hogy védeni kell a mesterségesen magasra pakolt gépigényt? Többet költhetsz gépre? Ezt megteheted úgy is, hogy az adott program és effekt úgy fut ahogy kell. -
Abu85
HÁZIGAZDA
válasz
stratova
#5866
üzenetére
A saját felhasználóid megszopatása a következő szint ebben a nem túl fényes jövőben. Ez alapvetően sikeresnek mondható, hiszen nem egy ember védi azt az álláspontot, hogy a saját PC-jén legyen egy effektnek -20-30%-os deficitje az amúgy reális -5-10%-os helyett, csak azért, mert biztosan jót akart ezzel az adott gyártó.
-
Abu85
HÁZIGAZDA
Nem értitek a gondot. A gyártók olyan szerződéseket kötnek, amellyel az adott partnernek gyakorlatilag nincs reális kiszállója. Még ha a szerződésnél át is beszélik: jó persze erre nem fog sor kerülni, mert aranyosak vagyunk, akkor is szerződés világosan fogalmaz. Gondoljatok bele. Az AMD fogja magát és ismét hirtelen felindulásból letiltatja a TressFX-et, vagy akármelyik effektet a Star Citizenben. Nem fog a CIG ellenkezni, mert túl drága lenne. Inkább megteszik, amit kérnek.
Ez az egész ipar problémája. Még ha az iparért is akarnak dolgozni a szerződésekben kibiztosítják magukat és ha elpattan a húr, akkor itt tök szabványos effektek lesznek Radeon és GeForce only megoldások szinte minden játékban. Melyikőtök akar ilyen jövőt?
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5852
üzenetére
Pedig a fejlesztő most a legkevésbé okolható azért, hogy az NV milyen paraméterezéssel kéri szállítani a GameWorks csomagokat. Ezt ők határozzák meg.
Szerinted az AMD miért tehette meg, hogy letiltatja a TressFX-et a Lichdom januári frissítésében? Egyszerűen szerződésben megvan hozzá a joguk. Ott sem a fejlesztő a hibás, de ha nem teszi meg, akkor olyan kötbérrel tud kiszállni a szerződésből, hogy azonnal tönkremennek. -
Abu85
HÁZIGAZDA
válasz
#85552128
#5846
üzenetére
Az a baj, hogy a haj annyira vékony geometria, hogy az nem így működik. Elképzelhető, hogy még 16 mintavételi pontnál is úgy átmegy egy haj a pixelen, hogy egyetlen mintavételi pont sem "döfi át". És onnantól kezdve rögtön rossz az adott pixel színe. Ezért nem adnak rá külön opciót, mert tudják, hogy a 8x is kevés.
Az anizo esetében vannak problémák. Nem minden felülettel kompatibilis, így előbb ezeket kell megoldani, hogy használható legyen.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5843
üzenetére
Az MSAA részletességét a HairWorksre vonatkozóan csökkenteni kérdéses. Így sem elég a 8xMSAA opció. 16x lenne az ideális.
A HairWorks esetében semmilyen minőségvesztést nem eredményezne a tesszellálás 64x-ről 16x-re csökkentése és két-háromszorosára gyorsítaná az effekt sebességét. Ez sem lenne optimalizálás, de gyakorlatilag minőségvesztés nélkül kapnál extra sebességet, ami kezdetnek jó. A következő lépcső egy analitikai élsimítás lenne, ami kiváltaná a HairWorksre futtatott MSAA-t, mert ez valószínűleg olcsóbban jobb minőséget eredményezne pusztán a célirányos jellege miatt.
Ezután esetleg el lehetne gondolkodni az önárnyék és az átlátszóság problémáján, amivel a HairWorks újra -20-30%-os teljesítménybe kerülne, de a minősége a mostani szinthez képest nagyban megugrana. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#5834
üzenetére
Én a GTX 760-en a 25-30%-os kihasználást nem mondanám magasnak. Ezt szerintem fel lehet tornázni a GCN-es hardverek 35-40%-os szintjére, vagy a közelébe. Az, hogy egy program mit ír semmit sem jelent. A belső kihasználás számít, amit mondjuk GPUView-vel tudsz ellenőrizni, vagy GPUPerfStudióval. Ettől a 99%-ot oda fogja írni rá az olyan kamuprogram, mint az afterburner és bármi hasonló.
-
Abu85
HÁZIGAZDA
A WDDM 2.0 alatt megmarad a régi WDDM szegmentált fizikai címzése. Ez egy legacy funkció lesz, de maga a low-level API meg fogja engedni, hogy a fejlesztő megírja az implementációt a programban a szegmentált fizikai címzés működéséhez. A kezdetekben valszeg ilyen motorok fognak születni, mert túl kevés lesz a Windows 10 felhasználó WDDM 2.0 only játékokhoz. Ilyen esetben a fejlesztőknek lényegében ugyanolyan lehetőségei vannak a VRAM vezérlésére, mint ma a kernek drivernek, persze a közvetlenebb elérés miatt a WDDM ellenőrzésre vonatkozó funkcióit el lehet felejteni, tehát a sebesség jobb lesz.
-
Abu85
HÁZIGAZDA
A low-level API-nál azt is figyelembe kell venni, hogy mit csinál a program. WDDM 2.0 alatt nem szükséges tudnia, hogy mennyi VRAM van a kártyán, mert ott a virtuális memóriára vonatkozó GPUMMU mód. Ha a program mindenképpen fizikai címzésre akarja kényszeríteni magát, akkor kell tudnia a hardver VRAM kapacitását. Ez lehetséges, főleg akkor, ha nem akarják, hogy az alkalmazás csak Windows 10-en fusson. De többen mondták már, hogy 2016 végére inkább bevállalják a Windows 10 only dolgot, mert a WDDM 2.0 túl sok előnyt kínál a GPUMMU-val és az IOMMU-val.
(#5814) Szaby59: A low-level API igazából mindegy. A WDDM 2.0 kínál olyan előnyöket, amelyekkel a VRAM használata a mainál lényegesen hatékonyabb lehet, és igazából lesz is. Mindegy, hogy DX12, Vulkan vagy Mantle, mindegyik rendszerből kihasználható a WDDM 2.0 extrája. A GPUMMU rendkívül hasznos, mert igazából a VRAM működése sokkal jobban fog hasonlítani a rendszermemória működéséhez. Az IOMMU pedig még egy lépés előre, mert igazából az adatnak nem is kell a VRAM-ban lennie, egyszerűen olvashatja és írhatja azt a hardver a rendszermemóriában is. A különböző linkelési lehetőségek is nagyon jók. Például egy GPU-val minden különösebb probléma nélkül olvashatod egy másik GPU memóriáját, sőt írhatsz is abba. Ezek a mai limitált modellhez képest nagyságrendi előrelépések. Elsődlegesen ott fog ez érződni, hogy jóval több szabad VRAM-od marad, amit persze elhasználhatsz másra. Tehát önmagában a mai pazarló rendszer ki lesz ütve.
(#5826) gbors: Hagyományos fizikai címzéssel a fejlesztő is képes beleírni az alkalmazásába, hogy a GTX 970 esetében 3,5 GB gyors memória van és 0,5 GB lassú. Tehát ez egyedi szinten lekezelhető. GPUMMU mellett nem lehet kezelni, mert ott az OS jelzi a rendszernek a VRAM méretét. A user-mode driver csak arról dönt, hogy az allokációhoz 4 kB-os vagy 64 kB-os lapméret legyen használva.
-
Abu85
HÁZIGAZDA
Az XDMA-nak nincs köze az AFR profilhoz. Az XDMA kizárólag azt teszi lehetővé, hogy 4K-ban is egyenletes legyen az AFR frame pacing, és ne legyen tele mikroakadással, mint a hidas megoldásokkal:
Semmi más jelentősége nincs szoftveres és profilozási szempontból. Low-level API-val lehet más előnye is az XDMA-nak, de AFR-ben csak ennyi.
-
Abu85
HÁZIGAZDA
PCLabs teszteket sosem néztem. Korábban is mondtam, hogy az a tesztmetodikájuk, hogy a gyorsaság érdekében több konfiguráción nyomják párhuzamosan nem feltétlenül jó. Még ha tök ugyanaz is két konfigban a VGA-n kívül minden, akkor is lehetnek eltérések a szoftverben. De ettől te hihetsz nekik, de a PCGamesHardware jellemzően jobb konstrukcióban tesztel, és jóval közelebb állnak más oldalakhoz az általuk közölt eredmények, mint a PCLabs-osoké.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5667
üzenetére
Sajnos semmivel sem jobb egyik AFR technológia sem. Ahol az egyik működőképes ott a másik is, de ahol az egyik nem az ott a másik sem. Erre jön a változás a low-level API-ban, hogy a fejlesztő írja meg, hogy miképp működjön, és ne lehessen a driverekből kényszeríteni egy alig működő megoldást. Ez majd nagy változást fog hozni, mivel újra megéri multi-GPU-ra gyúrni, hiszen a gyártók kontrollja teljesen megszűnik a rendszer felett és átkerül a program irányítása alá a teljes vezérlés.
-
Abu85
HÁZIGAZDA
Az a baj a GameGPU-val, hogy egy olyan driverrel teszteltek, amelyben nincs Witcher 3 profil. A 15.4.1-ben van, ami elérhető volt már május első felében. A 15.4-es áprilisi, és ezt használták. Ezért nem hozza ez a teszt azt, amit más tesztekben látsz a 15.4.1-es driverrel, amibe már raktak profilt pont a játékra készülve.
-
Abu85
HÁZIGAZDA
Kész. Rárepültek a Titan-GTX 960 harcára a W3-ban.
Egyébként azt mondják, hogy a 352-es driver sorozatban egyszerűsítették a shader fordítót. Ez például lehet az oka annak, hogy nem meg annyira jól a Kepler. Érdemes lenne egy régebbi driverrel kipróbálni, ahol még a régi fordító volt.
-
Abu85
HÁZIGAZDA
A Fermi volt az utolsó generáció, ahol a túlterhelés valós problémát jelenthet. Nem feltétlenül kell hardveres védelem és hardveres rendszer. Lehet szoftveresen asszisztált hardveres konstrukció. Ez is stabil marad, csak picit nagyobbat esik az órajel a kelleténél.
A Fermi is stabil marad már, mert a driverbe van egy szoftveres rendszer építve. Ha túlterhelést érzékel, akkor levágja az órajelet elég alacsonyra. Fagyni egyik sem fog. Arra már be vannak építve a rendszerek. A kérdés, hogy mennyire lesz jó a folyamatos órajelállítás. -
Abu85
HÁZIGAZDA
Nem, ezek gyakorlati mérések egy alpha állapotú szoftveren.
Igen a ventit azt pörgeti csúnyán. Ezt írtam az előbb.
A mai hardverek állítható a TDP limit. Az Catalyst erre kínál egy negatív/pozitív csúszkát. Nem tudom, hogy az NV ad-e, de ha nem, akkor tuningprogramokban láttam ilyet. Az persze kérdés, hogy ez negatívba letolható-e.
(#5606) Asbee: Igazából az AotS sem fog a tuningra úgy reagálni, hogy tuti fagy. Ezt kipróbálták. Ha stabil a tuning, akkor annyi történik, hogy a hardver picit jobban veszi vissza az órajeleket. Tehát a stabilitás megmarad, csak lassulást okoz az órajelállítás. Nem stabil tuning meg fagyás, ez egyértelmű. Mondjuk ez a DX12-ben jó lesz, mert nincs TDR a hardverre, és akár viheti a fájlrendszert is magával a gép a resetnél. A bátrak játéka lesz a tuning.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Abu85
HÁZIGAZDA
Egészen konkrét mérések is vannak erről, bár csak az R9 290X-ről. Ott a tesztjelenet async shaderrel 45-50 fps között van. Async shader nélkül ez 30-35 fps-re esik. Tehát azzal, hogy a hardvert 85-88% közelébe terheled még úgy is nyersz egy csomó sebességet, hogy a magórajel 150-200 MHz-cel az alapórajel alá esik. Ez a jó a GPU-kban, masszív adatpárhuzamosításra valók.
-
Abu85
HÁZIGAZDA
Azért a boost és az alapórajel különbözik. A hardver szintjén is meg van különböztetve. Ha növeled az alapórajelet növekszik a Boost is.
Hohó de még mennyire. A Fiji-t 94%-ra is leterheli.
A többi hardvert ennyire nem, mert elfogy a sávszél, de a többség 70% fölött van. 80% körül.Hát milyen dizájnra jó?
Ezek a hardverek már képesek az órajelüket visszavenni, ha túlterhelést érzékelnek. -
Abu85
HÁZIGAZDA
Én terelem a témát? Nem én mondtam ki, hogy 1300 MHz-en megy mindegyik 970 out of box. Ki vállalja érte a felelősséget, ha nem? Ilyeneket ne állítsunk, mert nem igaz. Találhatsz olyan alkalmazást, amin jó az a tuning, de biztos találni fogsz olyat is, amin nem. A gyári órajel mindig arra szolgál, hogy oda mindig visszatérhess, ha túlterheli az alkalmazás a rendszeredet, és arra van garancia. Az, hogy te otthon saját felelősségre meghúzod nem jelent semmit. Nincs meg a sok százezer dolláros eszközparkod, hogy kiteszteld úgy, ahogy az NV teszi meg magának, amikor dönt az alapórajelekről.
(#5597) TTomax: Az AotS egy játék lesz. Azzal hívja fel magára a figyelmet, hogy a VGA-k ventijét 70-80% fölé állítja annyira terhel.
50-60% nem jó, csak ennyit lehet ma reálisan kihozni max. A jó a 100%. -
#5598
Abu85
HÁZIGAZDA
Malibutomi
#5595
Abu85
HÁZIGAZDA
válasz
Malibutomi
#5595
üzenetére
Minden stratégiának megvannak a hátrányai. Az NV-nek gyorsan ki kell termelnie az adott architektúrából a pénzt, hogy a gyors váltásokat fenntartsa. Ezért is van az elzárkózás. A fejlesztőknek mindig megmondják az aktuális tutit, ami a korábbi architektúrát és architektúrákat nem érinti olyan pozitívan.
Pedig annyira nyilván nem rossz az első Titan, hogy a GTX 960-nal és az R9 285-tel versenyezzen, de mit tehetnek a fejlesztők, ha nem kapnak dokumentációt a hardverekről. -
Abu85
HÁZIGAZDA
Gondolom ezt a tutimegy 1300-ot out of box dolgot a mai tesztprogramokból és játékokból szűrte le a világ, amelyek mennyire is terhelik a GPU-t? 40-50%-ra?
No offense, de azért ez nem ilyen egyszerű. Az NV nem véletlenül vállal garanciát arra az alapórajelre, amit beállítottak. Ők tudnak olyan alkalmazást írni, ami 100%-ra kimaxolja a terhelést.
A gyári OC meg oké. Ott a VGA gyártója vállalja rá a garanciát, ha mégsem megy. Viszont az, hogy alapmodell out of box tuti megy 1300-on eléggé durva kijelentés. Megnézném azt egy AotS-en, ami leterheli 80% fölé. -
#5591
Abu85
HÁZIGAZDA
Malibutomi
#5585
Abu85
HÁZIGAZDA
válasz
Malibutomi
#5585
üzenetére
Jó, de az NV ráállt az architektúra átlagnál gyorsabb cserélgetésére, míg az AMD előbb letervezett egy jövőbiztosat és azt faragják. Ez két külön stratégia. Nyilván az NV-nél ez költségesebb, hiszen folyamatosan tervezik a rendszereket, amelyekkel hozzák be azokat, amiket az AMD bepakolt a GCN-be. A Maxwell már eléggé megközelítette. Ennek a hátránya, hogy rövidtávon is lesz két olyan architektúra a piacon, amelyet normálisan kellene támogatni, miközben igazából csak az számít, hogy a legújabban jól menjen. A Kepler ennek az áldozata. Majd jövőre jön a Pascal és a Maxwell lesz az áldozat. Ez így megy, ha gyorsan váltod az alapokat.
-
Abu85
HÁZIGAZDA
válasz
Yllgrim
#5582
üzenetére
10% inkább. Valamit elnéztél, vagy fps-t akartál írni. Igaz a Radeon csak 30 MHz-cel volt húzva a gyárihoz képest, míg a GeForce szénné tuningolt verzió a gyárinál ~200 MHz-cel magasabb alapórajellel. A gyári termékek között nyilván kisebb lehet a különbség.
(#5583) TTomax: A 970 is egy gyárinál jó extra 250 MHz-cel megtuningolt verzió.
(#5586) Szaby59: Az AA ilyen MSAA post-process keverék.
-
Abu85
HÁZIGAZDA
[link] - Itt a W3 teszt. Semi-final, Full HD, GameWorks off. GCN és Maxwell jó. A Kepler lemaradt mint a borravaló. Az R9 285 és a GTX 960 ott van az első Titan nyakán. Majdnem verik, de nem, viszont a GTX 780-at elkapta mindkettő.
A Fermi és a régiek ultra grafikára nem jók. -
Abu85
HÁZIGAZDA
Hogy minek? Hát ők írták volna meg az erőforrás-igényes effektek 80%-át a játékba. Azt kell kérdezni, aki megírja, mert ők ismerik a forráskódot és azt, hogy mennyit tudnak rajta gyorsítani x időtartamon belül.
Gondolom nem úgy lett 2013-ban bemutatva az a videó, hogy ezeknek az effekteknek a többségét nem tudjuk megcsinálni, de kell a hype, így rámondták, hogy meglesz. 2013-ban még mindenki kőkeményen hitt benne, hogy ez működni fog. -
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5568
üzenetére
A gamescon demóban nem volt minden aktív.
2013-ban biztosan nem tudták még. 2014-ben valószínűleg tudták, hogy a tervekből nem valósul meg minden.
Azért ez nem olyan dolog, hogy odamész az AMD-hez, vagy az Intelhez, hogy pacsizzunk le. Az AMD hova tudná őket berakni? Ők viszik a teljes EA, a Square Enix nyugati stúdióinak, és a SEGA nagy részének a fejlesztését, amihez még hozzájött a teljes Capcom is. Azért ezek az erőforrások végesek. Az NV-nél most jóval több a szabad kapacitás, mert csak két komolyabb kiadóval dolgoznak. Szóval a mit akarsz és a mit lehet között nagy a különbség.Dying Light sem volt valami korrekt. Persze az első nekifutás a Chrome 6-tól. Egyébként a W3 attól függetlenül, hogy nem tartalmaz majd egy rakás tervezett effektet elég korrekt lesz.
-
Abu85
HÁZIGAZDA
Nyilván 2013-ban látták, hogy miképp fut. Volt mondjuk 10 fps. Megkérdezték az NV-t, hogy 2014-re lesz-e ebből 30. Mondjuk azt mondták igen. Ilyen esetben a fejlesztő csak abban hibás, hogy elhitték, amit mondanak. Ez is valahol egy hiba a fejlesztőknél, csak itt az a gond, hogy nagyrészt meg volt kötve a kezük, tehát még ha akarták sem tudták volna megoldani a problémákat.
Konkrétan ezért menekül az EA az összes zárt környezet elől. Nem rajtuk műlik a problémamegoldás, ami több területen hazavághat egy nagy projektet. A Havokot is csak akkor hajlandók továbbvinni, ha kapnak egy olyan licencet, amivel szabadon átírhatják a forráskódot, ha nem, akkor el fognak menni a Bulletre. Költséges? Az, de a saját kezükben lesz a sorsuk. -
Abu85
HÁZIGAZDA
válasz
#85552128
#5564
üzenetére
In-engine render. Lejátszottak egy előre felvett dolgot. Akkor mindegy, hogy egy másodperc volt egy frame. A hardver offline kiszámolta azt.
Átvihető a Gameworks. Nagyon sok csomagnak van és a jövőben még lesz is konzolra portolható verziója. A GameWorks esetében nem ezzel van a legnagyobb baj, hanem a beépíthetőséggel. Ha nem jó, akkor csak a motort hackelheted addig amíg jó nem lesz, vagy egy idő után feladod.
Hihetitek ezt is, de a helyzet az, hogy lassan érdemes lenne feltenni a kérdést, hogy az utóbbi évben miért volt gond főleg az NV által támogatott PC-s portokkal. Biztos, hogy csak az NV választ mindig bénán partnert? Vagy esetleg a fejlesztők által nyíltan kritizált konstrukciójuk is közrejátszik.
-
Abu85
HÁZIGAZDA
válasz
decibel
#5523
üzenetére
Oké, akkor nézzük, hogy mi butult le két év alatt.
Eltűnt a házakról és a különböző egyéb felületekről a tesszelláció: hiányzik a GeometryWorks
Alaposan megváltozott a tenger hullámzása: hiányzik a WaveWorks.
A részecskeeffektek közül a tűz megváltozott: hiányzik a PhysX Particles
A növényzet minősége és a látótávolság csökkent: beleütköztek a DirectX 11 korlátjaiba.
A víz visszatükröződése a tervezett teljes világhoz képest egy hamis megoldás lett: hiányzik a PostWorks SSR.Persze gondolom így is a fejlesztők a bűnösök. Egyáltalán nincs köze az eredménynek annak, hogy zárt middleware-ekkel vagy magával a korlátozott API-val sokszor lehetetlen helyzetbe hozzák őket.
-
Abu85
HÁZIGAZDA
Azért jobban néz ki, bőven. Meg vannak ennek a váltásnak egyéb technikai részei is. Szóval az előrelépés tényleg megvan. Ha a kategóriához nézzük, akkor valóban a Dragon Age: Inquisition szebb. De itt megint meg kell jegyezni, hogy az EA és a CDPR kasszája között durva különbség van. És alapvetően egy játék technikai oldalát még mindig nagyban befolyásolja a belerakott pénz és erőforrás. Egy CDPR nem képes versenyezni egy EA/Bioware/Frostbite Team felállással. Nem elég tőkeerősek és nagyok hozzá. Viszont a két érintett közötti különbséget figyelembe véve a W3 elég jó lett így is. Legalábbis azért ez a grafika megfelelő a 2015-ös szintre. Persze láttunk szebbet, de egy W3 játékost ez nem fog érdekelni.
-
Abu85
HÁZIGAZDA
válasz
decibel
#5500
üzenetére
Nem értem miért őket kell azért hibáztatni, mert zárt middleware-eket nehéz egy játékba beépíteni. A CDPR igazából nagyon jól megcsinálta a játékot. Amit reálisan ki lehetett hozni, azt kihozták belőle. Az, hogy nem sikerült működésre bírni a GeometryWorksöt, a WaveWorksöt, GPU-s PhysX Particlest, meg pár dolgot, hát van ilyen. Ettől a játék még ugyanolyan jó lesz, csak nem néz ki olyan jól, mint a 2013-as videókban. A kamuzás meg kérdőjeles. Szerintem 2013-ban bőven úgy gondolták, hogy ezek az effektek beépíthetők. Nem hiszem, hogy akkor bárki kételkedett ebben. Valószínűleg 2014-ben került elő először, hogy azért ez a része a dolgoknak nem áll úgy, ahogy tervezték. Maximum azt lehet mondani, hogy 2013-ban túlságosan optimisták voltak és hittek abban, hogy a middleware-ek beépítésével nem lesz semmi gond.
Az vesse rájuk az első követ, aki a GeometryWorksöt és a WaveWorksöt valaha is sikeresen beépítette egy játékba. Na ugye... Ők legalább megpróbálták. Ez dicsérendő inkább. Majd kielemzik, hogy miért nem jött össze.
-
#5497
Abu85
HÁZIGAZDA
huskydog17
#5490
Abu85
HÁZIGAZDA
válasz
huskydog17
#5490
üzenetére
Az NVIDIA a GameWorksöt nem véletlenül vezette be. Nagyon sok fejlesztőnek korlátozott az anyagi tőkéje, és a GameWorks esetében kínálnak kész effektet, amelyeket csak be kell építeni és még egy rakás pénzt is adnak hozzá. Nyilván a GameWorks hátránya, hogy ha nem sikerül integrálni, akkor nem sikerül. Nem tud az adott fejlesztő semmit sem tenni, hogy működésre bírja a rendszert, mert korlátozott az idő a megjelenésig.
Azt nem hiszem, hogy a CDPR megbánta a döntését. Elvették az NV-től a pénzt és befejezték a játékot. Aztán persze a tervekhez képest nem úgy néz ki, kivettek belőle egy csomó GameWorks effektet, illetve a végén már a GPU-s PhysX rendszert is eltávolították, de a játék kész, és ennyi ami számít.A fejlesztők alapvetően nagyon jó munkát végeztek a játékkal. Addig a pontig, amíg azokat az effekteket kapcsolod be, amiket ők terveztek és teljes egészében kontrolláltak nagyon jó a port. A többire pedig nincs ráhatásuk, ezek zárt middleware-ek, így csodát nem lehet velük tenni. Valószínűleg kapni fognak egy ideig a médiától, hogy mekkora butítást lőttek, de most nehéz a médiának megmagyarázni, hogy itt azért ezt a programot működő formában kell kiadni a játékosoknak, márpedig alapvetően megnehezíti a munkát, ha egy integrálásra váró effekt vagy eljárás forráskódját nem módosíthatják, vagy esetleg nem is láthatják. Ez mindig ott fog lebegni azoknál a stúdióknál, akik nyílt megoldások helyett zártra szavaznak, mert inkább pénzre van szükségük, mint szaktudásra.
A Rockstar egészen más kategória. Őket nem fenyegeti az a veszély, hogy a fejlesztés végére elfogy a pénz. Ettől sokkal szabadabb döntéseket lehet hozni. Az olyan stúdiókat szintén nem, mint a EA összes, a Square Enix nyugati csoportja, a Rebellion, a Firaxis, a Stardock stúdiók, ésatöbbi. Ők anyagilag jóval stabilabbak, így számukra logikus döntés a nyíltságot és a szaktudást választani a zártság és a pénz helyett. Ezért is tudják jellemzően jól megoldani azt, hogy a játék a terveknek megfelelően készüljön el.
(#5496) Szaby59: Elég sok olyan konzolos játék van, ahol a látótávolság nagyobb, mint PC-n. Van ellenpélda is, ahol a konzolt a fejlesztők wrapperen használják. A konzolon máshol vannak a limitek. A látótávolságot jellemzően a draw call limit korlátozza és ez PC-n a legnagyobb, amennyiben a konzolon tényleg használod a low-level elérést. Ha nem, akkor a konzol sem fog egymilliószor gyorsabban beírni egy parancsot a parancspufferbe.
Pont két olyan játékot nézel, amelyek nem low-level elérésűek konzolon. Nézz mondjuk egy Dragon Age: Inquisitiont. Az minden platformon kínál low-level elérést és ott a látótávolság elég nagy. Még DX11-be is átmentették ezt a látótávolságot, bár itt elég durva a pop-in probléma, de alapvetően ellátsz addig, amíg low-level eléréssel el lehet.Egyébként a látótávolság (ami egyébként így sem rossz) "gondja" a W3-ban simán meg lesz oldva, ha átállnak low-level API-ra. Azt nem mondom, hogy más kimaradt effekt bekerül, mert ott azért több meló lenne. Alapvetően a kiadó is inkább játékbeli tartalomba forgatná vissza a bevétel egy részét, mert az jobban érdekli a vásárlókat.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5489
üzenetére
A konzolon jellemzően jobb a látótávolság, már amelyik játék nem wrapperen fut, hanem a tényleges low-level elérésen. Nem mindegy, hogy egy rajzolási parancs beírása a parancspufferbe három órajel, vagy egy-kétmillió. Ezért hozza a Microsoft PC-re is a low-level API-t. A DX11 ebből a szempontból egy fos, és ezzel már ők sem tudnak mit csinálni, ahogy senki sem a világon. Ezért cserélik le a DX12-vel.
Tudom, hogy sok dolog ki lett kapcsolva. A végleges programban már nem lesz GeometryWorks, a WaveWorks, GPU-s PhysX a részecske effektekre (Particles & Fluids). Ezek mind ott voltak, de hiányoznak. Ez azonban nem a fejlesztők hibája. Maguk a csomagok annyira zártak, hogy borzalmasan nehéz integrálni őket. Az idő múlásával, ha nem sikerül, akkor ráhagyják, mert az NV-nél is van erre egy büdzsé. Ha azt elégetik úgy, hogy nem lesz eredménye, akkor nem löknek bele még több pénzt, hanem elfogadják, hogy nem sikerült, és fókuszálnak arra, amit sikerült beépíteni, mint most a HairWorks, vagy a HBAO+.
Sokszor lehet azt mondani, hogy a fejlesztők a hibásak, de akkor nem amikor olyat várnak el tőlük, hogy zárt rendszereket próbáljanak integrálni. Komolyan a legjobb példa a valóságból, hogy házat senki sem épít úgy, hogy kapnak egy kész tetőteret, és alá behúznak mindent. Nem véletlenül kezdik az építést az alappal, majd a falakkal és végül a tetővel. Persze lehetne találni olyat aki esetleg bevállalná ezt, de baromira megnehezíti a munkát, és ugyanez igaz a programfejlesztésre is. Önmagában mint felhasználók titeket ez nem érdekel, de mégis mit vártok egy fejlesztőtől, meddig égessék a pénzt, amikor negyedik vagy ötödik nekifutásra sem sikerült a zárt middleware-t működésre bírni? Egy idő után közeledik a megjelenés, és a kiadó nem fogja elfogadni azt, hogy egy-két extra effekt miatt a fejlesztők kérnek még fél évet, vagy plusz egy évet. Mondjuk inkább úgy, hogy a W3 a körülmények áldozata lett. Így is elég komplex program volt, gondolom úgy voltak vele, hogy nem számít, ha hat-hét tervezett zárt middleware nem kerül bele. Azok a játékmenetet úgy sem befolyásolják. A program pedig ezek nélkül még jobban optimalizáltabbnak fog tűnni.
-
Abu85
HÁZIGAZDA
válasz
proci985
#5484
üzenetére
Így van. És ami a W3-at érinti, az ami a fejlesztőkön múlott az jelen esetben jó. Végigcsinálták, nagyjából jól is optimalizálták. Az amire nem volt hatásuk az vagy nincs beépítve vagy nem jó. És akkor előjön az, hogy mennyire van értelme a fejlesztőket felelőssé tenni azért, mert totál feketedoboz jellegű rendszereket képtelenek voltak jól integrálni. Itt nem velük volt a baj, és ez látszani is fog a játékon. Amint kikapcsolod azokat az effekteket, amelyeket szimplán a konstrukcióból eredően nem tudtak optimalizálni, nagyon jól fog futni a játék.
A látótávolság pedig magának a DX11-nek a problémája. A Microsoftot kell ütni érte, hogy szar az API. A fejlesztők csak próbálják tartani az ideális draw call értékeket. Semennyivel sem jobb kiadni egy játékot, mint a Dying Lightot és egy későbbi patchben limitálni a látótávolságot, azzal, hogy bocsi, de mégse működik az eredeti elképzelés. -
Abu85
HÁZIGAZDA
válasz
#85552128
#5479
üzenetére
A DX12 sem lesz csoda. Oké eltűnik az overhead, így a látótávolság, illetve a szimuláció részét nem képző objektumok száma növelhető. Nyilván ez a W3-ra is igaz lesz, hiszen ez a játék is küzd attól, hogy 10x-es a rajzolási parancsok többletterhelése DX11-ben, mint low-level API-val. Nyilvánvaló, hogy főleg ez fogja korlátozni a látótávolságra vonatkozó beállításokat, illetve a növények mennyiségét. Ezzel ma nem tudnak mit csinálni.
A zárt effekt egy másik lapra tartozik. Az nem egy API-val kapcsolatos probléma. Az egy döntés, ami vagy bejön vagy nem. Ha úgy veszed akkor a végeredményben lehet úgy gondolni rá, hogy nem vesztesz vele semmit. Ha nem működik, akkor nem lesz benne a végleges játékban. A GameWorks esetében főleg az NV pénze áll benne, vagyis nem az adott fejlesztő büdzséje került elégetésre. Nyilván valamennyit az adott stúdió is belerak, de közel sem annyit, mint amennyibe kerülne egy saját rendszer kidolgozása. Mondjuk utóbbinak az előnye, hogy nagy eséllyel működne, de ha valami gondja van, akkor minimum javítható.(#5482) Szaby59: A rajzolási teljesítmény a konzolon nem gond. PS4-en egy rajzolási parancs beírása a parancspufferbe mindössze három órajel a GNM API-val. Ugyanez DX11-en nagyjából kétmillió órajel. A DX12-ben ezt csökkentik 10-20 órajel közé. Világosan látszik, hogy miért nem rajzolhatsz akármekkora távolságra. Majd az új API-k ezen javítanak. Ez az egyik dolog, ami tényleg nem a fejlesztők hibája.
GameWorks nincs konzolra. Fel sem merül, hogy ott olyan kódot használjanak, amelyet nem tudnak optimalizálni. Ergo semmiben nem határozza meg a két konzol azt, hogy melyik GameWorks effekt kerül beépítésre a PC-s portba és melyik nem.(#5481) TTomax: Nem az a probléma, hogy nincs erőforrás ténylegesen megírni egy komplett rendszert, ami működő. Ezt konzolra minden fejlesztő megteszi lassan pár éve állandó jelleggel.
A PC problémája igazából az, hogy sok az olyan komponens, amelyet semmilyen formában nem tudsz befolyásolni. Például az API és a driver modell, amit érdemes egybevenni. Van egy programod, amelyet ezen futtatsz, és tulajdonképpen a driver csinál valami csodát, hogy jó legyen a hardveren. Na de ha nem jó, akkor mit tudsz tenni? Igazából nem sokat. Semmilyen lehetősége nincs a fejlesztőnek megkeresni a hibát, amely a gondokat okozza, mert nem tudja profilozni a meghajtót. Tehát van egy kód, amelyben elvileg nincs gond. A driver valamit elront, és igazából a programozónak fingja nincs róla, hogy mit. Ekkor jönnek a megbeszélések, hogy hol a hiba. A gyártó és a fejlesztő összeül elemezni, és arra jutnak, hogy ez bizony az API hibája. A fejlesztő elmegy az API biztosítójához, ahol kiderül, hogy márpedig a gyártó a bűnös, azok a szemetek még hazudnak is. A gyártó és az API biztosítója esetleg még összeül, és megegyeznek abban, hogy itt csak a fejlesztő lehet a hibás, néznek egymásra, hogy mégis mi a fasz baj van ezekkel az emberekkel... Na ez az iparág legnagyobb hibája. És akkor kezdődik a foltozgatás, hogy legalább egy picit működjön a program, de valójában senki sem tudja igazán, hogy hol a hiba. Ha a gyártó és a fejlesztő nincs szoros kapcsolatban egymással, akkor talán rá sem jönnek, mert a gyártó a program profilozásánál látja, hogy mi történik a driverben, és még annak a forráskódjával is tisztában van, de a program forráskódják már nem látják. A fejlesztő pont a program forráskódjával van tisztában, de a driverét már nem látják. Aztán az ilyen helyzetek jellemzően megoldódnak úgy, hogy a gyártó visszaad a fejlesztőnek egy forráskódot, hogy ezt írják be és elvileg jó lesz. Aztán később azon megint módosítanak, és kezdődik a buli újra. És a gond ott van, hogy egy hibajavítás hónapokig is tarthat, ami miatt előjön a kérdés, hogy megéri-e bizonyos effektek fejlesztésébe invesztálni, ha ekkora az esélye annak, hogy végül úgy sem fog működni.
MultiGPU dettó. Meg van határozva, hogy mire kell ügyelni, hogy működjön a kényszerített AFR. Megírnak erre egy elvileg jó motort és nem működik. Mindenki csak néz előre, hogy na mi lehet a baj, és megint pitiáner dolgokra mennek el olyan erőforrások, amelyeknek meg lenne a helye. Hogy kevesebb az AFR-t támogató játék manapság? Csodálkoztok? Ki garantálja, hogy működni fog az AFR optimalizálás? Senki. Ilyen szituációban mégis miért lehetne cél az, hogy ebbe invesztáljon egy fejlesztő.
Ezek azok a dolgok, amik miatt a fejlesztők ennyire akarják a feketedobozok eldobását. Hogy lehetnek-e hibák low-level API-val? Hogyne, de nagy különbség lesz, hogy ezeket leprofilozzák, és kijavítják, anélkül, hogy hetekig megbeszéléseket folytatnának a gyártókkal, a szabványalkotókkal, és még az isten tudja kivel. MultiGPU dettó ugyanez. Lehet gond vele low-level API-val? Naná, de ki lehet javítani.Az a poén, hogy ha egy fejlesztőt megkérdezel, hogy mit tart a low-level API-k előnyének, akkor sokan nem a kisebb overheaddel jönnek elő, vagy a hasonló dolgokkal, amelyeket az érintettek esetleg hype-olnak, hanem azzal, hogy kiszámítható lesz a működés. Látják, hogy a program hogyan fut a hardveren, és nincsenek elrejtett szálak, amelyeket nem lehet leprofilozni, vagy olyan forráskód, amelyet nem látnak. Minden hibára célirányos megoldást lehet találni, és nem kell új ösvényeket vágni, amelyek vagy működnek vagy nem. És erre már van erőforrás, mert kiszámíthatóvá vált a rendszer. Tudod a buktatókat, és nem egy előre nem várt tényező fogja megakadályozni, hogy végül az effekt ott legyen a játékban.
-
Abu85
HÁZIGAZDA
Elég sok újítás a GameWorksból való. Egyiket sem tervezték konzolra. Azt nem értem, hogy miért várjátok el ezektől a fejlesztőktől, hogy minden szuper legyen, amikor arra kényszerítik őket, hogy előbb tetőt építsenek a háznak. Ez egy baromság, és ezt az eredmény több esetben is bizonyította.
Érdekes, hogy aki alapoktól a tetőig építkezik, az minden eltervezett effektet tökéletesen beépít a játék összes portjába, és furcsamód a portok minősége is elég jó.
Alapvetően két eset lehetséges. Vagy mindenki hülye, aki GameWorksöt használ, vagy tényleg igaz, amit a fejlesztők mondanak egy ideje, hogy nem lehet úgy hatékonyan játékot fejleszteni, hogy a kész "fekete dobozok" alá behúzod a motort. Lehet ennek tapsikolni, hogy ez milyen fasza dolog, meg annak is, hogy a kompatibilitási problémák miatt a tervezett effektek jó része fejlesztés alatt eltűnik. -
#5477
Abu85
HÁZIGAZDA
Malibutomi
#5466
Abu85
HÁZIGAZDA
válasz
Malibutomi
#5466
üzenetére
A draw distance és a növényzet szerintem egy későbbi patchben vissza lesz rakva, mivel elvileg készül a játékhoz low-level port. Arról nem tehetnek a fejlesztők, hogy a DX11 korlátjai miatt beleütköznek a rajzolási limitekbe. Ez egy API probléma, ha kicserélik az API-t lehet engedélyezni a magasabb látótávolságot. A több növényzetet nem feltétlenül. Ha a növény dekoráció csak, tehát nem akadhat bele az AI, akkor nyilván be lehet dobni, de lehet, hogy az AI-t esetleg limitálta az interakció részét képző növényzet.
A tesszelláció szerintem azért maradt ki, amiért az Ubisoft kihagyta az AC: Unity-ből. Ez a GeometryWorks csomagból jött volna, de nem tudták működésre bírni, ahogy az Ubisoft sem fél éve. A GeometryWorks nem ad lehetőséget a tesszelláció kontrollálására, így ha a felületek nincsenek tökéletesen kialakítva, akkor sokkal rondább lesz az egész tesszellációval, mint tesszelláció nélkül. Ezért fontos, hogy a fejlesztő kontrollálhassa a tesszellálás működését, mert más esetben nem tudja belerakni a játékba. Szóval itt nem arról van szó, hogy miért nem maradhatott bent ultra opcióként, jó eséllyel sosem működött a beállítás. Ilyenkor általában a kiadó közbeszól, hogy ha aránytalanul sok erőforrást költenek valamire a fejlesztésnél, akkor azt lelövik. Megpróbálták, de nem sikerült. Az Ubisoft is négy hónapig próbálkozott a tesszellálás beépítését az AC Unity-be, de egyszerűen az NV zárt csomagjával ez nem működött. Valószínűleg meg lehetne oldani, csak a megoldás a zárt forráskód miatt egy évig eltarthat, és így ebbe bele sem kezdenek.
-
Abu85
HÁZIGAZDA
Konzolokba eleve nem is tervezték ezeket a funkciókat. A gond inkább az volt, hogy baromira nehéz zárt forráskódú effekteket beépíteni, mert ha nem kompatibilis a motorral, akkor a motort kell módosítani, ami többletköltség. Ha erre nincs idő és erőforrás, akkor sokkal jobb, ha az effektet nem építik be, mert amúgy sem működne. Minél komplexebb dologról van szó, annál nehezebb az integrálása, ha az effekt forráskódja nem írható át.
A konzolokra eleve nincs még GameWorks, de úgy néz ki, hogy nem is lesz, tehát ezeket a gépeket ez a gond abszolút nem fenyegeti. Ide a Sony és az MS nyílt forrású effekteket támogat.Ott van példának számos fejlesztőstúdió, amely meg tudja csinálni, amit elhatároz, és ez nagyban köszönhető annak, hogy nem lezárt kódokat próbál valahogy behackelni, hanem maguk írják a kódot aszerint, hogy a motor mit támogat.
Nem véletlen az sem, hogy például az Unreal Engine main branch a GameWorks kódokat nem tartalmazza. Az Epicnek sajnos nincs hatalmában azoknak a hibáknak a javítása, amelyeket ezek okoznak, így inkább szeparált branchben érhetők el, amely nem sok licencelőt érdekel, mert egy fejlesztőnek púp a hátára, még azt is kitalálni, hogy mit kell átírni a motorban, hogy xy effekt jól működjön.És ezzel kapcsolatban a jövőben is lesznek gondok. Nem lehet úgy házat építeni, hogy felhúzod a tetőt és aláépíted ami hiányzik. Ugyanezt várja el tőled a GameWorks, szinte lehetetlent kérnek a fejlesztőktől, és idővel az erre épülő rendszereket kikapcsolják, mert kevés az esély a működésükre.
-
Abu85
HÁZIGAZDA
Ha összehasonlítod a tesztkörnyezetet, akkor esőben most is így teljesít a játék. A Radeonok belassultak. Nem tudni miért. Számos oka lehet. Akár még az is, hogy az early access esetében engedélyeztek olyan optimalizálásokat, amelyek nem biztos, hogy stabilak, így a Final verzióra letiltották.
Az is nagyon érdekes, hogy a Radeonok Windows 10 alatt 40%-kal is gyorsabbak ( [link] ), mint korábbi Windows alatt. Itt valami fatális hiba csúszhatott a Final verzióba, amit nem vettek észre. Teszthiány? Az early access játékoknál nem ritka. -
Abu85
HÁZIGAZDA
De abszolút van. Ugyanis a gépigényben jelezni kell, ha a fejlesztő tud valamilyen problémát bizonyos hardvercsaláddal. A Telltale pont ezért írja oda minden játékához, hogy teljesítményproblémák miatt az Intel IGP-hez nem ajánlják. Mivel a Slightly Mad Studios ezt nem tette meg, így abszolút jogos egy csoportos per a pénzvisszafizetésre vonatkozóan. USA-ban még simán meg is lehet nyerni.
A legutolsó Early Access verzióknak ilyen volt a teljesítménye: [link] - szóval az még vagy már jól futott, és ebből nem lehetett kiindulni. Valami a Final verzióval történt. Nem kizárt, hogy a fejlesztők szúrtak el valamit a Final verzióval. Ebből a gondolom, hogy szándékosságról nem érdemes beszélni, még.
-
Abu85
HÁZIGAZDA
válasz
Xmister
#5402
üzenetére
Ha gyorsan jön egy patch akkor az gyanús, de nem kizárható, hogy be nem épített optimalizációk tesztelése zajlik.
Igazából ami most történik az senkinek sem kedvez. Még az NV-nek sem. A geforce.comon megnézheted, hogy mindent eltüntettek a Project Carszal kapcsolatban. Mintha sosem támogatták volna. Ki akarnak maradni az egészből, mert nagyon kínos, hogy a partnerprogramjuk ideje nem tud kiadni olyan PC-s játékot, amellyel nincs probléma. Még ha semmi közük az egészhez, akkor sem vállalhatják fel ezt.
Egyetlen olyan szereplőt nem tudok mondani, akinek ez a szituáció jó, és így nehéz ebbe szándékosságot látni.Én csak annyit mondta, hogy optimalizálások maradtak ki, de ez bőven lehet teszthiánytól is. Mint írtam manapság nem olyan számít gondnak béta állapotban kiadni egy programot.
-
Abu85
HÁZIGAZDA
válasz
Xmister
#5383
üzenetére
A tesztelés sokáig is elhúzódhat. Manapság nagyon jellemző, hogy a játékot megéri béta állapotban kiadni, mert gyorsan lehet patch-elni.
Abba érdemes belegondolni, hogy a fejlesztőknek ez nagyon gáz. Semmivel nem tudják magukat védeni egy jogi lépéstől. Ha egy csomó felhasználó csoportos pert indít, akkor ezt ilyen formában baromira egyszerű megnyerniük, mert a fejlesztők nem hívták fel a figyelmüket a gondra sehol sem. És egyetlen dolgot nem akar egyetlen fejlesztő sem. Visszafizetni a felhasználóknak a pénzüket.
Szóval mielőtt szándékosságot feltételezünk érdemes figyelembe venni, hogy a Slightly Mad Studios baromira nem tőkeerős cég, és egy ilyen perbe simán belerokkannak. Ugyanezt egyszer ők már eljátszották az NFS Shifttel. Ki is baszta őket az EA a picsába. -
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
A fordításhoz még annyit, hogy van egy nagyon jó eszköz erre. A CodeXL-ben pont az offline ellenőrzésre találták ki a shader analyzert, amelyen nem szükséges futtatni a programot. Egyszerűen csak be kell tölteni a shadert és azt elemzi a rendszer. Ki fog adni szép színes kockákat, hogy miképp fog futni. A shadert valós időben lehet ott szerkeszteni, és látható ennek a hardverre vonatkozó hatása is.
Itt be is mutatják a programot: [link] - látható, hogy mire kell figyelni, és mutatja, hogy nagyjából milyen optimálisan használja a shader a hardvert. Ez igazából a GE fejlesztők titka is, mert ez egy olyan eszköz, amivel nagyon hatékonyan lehet optimalizálni. -
Abu85
HÁZIGAZDA
Nem lehet megnézni, mert az NV architektúráját nem lehet vizsgálni. De a GCN-ben kétszer több regiszter van egységnyi feldolgozóra, mint a Maxwellben és négyszer több, mint a Keplerben. Ráadásul mindhárom architektúra birtokláslimites és a regiszterhasználatra kell optimalizálni. Szóval nincs különösebb magyarázata, hogy a GCN-nek miért kell sokkal több regisztert lefoglalni. Nyilván nem zárható ki a complier bug sem, de furcsa, hogy csak és kizárólag ezt a játékot érinti.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5374
üzenetére
Persze, hogy nem, egy csomóan pénzvisszafizetést követelnek a fejlesztőktől. Már alakul egy csoportos per is. Nem ezt támogatták.
A fejlesztők elkövették azt a hibát, hogy a gépigénynél nem írták ki, hogy a Radeon tulajon ne vegyék meg. Ettől jogilag nagyon durván támadhatóvá váltak. A Telltale Games pont ezért írja oda mindig, hogy Intelen nem fut jól xy programjuk, és ennek tudatában vedd meg. Védik magukat a pertől. -
#5373
Abu85
HÁZIGAZDA
gainwardgs
#5369
Abu85
HÁZIGAZDA
válasz
gainwardgs
#5369
üzenetére
A low-level API nem segít azon, ha rossz a regiszterallokáció. Arra hiába írják át, attól még ugyanúgy sokkal több regiszter lesz lefoglalva, mint amennyi kell.
-
Abu85
HÁZIGAZDA
Fordítós dolognak néz ki inkább. A disassemblerben látszik, hogy nagyságrendekkel több vektorregisztert foglalnak le a shaderek, mint amennyit kellene nekik. Ezért az ideális 7-10 helyett 1-3 wavefront fut a CU-kon. Innen nehéz megmondani hol a hiba, mert a GCN tele van regiszterrel, így nem tudni, hogy egy shader miért foglal le tízszer nagyobb regiszterterületet GCN-en, mint máson. Az is érdekes, hogy konzolon semmi baja, pedig ugyanaz a hardver, bár nem ugyanaz a kód.
-
#5367
Abu85
HÁZIGAZDA
ricshard444
#5366
Abu85
HÁZIGAZDA
válasz
ricshard444
#5366
üzenetére
Úgy tudom, hogy az Inteltől, hogy több gyorsabb kódot is leadtak nekik, de nem építették be egyiket sem. Gondolom az AMD-nél is ez volt. Február óta dolgoznak rajta emberek, de végleges verzióból hiányzik ez a gyorsulás. Lehet, hogy nem tesztelték ki, így nem is engedélyezték még.
-
Abu85
HÁZIGAZDA
válasz
sayinpety
#5242
üzenetére
A GAB és az ARB munkáját már befolyásolják azzal, hogy az xy fejlesztővel kidolgozott ötletükre még a szabványosítás előtt kiadnak egy játékot. És ezért nem olyan jó dolog ez a diktálás, mert egyrészt rendben van, hogy a GAB és az ARB ettől dolgozhatna nyugodtan és átgondoltan, de a másrészt a gyártók számára a gyorsaság fontos lenne, mert az AMD a beépítendő technikára már hardvert és programot is kínál, miközben az Intel és az NV a szabványosításon tanácskozik. Ez közvetetten már nevezhető hatalommal való visszaélésnek.
(#5256) tom_tol: A GAB a Microsoft Graphics Advisory Board, míg az ARB a Khronos Group Architecture Review Board. Röviden itt születnek meg szabványok (DX, OpenGL, Vulkan).
-
Abu85
HÁZIGAZDA
Egy piacot néztünk az elmúlt másfél évben? Mi a jövő? A low-level. Ki szerint? Mindenki. Kinek a kutatására épül ez a jövő? Az AMD-ére.
Gyakorlatilag másfél év alatt elérte az AMD, hogy ők mondhassák meg a tutit az MS és a Khronos helyett. És ne hidd azt, hogy ennek bárki örül rajtuk kívül. Innentől kezdve bármit átnyomhatnak a GAB-on és az ARB-n. Ez baromira nem tetszik a konkurenciának. -
Abu85
HÁZIGAZDA
Nem beszéltem játékokról. Kiadót és fejlesztőt említettem.
Sajnos nem. Próbáltam tesztre, de ugyanazokat a lassulásokat generálja bármilyen hardverrel. A fejlesztők szerint a DX11 miatt van. Szerintem azért a motor sem százas.
Tudtommal nem jön a GTA5-höz DX12 vagy Vulkan frissítés. Megkérdeztem ezt és az a baj, hogy a PC-s port motorja az X1/PS4 port struktúráját használja. Ezt nem tervezték low-levelre. Konzolon sem úgy fut. Ha akarnak low-level portot, akkor az egy jó fél éves munka lesz a motor átírása miatt.
Egy oldalon jelent meg teszt, és ott is ki volt hangsúlyozva, hogy alpha kód. Meg az Intel is nyilatkozott, hogy a tesztelt verzió nem tartalmaz optimalizálást számukra.
Akármennyire nem tetszik jelen pillanatban messze az AMD teszi a legtöbbet azért, hogy a PC továbbra is alternatíva legyen a top fejlesztőknek. Mert amit az Ubi és Warner művel az a konzol felé hajtja a népet.
-
Abu85
HÁZIGAZDA
A Square Enix adja a PC-nek a legjobb portokat. Csak ezért külön stúdiót tartanak fennt. A SEGA számos PC only stratégiát ad ki. A Capcom szeretne több PC-s portot. Ezért álltak be. A többi kiadó is elég nagy az eladások alapján.
A Dying Light semmin sem tökéletes. Ez nem a GameWorks hibája. Egyszerűen nincs kész a motor.
A GTA5 esetében a javítást nehezíti, hogy nem minden konfigon van meg a hiba. Ugyanazt a VGA-t más alaplapba teszed és jó. Nem valószínű, hogy driverből javítható.
A StarSwarmban nincs benne a DX12. Nem is frissítik bele, mert nincs rá idő, hogy minden hardverre optimalizálják az utolsó buildet. Persze a fejlesztőktől meg lehet szerezni, de nem ajánlják teljesítmény összehasonlításra.
-
Abu85
HÁZIGAZDA
A Square Enix csak demót készített az NV-nek és az MS-nek megrendelésre. Valójában minden nyugatra kiadott játékuk Gaming Evolved. Ez volt a múltban is és még két évig lesz a jövőben is.
A 2K által birtokolt két top stúdió a Firaxis és az Irrational. Az utóbbi két évben csak GE alatt adtak ki játékot.
Az AMD sosem kérte, hogy optimalizálják tovább a StarSwarmot. Ők már ezt nem akarták mutogatni. Helyette az AotS játékra koncentráltak, amely a Nitrous motor tényleges játéka lesz. A Microsoft és az NV kérte a további optimalizálást, hogy bemutathassák ők is azt, amit az AMD már 2013-ban bemutatott.
-
Abu85
HÁZIGAZDA
Azok az idők elmúltak. Jóval több top fejlesztő van a GE-ben, mint a TWIMTBP-ben. Már kiadók miatt nem lehet más a helyzet, mert az AMD-nek nyolc komolyabb kiadóval (EA, Capcom, Square Enix, SEGA, 505 Games, Deep Silver, 2K Games, Stardock) van szerződése, míg az NV-nek hárommal (Ubisoft, Warner, City Interactive).
-
Abu85
HÁZIGAZDA
Azért nem árt, ha van egy tapasztalt rendszerprogramozó a fejlesztő mellett. Viszont gondolod az AMD-nek megvan az erőforrása mindenkire? Ott van náluk az EA, a Capcom, a Square Enix, a SEGA, az 505 Games, a Deep Silver, a 2K Games, a Stardock, illetve a fejlesztőktől az Oxide Games, a Firaxis, a Rebellion, a CodeMasters, a CIG, a CCP, stb. Ennyi partnerrel a hátuk mögött túlterheltek. Kisebb stúdiókat talán tudnak vállalni, de a mostani nyolc mellé még egy kiadót biztosan nem.
Ezzel szemben az NV csupán három nagyobb kiadóval van partneri viszonyban, tehát bőven van szabad erőforrásuk. Azért lenne jó, ha ők is segítenék a top fejlesztőket, mert az AMD kapacitása véges. -
Abu85
HÁZIGAZDA
Mi köze a konkurenciának ahhoz, hogy az NV kínáljon egy olyan alternatívát a TWIMTBP partnerprogramba, amely segíti a tehetős, pénzes és komoly tudással rendelkező szakemberek munkáját? Egyáltalán mi az, ami miatt rájuk az NV mostohán néz? Ők is ugyanazt teszik, amit egy indie, csak alkotni akarnak valami egyedi technikát, így saját pénzből, saját erőforrásból megépítik maguknak. Ha valaki nem így gondolkodna, akkor ma nem létezne a Crysis, a Ryse, vagy sok egyéb AAA játék, amelyek a maguk területén valami egyedit alkottak (most a játékélményt hagyjuk, szorítkozzunk a technológiára). Egyetlen reális okot nem tudok mondani, ami miatt a jövőben meg kellene akadályozni a PC-s grafikai innovációt a fejlesztők munkájának korlátozásával. És amíg erre nem lesz reális ok, addig ez „hiba”.
-
Abu85
HÁZIGAZDA
Pont ez a lényeg, hogy most nem kapjátok meg azt, amit kellene. És ebben vezető szerepe van annak, hogy a fejlesztők nincsenek a középpontban, vagy rosszabb esetben az adott partnerprogram inkább akadályozza az optimalizálást.
A másik dolog, hogy a végtermék három rendszertől függ. Magától a programtól, az API-tól és a gyártóktól. Eddig a gyártók és a szabványalkotók diktáltak, és oda jutottunk, hogy mindenki szerint rossz a rendszer. Az új modellben a fejlesztők diktálnak, mert a korábbi irányról már bebizonyosodott, hogy nem működik. Van esély rá egyébként, hogy az új modell sem fog működni, de választani kellett a biztosan nem működő és a lehet, hogy működő ösvény között. Utóbbi mellett szol, hogy konzolon működik, és egyelőre nem úgy tűnik, hogy akadálya lenne a PC-s működésnek. -
Abu85
HÁZIGAZDA
Nem a GameWorks-szel van a baj önmagában. Bizonyos szempontból megmagyarázható, hogy van egy olyan réteg, ahol ez előny. Le is írtad melyik. A probléma forrása itt az alternatíva hiánya. A GameWorks lefedi a célzott réteget, de mi van a másik réteggel, ahol van pénz, szaktudás, erőforrás, stb. Számukra az NV nem kínál semmit, pedig hiba azt hinni, hogy ők olyan isteni képességekkel rendelkező szakemberek, akik pusztán a VGA vizuális látványától tudják, hogy a rajta lévő szilícium hogyan működik. Az is hiba, hogy számukra a GameWorks nem kínál olyan konstrukciót, hogy a forráskódot szabadon, korlátok nélkül át lehessen írni.
Az NV-nek a piacra levetített hipotézise a probléma. Az a feltételezés, hogy itt bizony minden fejlesztő birka, így az lesz a legjobb, ha kikötjük őket.
-
Abu85
HÁZIGAZDA
Nem írtam, hogy nincs erre példa. Nyilván az AC: Unity egy elbaszott program. Hülyeség volt azt hinni, hogy egy olyan komplex játékhoz a konzolon is elég lesz a magas szintű elérésé. Nem, nem elég. De ettől még számos más játék van, amivel gondok vannak. És az egyik legfontosabb dolog, hogy ezzel a fejlesztők bizalmát is elvesztik. Lehet építeni stratégiát arra, hogy a felhasználók 90%-a idióta és sose jön rá, hogy át vannak ejtve. Rengeteg cég (és kormány) ebből él meg. Sőt, ha a hatékonyságot nézem, akkor ez a jó stratégia. De stratégiát építeni arra, hogy maguk a programfejlesztők is birkák egy rendkívül arrogáns dolog, és nem csodálom, hogy a top fejlesztők körében ez népszerűtlen. Én mint felhasználó utálom, ha egy cég hülyének néz, hát még ha programfejlesztő lennék...
-
Abu85
HÁZIGAZDA
válasz
Locutus
#5174
üzenetére
Teljesen félreértitek az egészet. Az a fontos, hogy a PC-s iparnak jót tegyen egy ilyen partnerprogram. Magát az NV irányát egy Ubisoft programozó bírálta. Andrew Lauritzen is leírta, hogy rossz dolog sok-sok százalékkal lassabb kódot szállítani a saját! felhasználóidnak csak azért, hogy pár százalék előnyöd legyen a konkurenciával szemben. Ez az abszolút mélypont a rossz ötletek tárházában, és sokan ezért tapsikolnak. Persze gondolom, hogy nem tudja az átlag user, hogy ugyanaz a program mehetne sokkal gyorsabban is, de az azért már eléggé feltűnő, hogy az elmúlt egy évben csupa optimalizálatlan TWIMTBP játék érkezett egy csomó jól optimalizált GE játék mellé. Egy idő után nem lehet a fejlesztők nyakába varrni, hogy márpedig ők a hülyék, és nem a zárt konstrukcióval van a gond.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5172
üzenetére
Akkor ezt tegyük tisztába. A Gaming Evolved egy komplex csomag. Három opciót kínál a fejlesztőknek. Egyrészt van az optimalizálási segítség, másrészt a reklám, harmadrészt a lehetőség a pénzcsaphoz. A Gaming Evolvedben a segítség az alap. Innen a következő szint a reklám, hogy ha relatíve jó lesz a játék. Ezt értsd például úgy, hogy az AMD-nek joga van a kereskedőláncokkal ilyen akciókra.
A harmadik szint az, amikor a játék hivatalosan Gaming Evolved cím lehet. Ehhez nagyon szigorú minőségi mércét kell megugrani, de cserébe az AMD akár tízmillió dolláros pénzcsapot nyithat ki, amin keresztül a fejlesztőknek lehetősége van kódokat biztosítani, hogy bekerüljön a játék a Never Settle promócióba. -
Abu85
HÁZIGAZDA
válasz
#85552128
#5169
üzenetére
A Rockstar nem akart választani. Mindkét partnerprogramba beállt. Mindkét cégnek joga van reklámozni. Még az Intelébe is be fognak állni, bár azt csak reklámból teszik. A Gaming Evolvedbe azért léphetett be a Rockstar, mert az ott készült játékok optimalizációja nagyon sokszor példás, így az AMD szakemberi gárdáját el akarhatták érni a GTAV-höz. Gondolom azt is láthatják, hogy a TWIMTBP olyan irányba ment el, ami inkább akadályozza a PC-s optimalizálást.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#5150
üzenetére
A koncepció hasonlít, de a kód eléggé eltérő lehet. Fogsz egy motort abba leportolni egy Vulkan és egy DX12 kódot nem nagy költség. A gond az, hogy azokat külön kell validálni, és egy játékra lekorlátozva a tesztelést ez nem feltétlenül éri meg. A Frostbite-ban biztos benne lesz egy pár API, de ebből szinte biztos, hogy csak egy-kettő lesz PC-n aktiválva.
Nagyon sokan egyébként inkább a Vulkan irányában nézelődnek. Nem csak az EA. Ott a Valve is, illetve aki SteamOS-re hoz játékot biztosan nem DX12-t választ.
A Vulkan előnye még, hogy a Windows 10-ből a WDDM 2.0 újításait ezzel az API-val is lehet használni. Tehát nyugodtan hozzá lehet nyúlni a GPUMMU-hoz és az IOMMU-hoz. Nem kötelező a legacy WDDM funkciókat használni. Persze ilyen esetben a Vulkan megléte mellett is a Windows 10 lesz a minimum igény, de maga az előny amit ad a GPUMMU az sok. Az IOMMU pedig pláne, ott komoly extrákat lehet szerezni. -
Abu85
HÁZIGAZDA
A Vulkan az EA-nek azért nagyon jó opció, mert eleve van egy kitesztelt és validált Mantle kódjuk. Ez nagyjából 4000 sor, de a Mantle és Vulkan függvények 90+%-a megegyezik, tehát számukra a portolás nagyrészt annyi lenne, hogy a függvénynevekben a gr-t lecserélik vk-ra. Ez rendkívül költségkímélő, illetve nyilván sok hiba is kizárható.
Másrészt az EA szerintem a DX11-et már dobná, mert csak állandó problémájuk van vele. A Vulkan elérhető lesz Windows 7-re is, így gyakorlatilag úgy tudják dobni a DX11-et, hogy még mindig elérik a potenciális vásárlóbázis nagy részét. A DX12-vel ez nem lehetséges, mert Windows 10-hez van kötve az API.
Egyébként a DX12-t be lehet építeni, de most két ugyanolyan funkcionalitást kínáló API-t validálni felesleges. A Vulkan ráadásul kézenfekvő az OpenCL C és C++ direkt támogatása miatt, amit DX12-ben nem lehet egyszerűen megoldani. -
Abu85
HÁZIGAZDA
A Square Enix továbbra is az AMD partnere, csak az AMD nem akar a Luminous Engine-be pénzt rakni, mert a Luminous Studio azt mondta róla a Square Enixnek, hogy játékfejlesztésre alkalmatlan. A Final Fantasy XV épített volna elsőként a Luminous Engine-re, de már nem fog, mert nem működik. Helyette a mostani motor lesz kiegészítve a Luminous fénykezelésével, és ez lesz így felhasználva a Final Fantasy XV-hez, ami viszont nem jön PC-re. Ezért az AMD úgy döntött, hogy egy olyan motorba nem rak több pénzt, amivel maguk a fejlesztők sem számolnak.
(#5140) CsonkaImo: Az EA és az AMD kapcsolata kb. olyan, mint az NV és az Epic kapcsolata. Annyira össze vannak nőve, hogy ott a szakítás maga a csoda lenne.
(#5141) daveoff: Nem. A Codemasters Intellel dolgozik. A dolog itt annyi, hogy az AMD-nek vannak külön szerződései bizonyos címekre. Például a SEGA-nál az Alienre, vagy a Codemastersnél a DiRT-re. De ha megnézed, akkor a többi 2014-ben befutott SEGA és Codemasters játék inteles.
A Frostbite kapcsán Repi Vulkan API-t támogatja, és ez hivatalos. A DX12-re még nem mondott semmit. Igazából sok értelme a Vulkan mellett ennek nincs.
-
Abu85
HÁZIGAZDA
Ez nyilvánvaló. Máig ezt ajánlom mindenkinek, hogy nézze meg az adott kedvenc játékot ki támogatja, és akkor nem éri majd meglepetés. Sajnos ma ez a PC. Vannak speckó dolgok mindkét gyártónál, amelyeket esetleg nem érhetsz el, ha nem olyan VGA-t választasz, amin az fut. Ez van.
A Civ6-ban nekem sem a speckó MSAA tetszett, hanem az, hogy low-level API-n futtatva a gép a lépéseknél az AI-t az összes processzormagon számolja. DX11-ben viszont ez egy magra van korlátozva. A játék vége felé elég sokáig tarthat egy lépés, így elég jól jön, ha az negyedannyi idő alatt megtörténik. De ez elsődlegesen az én igényem, mert kizökkent a játékból. -
Abu85
HÁZIGAZDA
válasz
mcwolf79
#5117
üzenetére
Mivel kapcsolatban van ez a kérdés? A hardverről már nem beszélhetek, de szoftveres változások vannak már ma is. Ha megnézed, akkor mindenkinél hamarabb vezettek be low-level API-t, és most mindenkinél hamarabb bevezettek egy olyan LiquidVR csomagot, amely kipótolja a szabvány API-knak (DX12/Vulkan) a VR-re vonatkozó hiányosságait. Az persze igaz, hogy ezek nem szabványosak, de az első működő rendszerek az adott problémára. A Mantle-nek és a LiquidVR-nek is lassan kész vannak a frissítései. Előbbinél már nem a többletterhelés a fókusz, míg utóbbinál elérhető lesz a mid-wave preempció, hogy az async timewarp ne késse le a szinkronizációt. Ezek 2017-ben válhatnak szabványossá. Hozzávetőleg másfél évvel gyorsabban dolgoznak mindenkinél. Nekik azt mondani, hogy mire várnak eléggé érdekes.
-
Abu85
HÁZIGAZDA
Sose mondtam olyat, hogy a low-level API miatt nem tudod majd futtatni a programot. Csak annyit mondtam, hogy a konzol, illetve a low-level API hatása az lesz, hogy a játékokban lesznek olyan funkciók, amelyek csak Radeonon működnek. Erre volt pár példa, lásd a Thiefben a TrueAudio és az async compute, a Lichdom: Battlemage-ben és a Sonic & All-Stars Racing Transformedben a TrueAudio, illetve a Civ 6-ban a speciális MSAA. Ezeket más hardverrel nem éred el. Ilyen a jövőben is lesz egyébként, és ennek vezető indikátora a konzol, valamint az, hogy a low-level API irányban a szabványalkotók a konzolhoz próbálják igazítani a PC-s API-k tudását, hogy a fejlesztők minél több dolgot átmenthessenek. Később ezeket ráérnek a gyártók beépíteni a hardverbe, és a meglévő kód futni fog.
-
Abu85
HÁZIGAZDA
A multiplatform címeknél a PS4-X1-PC trió együttesen számít a kiadónak.
Amikor a fejlesztők az NV zártságát vitatták a Twitteren, akkor Bartlomiej Wronski mondta, hogy igazából a konzol a domináns faktor. [link]Az AMD víziója az, hogy a fejlesztők alacsony szintű hozzáférést kapjanak a hardverekhez. Ez már bejött, hiszen két szabványos API is lesz erre az irányra. Nyilván okkal akarják. Pontosan tudják, hogy a konzolok miatt a GCN a domináns architektúra.
A PC-s időszakos problémákról a Microsoft és a Khronos tehet. Ez eléggé világos már. Viszont a fejlesztők dolgát a "feketedoboz" API-k mellett nem kell "feketedoboz" middleware-kkel nehezíteni. Utóbbi ellen lehet tenni. -
Abu85
HÁZIGAZDA
válasz
mcwolf79
#5022
üzenetére
Az igazából nektek előny, hogy a top fejlesztők az AMD-vel és az Intellel borultak össze, mert ők megadják a szükséges eszközöket, hogy optimalizált PC-s portok szülessenek. Az NV ezt valamiért nem akarja, és az elzárkózással mesterségesen magas gépigényeket teremtenek, ráadásul rossz minőségű effektekkel. Nehéz meglátni, hogy ez miért lesz jó a PC-nek, nem véletlenül léptek le tőlük vezető szakemberek.
Itt egy fejlesztői vélemény: [link] - ő sem látja az értelmét. A felhasználóknak rossz, és a fejlesztőknek is. Az egyetlen reális feltételezés az, hogy az NV ki akarja csinálni a kliensoldali hardcore játékot, hogy mindenki áttérjen a GRID felhőre. Ebben van ráció, csak a felhő eddigi életútját látva kockázatos. -
Abu85
HÁZIGAZDA
Azért sikerült ennyire összeborulni a fejlesztőkkel, mert az NV-vel a nagyok nem tudnak együtt dolgozni, mert elzárkóztak, és ez nagyban hozzájárul ahhoz, hogy a TWIMTBP az elmúlt évben nagyrészt bugos, alig optimalizált PC-s portokat rakott le az asztalra. Na meg persze nyilván számít az is, hogy az NV-től számos szakember távozott 2014-ben, akik nem értettek egyet az "ezt is lezárom" politikával. Nyilván ők azért ebben élnek nap mint nap, és pontosan tudják, hogy ha ezt csinálja az NV, akkor nem fog az adott stúdió engedelmeskedni, hanem elmegy az AMD-hez és az Intelhez. Ha az NV nem változtatott volna a G80 idején bevált recepten, akkor ma nem lenne az AMD-nek annyi partnere, amivel gyorsan át tudnak nyomni az iparon egy teljes API reformot.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#4814
üzenetére
Ők még a jobbik félbe tartoznak, de azért nem olyan jók, mint a nagyobbak. Bár ez viszonyítás kérdése. A PC Labnál sokkal jobbak, azért akkora eltéréseket ők nem dobnak be, hogy 10 fps legyen két ugyanolyan mérés között a különbség, de nem véletlen, hogy azonnal az elsőségre törnek, mert minőségben a többiek ütik őket.
Ezen a piacon általában így megy a dolog. Ha tudod, hogy nem vagy jó, akkor legyél gyors. Ha pedig tudod, hogy jó vagy, akkor legyél precíz. Nincs ezzel semmi baj egyébként.
-
Abu85
HÁZIGAZDA
válasz
regener
#4811
üzenetére
PCLab mérésekben ne keress logikát, ők régóta össze-vissza mérnek. Nem ez az első eset.
Majd jönnek a nagyok. A GameGPU és a PCLab mindig első, ezért abszolút felületes munkát végeznek, míg a többiek precízek, de elvesztik a megjelenés elsőségét. Valamit valamiért.
(#4808) sayinpety: Oké ez így világos, de mégis milyen motor az, amit csináltok? Hány compute és hány grafikai futószalagot futtattok, hogy ez így ennyire fekszik a GCN-nek?
-
Abu85
HÁZIGAZDA
válasz
sayinpety
#4781
üzenetére
Oké elfogadom ezt a lehetőséget, de azok az adatok amiket írtál itt, azt mutatják, hogy a Hawaii sokkal gyorsabb a GM204-nél. Aszinkron compute mellett és nélkül is erősebb. Aszinkron compute-tal 10 ezresmásodperccel jobb, ami azért nem kevés. Ez azért nem feltétlenül azt támasztja alá, hogy minden rendben lesz az optimalizálás kiszervezésével, de nyugodtan javíts ki, ha tévedek.
De amúgy ja egyetértek, a Dragon Age: Inquisition-t grafikailag nem sikerült lenyomni, csak ez pénzkérdés inkább, mintsem technikai.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ezek a hardverek már képesek az órajelüket visszavenni, ha túlterhelést érzékelnek.
Ú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.
- Doky586: SecureBoot kulcsok frissítése (2026 nyara)
- Fejhallgató erősítő és DAC topik
- Házimozi haladó szinten
- Micro Four Thirds
- EAFC 26
- Sütés, főzés és konyhai praktikák
- GoodSpeed: Daikin FTXF35E / RXF35F Sensira 3,3 kW Inverteres klíma - a Sztori
- Eredeti játékok OFF topik
- Autós topik
- Szeged és környéke adok-veszek-beszélgetek
- További aktív témák...
- Apple iPhone 13 128GB,Átlagos,Adatkabel,12 hónap garanciával
- MCDODO T03 fejhallgató
- BESZÁMÍTÁS! ASRock A520M R5 3600 16GB DDR4 512GB SSD RX 6600 8GB Rampage SHIVA Cooler Master 600W
- Apple MacBook Pro 14 (2021) M1 Pro 16GB/500GB használt, szép állapot 87% akku (323 ciklus)
- iKing.hu Apple iPhone 14 Pro 128GB használt Silver 100% akku 6 hónap garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest