- GoodSpeed: 3I/Atlas: Üstökös vagy idegen civilizáció űrhajója?
- Trewerr: Analóg-digitális jelátalakítás (zenefájlok leegyszerűsítésével magyarázva)
- sziku69: Fűzzük össze a szavakat :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
Új hozzászólás Aktív témák
-
#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.
-
Abu85
HÁZIGAZDA
Az a gond, hogy nem látom, hogy egy külsős stúdió mégis hogyan tudná jobban optimalizálni a kiadott architektúrákra az adott programot. Azt értem, hogy a kiadónak a költségei így sokkal kedvezőbbek lesznek, és el is fogadom, hogy a mai világban ez egy cél, csak azt nem látom biztosítottnak, hogy a kiszervezett architektúrák optimalizálása legalább olyan jó lesz, mint amit belsőleg elvégeznek a GCN-re.
Még azt elfogadnám, hogy a kiadó esetleg úgy látja, hogy a külsősök jobban meg tudják oldani, mint a saját anyastúdió, csak az már eleve egy olyan hozzáállás a kiadó részéről, hogy belsőleg ezzel nem igazán törődtek volna, tehát a kiszervezett architektúrák hátránya már az anyagiak elosztásánál kialakult, ami viszont előre leosztott erősorrend. -
Abu85
HÁZIGAZDA
válasz
MiklosSaS
#4764
üzenetére
Csak a kiadók nem így gondolkodnak. A konzol és a PC nincs különválasztva, hanem egy nagy next-gen platformként van kezelve, és így már a GCN van többségben. A multiplatform fejlesztéseket három platformra végzik, és ha beleszámolod az Xbox One és a PS4 folyamatosan növekvő felhasználóbázisát a PC-s AMD-s bázisba, akkor az már úgy többet ér, mint ami maradt a PC-ből. Csak PC-re levetítve ez valóban öngól, de a kiadók úgy már nem tekintik annak, ahogy manapság a PC-t, az Xbox One-t és a PS4-et egybeveszik, főleg azért, mert az új lehetőségekkel a programozásuk is nagyon hasonló lesz.
Ebből a szempontból vizsgálva már érthető bizonyos a kiadók álláspontja. Nem is mondom, hogy nincs benne logika, csak PC-s szinten ez akkor is egy rossz irány, és nem tesz jót a piacnak. -
Abu85
HÁZIGAZDA
válasz
mcwolf79
#4761
üzenetére
Értsd meg miről van szó. Amit Gbors felhozott az az, hogy van egy fejlesztő a fórumon, aki azt írta, hogy a kiadójuk kiszervezte az Intel és az NVIDIA optimalizálást. Ez mégis hogyan kedvezhetne bármiben a PC-nek? Ha most azt vizsgáljuk, hogy mennyire rossz a PC-nek az, hogy zárt middleware-ek jönnek az egyik oldalról, akkor azt is el lehet mondani, hogy semmivel sem jobb, ha ezeket middleware-eket kizárod, de közben a fejlesztéseket GCN-re korlátozod. Ezzel csak átesünk a ló túlsó oldalára. Valami kompromisszumos megoldás kellene, mert nem vagyok meggyőződve arról, hogy egy külsős stúdió a motor ismerete nélkül jó optimalizálást tud biztosítani az Intelnek és az NVIDIA-nak.
-
Abu85
HÁZIGAZDA
Ezek alapján ugyanezek az értékek vannak benne egy fél évvel korábbi bétában. Nem lett volna egyszerűbb a WHQL-ekből nem kivenni? Ez az ami szerintem totálisan felesleges a PC-s játékosoknak, hogy egy profilt fél évre kivegyenek, majd most egy bétában visszarakjanak. Csak pár bájttal nyomja meg a letöltést, és már az elmúlt 4-5 WHQL GTA5 ready lenne az NV-nél is.
Egyértelműen amellett vagyok, hogy drivert csupán egy olyan profilért, amely régóta kész van felesleges kiadni, és ez mindenkire vonatkozik. Régen az NV itt volt előnyben, hogy készen várták a játékokat, most meg csak a megjelenés napján lesz WHQL? Ezt egyértelműen rossz iránynak érzem. Rossz iránynak éreztem az AMD-nél is, amikor ezt csinálták csak nem Game Readynek hívták, hanem HotFixnek. -
Abu85
HÁZIGAZDA
Olvastam a bejegyzéseket, amiről beszélsz, és szerintem az az egyik legrosszabb véglet, ami a PC-vel történhet. Én megértem, hogy a kiadó spórolni akar és kiadják az optimalizálást külsős kezekbe, de így szerinted mennyi esélye van az Intel és az NVIDIA GPU-inak jó optimalizálást elérni? Oké a kiadó hozott egy olyan döntést, hogy mivel nem tudják jól megcsinálni ezért inkább nem is foglalkoznak az Intel és az NVIDIA GPU-ival, de az anyastúdió legalább ismeri a motort, még ha a hardvert nem is ismeri, míg a külsős stúdió se a motort se a hardvert nem ismeri. És gondolják, hogy a külsősök jobb munkát végeznek? Jó persze csodák vannak, csak logikusan átgondolva nem látom miért lenne ez lehetséges.
-
Abu85
HÁZIGAZDA
válasz
mcwolf79
#4746
üzenetére
Mégis mi él a PC-s játékiparból? Az MMO biztos, az indie biztos, de az AAA multiplatform címekben a PC hátrányos, és ez az egyes játékok eladási statisztikáján is látszik. Ha előnyös lenne a PC, akkor nem most kapnál GTA5-öt, hanem megkaptad volna, amikor kész lett az X1 és a PS4 verzióval párhuzamosan.
Amikor a cikkek elkezdik bizonygatni, hogy a PC-s AAA játékpiacnak nincs semmi baja, akkor az önmagunk becsapása. Elfogadjuk, hogy az a normális, ha szar portok születnek, és ehhez még rossz support is jár. És az önámítás erre a piacra ma a legnagyobb veszély.
-
Abu85
HÁZIGAZDA
November óta kész van a leképző. Lényegében semmit sem változott. Nehogy azt hidd, hogy a Rockstar azért tolta a játékot, mert technikai gondja volt. Nem, már szeptemberben kiadható állapotban volt a PC verzió, nem véletlenül mutogatta az AMD a szokásos IDF-elleni rendezvényén. Azóta csak bekerült a sztereó3D, pár effekt, amelyek egy része ki is került, meg a TXAA, ami az AMD-nek mindegy. Semmin nem kell változtatniuk, mert semmi nem módosult, ami a grafikát érinti.
Azért meglepődnék, ha volna olyan hardcore PC-s játékos, amely azt mondja, hogy csak azért, mert az az NV-nek jelenleg kedvezőbb, inkább jöjjenek magasabb gépigényű és rondább effektek a játékokba. Hiba azt hinni, hogy a PC-s réteg annyira meghülyült, hogy már az orruknál fogva lehet őket vezetni. Biztos van ilyen ember, de az tisztán látszik, hogy a fejlesztők nem hülyültek meg és az utóbbi egy évben annyi szidást kapott az NV, amennyit a korábbi tíz évben nem. Azért ezek az emberek érteken hozzá, és pontosan látják, hogy mennyire korlátozzák a munkájukat, ami miatt rosszabb minőségű játékokat tudnak letenni az asztalra. Ha valami nem a PC gaming érdeke, akkor az ez, és teljesen normális, hogy erről a jelenségről elkezdtek páran blogolni, reménykednek, hogy az NV még azelőtt észhez tér, mielőtt túl késő lenne.
-
Abu85
HÁZIGAZDA
De ez mindkét oldalon megvalósult/megvalósul. Ha csak ez a kritérium, akkor például ott a GTA5 profil az Omega Catalystben.
Nem kell szélsőségekben gondolkodni. Elég lenne annyi, ha az NV visszaálna arra a modellre, amit 2010 előtt alkalmaztak. Jó persze nyilván hazugságokat is követel, mert nem mondhatják majd ki, hogy a GameWorks azért szűnt meg mert csak lassú és ronda eljárások lehetségesek ilyen formában, de azért vannak ott a marketingesek, hogy kitalálják mit kell hazudni ilyen esetben.
-
Abu85
HÁZIGAZDA
A sűrű WHQL pont azt a célt szolgálta, hogy gyors legyen a reakció. Az mindegy, hogy minek nevezik Game Ready, Hotfix, marika csodája, a cél megegyezik. Na most ez vagy általánosan rossz, vagy általánosan jó, vagy tekinthetjük egy stratégiának, amit jónak tarthatunk vagy rossznak, természetesen magánvéleményként. Olyan viszont nincs, hogy ez akkor rossz, ha az egyik gyártó csinálja, de akkor már jó ha a másik.
Úgy jön ide, hogy a PC valódi problémája ez. Nem az, hogy az NV átvette az AMD régi driverfejlesztési stratégiáját, míg az AMD átvette az NV-ét.
-
Abu85
HÁZIGAZDA
válasz
Bingisz
#4728
üzenetére
Nézd meg a Valve véleményét a témáról. A GDC-n nagyon leteremtették a piacot azért, mert nem gondolnak arra, hogy a felhasználóbázisuk 90%-a nem hozzáértő. Még a felbontást sem tudja átállítani. Az, hogy a cégek elkezdték hozni az olyan segítő programokat, mint a Gaming Evolved, a GeForce Experience, vagy a Raptr Intel támogatással azt jelenti, hogy rájöttek, hogy ez egy komoly gond. Ha a userek 80-90% (és ez a cégek felmérése alapján a felhasználóikra vonatkozik) nem tudja beállítani magának a natív felbontást, és Full HD-s monitoron 1024x768-ban játszik, akkor az probléma. Nagy probléma, és ennek a megoldására pénzt fektetnek. Viszont a Valve szerint ez sem elég jó. A fejlesztőnek kellene ezt egyedileg megoldani egy játékba épített ellenőrzővel, és igazuk van.
-
Abu85
HÁZIGAZDA
A játék hibája nem feltétlenül jelenti azt, hogy új profil kell.
A Frostbite 3 speciális eset. Az nem úgy van profilozva, mint egy mai átlag játék. A motor hív meg egy beépített specifikus driverrutint. Ezt azért teszik, hogy akkor is működjön a motorhoz tervezett profil, ha átnevezed a játékot, mert ugye a driver biztosítja, illetve biztosítaná, hogy ne fagyjon szét a játék DX11-es módja. De mondjuk a Frostbite 3-nál én eleve egy hibás döntésnek tartom egy olyan optimalizálást használni, amit a Microsoft a DX11-hez nem ajánl, mert tudják, hogy nem stabil. Szerintem bődületes baromság ilyenhez nyúlni, de szerencsére ez egyedi eset, más motor nem működik így.A friss driver jó dolog. A felesleges driver a rossz. A legutóbbi 5 GeForce driverben benne lehetne a GTA5 profilja, és ennek az oka az, hogy a leképző november óta változatlan. Csupán két extra effekt került bele, de nem szükséges rájuk új profil, mert ismert eljárások, amikhez már jó kódot fordít az amúgy kigyúrt complier.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#4716
üzenetére
Azt ugye tudod, hogy ha ezért a PC-s játékosbázis 90%-a átáll, akkor a PC-nek lőttek. Ez nem olyan probléma, amit el lehet intézni azzal, hogy hát akkor neked a konzol való, mert az megöli a PC gaminget. Marad pár százezer fanatikus világszerte és kész. Itt olyan megoldást kell találni, ami elfogadható kompromisszum. Például a low-level irány az. Ott profilozás sem lesz, mert az alkalmazás dönt mindenről, amit ma még profilban állítgatni lehet. Ez már egy lépés a helyes irányba.
Én inkább nem szeretnék sok drivert telepíteni, ha nem muszáj. Rakják bele előre és működik. Vannak nekem olyan Catalyst drivereim, amelyek ki sem jöttek, és olyan játékok nevei vannak benne, amelyek még meg sem jelentek. Például hetek kérdése és bejelent valamit a Codemasters, és arra már a 15.4 early test kiadásban ott a végleges profil. Szerintem ez a jó irány, mert amikor megjelenik az a játék, aminek a nevét most nem írom le, de jön, akkor én vígan elvagyok az áprilisi frissítéssel, és kész. Miért is telepítenék csak egyetlen új profilért egy új drivert? Tök feleslegesnek érzem, és tiszta szopatás, hogy rég benne lehetne a csomagban a profil, de nincs, mert a nagyfejűek úgy tartják jónak, ha erről a média ír. Mint mondtam, jelentsék be azt, hogy már ott a profil x ideje, csak ne szopassák a PC-s réteget ezzel. Nem jó, ha ezért valaki konzolra megy.
-
Abu85
HÁZIGAZDA
Nem a világnak jobb, hanem a felhasználóknak. Te is arra panaszkodtál régen, hogy hiba sűrű drivert kiadni, és az NV ezt sokkal jobban csinálta hogy nem tett így. Szerintem is nagyon igazad volt abban, hogy jobb az, amikor előre benne vannak a profilok a driverben, amikor elkészülnek, nem aznap amikor kiadják a játékot, vagy havi rendszerességgel. Volt olyan, hogy egy hónapban háromszor jött Game Ready driver. Mégis minek? Azon a két-három napon múlott a profil elkészítése? Elég lenne előre belerakni a profilt a driverbe és kész. Mindenkinek egyszerűbb lenne. A PC-s piac egyik legnagyobb problémája, hogy ma már minden játékhoz új driver kell. Ismerőseim mind PC-s játékosok voltak, de ~70%-uk már konzolos, és az elsődleges indokuk, hogy a PC túl van bonyolítva, új driver, új ez, új az, ami szükséges, hogy elinduljon a játék. Konzolon berakod és működik. Nagyon fontos lenne, hogy a felhasználókat ezzel ne szopassák, mert mennek a konzolok felé.
De a driverkérdés csak döntés kérdése. Igazából csinálhatják ahogy akarják, ha működik, akkor oké, és igazából ez régóta működik mindkét oldalon. A nagyobb probléma a teljes széthúzás, amit a fejlesztők felé tanúsítanak. Tényleg lassú middleware-ekre van a PC-nek szüksége? Most komolyan, végre közelebb kerül a PC a konzolos fejlesztési modellhez, ami szebb és gyorsabb játékokat eredményezhet, erre most meg az effekteket zárják le. Te is pontosan tudod, hogy az általános middleware-ek a kompatibilitásra alapoznak, és ezért cserébe beáldozzák a minőséget és a sebességet. Tényleg ez a jövő? Jó az árnyékok és a post-process elmegy. Maximum lassú, de a minősége elfogadható szintű lehet, hiszen nem komplex effektek. Egy SSAO algoritmus is screen space. Viszont amint bonyolódik a helyzet jön a gond. Lásd a hajszimuláció. Nem sok embernek tetszik a HairWorks, pedig láthattad több programban is. Mi hiányzik belőle? A transparency eljárás, hogy ne legyen spagettiszerű. Miért nincs benne? Mert zárt a kód, és baromira nehéz, vagy nem is lehet általánosan transparency eljárást csinálni, ami minden leképzővel kompatibilis. Ha beleraknának egy elfogadható technikát, akkor csak bizonyos körülmények között működne az egész rendszer, vagyis nagyon sok motorba nem is lehetne implementálni a technikát. Ezek tipikusan gyengítik a PC-s ipart, ráadásul zéró értelme. Daveoff mint NV tulaj korábban mondta, hogy neki a TressFX jobban tetszik, de igazából ami tetszik neki, az nem a TressFX mint technika előnye, hanem a nyíltságé, hogy a kód módosítható, és aki bedobja a játékba, az tényleg leportolhatja a teljes eljárást. Ha nem kompatibilis az eredetileg szállított analitikai AA és az árnyékolási rendszer, akkor át kell írni és működik. A HairWorks esetében ilyen nincs. Ha valami nem kompatibilis, akkor kikapcs és minden egyes ilyen döntéssel folyamatosan minőséget veszít az effekt. Meggyőződésem, hogy ez nem az a jövő, ami a PC-nek jár, vagy amit egy hardcore PC-s játékos elvár.
-
Abu85
HÁZIGAZDA
válasz
Televan74
#4660
üzenetére
Amióta eldöntötték, hogy jön next-genre, ideértve a PC-t, azóta részt vesznek a fejlesztésében. Az új effektek közül, amik vannak konzolon és most már elmondhatom, hogy lesznek PC-n is, a tesszellációt, az HDAO-t, a DoF-ot az AMD adta a fejlesztőknek, amit a végén megfejeltek egy CHS-sel, ami egy gyors igény volt. Egyetlen dolog nem jön PC-re, az pedig a temporális szűrés, mivel az gépi kódban fut a konzolokon, és magasabb szintre nem portolták. PC-n ez az eljárás jelen formájában működésképtelen, elméletben viszont lehetséges, a DX12 kínál is majd rá egy alapot.
-
Abu85
HÁZIGAZDA
Ez főleg annak tükrében érdekes, hogy a PC-s fejlesztők most folyamatosan szidják az NVIDIA-t a GameWorks middleware-kért. Még az Ubisofttól Bartlomiej Wronski is odaszólt nekik az elmúlt évben, hogy a hardvereik tök jók, de a szoftveres részleg lábon lövi magát a GameWorks-szel. Arra törekszenek, hogy minél jobban elzárják a fejlesztők elől az optimalizálási és dizájnbeli döntési lehetőségeket, ami teljesen érthetetlen, hiszen régen pont ők képviselték azt, hogy a fejlesztőknek szabadság kell, mert csak akkor lesz jó minőségű a program, ha kevés middleware-t használnak.
A legjobb példa most a The Order: 1886. Látszatra azt hiszed, hogy PS4-es csodafícsőrökkel tarkított valami, de Matt Pettineo a GDC-n elárulta a "titkot", és ezt magyar fordításban idézném: "Ne használj kibaszott middleware-ket!". Nyilván egyébként PC-re nem lesz kiadva, mert a Sony-nak nem érdeke, de azt is elmondta, hogy elméleti akadálya nincs a portolásnak, és így nézne ki PC-n is.
Szerintem egy óriási probléma, hogy amikor végre történik valami a PC-n, akkor előkerülnek a mesterséges akadályok. Végre átnyomtuk az új API-kat (nem úgy ahogy azt az MS és a Khronos szerette volna, de ezen már kár siránkozni), a fejlesztők megkapták a lehetőséget, hogy a működést mélységekben profilozzák, és ehhez még hozzájönnek az új API-k új funkciói, de ez csak járulékos extra, most tekintsünk el tőle. Mi lett volna a hardvergyártók feladata? Dokumentálni a hardvereket és kiadni a belsőleg használt disassemblert. Egyszerű az egész, ezt régen, 2010 előtt amúgy is megtette lényegében mindenki. Erre most, amikor igazán szükség lenne rá, előjönnek az önös érdekek, hogy mivel lehetne a fejlesztő munkáját akadályozni. Ma nincs olyan fejlesztőstúdió, vagy szimplán motorprogramozó, aki szerint a nagyobb kontroll ne eredményezne jobb játékokat. És az, hogy látják a kód teljes működését lényegében óriási előny, mert eddig ez hiányzott. Erre előjön az NV, hogy nesze itt a GameWorks, ami zárt middleware-ek gyűjteménye, hogy még véletlenül se tudd optimalizálni a működését, és PC-n ne lehessen előhozni olyan minőségi grafikát, amivel a The Order: 1886 előállt. Megint sikerült kilopni a szenet a mozdonyból.
Egyébként aki kíváncsi a GTA5-re megnézheti. A játék azért nem jelent meg márciusban, mert a Rockstar beépítette az NVIDIA ShadowWorks middleware-t, és amikor megnézték a teljesítményét, akkor megdöbbenve látták, hogy a PS4-en alkalmazott technikáknál rondább és lassabb effekteket kaptak. Éppen ezért a PC-s AO helyére behozták a konzoloknál alkalmazott egyedi HDAO variánst, így a PC-s port ebből a szempontból olyan szép és gyors lesz, mint a konzolos (X1/PS4) verzió, míg az NVIDIA PCSS a szerződés értelmében bennmaradt, de az AMD-től elkérték a CHS-t, amit végül integráltak a mostani startig, hogy ugyanazokat az árnyékokat gyorsabban is kiszámolhassák a PC-k. Ez a baja a zárt middleware-eknek. Az így kapott effektek lassúak és sokszor rondák is, mert nincsenek jól beleintegrálva a motorba. Utóbbi szimplán lehetetlen, mert zártak, és ezért optimalizálhatatlanok is. -
Abu85
HÁZIGAZDA
Technikailag nem szükséges minden játékra új driver. Az NVIDIA csak átállt egy olyan modellre, hogy minden játékhoz új drivert kelljen telepíteni, annak érdekében, hogy ezzel marketingelni lehessen. Ezért van mostanában sokkal több driverük. De csinálhatnák úgy is, mint régen, hogy ritkán jön a driver, és előre belerakják a profilokat. Erre állt most rá az AMD. A GTA5 esetében lényegében nem kell új profil, magához a játékhoz már novemberben kész volt a szükséges profil, és mivel a leképzőn az elmúlt 5 hónapban nem változtattak a Rockstarék semmit, így ezek a profilok ma is jók. A különbség az, hogy ezt az NV a novemberi béta driverből kivette, hogy most bele tudják tenni ugyanazt egy Game Ready driverbe, míg az AMD ezzel nem foglalkozik, és az Omega driver óta szállítják, minden újabb driverben.
A felhasználó nézőpontjából is csak annyi a különbség, hogy GeForce-on telepíteni kell egy új drivert, míg Radeonon nem muszáj.
Régen egyébként pont ellentétesen csinálta az NV és az AMD. Az NV adott ki ritkán drivert és azokban mindent előre beépített, míg az AMD havonta nyomta az új Game Ready drivereket.
Ez nyilván a dolgok stratégiai része, de amit én nem értek, hogy mi értelme egy profilt visszatartani hónapokig, amikor novemberben ott volt egy driverben. Ott lehetett volna hagyni. Nem feltétlenül akarok én minden új játékhoz új drivert telepíteni. Szerintem ez rossz irány, és ez az amitől több PC-s játékos is menekül. Szoftverfrissítésre természetesen szükség van, de hogy minden nagyobb játék előtt? Rakják be amikor kész és azzal le van tudva a támogatás. Azzal is nagyon jól lehet marketingelni, hogy némá ott a profil 5 hónapja, és közben nem szopatod a felhasználóidat. -
Abu85
HÁZIGAZDA
Már az Omega driver tartalmazta a GTA5-re a profilt. A 15.3-as béta driverben is ugyanaz a profil van, és dev csatornán is az van odaírva mellé, hogy nincs szükség módosításra a végleges játéknál sem. Ettől függetlenül lesz áprilisban egy új driver, de nem a GTA5 miatt (hanem a Crossfire FreeSync támogatás miatt). Ennek a játéknak a profilja ugyanaz marad, mint ami az Omega driverben benne van.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#4507
üzenetére
Nem. Nagymértékben függ majd a teljesítmény a szoftvertől, egészen pontosan attól a kódtól, amit a fejlesztő bevisz. Ha az a kód nem jó, akkor azt driver ki nem javítja.
Elsődlegesen az kell, hogy a fejlesztőknek elárulják a gyártók, hogy mit tud az adott GPU. Ezért fejezi be a bemutatókat az MS és a Khronos úgy, hogy "disassembler és dokumentáció"! Ezek mostantól kellenek. -
Abu85
HÁZIGAZDA
válasz
daveoff
#4505
üzenetére
A DX12-ben nincsenek hagyományos értelemben vett driverek. Az alkalmazásban van benne az, ami ma még a driverben van. Ennyi. A driver marad egy shader fordító és nem több, de egy be nem jelentett újítás majd ezen is teker egy nagyot, és onnantól kezdve a gyártónak gyakorlatilag semmi beleszólása nem lesz, hogy melyik program hogyan fut a hardverén. Maximum odaülhetnek a stúdiók programozói mellé tippeket adni. Kb. ennyi marad a hatáskörük.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#4395
üzenetére
Ha a teszt csak szimplán tolná rá a parancsokat a hardverre és igazából a mérés csak az overheadre lenne korlátozva, akkor lényegében az azonos architektúrára épülő GPU-k eredményei megegyeznének.
Mivel a 3DMark tesztje ennél komplexebb teszt a procedurális tartalmakkal és a GPU-k erős terhelésével, így számít a GPU-k teljesítménye. -
Abu85
HÁZIGAZDA
A 3DMark API Overhead tesztje nem tipikus API Overhead teszt. Ezért vannak benne látszatra furcsa eredmények. Ami a teszt célja, hogy az API-nak a többletterhelését küldje az egekbe a sok generált paranccsal. A draw call itt nem csak a grafikai munkára vonatkozik, hanem a procedurális tartalomra is. A teszt a kirajzolandó tartalmat compute-tal generálja, ráadásul a generálás aszinkron. Tehát egyszerre beszélünk egy overhead tesztről, mert generálja a parancsokat, mint az állat, és egyszerre van szó egy stress testről is, mert aszinkron etet mindent a GPU-val, minden lehetséges parancslistán keresztül, illetve a procedurális tartalomgenerálás sincs ingyen, így a GPU-k teljesítménykülönbsége meglátszik.
-
Abu85
HÁZIGAZDA
Szerintem ezt a sample-t eleve nem hardveres összehasonlításra szánta. A jellegét tekintve nagyon szintetikus, tehát nem is igazán reprezentatív, mert egy valós programban sokkal több fényforrás lesz, és sokkal komplexebb a jelenet is. Itt azt akarja reprezentálni, hogy az Ola Olsson, Markus Billeter és Ulf Assarsson által kidolgozott koncepció működik, ahogy ő a gyakorlatba ültette. Persze ezt más is megtette már picit eltérő, de alapjaiban hasonló módon, viszont más csak diagramokat mutogatott. Emil Persson most mutatott egy gyakorlati példát, ami jól reprezentálja a hardvereken elérhető gyorsulási lehetőséget.
-
Abu85
HÁZIGAZDA
Az a szép ebben, hogy itt mindenre vonatkozik a gyorsulás. Persze valamennyire meghatározza az architektúra, hogy mennyi lesz az extra, de az biztos, hogy mindenen extra lesz. Ráadásul erősen két-háromjegyű százalékban.
Ezért írok sokszor ezekről a leképzőkről, mert egy csomó motor leragadt a klasszikus deferrednél, aminél ma már sokkal gyorsabbak vannak, és ugyanarra a minőségre képesek.
Ha megnézed a játékokat, akkor alig van olyan, amely mozaikos koncepciót használ. Klasztereset pedig nagyítóval kell keresni. -
Abu85
HÁZIGAZDA
Tudom, hogy nem gyártógyalázós dolog, de érdekes.
Emil Persson felrakott egy borzasztóan jó sample demót az oldalára. [link] - itt töltsétek le. Kérjetek fullscreent és natív felbontást, illetve max MSAA-t, ami 8x. Nézzétek meg mi történik az fps-sel, ha az F5 és az F7 billentyűvel a Clustered Forward (nem igen alkalmazzák még) és a Classic Deferred (eléggé elterjedt) leképző között váltogattok. Ennyit számít az algoritmus!
Jó szórakozást.
-
Abu85
HÁZIGAZDA
Kisebb felbontáson igen.
Az AotS brutál extrém terhelés. A sávszél nagyon kell neki, de nagyon díjazza azt is, ha az architektúra hatékonyan képes egymás mellett futtatni több compute pipeline-t. Manapság erről azért nincs semmi, mert nincs olyan játék, ami két pipeline-t egymás mellett futtat, erre most jön egy, ami 1 grafikai mellé 7-9 compute pipeline-t is odapakol. Ebben nyilván a GCN új verziója erősebb, mint a GCN2.
(#4299) players111: Májusban opció. De maga a hardver kész, csak az AMD nem akar külön rendezvényt tartani a hardvernek és a szoftvereknek. Nem csak új GPU jön, hanem egy új API is.
-
-
#4144
Abu85
HÁZIGAZDA
Malibutomi
#4142
Abu85
HÁZIGAZDA
válasz
Malibutomi
#4142
üzenetére
De nem ebből a diasorból. Hanem egy másikból. Egyébként maguk az adatok valósak csak nem grafikonon szerepelnek.
-
Abu85
HÁZIGAZDA
Ebben nem is kell hinni. Ez nem a végfelhasználóknak szól, hanem a fejlesztőknek.
Régóta látszik már a piacon, hogy az NV azokat a fejlesztőket gyűjti maga köré, akik azt szeretnék, ha vezetnék őket. Nincsenek különösebb igényeik, csak ki akarják valahogy használni az elérhető API-kat, és itt jön képbe az NV az effektjeivel. Az AMD ezzel szemben azokat gyűjti maga köré, akik diktálni akarnak, és azon gondolkodnak, hogy milyen elméleti kutatásokat lehetne a gyakorlatba önteni, függetlenül attól, hogy szabványos API-n megvalósítható-e. Ha nem, akkor kell hozzá egy felület és itt jön képbe az AMD a saját API-jával. -
Abu85
HÁZIGAZDA
A fejlesztők. Az AMD azért ül oda egy-két mérnökkel a világ top fejlesztői mellé, hogy első kézből, mindössze pár méterre tőlük hallják a bajokat, amire rekordsebességgel akarnak reagálni. Ezzel a fejlesztők meghatározhatják a fejlődést, és fel is gyorsíthatják, mert az MS és a Khronos elfogadja az igényeket, de két évig úgyis csak megbeszélés lesz róla. A Mantle azért marad zárt, mert nem akar az AMD megbeszélést a többi gyártóval. Ha valamire igény van, akkor beépítik, az igénylő használhatja, majd odaadják a speckókat az MS-nek és a Khronosnak, hogy építsék be a szabványos API-kba. Az AMD-től ők persze ülhetnek rajta évekig, de nem fognak, mert kényszerhelyzetben vannak, hogy van egy API, ami már támogatja, így lépni kell szabványos szinten is.
-
#4126
Abu85
HÁZIGAZDA
Malibutomi
#4124
Abu85
HÁZIGAZDA
válasz
Malibutomi
#4124
üzenetére
Valószínű, hogy nem teljesen helytálló az a kép. Csak azért, mert ma nem adható ki ilyen kártya tesztre. Emellett a gyártóknál is egy nagyon megbízható zárt körben érhető el. A nem megbízható körök először csak papírt vagy pdf-et kapnak, és csak utána hardvert.
Egyetlen adat van a Fijiről, mégpedig az Stardock vezérétől. Ő nem mondta ki a termék nevét, illetve a Fiji nevet sem, csak azt, hogy az új generációs Radeon a játékukban minden korábbi VGA-nál egyértelműen gyorsabb, ideértve a 295X2-t is. Bár náluk vélhetőleg felerősíti az előnyt az a tény, hogy a Nitrous új verziója rendkívül ki van éhezve a memória-sávszélre, így a többi VGA teljesítményét ez erősen limitálja. -
#4122
Abu85
HÁZIGAZDA
Malibutomi
#4119
Abu85
HÁZIGAZDA
válasz
Malibutomi
#4119
üzenetére
Nem a takarékosságon volt a hangsúly, hanem a hatékonyságon. Nem ugyanaz.
Van pár be nem jelentett dolog az AMD-nél. Februárban kb. tíz GPU-hoz kötődő projektet zártak le, amelyeket az év további részében beépítenek. Ezek között van pár, ami a dedikált GPU-kat közvetlenül érinti, és elég érdekes irányokat vet fel. Amit eddig tudni, hogy az AMD innentől kezdve nem vár majd az iparra, hanem berendezkedtek egy olyan szisztémára, ahol ők határozzák meg az irányt. Ez majd rengeteg exkluzív programfunkciót fog eredményezni a jövőben, mert számos fejlesztő is azon a véleményen van, hogy ha így hamarabb lesz DX13 vagy Vulkan 2, akkor támogatják az AMD koncepcióit, csak kényszerüljön fejlesztésre az MS és a Khronos. Ez egy igen furcsa váltás lesz a PC-s játékpiacon. -
Abu85
HÁZIGAZDA
válasz
mcwolf79
#4093
üzenetére
(#4092) TTomax: Mármint, hogy az AMD-nek jön jól, vagy az AMD adta az alapját? Igazából többször is elismerték az érintettek, hogy az AMD mutatta meg, hogy PC-ben is lehetséges ez a low-level modell, és erre épített a Microsoft is. Persze az MS mindig is a Win 10-hez tervezte.
Az meg, hogy az AMD-nek jön jól egészen nyilvánvaló, ők szenvednek a leginkább attól, hogy a hardverek nehezen használhatók a limitált API-k miatt. Mostantól ez megszűnik. Nem véletlen, hogy a GCN támogatja a legtöbb DX12 funkciót. -
#3518
Abu85
HÁZIGAZDA
Malibutomi
#3516
Abu85
HÁZIGAZDA
válasz
Malibutomi
#3516
üzenetére
Az 1.0-s Mantle átkerül a Vulkan API-ba. A Khronos nyitja meg.
Aki eddig fejlesztett Mantle-re, annak elérhető marad az SDK, mert nyilván nekik gáz lenne az átmenet, tehát a munkát befejezhetik.
Aki most akar Mantle-re 1.0-ra fejleszteni az ne tegye, mert a Vulkan lényegében ugyanaz. Ez tök logikus felhívás.
Csütörtökön lényegében egy puszilkodás lesz, hogy köszöni a Khronos a Mantle 1.0-t, amivel megmenekültek attól, hogy az MS ismét megalázza őket.
A Mantle jövőjéről májusban lehet majd hallani. Igen egyébként megy tovább, de egy teljesen új API formájában, ami nem lesz kompatibilis az aktuálissal. A Mantle arra szolgál majd, hogy ha egy fejlesztő valamit nem tud megcsinálni a szabványban, akkor nem kell az álmait eldobnia, hanem az AMD csinál kiterjesztést az álmaihoz. -
Abu85
HÁZIGAZDA
Attól még a probléma létezik. A gyártóknak egyénileg kell eldönteni, hogy ez a ghosting hiba belefér-e vagy sem. Az AMD ezzel úgy van, hogy döntsd el te: AFR friendly.
Az XDMA arra való, hogy a multi GPU akkor is működjön, ha a hidas megoldás már nem elég jó. 4K-ban a Crossfire XDMA azért ad sokkal jobb eredményeket, mint az SLI, mert híd sávszélessége kevés. 4K-val az NV már nem is használja. Helyette az adatokat először a rendszermemóriába másolják, majd onnan elérheti a másik GPU. Ennek az előnye, hogy nagyobb a sávszél mint a hídnál, de hátránya, hogy jóval nagyobb a késleltetése is, tehát nehéz a folyamatosságot biztosítani. Ez az oka annak, amiért a H azt írta, hogy 4K-tól a CF folyamatossága jobb.
-
Abu85
HÁZIGAZDA
(#3487) TTomax: Ez nem teljesen igaz. Azt is lehet egyébként tudni, hogy mi a gond. A Dunia Far Cry 4-hez használt iterációja Ka Chen adaptív virtuális textúrázását alkalmazza. Ennek az előnye, hogy igen nagy méretű terepet lehet feltextúrázni, de a hátránya, hogy a rendszer címzése adaptív. Ez AFR-rel egy olyan problémát eredményez, hogy a páros képkockákon bizonyos textúrák eltolódva jelennek meg, mint a páratlanokon. Ez egyfajta ghosting hatást generál, ami elmossa valamennyire a textúraminőséget. Ez csak mozgás közben látszik, mert egy képkockára levetítve a ghosting jelenség nem él. Lehet dönteni, hogy ezt elfogadod és engeded a multi GPU-t, vagy inkább nem, és akkor nem lesz ghosting sem.
A CoH 2-ben is működhet az AFR, csak zizegni fognak a textúrák.
-
Abu85
HÁZIGAZDA
Nem tudom kire gondolsz az OCUK-n. Én főleg Andrew Doddtól kapok erre vonatkozóan adatokat. Ő a driverfejlesztés vezetője. Elmondta, hogy ha az Ubisoft megoldja, hogy hibátlan lehessen az AFR, akkor bekapcsolják a támogatást. Addig csak az AFR friendly az opció erre, ami olyan minőség, mint az SLI. Ennél több ebben a programban még nincs. A nyárt sem véletlenül mondtam. Az Ubi akkorra ígérte, hogy megoldják az AFR-t. De ha mostani minőség elég, akkor ott AFR friendly opció és műxik.
-
Abu85
HÁZIGAZDA
Mert bugos az AFR támogatása a játéknak. Innentől kezdve vagy letiltja a gyártó az AFR-t, vagy bugokkal elfogadja. Egyébként azt ígérte az Ubi még januárban, hogy megoldják a gondokat, csak nem élvez prioritást a multi GPU. Valamikor nyárra talán lesz egy olyan frissítés, amivel bugok nélkül működni fog.
Egyébként az AFR-Friendly profillal bekapcsolhatod a CF-et is, csak ugyanazt az élményt kapod, mint az SLI-vel, ami nem jó.
Azt tudni kell, hogy az AMD akkor nem kapcsolja be AFR támogatást, ha bármilyen hiba van. Az NV akkor is bekapcsolja, ha akadni fog, vagy apró grafikai hibákat generál. A Far Cry 4-nél például a textúrák eltolódása. Ha hiba van, akkor döntsd el, hogy bekapcsolod-e vagy sem AFR-Friendly-vel. -
Abu85
HÁZIGAZDA
válasz
daveoff
#3478
üzenetére
A HBM miatt nem csak az AMD tervezi a hűtést. A Hynix, a Cooler Master és az Asetek is részt vesz benne. Ez az első bevetése egy nagyon új technikának, tehát másnak is nagyon tudni kell, hogy mi az, ami működik. Ez a kártya határozza meg azt is, hogy a Hynix a második generációs HBM-hez mit ajánl és mit nem.
-
Abu85
HÁZIGAZDA
válasz
proci985
#3472
üzenetére
Tulajdonképpen a 295X2 pontosan úgy működik, mint a 290X CrossFire, tehát abszolút mindegy, hogy melyiket választja. Nyilván a 295X2 előnye, hogy eleve egy baromi jó hűtéssel jön, de hátránya, hogy egy kártya, tehát egyben is lehet eladni. A 290X CrossFire pro/kontra dolog pedig fordított.
Az új szériából esélyes, hogy nem is lesz cserélhetű hűtés, mert a HBM nagyon bonyolítja a lehetőségeket. Sokkal jobb, ha marad a gyári, mert annál hatékonyabbat úgy sem fognak építeni a gyártók.
Az mindenképp előny egyébként, hogy az új GPU-k XDMA-sak. Ez majd a DX12-nél fontos lesz, mert XDMA nélkül le kell állítani a futószalagot az adatmásoláskor, míg XDMA-val erre nincs szükség, tehát a másolások mellett is számolhatnak a GPU-k.
-
Abu85
HÁZIGAZDA
Abból megy ki a kép a monitorra. Ma az alkalmazás a low-level API-val megmondja a drivernek, hogy hol a képkockapuffer, majd a driver a kijelzőszinkronhoz igazodva kiteszi a tartalmát. Viszont a belső szinkron mellett azt is meg kell mondani, hogy a képkockapuffer kész-e. Mert ugye itt most törött tartalom is kimegy.
Ezt eddig a driver láthatta, és aszerint szinkronizálhatott, de a low-level API-val már nem látja a meghajtó, tehát az alkalmazásnak kell megmondani, hogy kész a puffer és mehet. Ha nem teszi meg, akkor a driver nem fogja tudni eldönteni, hogy mikor teljes a puffer tartalma, tehát se a V-Sync, se az ilyen-olyan Sync nem fog működni. Nem jelentős probléma, csak pár sor, de bele kell írni az alkalmazásba. Aki támogat V-Sync, annak lényegében nincs igazán dolga más Sync-cel sem. -
Abu85
HÁZIGAZDA
Mert csak az alkalmazás tudja, hogy hol van a memórián belül a képkockapuffer. Erről a DirectX 12 alatt egy külső programnak, vagy akár drivernek fogalma sincs.
Minimális dolog, hogy a külső rutinok megtudják hol van a szükséges adat, és ezt csak a program tudja megmondani nekik. Ehhez kell majd SDK. A fejlesztők munkája nem lesz túl nagy, de meg kell mutatni milyen címtartományban van a képkockapuffer és azt mikor olvashatja a driver.(#3466) Taposo: Mert amikor ezek a technológiák bemutatkoztak még nem került előtérbe a low-level API. Enélkül természetesen általános lehet a támogatás.
-
Abu85
HÁZIGAZDA
Nem írtam, hogy nem lehet használni (és szerintem erre vonatkozóan nincs megkötés a partnerprogramokban), de az A-Sync és a G-Sync támogatásához direkt kód kell az alkalmazásba. Az A-Sync implementálásához szükséges alap ott lesz a DX12 SDK-ben. A G-Sync implementálása is lehetséges, de ahhoz egy külön csomag kell, amit az NV-től kell licencelnie a fejlesztőknek. Ha valamiért nem licencelik, akkor nyilvánvalóan képtelenek lesznek G-Sync támogatást írni az adott programba.
Olyan ez, mint a 3D Vision. Például a Square Enix nem licencelte, így csak több hónappal később épült be a támogatás a Deus Ex: HR-be, amikor az NV már ingyen odaadta nekik az SDK-t. Valószínűleg lesz olyan fejlesztő, aki a G-Sync-ért sem fog fizetni, hanem kierőszakolják az ingyenességet. -
Abu85
HÁZIGAZDA
válasz
daveoff
#3460
üzenetére
Mivel a DX12 egy low-level API, így a Crossfire és az SLI pont annyira lehetetlen, mint az AMD API-ján. A fejlesztőnek kell egyénileg megírnia a több GPU-s módot. A driverből kényszerített megoldások üzemképtelenek.
Minden low-level API, amely explicit memóriamenedzsmentet enged annyit jelent, hogy a grafikus driver az aktuális formában eltűnik. Amit ma be tudsz kapcsolni, mint az MSAA, post-process AA, anizo, akármiizé, V-Sync, A-Sync, G-Sync, adaptív akármiSync, meg még a jó ég tudja, mi van a driverben teljesen eltűnnek. Mindegyik funkcióra az alkalmazásba kell támogatást írni, direkten, minden architektúra minden verziójára, mindenféle különbséget figyelembe véve.
Ez az egész abból keletkezik, hogy eddig a driver látta mi van a memóriában. Mostantól csak az alkalmazás látja ezt. -
Abu85
HÁZIGAZDA
válasz
daveoff
#3455
üzenetére
Dehogy lőttek! Már milliószor írtam, hogy az AMD API-ja mögött egyetlen cég áll, vagyis sokkal gyorsabban fejlődik majd, mint a DirectX 12. Amellett persze, hogy már ma is többet tud. Azért fejleszt számos stúdió elsődlegesen az AMD API-jára, mert ha igényelnek valamit, ami az API-ban nincs benne, akkor azt akár saját maguk belerakhatják. A DirectX 12-nél a Microsoft dönt arról, hogy mi a jövő és nem a fejlesztő. Ez még mindig sokaknak nem tetszik. De a DirectX fejlődése is irányítható, ha van egy olyan API-d, ami kikényszeríti a változást a Microsofttól. Nem kell könyörögni nekik egy funkcióért. Belerakja az AMD a saját API-jába és a fejlesztők odadobják a pöttyös labdát az MS-nek, hogy mi erre megyünk. Követhettek minket, vagy lemaradhattok.
-
Abu85
HÁZIGAZDA
Ez az antiboostolás tök értelmetlen, mint problémaként feltüntetett jelenség. Meg kell érteni, hogy ma annyira széles spektrumú a terhelés, hogy egy alapórajel nem elég hozzá, mert akkor a legrosszabb lehetőséget kellene figyelembe venni. Ezért jöttek a DVFS technikák, amelyeknél elég az átlagos szintekre tervezni, és ha marad kraft, akkor mehet a boost, ha meg nem, akkor az alap alá megy az órajel.
Ti még nem láttátok, de az Oxide-nak lesz egy új demója. A GDC-n mutatják be, és ott nem egy mai kártya az alapórajeléből lead 200-300 MHz-et is, mert annyira túl van terhelve. De lefuttatja a programot, tehát működik a technika. Tuning mellett lehet, hogy probléma lesz, de alapkonfiguráción okés. -
Abu85
HÁZIGAZDA
A 128 bit nem annyira kritikus probléma. De eleve elfelejtjük, hogy a bitek helyett inkább a GB/s-ot kellene nézni. Biztos megszokás.
Egyébként nyilván a mai motorok nagyon sávszélkímélők, ami szerintem abszolút logikus fejlődés volt, mert pár éve világosan látszik, hogy a bandwidth nem igazán nő, miközben a TFLOPS igen. A nagy kérdés ott van, hogy az új motorok merre mennek. A leképzőknél nincs értelme kidobni az eddig elért eredményeket. Mindegy, hogy miért megyünk a klaszteres technikák felé, a lényeg, hogy gyorsak. A jövő technikái viszont érdekesek. A Nitrous 36 mintás temporális MSAA-ja azért nem sávszélbarát, tehát amit most nem használunk ki, annak az új lehetőségekkel nekieshetnek a fejlesztők. Az anizo cseréjére is vannak érdekes javaslatok, és azok kétpofára zabálják a sávszélt, miközben ALU-t alig terhelnek. -
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
A Computerbase tesztjében látszik egyébként az egész probléma: [link] - olyan mintha egy GPU-val is AFR-ed lenne frame pacing nélkül. És látszik, hogy a Radeon kihasználása alacsony, tehát sokkal egyenletesebb a frame-time. Az AFR támogatása itt most a legkisebb gond.
A gyártóknak is mérlegelni kell, hogy a folyamatosságra, vagy a nyers fps-re mennek. Ez így teljesen hibás. Mindenképp változtatni kell a motor paraméterezésén. -
Abu85
HÁZIGAZDA
Kell hozzá profil. Egyelőre ennek a játéknak más baja is van. Ha nő a GPU-k terhelése, akkor iszonyatosan rossz lesz a frame-time. Az AFR-rel ilyenkor nem éri meg foglalkozni, mert a legnagyobb gond, hogy 40%-os kihasználás felett egy GPU-val is 30 ms-os frame-time különbségek vannak nagyon sűrűn. De érdekes, hogy 30%-os kihasználással ez a gond eltűnik, csak úgy meg alacsonyabb a teljesítmény, de érzésre sokkal folyamatosabb. Itt a motort is tovább kell patch-elni, mert az úgy nem jó, hogy növeled a kihasználtságod, amivel nő az fps, de közben bejönnek a mikroakadások.
-
Abu85
HÁZIGAZDA
válasz
Anubris
#3168
üzenetére
A SEGA leányvállalata a CA. Még ha csak partnerek lennének, de nem, vállalati kapcsolat van köztük. De egyébként mindegy ki a bűnös a lényeg, hogy rossz irányba haladnak, és ez igen hamar megbosszulja magát, mert a stratégiai játékok műfaja erősödik. A Firaxis mellett elevickéltek, és a Stardock sem volt nagy versenytárs nulla kiadott játékkal 2014-ben, de mostantól sokkal többel készülnek, vagyis a kiéhezett játékosokra nem lehet számítani, mert egy-két stratégiai játék helyet mostantól kapnak fél tucatot, vagy többet.
Csak kezeljük megfelelően.
Ehhez a motorhoz komoly javítások kellenek.Ú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.
- ASUS RTX 5090 32GB GDDR7 ROG ASTRAL OC - Új, Bontatlan, 3 év garancia - Eladó!
- MSI GeForce RTX 3080 10Gb GAMING Z TRIO
- RTX 5000-ES SZÉRIA ÚJONNAN GARANCIÁLIS ELADÓ TERMÉKEK! 5050, 5060, 5070, 5080, 5090.
- 27% - GIGABYTE RTX 3080 Ti OC 12GB GDDR6X GAMING Videokártya! BeszámítOK
- PowerColor 9070 XT Hellhound Spectral White OC 16GB - Garancia 2028.05.28 - BESZÁMÍTÁS
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő