Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
TTomax
#14434
üzenetére
Nincsenek még. Igazából nem is AMD effektek lesznek benne, hanem GPUOpen effektek. Ezeket a Square Enix R&D csoportja a LABS fejleszti, akik csinálták a PureHairt. A mostani béta egy decemberi build.
A játék az elkövetkező hónapokban is fog fejlődni, ahogy jönnek hozzá a tartalmak. A megjelenésre kiadandó kód egy alap annak érdekében, hogy számos effektet hozzáadhassanak az év során. Ez az alap tartalmazza a normál DX11-es leképezőt és a DX12-nél a multiengine optimalizálást. A multiengine adja az effektek alapjait, mivel minden effekt, amit hozzáadnak compute, és szimplán párhuzamosan futhat a grafikus vezérlőn.
Az AMD azért promózza, mert a Glacier 2 továbbfejlesztése lesz a Square Enix multiengine implementációinak alapja. Ezt a koncepciót kapja meg az új Deus Ex is a Dawn motorban. Gyakorlatilag ez egy olyan implementáció lesz, ami megmutatja, hogy milyen, amikor a GPU nem sorosan, hanem párhuzamosan dolgozza fel a feladatokat. -
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Néha megnézem, de a játék része még nem igazán van kész. Az AI nagyon jó, de kiegyensúlyozatlan az egész. Nyilván ez az utolsó fázis, amikor a fajok képességeit kiegyensúlyozzák. Maga a játékélmény azonban Supreme Commander szintű hárommal felszorozva. Amint meg lesz oldva az egyensúly egy abszolút korszakalkotó RTS lesz belőle. Ha az egyensúly béna marad, akkor meg kell várni a következő hasonló megastratégiát, és az lesz a korszakalkotó.
Az biztató egyébként, hogy a Stardock adja ki. Ők az egyetlenek, akik önerőből fennmaradtak az RTS és a 4X stratégiák világában. A többiek sajnos teljesen lemorzsolódtak. -
Abu85
HÁZIGAZDA
A következő héten jön az Ashes of the Singularity frissítés, ami hozza a leképezőre vonatkozó újításokat és optimalizálásokat. Lesz benne multi-GPU keverhető formában, fejlesztett async compute és FreeSync. Az optimalizálások miatt egyébként némileg minden gyorsulni fog.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#14257
üzenetére
Alapvetően a Vulkan nem rossz. Sok szempontból kedvezőbb API a piac számára, mint a DX12. Nem annyira GCN centrikus a működése, mint a Microsoft API-jának, így a jobban átgondolt specifikáció miatt sokkal inkább illik a többi architektúrához is. Nem véletlen, hogy az NV ennyire tolja a Vulkánt. Nekik is jobb, ha egy DXKG nem kényszeríti a hardverüket lehetetlen szituációkba. Aztán persze lehet, hogy ez a fejlesztők jó részét nem fogja érdekelni, de szerintem ez mindenképpen az előnye.
Ha a fejlesztőnek nem elengedhetetlenül fontos a DX12 fejlettebb bekötési modellje, akkor mindenképp a Vulkan API-ra érdemes dolgozni. -
Abu85
HÁZIGAZDA
válasz
solfilo
#14256
üzenetére
Igen. A fő tényező az, hogy eltűnt a kernel driver. A gyártók ilyet már nem írhatnak, mert abban az az alapkoncepció, amit az AMD kidolgozott 2010 környékén arra épül, hogy egyszerűen kivágja a rendszerből a kernel oldalo grafikus drivert. A Microsoft ezt annyiban vizsgálta felül, hogy rakott be egy DXKG-t, ami bizonyos feladatokat ellát, de ez univerzális lett mindenkinek. A Vulkan viszont nem tartalmaz hasonlót. Összességében tehát a gyártók zéró kernel oldali kódot tudnak biztosítani ezekhez az API-khoz. Viszont a hardver vezérlése kell a programfuttatáshoz, így ezeket a kódokat a motorba kell mostantól rakni. Emiatt a fejlesztőknek részletesen dokumentálni kell az architektúrát, hogy legalább olyan hatékony kódot írjanak, amire a gyártók képesek voltak a kernel driverben.
-
#14255
Abu85
HÁZIGAZDA
huskydog17
#14251
Abu85
HÁZIGAZDA
válasz
huskydog17
#14251
üzenetére
Az explicit API-val a dokumentáció lesz a kulcs. Nem számít, hogy ki milyen drivert ír, mert az alkalmazás fogja menedzselni a GPU vezérlését. Az számít, hogy ki mennyi információt oszt meg a fejlesztőkkel a hardverről, hogy a fejlesztő tudjon legalább olyan hatékony menedzsmentet írni a motorba, amilyet a gyártó tudott a driverbe.
(#14253) solfilo: Egyszerű a válasz. Ha az NV ledokumentálja a hardvereit, akkor a fejlesztő is tud velük dolgozni, tehát visszaszerezhetik az előnyt. Ha nem dokumentálják le, mert üzletileg ez nem olyan előnyös, akkor gyorsabb hardvert kell csinálniuk, hogy az AMD dokumentációból származó előnyét ellensúlyozzák.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#14226
üzenetére
Ez nem attól függ. A legfőbb tényező a konzoloknál a felhasználóbázis. Minél nagyobb ez a szám annál célszerűbb egy konzolt sokáig piacon tartani, mert a fejlesztők számára ez egy fontos szempont lesz. A PS2 is ezért maradt nagyon sokáig piacon. Egyszerűen a fejlesztők számára baromira fontos tényező volt, hogy rengetegen vették. A PS4 is hasonló helyzetben lehet azzal, hogy az eladásai egységes időintervallumra levetítve jobbak a PS2-nél. Nyilván a fejlesztők is fasza dolognak fogják tartani az esetleges új generációt, de mire jön, addigra minimum 70 milliós PS4 bázis épül ki. Hülye az aki nem készít nekik játékot.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#14223
üzenetére
Senki sem állította, hogy nem lehet megcsinálni, csak kell hozzá kiadás után egy extra év, hogy amit nem tudsz normálisan optimalizálni az effekt átírásával, azt optimalizáld a leképező átdolgozásával. Házat is lehet úgy építeni, hogy előbb a tetőt húzod fel, csak marhára nem célszerű, mert sokkal nehezebb lesz a munkád. De ha megfizetsz egy építészt, és időt adsz neki, akkor megcsinálja.
Tényleg nem akarok azzal jönni, hogy ugyanezt konkrétan nem csak az AMD és az Intel, hanem az NVIDIA is elmondta, de elmondták az AndroidWorks esetében. Ott a GPUOpen-hez és az Intel névtelen rendszeréhez hasonló a konstrukció.
-
Abu85
HÁZIGAZDA
válasz
imi123
#14220
üzenetére
A konzolnál a teljesítmény nem elsődleges tényező. Van a piacon rengeteg konzol. Ránézel a listára és látod, hogy: Microsoft Xbox One, Sony PlayStation 4, NVIDIA Shield, Google Nexus Player, Amazon Fire TV, Tencent miniStation, Razer Forge TV, ésatöbbi. Napestig sorolhatnánk. Ezek egy nagy piacot fednek le, mert baromira nagy az igény az otthoni nappaliban a multimédiás mindenesekre. A Nintendo ide pályázik, és olyan géppel állnak majd elő, amellyel ezt a kategóriát a legjobban le lehet fedni. Mindenki ilyen gépet csinál ... persze aztán vagy bejön, vagy nem.
-
Abu85
HÁZIGAZDA
válasz
imi123
#14205
üzenetére
Mivel a multiplatform eleve kizárja, hogy a célplatformok közül bármelyiknek kihasználja az erejét, ugyanis a több konfiguráció miatt lehetetlen célirányosan optimalizálni. Ez régen is így volt, és a jövőben is így lesz. Minden nem skálázható tényezőt a leggyengébb láncszemre tervezik a stúdiók. Ez sajnos kompromisszumokkal jár.
A platformok előnyeit csak platform exkluzív programokkal lehet kimutatni, mert ekkor egy másik platform limitációit nem kell figyelembe venni a tervezésnél. -
Abu85
HÁZIGAZDA
válasz
nonsen5e
#14203
üzenetére
Alapvetően ugyanaz a motor. Azt tudni kell, hogy a mostani Hitman esetében a PC verzió volt a fókuszban, mivel az AMD a játékot elég sok pénzzel támogatta. A konzolverziókat is megcsinálják, mert ott is jó, ha van eladás, de ezek a PC-s verzió után fognak frissülni. A mai kód tekintetében a Hitman még nem low-level egyik konzolon sem. A régi Glacier 2 struktúrán fut. Az új struktúra a PC-hez készül, és az lesz átemelve a konzolokra is. Xbox One-ra a DX12, míg PlayStation 4-re a Vulkan (tudom spoiler, de mindegy már
![;]](//cdn.rios.hu/dl/s/v1.gif)
). A PC jelenleg úgy néz ki, hogy csak DX12 opciót kap a DX11 mellé. -
Abu85
HÁZIGAZDA
válasz
mlinus
#14201
üzenetére
A PC alapvetően egy átalakuláson megy keresztül. A Microsoft nézetei ezzel kapcsolatban abszolút érthetők, mivel gyakorlatilag írtak egy olyan API-t, ami megtalálható Xbox One-on és PC-n is. Ráadásul alig kell módosítás a kódba. Az előző generációnál a DirectX 11 sokkal jobban különbözött a DirectX 9.L-től, illetve a libGCM-től. Emiatt egy PC-s port sokkal több munkát igényelt.
Mint írtam ez egy befektetési probléma. Van egy határ, ahol már olyan befektetést igényel a PC-s port, hogy nem éri meg. Manapság ez a határ nem lett nagyobb, viszont a portolás olcsóbb lett, tehát realizálható belőle haszon.A Hitman bétaverzió. A Sony egy béta miatt nem fog idő előtti firmware frissítést tartani, így a fejlesztőknek kell az optimalizálásokat kikapcsolni.
-
Abu85
HÁZIGAZDA
válasz
imi123
#14199
üzenetére
Sajnos az Xbox 360 sosem jutott el harmadik fázisba, vagyis sosem érkezte rá olyan játékok, amelyek normálisan kihasználták a konzolt. Ez szimplán azzal volt magyarázható, hogy a Microsoft a fejlesztőeszközökbe egy idő után nem ölt annyi pénzt. Ezért hagyta le a generáció végére a PS3 az Xbox 360-at. Amúgy tudta volna a lépést tartani, de a libGCM túl nagy dobás volt a Sony-tól, amire az MS-nek sosem volt válasza. Ez látható a The Last of Us-on. Az volt a PS3 csúcsa. Még volt benne tartalék, de az már aránytalanul nagy költség lett volna. Van az a pont, amikor kedvezőbb a generációváltás a fejlesztőknek is. Az összehasonlítást úgy érdemes felfogni, hogy az Uncharted 4-gyel ott fog tartani a PS4 technológiailag, ahol az első Uncharteddel tartott a PS3.
-
Abu85
HÁZIGAZDA
válasz
imi123
#14197
üzenetére
Áh még eléggé az elején járunk. Nagyjából ilyen sebességgel használták ki az előző generációt is, sőt lassabban. A PS4-et csupán a rendkívül magas eladásuk miatt simán megéri még 6-7 évig a piacon tartani, addig rengeteg szoftvert lehet hozzá hozni.
A piacok problémája sosem a hardver, hanem a termék eladhatósága. Azért megy sok kiadó a mobilra vagy konzolra, mert ott adható el a játék normális haszonnal. Ez mindig egy befektetési kérdés. A helyzet az, hogy a PC-re vonatkozó befektetés rendelkezik a legnagyobb kockázatokkal, míg a mobil a legkisebbel.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#14191
üzenetére
Ez nem elmélet, ez a keserű gyakorlat. Még az NVIDIA is elmondta az elmúlt évben az AndroidWorks bejelentésénél, hogy azért tették nyílt forráskódúvá az effekteket, mert másképp nem lehetne optimalizálni a játékokat. Az epices srác, aki mellette az UE4 bemutatót tartotta pont a kedvelt házépítős példával állt elő a zárt middleware problémájára. Természetesen lehet úgy építeni a házat, hogy előbb a tetőt húzod fel, de magad szívatod vele, mert akkor meg van kötve, hogy milyen alapot és házat csinálsz alá. Ráadásul ilyen formában az építkezés sokkal nehezebb. Ezért sokkal célszerűbb az effekteket átírni. Erre az AndroidWorks abszolút lehetőséget ad az NV-nél is, és pont az optimalizálhatósággal hirdetik. Ez ugyanaz a cég, aki a GameWorksöt kínálja ... érted már?
-
Abu85
HÁZIGAZDA
válasz
daveoff
#14189
üzenetére
Azt csúnya lenne azt mondani, hogy elég jól helyrerakta. Elégtelenről talán elégséges szintre vitte fel.
Az a baj, hogy nem tudták kiadni így. A GameWorks DRM-je és az effektek belső felépítése folyamatosan változik, tehát amíg az eredeti verzióra esetleg jó a motor, addig az új verzióra már lehet rossz. A szerződés kötelezi őket arra a verzióra, amit az NV ad. Ahhoz létrehozzák a szükséges RT/erőforrásokat és kiadják. Az ok, amiért ennyit gyorsultak az az, hogy tudták mire van szüksége annak a GameWorks verziónak, amit használnak, és egy év alatt rá tudták szabni a leképezőt. Viszont ez csak ilyen formában működik, mert az első megjelenésnél nagyjából egy héttel a gold kód előtt látják a GameWorksöt. Egy hét alatt nem lehet elvégezni egy évnyi munkát. -
Abu85
HÁZIGAZDA
válasz
daveoff
#14187
üzenetére
Az optimalizálás. A probléma a zárt middleware-rel, hogy nem lehet magába az effektbe beleírni, hogy például olyan RT, vagy erőforrást használjon, amit a leképező már létrehozott valamire. Az effekteknek saját igényeik vannak, amelyeket biztosítani kell a leképezőből, és ez pár effekt után már rendkívül pazarló lesz, mert létrehozol különböző erőforrásokat csak a működéséért, és ezek akkor is ott lesznek, amikor inaktív az effekt. Viszont, ha van extra egy éved, akkor át lehet dolgozni a leképezőt, így megpróbálhatsz pár korábbi RT és erőforrást törölni, és valahogy átütemezni ezeket a GameWorks által igényelt erőforrásokra. Ezzel viszont az a baj, hogy nagyon sok időbe kerül. Ezért sokkal kézenfekvőbb átírni magát az effektet, hogy a motor által eleve létrehozott erőforrásokat használja.
-
Abu85
HÁZIGAZDA
válasz
#45185024
#14171
üzenetére
A Quantum még mindig elérhető a tervek tekintetében, de csak úgy éri meg a gyártóknak, ha 20000 dollárért adják. Van pár cég, akit érdekel az egész, de csak olcsóbban. Például Falcon Northwest csinál VR-re épített minigépet, amin egyébként az egész CES-en és a VRLA-n mentek a VR demók. Ez a Tiki lesz. Nem néz ki ugyanúgy, mint a Quantum, de ugyanaz van benne, és pici ez a gép is. Ennek az ára 10000 dollár, vagyis feleannyi, amennyiből a Quantum kihozható.
A WDDM 2.0 csak IOMMU módban tud memória-összevonást. Ezt a módot dedikált GPU nem támogathatja. A GPUMMU mód csak törlési lehetőséget biztosít, anélkül, hogy akadna tőle a program.
-
Abu85
HÁZIGAZDA
Amikor bejelentették az early access programot, akkor a Stardock felvázolta, hogy lesz egy alpha, ami az alap lesz. A beta 1 lesz az, amikor bekerül pár új játékelem. Új faj, matchmaking, stb. Itt lesz kialakítva a játék alapja. Nagyjából itt tartunk most, ezen belül is az új fajnál. Ezután a beta 2 az, amikor frissítik a leképezőt. Ez már megkapja majdnem az összes effektet, illetve az optimalizálást, ami ma teljesen inaktív. Valamint lesz multi-GPU támogatás ... asszimetrikus és cross-vendor. Ilyenkor lesz stabil maga a játék is. A beta 3 amikor már a technikai oldallal nem törődnek, így ott már a kiegyensúlyozáson lesz a fő hangsúly, és kipróbálásra kerül a térképszerkesztő. Végül jön a release build.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14084
üzenetére
Biztos csak elhanyagolták. Tuti nagyon büszkék erre a portra.
A helyzet az, hogy a projekt oldalon minden portjuk ott van, csak a PC-s RotTR hiányzik.
Természetesen felelősek, de attól még nem muszáj kirakniuk. Nem hiszem, hogy büszkék rá, és így inkább be sem sorolják. Nekik ez rontaná az imázsukat.
-
Abu85
HÁZIGAZDA
válasz
Valdez
#14080
üzenetére
A Nixxes számára az Xbox 360-ról való portolás volt az egyszerűbb, mert arra vannak eszközeik, és eleve ők csinálták az Xbox 360 verziót, tehát ismerik is. Az Xbox One port a Crytal Dynamics számára lett volna egyszerűbb. A Nixxesnek arra nem voltak eszközei, illetve nem is hiszem, hogy ők azzal a kóddal közelebbi viszonyba kerültek volna a játék fejlesztése alatt.
(#14082) Balazs_: Biztosan nem. Párhuzamos projekteknél a csapat fel van osztva. Maximum egy-két ember esett ki az új Tomb Raider miatt.
(#14079) Szaby59: [link] - itt keresd meg.
-
Abu85
HÁZIGAZDA
válasz
imi123
#14073
üzenetére
A Nixxes esetében ez teljesen érthető. Nekik a 2016-ra az új Hitman és az új Deus Ex a fő projekt. Ezek DX12-vel jönnek. Viszont hirtelen felvenni egy harmadik projektet nem túl könnyű, főleg ha nincs elég embered rá. Korábban is írtam, hogy mindenkinek van egy minimális alvásigénye, és akkor sem tudnak többet dolgozni, ha a kiadó nagyon erőlteti. Ennek az áldozata lett a Rise of the Tomb Raider. Nyilván nem a Nixxes felejtett el portolni, egyszerűen csak a körülmények nem voltak megfelelők egy minőségi PC-s portra. A Nixxes a PC-s RotTR portot nem is jegyzi a projektjei között.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#14066
üzenetére
Minden új driver tartalmaz hibajavítást. Ez teljesen általános. A Hotfix mindkét cégnél egy olyan jelző, amely arra vonatkozóik, hogy az adott driver alapja WHQL volt, és azt módosították. A Hotfix emiatt azt jelenti, hogy bizonyos modulok még tartalmazhatnak WHQL aláírást, mert nem biztos, hogy módosultak.
A névvel ellentétben a Hotfix-en belül a fixnek semmi köze ahhoz, hogy ez valami javítás lenne, mert minden meghajtó azért jön, hogy valamit javítson. -
Abu85
HÁZIGAZDA
válasz
#85552128
#14057
üzenetére
Nincs szükség rá. Csak toljuk magunk előtt azokat a problémákat, amelytől a PC döglődik. Eközben simán portolható az Xbox One-ról az alkalmazás, mert ott a Windows 10-en a WDDM 2.0.
Orbitális baromság, hogy neked kell egy 300K-s VGA ereje. Ehhez a grafikai színvonalhoz nem kell. Viszont baromira jó üzlet lehúzni a júzert egy rakás pénzzel, és működik, mert ha most elolvasod a saját hsz-ed, akkor fel sem merül benned, hogy ez a program sokkal kisebb erőforrásigénnyel is működőképes lenne, ha nem Xbox 360-ról portoltál volna. Mivel alapvetően a gondolkodni nem tudó felhasználók generációjába csöppenünk bele, egyre több ilyen mesterséges vásárláskényszerítés lesz bevetve. És ez mindaddig működni fog, amíg te vagy más nem teszi fel azt a kérdést, hogy miért kell ennek ennyire drága hardver. -
Abu85
HÁZIGAZDA
válasz
#85552128
#14055
üzenetére
Gyerekek mikor értitek már meg, hogy ha a konzolon a memóriaigény a PC-s tizede, akkor nem a PC-s hardverekkel van baj. A memóriakapacitás hajkurászása egy szoftveres probléma eredménye. Kurvára nincs szükséged 8 GB-os VRAM-ra a mai grafikai színvonalhoz. Amiért rárakják a kártyákra az az, hogy a fejlesztő a WDDM 1.x alatt képtelenek törölni egy rég nem használt allokációt úgy, hogy közben a program ne akadjon be. A helyzet az, hogy ha megnézik a gyártók a memória hozzáféréseket, akkor a betöltött adat 90%-a csak ott van, de jó eséllyel hozzáférés egy jelenet elhagyásával nem történik feléjük. Ami baj, hogy még mindig ehhez a 18 éve létrehozott modellhez igazodik a szoftver. 18 éve ez jó volt, de ma nem az, ma már a hardver sem így működik a driver alatt.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14053
üzenetére
Mert rossz a textúra streaming. Az Xbox One verzió memóriahasználata a high textúrákra fél gigabájt alatti, heted akkora, mint a PC-n. Ez szimplán egy programozással kapcsolatos probléma. Az Xbox 360 verzió streamingje van PC-be átmentve, és az marhára nem hatékony. Az Xbox One verziót kellett volna PC-re portolni nem az Xbox 360-ast. De erről most nem igazán tehet senki. Az Nixxes baromira leterhelt már így is. Három játékot párhuzamosan portolni egy kis létszámú csoport nem tud. Tartani kellett volna az eredeti tervez, vagyis azt, hogy a Crytal Dynamics elintézi a PC-s portot is.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14051
üzenetére
Nem a memóriától függ a shader, hanem attól, hogy milyen a vektor load/store. Valójában egyik mai VGA-nak sem jó a Rise of the Tomb Raider által használt 16 bájtos elérés. Ez az Xbox 360-nak és a 64 bites busszal rendelkező kártyáknak ideális. Minden VGA, amely nagyobb memóriabuszt használ alternatív shadert igényel. Minél nagyobb a memóriabusz szélessége, annál nagyobb gond a 16 bájtos elérés.
Arra ezért kevesen gondolhattak az AMD-nél és gyakorlatilag másnál, hogy 2016-ban egy PC port az Xbox 360 verzióból készül, miközben van Xbox One változat. -
Abu85
HÁZIGAZDA
válasz
#85552128
#14048
üzenetére
Mond meg nekik, hogy teszteljék újra a 16.1.1-gyel, mert az már lecserélte a problémás shadereket.
Egyébként nem tudom, hogy mit nem lehet ezen érteni. A WDDM 1.x alatt a VRAM kihasználása rendkívül rossz hatásfokú. A kernel driver felel a menedzsmentért. Az AMD nagyjából másfél éve kutatja azt, hogy miképpen lehetne a WDDM-et megkerülve törölni a memóriából az "ezer éve" nem használt allokációkat. Az első erre vonatkozó implementációt az Omega driver tartalmazta. Azóta ez sokat fejlődött, így ugyanannyi memóriával sokkal takarékosabban bánik az AMD. Ebben az is benne van, hogy az NV a Crossbar miatt meg pont az ellentétét csinálja ennek, vagyis ugyanazt az adatot több helyre is elhelyezi. Ez felfogásbeli különbség, de a WDDM 2.0-val nem lesz jelentősége.
-
Abu85
HÁZIGAZDA
válasz
solfilo
#14040
üzenetére
Ez azért van, mert az AMD meghajtója takarékosabban bánik a videomemóriával. WDDM felhatalmazás nélkül töröl sokszor, ami nem szabályos művelet, de az AMD másfél éve dolgozik a szabályok megkerülésén, aminek ez az eredménye. A GeForce driver inkább pazarló menedzsmentet alkalmaz, vagyis ugyanazt az adatot egyszerre többször is elhelyezi a memóriába. Ez felfogásbeli különbség. Az NV is megtehetné azt, hogy ráállít egy technikai csoportot arra, hogy találják ki miképpen lehetne takarékosabban bánni a VRAM-mal, de különösebben nem érdekli őket ez a lehetőség. Inkább kínálnak hardvereket több VRAM-mal.
-
#14038
Abu85
HÁZIGAZDA
#Morcosmedve
#14027
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#14027
üzenetére
Pedig inkább a 960 és a 380 között gondolkodj. Lehet, hogy nem tetszik a 128 bit, vagy a kevés shader, ésatöbbi, de valójában nem ez számít. Sokkal többet ér, hogy az NV a Maxwellel még törődik, és emiatt a 680-nál simán jobb a 960 is az agyonherélés ellenére is. Sőt, a különbség idővel nőni fog a 960 javára.
-
#14023
Abu85
HÁZIGAZDA
FragMaster
#14021
Abu85
HÁZIGAZDA
válasz
FragMaster
#14021
üzenetére
Igazából a GTX 680-nál legalább 10-20%-kal gyorsabb a 380 vagy egy 960 az újabb játékokban. A GFLOPS-ok és a GB/s-ok akkor számítanak, ha a meghajtó is engedi ezek elérését. Manapság sajnos nincs rá különösebb indoka az NV-nek, hogy Kepler optimalizált fordítót és shadereket rakjon a driverbe. Emiatt hiába van sok GFLOPS és GB/s a hardverben, azok jó része nem elérhető, mert a Maxwell nem igényel olyan specifikus optimalizálást, mint a Kepler. Simán lehetne olyan drivert írni, amely megdobja a GTX 680 teljesítményét az újabb játékokban úgy 10-15%-kal, csak az NV-nek ez már nem érdeke.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#14019
üzenetére
Az Antigua lapka csak azon van rajta, meg a 380X-en de ott több shaderrel. Az Antigua egyébként egy új Tonga stepping.
Az a kérdés, hogy miért merül fel egyáltalán a Kepler, amikor egy éve nem frissítették hozzá a shader fordítót. Nem rossz az architektúra, de ha nincsenek hozzá optimalizálások, akkor túl nagy lesz a regiszterallokáció, és ez baj egy regiszterszegény dizájnnál. Hiába lehetne hatékonyabb a shader fordítás rá, ha nem kapja meg az ehhez szükséges fordítóoptimalizálásokat. Ráadásul a shaderek is csak a Maxwellre vannak már kicserélve a játékokba. A Kepler ezeket a Maxwellre szabott shadereket futtatja. -
Abu85
HÁZIGAZDA
Friss DX12 lista redmondból:
Ark: Survival Evolved
Arma 3
Ashes of the Singularity
Caffeine
DayZ
Descent: Underground
Deus Ex: Mankind Divided
F1 2015
Fable Legends
Gears of War: Ultimate Edition
Hitman
Just Cause 3
King of Wushu
Squad
Star Citizen
Survarium
The Elder Scrolls Online
The Isle
Umbra
Warhammer: End Times Vermintide
W.N.C: Infantry
...many more TBA -
Abu85
HÁZIGAZDA
válasz
#85552128
#13979
üzenetére
Akkor szarna be a PC-s világ, ha tudná, hogy Xbox One-on high textúrákkal a memóriahasználat 400 MB. Szerencsére nem tudják, így nem fogják fel, hogy mekkora pazarlás az a streaming modell, amit a PC használ. Bár ha Repi tényleg beváltja, hogy idén már csak WDDM 2.0-ra dolgozik, akkor lehet, hogy leesik a tantusz sokaknál.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#13816
üzenetére
Amely stúdió egyébként egyáltalán nem béna, és ők csak segítették a portolast. De amúgy mindegy, hogy ki csinálja. Megjön a middleware csomag, azt be kell fordítani, és tesztelés utan le kell tiltani a nem kompatibilis optimalizálást, illetve létre kell hozni az effektekhez szükséges puffereket. Akárki csinálja ezt, ugyanarra kényszerül. Gondolom a fejlesztők az átlagnál magasabb logikai készség miatt nem hisznek az olyan technikákban, mint a ráolvasás, vagy az ima a gyorsabb kódért, más alternatíva pedig nincs a licenc megszegése nélkül.
-
Abu85
HÁZIGAZDA
válasz
schwartz
#13812
üzenetére
Tehát egy zárt middleware-kkel teletömött játék nem ment day-1. Hát ez sokkoló.
A viccet félretéve nyilván az NV-nek nem kevésbbé kellemetlen, hogy egy támogatott játék rosszul fut, de mit tudnának csinálni? Ha egyszer megengedik, hogy a fejlesztő módosítsa a kódokat, akkor onnantól mindenki azt fogja kérni.
Azért az nem volt véletlen, hogy az NV 8 éve még a dokumentálás és a nyílt fejlesztés élharcosa volt. Így lehet eredményeket elérni. Csak a mai világban többet ér a hype, mint a minőség, és egy cégnek ez egy mérlegelendő tényező. Lehet érte haragudni rájuk, de pont leszarják. -
Abu85
HÁZIGAZDA
Ezt a TressF X3.0-PureHair dolgot fontos lenne megérteni, mielőtt megint farkast kiáltunk. A lényeg a TressFX 3.0 esetében, hogy az külsőleg egy middleware, tehát teljesen nyílt, így bele lehet túrni, de akkor is egy middleware. Ez annyival jobb, mint a zárt middleware, hogy egyénileg optimalizálható, így nem kell a működőséhez esetleg letiltani a leképező optimalizációit. Viszont az AMD TressFX 3.0-s kutatásaiban az Eidos Montreal, a Crystal Dynamics és a LABS részt vállalat és ők tisztában voltak végig, hogy mi változik. Ezért megcsinálták azt, hogy a TressFX 3.0-t a következő generációs játékoknál már nem nyílt middleware-ként, hanem mélyen a motorba integrálva fogják használni. Ez a PureHair.
Az ilyen felfogásnak nagyon sok előnye van. Ezeket az előnyöket ma még csak a Frostbite-nál láthatjuk a PC-piacon, de az vitathatatlan, hogy mindent mélyen integrálva sokkal jobb minőség és sebesség hozható ki, mert az egész rendszer egymáshoz van tervezve. Nem fogsz csak egy effekt miatt külön RT-ket létrehozni, mert az brutális pazarlás. Nyilván ez viszonylagos kérdés. Például egy Fallout 4-es Creation alap annyira le van maradva technológiailag, hogy nem különösebben számít, hogy hat RT-t használ, amelyből hármat csak egy middleware effekt visz el, és ha az ki van kapcsolva, akkor is ki lesz számolva az a hat RT, de akkor csak megtörténik a számolás és ennyi, eredménye nem lesz. Természetesen forrnának a fórumok, ha kiderülne, hogy a Fallout 4 grafika jól integrált effektekkel 70-80%-kal gyorsabban megoldható mindenen, de a user nem tudja, és amúgy sem nagy a játék gépigénye.
A GPUOpen egyik célja pont az, hogy az effekteket nem tudják készre, mély integrálásra előkészítve odaadni mindenkinek, mert annyiféle motor van, hogy ez lehetetlen, de a fejlesztők a nyílt forráskód miatt el tudják végezni a munkát maguk, és a PureHair egy példa erre a lehetőségre, amely a TressFX 3.0-ból készült. Ez borzasztóan fontos egy olyan világban, ahol az EA-nek van egy Frostbite-ja, és majdnem annyi R&D-ből tartja fent azt az egy motort, amennyiből 5 top AAA stúdió megélne, ráadásul stratégiai megfontolásból nem licencelik. Egyszerűen megtehetik, hogy iszonyatos mennyiségű pénzt beletolnak, és mindent megoldanak maguk. Az olló pedig a nemhogy szűkül a többi motorhoz képest, hanem egyenesen jobban kinyílik. Ilyen felfogással még az Oxide, a Rebellion, a Firaxis és Crytek rendelkezik, mert ők megértik a problémát, de például a Crytek ebbe nemrég majdnem belerokkantak, tehát amellett, hogy piszkosul dicsérendő az, ahogy a CryEngine-t fejlesztik, egyszerűen nincs a hátuk mögött egy EA kaliberű cég, akik beletolnál a dollármilliókat. És tulajdonképpen a Frostbite a CryEngine-höz képest csak itt van előnyben, de ez egy elég nagy előny. És itt jön az a pont, hogy a piac nagy része már meg sem próbálja követni az EA-t ebben. Egyszerűen olyan mértékű strukturális átalakítást igényelne egy EA-hez hasonló fejlesztési politika, hogy borzalmasan nehéz meggyőzni a kiadók vezérkarát arról, hogy technikailag ez megéri. Még ha el is jut a pénzemberek agyáig, hogy ezzel a modellel mennyivel többre lennének képesek, akkor is ott van az az R&D, amit az effektfejlesztésre kell költeni. Ezt a terhet próbálja levenni a GPUOpen. A PureHair ilyen módszerrel anélkül volt megvalósítható, hogy abba a Square Enix beletolt volna egy rakás pénzt. Emiatt lett kivíve a GPUOpen a GitHUB-ra, hogy fejlesztők a többi fejlesztővel is megoszthassák a tudást. A legtöbben nem látnak a színfalak mögé, de amellett, hogy külsőre mindent faszának acceptálnak a stúdiók, azért látják, hogy a Frostbite ilyet tud ([link] , [link]) kurva jó sebességgel. Ez ellen önerőből már képtelenség versenyezni, tehát vagy megosztja a piac a tudást, vagy leszarja a sebességet és a minőséget, így jöhetnek a middleware-ek. A piacra egyébként hosszú távon káros az, hogy az EA az anyagi fölényét, és a jól elvégzett strukturális átalakítás előnyét kihasználva évről-évre távolabb kerül a többiektől. Ennek a lekövetésére maximum egy-két kiadó lenne képes, de ott is ordítják a nemet a pénzemberek, amint látják, hogy ez milyen költségekkel járna. Valamiféle összefogásra mindenképpen szükség van. Az is probléma egyébként, hogy az iparág legjobb szakemberei az EA-nél és a Sony-nál dolgoznak. Őket el kellene kezdeni visszacsábítani a többieknek. Lehet, hogy a fizetési igényeik magasak egy kiadó vezérkara nézőpontjából, de az EA elsődlegesen azért van ott ahol, mert megadta például Johan Anderssonnak azt, amit kér, így őt nem tudta elcsábítani a Sony vagy például az AMD. És utóbbi is probléma, mert az AMD is olyan embereket visz ki erről a piacról, mint Gareth Thomas vagy Timothy Lottes. De például a Sony is Michal Drobottal, illetve Bart Wronskival erősített. Őket nem szabadna a PC-s kiadóknak elengedni. -
-
#13642
Abu85
HÁZIGAZDA
Malibutomi
#13635
Abu85
HÁZIGAZDA
válasz
Malibutomi
#13635
üzenetére
Nem valamiért, egészen pontosan azért, mert egyszerre 10 wavefront futhat. Minél nagyobb lesz egy hardver, annál fontosabb, hogy a skálázás érdekében egyszerre több wavefront fusson, hogy ha ezeknek nincs elérhető adat, akkor legyen elég tartalék wavefront, ami beugorhat a helyére. A GCN-t az AMD legalább öt generációra tervezte, annak érdekében, hogy a konzolpiacra vonatkozó győzelmet ki tudják használni a PC-n, tehát már az elején úgy kellett tervezniük a hardvert, hogy az elskálázódjon 40 TFLOPS-ig anélkül, hogy a CU főbb jellemzőit megváltoztatnák.
Az NV például már a Maxwellt sem viszi tovább, mert elérte a limitet, amit beleterveztek, így a következő körben meg kell változtatni az ütemezést és a kihasználtságra vonatkozó jellemzőket. Ez több párhuzamosan futó WARP-ot jelent. -
#13633
Abu85
HÁZIGAZDA
Malibutomi
#13632
Abu85
HÁZIGAZDA
válasz
Malibutomi
#13632
üzenetére
A Fiji. Az eléggé sávszéllimites bizonyos motorokban.
Ha nem kellene nekik ekkora sávszél, akkor nem raknának rájuk HBM-et. -
Abu85
HÁZIGAZDA
válasz
Milka 78
#13628
üzenetére
De a csúcskártyához már kötelező a HBM. Túl sokat fogyasztana a GDDR5X, hogy azzal reálisan hozható legyen egy 12-14 TFLOPS-hoz szükséges 700-900 GB/s-os sávszélesség. Nincs meg rá a fogyasztási keret. Emiatt nem lesz kiadva egyetlen csúcskártya sem hagyományos konfigurációval.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13611
üzenetére
Attól rárakják, csak a VGA ára lesz magas, de megéri a teljesítmény miatt.
Nyilván az AMD ezért tervezi már azt, hogy nem csak egyetlen egy új generációs lapkára használnak majd HBM-et.
A következő körben még a sima GDDR5 lesz a leginkább használva. Egyelőre egyik cégnél sincs GDDR5X-et használó termék teszten.Az Xbox One-on a D3D12-n fut. A volumetrikus fényt, illetve a TressFX szimulációt aszinkron compute-ban számolja és ehhez kellett az Xbox One frissítés, ami tartalmazza a D3D12-t, mert az eredeti Xbox One API-ban ez nem lehetséges. Emellett az OIT-re ordered atomics-et használ. Ez mondjuk PC-n eleve nem lehetséges szabványosan.
A miértekre tudni kellene, hogy mennyire fut az Xbox One kód az összes D3D12 implementáción. Lehet, hogy nem igazán. -
Abu85
HÁZIGAZDA
válasz
#85552128
#13605
üzenetére
Számolj utána. Ha mondjuk szükséged van 512 GB/s-os tempóra, akkor az GDDR5X-szel ~80 wattból hozható, míg HBM-mel ~15 wattból. Azért ez nem mindegy.
A HBM-mel szerencsére nincs probléma, hiszen a JESD235a nem kapott működésre vonatkozó módosítást. A Hynix az elmúlt fél évben végig a Fiji-t vizsgálta és leadta a tapasztalatokat, amelyek alapján a JEDEC konstatálta, hogy a HBM hibátlanul működik a gyakorlatban is, tehát az alap specifikációt érintetlenül lehet hagyni, sőt, még kiegészítésre sem szorultak.Az NV-nek is ugyanaz lesz a HBM bevezetésének a modellje. Az teljesen normális, hogy első körben egy gyártó egy terméknél többre nem vállalja be, mert ha az nem sikerült, akkor csak egy terméket kell törölni, vagy jobb esetben részpiacokra korlátozni.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13602
üzenetére
A HBM még drága, így bizonyos termékeknél a GDDR5 jobb. A GDDR5X már kérdéses. Ezt nem biztos, hogy sok VGA-n beveti az AMD. Az előny, hogy olcsó maga a memória, de ha nem GDDR5 módban működik, akkor ez a NYÁK költségeinél hátrányos lesz.
Idén a HBM csak a felsőházban kap szerepet. Jövőre fog lejutni a középkategóriába. De itt a középkategóriát majd át kell értelmezni, mert az AMD-nél a termékskála az egyre gyorsabb dGPU-ról, a "leglassabb dGPU->IGP->egy gyorsabb dGPU->egy brutál IGP->és egy még gyorsabb dGPU" termékskálára vált át. Már az IGP is HBM-et kap. -
Abu85
HÁZIGAZDA
Most nem azért, de mi másban lehet hinni most? Azért Joe Marci már 8 éve felvázolta, hogy a hagyományos elvek szerint épített memóriarendszerek nem skálázhatók addig, ameddig erre szükség lenne. Ergo a fogyasztásuk egy idő után olyan szintre emelkedik, amivel az erre épített termékkategóriában az új generáció nem gyorsulni, hanem lassulni fog. Elég megnézni a GDDR fejlődését, ahol a dupla teljesítmény azonos buszon mindig kétszeresnél nagyobb fogyasztástöbblettel járt. Az persze világos, hogy a JEDEC feje 8 éve még nem tudta, hogy mi lesz a megmentő, de ettől függetlenül az előrejelzése pontról-pontra bejött. Persze őt ezért fizetik.
Ma HBM-en kívül semmilyen más működő alternatíva nem létezik a Marci által 8 éve felvázolt problémára, így baromira nehéz kétségbe vonni a HBM jövőjét. -
Abu85
HÁZIGAZDA
Akkor kezdjük az elején, ******** Egyrészt több tűt használ, tehát bonyolultabb lesz a routing, amivel bonyolultabb lesz a NYÁK. A magasabb effektív órajel miatt az EMI nagyobb gond, tehát a NYÁK-ot ez még tovább bonyolítja. Meg kell oldani, hogy ez ne zavarja a többi komponens működését, ezen belül is a NYÁK-ot érdemes nagyon sok rétegőre tervezni. Ezek nem kisebb módosítások, hanem komplett áttervezés és leárnyékolás. Egyedül akkor nem szükséges ez, ha eldöntöd, hogy GDDR5 módban működteted a GDDR5X-et.
Az interposer nem könnyű, de egyszerűbb vele bánni, mint az EMI-vel.A híreknél mindenkinek joga van benyalni a Micron marketingjét. Az viszont fontos tényező, hogy az AMD és az NVIDIA is a HBM felé tart, mert tisztában vannak a GDDR5X problémáival. A Hynix és a Samsung is erre épít.
[ Módosította: Racecam ]
-
Abu85
HÁZIGAZDA
Valójában HBM2 nincs. A HBM az egyetlen specifikált szabvány, csak a magasabb órajel miatt HBM2-nek hívják, de szabvány szinten csak egy HBM update. A két rendszer, amit mi külsőleg számmal megkülönböztetünk, valójában ugyanabba a JESD235 specifikációba van besorolva. Tehát pontosan ugyanaz a technológia.
Akkor beszélünk külön technológiáról, ha más besorolást kap. Például GDDR5 (JESD212), illetve GDDR5X (JESD232). -
Abu85
HÁZIGAZDA
Nem szar csak van sokkal jobb.
Előrelépést a HBM hoz. A GDDR5X egy kényszermegoldás, mert az implementálása nagyon nehéz. Az EMI régóta probléma ezeknél a magas effektív órajelű rendszereknél. 6 GHz az, ameddig úgy relatíve egyszerű leárnyékolni a VGA-t. Efölött már egyre nagyobb probléma az EMI. 7-8 GHz még talán megoldható, de például a 14 GHz-es GDDR5X+FPGA tesztszett 256 bites busszal 37 cm-es. Egyszerűen nagyon hosszú NYÁK-ot kell tervezni, hogy az EMI ne jelentsen gondot.
A másik gond a fogyasztás, bár az csak hűtés kérdése. Ugyanakkor a 14 GHz-es effektív órajelen 3,5-5 watt egy ilyen lapka kapacitástól függően. Szimpla GDDR5 módban fogyaszt kevesebbet, de akkor 8 GHz a max órajel. -
Abu85
HÁZIGAZDA
A mi cikkünk nem a specifikációból származik, hanem a gyártói leírásokból, amelyek részben tartalmazták a specifikációt, de részletezve van, hogy az EMI, a tokozás, illetve az árnyékolás miatt, valamint a dupla órajel fogyasztásnövelő hatása miatt miket kell módosítani. Ez sajnos nem egyszerű. Csak akkor kell kevés módosítás, ha a GDDR5X GDDR5 módban működik, de ekkor nincs magas órajel. Viszont nem gond az EMI.
-
Abu85
HÁZIGAZDA
Maga a timewarp eléggé általános megoldás, tehát többféle felhasználási módja van. Most, ha csak arról beszélünk, hogy mi az ideális, akkor nyilván egyértelműen az, ha minden kész nyers képkockát timewarpolunk. De ezt elsődlegesen azért tesszük, mert az aktuális szabványos grafikus API-k csak a jelenet kamerapozícióját fogadják el. Alternatíva a LiquidVR LDL funkciója, amely képes a jelenet kamerapozícióját megváltoztatni a képszámítás előtt. Ilyen módon úgy is kaphatsz felezett késleltetést, hogy nem timewarpolsz.
-
Abu85
HÁZIGAZDA
válasz
#45185024
#13563
üzenetére
90 Hz-es a Rift, de mindegy. Viszont a timewarp miatt nem kell 90 sztereó 3D képkocka. Elég 45 és a másik 45 pedig lehet timewarp. Persze ez csak az elmélet. A valóságban kelleni fog a magas frissítés, mert ideális szinkron a gyakorlatban nincs, így a timewarp is a késleltetés csökkentésére megy rá. Legalábbis ez az eredeti célja, de annyira általános a megoldás, hogy többféleképpen lehet használni. Bár az a módszer, amiről írtam most nem ajánlott.
-
Abu85
HÁZIGAZDA
Nyilván, ha nem számít a pénz, akkor megveszed a Falcon Northwest Tiki-t és le van tudva. Vagy DIY alapon veszel egy Dual Fiji kártyát. Ezzel biztosan nem lesz gond, mert erre lett tervezve. Csak ennyiért autót is vehetsz majd.
Nem akkora gond a timewarp. Bőven megéri használni, mert biztonságos, hogy ha megkétszerezed a valós frame-számítás szinkronablakát.
Az AMD ma még nem alkalmaz semmilyen képminőséget csökkentő módszert a saját SDK-jában. Az NV alkalmaz egy multi-res shading eljárást, ami a kép szélét csökkentett minőségben számolja. Ezt a fejlesztő aktiválhatja, vagy letilthatja attól függően, hogy mennyire van a programja a "hányáshatáron".
A multi-res shading célja egyébként pont a timewarp szabadabb alkalmazása. Kevesebb számítással csökken a késés esélye. -
Abu85
HÁZIGAZDA
A ritka drop nem számít. Nem kellemes, de viszonylag könnyen túléli az agy. A problémát az jelenti, ha folyamatosan lecsúszik a timewarp a szinkronablakról. Itt van egy olyan jelenség, hogy az aktuális grafikus API-kon belül nincs frame megszakítás. A megkezdett munkát be kell fejezni, még akkor is, ha már tudjuk, hogy a szinkronablakról lecsúszott. Ez akár még 3-5 ms-nyi extra számítást is jelenthet, de ugye már mindegy. Viszont a hardver innentől folyamatos hátrányba kerül, mert a még futó, de már felesleges számítás miatt késik az új, de fontos számítás.
Erre lesz egy megoldás idén, de csak a Mantle-be. Ez az instant killnek gúnyolt képesség, ami tulajdonképpen a szinkronablak lekésése után azonnal megöl minden késői timewarp-hez tartozó számítást. -
#13557
Abu85
HÁZIGAZDA
gainwardgs
#13556
Abu85
HÁZIGAZDA
válasz
gainwardgs
#13556
üzenetére
Csak azt tudom, hogy Xbox One-on hogyan csinálják. Ott az OIT-t ordered atomicsre építve használják és mutexszel zárolják a wavefrontokat. Ennek az előnye, hogy memóriakímélő és gyors. Ezzel a módszerrel az OIT az Xbox One-on 1 ms-os feladat. A gond az, hogy a PC-be ezt csak GCN-re lehet átmenteni jó eredménnyel, mert nem minden hardver tudja a feldolgozási sorrendet. Láthatod a Lichdom Battlemage című játékban (patch előtt), hogy a mutex zárolás más hardveren is lefut, de az eredmény hibás lehet. A másik megoldás a PPLL adatstruktúra használata, amely megoldja a problémát minden hardveren jó eredménnyel, de 3-4 ms-ba kerül, tehát sokkal lassabb, mint a mutexes megoldás. A harmadik opció az OIT kikapcsolása, de akkor olyan ronda lesz mint a HairWorks.
-
Abu85
HÁZIGAZDA
Finomszemcsés preempcióval gyakorlatilag garantált az aszinkron timewarp elkészülte. Az NV-féle rajzolási szintű preempció is jó, addig amíg 2 ms alatt van az üzemmódváltás. Ha valami beragad 2-nél több ms-ra, akkor a timewarp garantáltan lekési a szinkronablakot. Ezek eléggé nyíltan beszélt problémák a fejlesztők és az Oculus/Valve, illetve a gyártók által.
-
#13549
Abu85
HÁZIGAZDA
gainwardgs
#13546
Abu85
HÁZIGAZDA
válasz
gainwardgs
#13546
üzenetére
PureHair=TressFX 3.0 egyedi art pipeline-nal. A Square Enix EIDOS csoportja használja. Sajnos a GPUOpen GitHUB oldalra nem lesz visszatöltve, de a TressFX 3.0-val bárki csinálhat hasonlót.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#13521
üzenetére
Az NV-t biztosan nem érte váratlanul, hogy romlott a teljesítmény a Gameworks beépítésétől. Ők nem először látnak ilyet. Ez csak nektek új, mert még nem láttátok, hogy mit okoz a middleware beépítése. De persze módosítani bármikor lehet rajta, viszont sokkal egyszerűbb így hagyni és majd egy új meghajtóban lecserélni a HBAO+ shadert. Szinte egyik Gameworks játék sem a szállított kódot futtatja, mert az AMD biztosan lecseréli, és emiatt az NV-nek is le kell cserélnie egy optimalizáltabbra.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#13518
üzenetére
Az optimalizált kódút nem jelenti azt, hogy minden architektúrán javít. Inkább az manapság a cél, hogy kihozz egy olyan sorrendet, amit a játékos megszokott. Ezeket a megjelenés előtt nem látod, mert nem mérnek alpha programokkal. Egyszerűen megkapod a végeredményt, és azt hiszed, hogy az jobb mindenben, mint amilyen volt. A valóságban nem az.
Amikor a változás patch-ekben áll be, akkor láthatod, hogy mennyit változik. Az eredeti optimalizálás valószínűleg nem feküdt annyira az AMD-nek, bár azóta a driverek is javultak, tehát valószínűleg ennek a kényszerű kikapcsolásával csak maximum 5%-ot nyertek. De ez lényegtelen már, mert az új effektek miatt ez az optimalizálás nem használható. Írni kell újat, vagy így kell hagyni a kódot. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#13504
üzenetére
Igen, csak az előző verzióban nem volt még HBAO+, illetve Flex. Mivel ezek a kódok nem módosíthatók, így ahhoz, hogy ezeket beépítsd ki kell kapcsolni bizonyos leképező optimalizálásokat, amik akkor is inaktívak, ha a HBAO+-t vagy a Flexet nem aktiválod. Emiatt változott meg a teljesítmény. Most ezek helyére zsír új optimalizálásokat kell írni, amelyek kompatibilisek az újonnan beépített zárt middleware kódokkal. Nyilván egyébként az kérdés, hogy ilyeneket írnak-e, mert ez akár időigényes is lehet. Önmagában ez nem hiba, hanem annak a mellékterméke, hogy nem módosíthatók az újonnan beépített effektek kódjai, így a leképezőt kell hozzájuk szabni.
-
Abu85
HÁZIGAZDA
Azért csökkentik, mert jóval többet tudnak belőle gyártani az új interposer miatt, így jóval több kerül a piacra is, így ugyanazt a mennyiséget gyorsabban kell eladni. Korábban mondtam, hogy a Fiji esetében problémát jelentett az, hogy külön-külön működött az összes komponens, míg összerakva a csomag már nem működött. Ennek az okát lényegében megkeresték és korrigálták, így most már nem kell eldobni egy csomó Fiji-t.
Lesz még a hónap vége felé egy másik, Fury-ra vonatkozó bejelentés is emellett.(#13481) Locutus: Mondj gyorsabb és olcsóbb VGA-t.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#13416
üzenetére
Nem nehezebb vagy költségesebb, csak ha nem jó a motor struktúrája, akkor úgy járnak, mint a Unity vagy az Unreal Engine 4. Mindkét motornak van DX12 módja és megfelezi a sebességet.
A legfőbb gond az, hogy kvázi hasonló időben elérhető volt két explicit API. Most ne számítsuk a nagyon korai elérést. Az AMD Mantle a tömegek számára nagyjából 2014 februárjától, míg az Apple Metal márciustól vált elérhetővé. Majdnem azonos időben, az az egy hónap nem számít. Számos cég a Mantle-t igényelte, míg a másik tömeg az Metált. Ekkor már mindenki tudta, hogy lesz DX12, tehát akartak valami tapasztalatot róla.
A Frostbite Team, a Rebellion, a Firaxis, az Oxide, a Nixxes, az EIDOS Montreal, a CIG, az Arkane Studios, a Capcom, a Crytek, a Crystal Dynamics, a Codemasters, a Bohemia Interactive, stb a Mantle-t kezdték tesztelni és erre írták át a motorokat. Nekik a DX12 (és a Vulkan is persze - csak az akkor még nem létezett) implementálása egyszerű volt, mert tulajdonképpen a Mantle a két új PC-s API apja, tehát hasonlók az igények. Emiatt tudott az Oxide előállni egy DX12-es tesztprogrammal viszonylag hamar, és ezek közül a cégek közül más sem panaszkodott gondra. Ezzel szemben voltak akik az Apple Metalt implementálták elsődlegesen, ami persze ment. Ilyen cég az Epic, a Unity, pár Zenimax és WB stúdió, és akik ezeket a motorokat használják erősen panaszkodnak, mert amíg a Metal nem igényel új motorstruktúrát, addig a DX12 igen. Tehát az az elmélet, hogy először tesztelem a Mantle vagy a Metal API-t és aztán majd onnan megyek szabványra csak a Mantle-lel működik. Nem azért mert a Metal rossz, hanem azért, mert túl sok az eltérés a DX12-höz képest. A Unity motorprogramozója ennek teljes előadásokat szentelt az előző évben, hogy portolta a motort Metalra, aktiválta és alázott a teljesítmény, aztán innen portolta DX12-re és még a DX11-hez képest felére esett a tempó. Nem helyrehozhatatlan csak az elmélet nem találkozott a gyakorlattal. Tipikusan egyébként azoknál a cégeknél van a baj, ahol a motor nagyon öreg, így a konzolokon sem használják az alacsonyabb szintű elérést, tehát rá sem voltak kényszerítve arra, hogy modern struktúrát tervezzenek.
Aztán még ott vannak a gyártói profilozó és debug eszközök, amelyek nagyon bugosak a DX12-re vonatkozóan. Ezek javítása nem kevés időt vesz igénybe, tehát a kódok ellenőrzése igen lassan halad. Jellemzően azok a cégek állnak jól, akik írtak maguknak DX12 profilozót, mint az Oxide, mert még az MS cuccával sem lehet igazán haladni. Valószínűleg sokat segít, hogy az AMD a saját fejlesztőcsomagjának a forráskódják nyilvánosságra hozza, hogy lehessen javítani a bugokat a fejlesztőcsomag biztosítója nélkül is. -
Abu85
HÁZIGAZDA
Igen, csak nem tudod, hogy milyen beállításokat rejt az a high ... Simán lehet, hogy minimumon van a post-processt, vagy inaktív a lágy árnyék, meg egy rakás dolog ezen kívül, miközben pár olyan dolog meg maxra van rakva, amelynek látható hatása nem igen van a játékban, de a procit zabálja, hogy még a hat pixelnek látszó útra is autókat rak.
-
#13381
Abu85
HÁZIGAZDA
Firestormhun
#13378
Abu85
HÁZIGAZDA
válasz
Firestormhun
#13378
üzenetére
Nem csak nekik. A CR-re vonatkozó részek TIER_3-as effektek, mert az Intel csak olyan algoritmust írt, ami belső bemeneti lefedettséget használ, és ezt csak a Skylake IGP támogatja. Azt nem tudom, hogy a Codemasters ír-e rá alternatív kódot. A Just Cause 3-nál van, mert ott az Avalance eleve használ light assignmentet compute shaderrel, csak azt gyorsabban meg lehet csinálni CR TIER_3-mal.
A Polaris nem biztos, hogy támogatni fogja a ROVs-ot, mert a GCN-ben ordered atomics van. [link] - a két konzol ezt támogatja és lesz is hozzá kiterjesztés a PC-s API-khoz. Ez a következő szintje az order funkcióknak. Még ha támogatják is a ROVs-ot, akkor sem igazán lényeges az AMD-nek, mert a konzolból áthozható az ordered atomics képességet használó eljárás, aztán az már marhára hidegen hagyja az AMD-t, hogy a fejlesztők csinálnak-e ROVs alternatívát. Az már észrevehető egy ideje, hogy az AMD nem a többiekhez igazodik, hanem a két konzolhoz.
-
-
Abu85
HÁZIGAZDA
válasz
#45185024
#13361
üzenetére
Chrome Engine 6. Sok fejlesztést kap, de az alapja a 6-os főverzió. Azt nem tudom, hogy ezen belül mennyit fejlődött. Nyilván nem ugyanaz lesz, amivel megjelent eredetileg.
(#13362) Crytek: A Capcom Microsoft supportos cég. Ők szerintem simán megkapják a Microsoft UE4 verzióját.
-
#13357
Abu85
HÁZIGAZDA
Firestormhun
#13356
Abu85
HÁZIGAZDA
válasz
Firestormhun
#13356
üzenetére
AMD ordered atomics algoritmust kap, ami az Xbox One-on van. Az ugyanarra jó, mint a ROVs, na jó picit többre, de kell hozzá az AMD DX12 kiterjesztése.
A CR-ből mindenki kimarad, mert TIER_3-as szintet kér, vagyis az az effekt csak Skylake IGP-vel működik. Persze maga az effekt szabványos szóval, amelyik hardver tudni fogja a belső bemeneti lefedettséget az jó lesz hozzá. A light assignment egyébként nem akkora gond, mert az Xbox One-ból átmenthető egy alternatív compute algorimtus ugyanarra a problémára. Az Intel ezt csak azért kéri, mert ez így nekik gyorsabb. A DX11-ben is aktív ez a compute shader, csak meg lehet csinálni aszinkron módban is. Ergo ez mindenkinek megjelenik csak máshogy is számolható. -
-
Abu85
HÁZIGAZDA
válasz
Crytek
#13333
üzenetére
Arra, hogy ingyé van hozzáférés a GitHUB-on a forráshoz, illetve van egy saját boltja, amin belül tartalmakat vehetnek, illetve hogy csak akkor kell fizetniük, ha már van 50000 dollár bevételük, és akkor is csak 5%-ot...
A motor választásánál természetesen van több alternatíva, de mondjuk egy CryEngine full licenc már elég drága, míg egy szintén licencelhető Nitrous kezdő cégnek megfizethetetlen. Az ARK-ra összesen a töredékét költik, mint amennyi ma a Nitrous licenc.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#13330
üzenetére
Nem mindegy, hogy az embered neve Albert Einstein vagy Budai Józsi*.
Nincs igazán sok szakember az iparágon belül, így aki tényleg tud valamit, és nem csak átlagos programozó, azokat már rég elvitte az EA, a Sony, a Microsoft, és egy csomó nagy cég. A garázsstúdiók nem tudnák megfizetni őket.
*disclaimer: semmi bajom a Budai Józsikkal...
-
Abu85
HÁZIGAZDA
válasz
Crytek
#13326
üzenetére
Nem érteni kell hozzá, hanem pénz kell hozzá. És az MS-nek van pénze ahhoz, hogy az Epic pénzhiány miatt érdektelenné vált, jellemzően komolyabb fejlesztéseit kiegészítse, normálisan megcsinálja. Ennyi a titok. Csak sajnos ami hiányzik az Epicnél, az hiányzik azoknál a stúdióknál is, akik azért választják az UE4-et, mert a kezdés ingyenes.
Fel kell fogni, hogy abba az egyébként tényleg baráti üzleti modellbe, amit az Epic kínál már nem igazán lehet minden egyes platformra minőséget építeni. -
Abu85
HÁZIGAZDA
válasz
TTomax
#13323
üzenetére
Azt tudom, hogy a Daylight mobil leképezőt használt és azon ment is az AFR. A többi játékot annyira nem követtem. A Daylightot is csak azért, mert az első UE4-es cím volt, persze akkor még nem volt igazán jól optimalizálva a motor a mobil leképezővel sem.
A DX12 csak a PC-es leképezőre készült el. A mobil leképező Vulkan alatt lesz használható. Egyedül Metal API-val választható meg a leképező. Persze a DX12-es mód az UE4-ben elég gyenge. Nagyon sokszor abnormálisan működik, valószínűleg az Epic is azt várja, hogy a Microsoft odaadja nekik a saját DX12 portját, és ezt biztos megteszik, így az Epic számára nincs különösebb szükség ebbe pénzt rakni. -
Abu85
HÁZIGAZDA
válasz
Areturus
#13320
üzenetére
Radeonra talán át tudják hozni, de nem hiszem, hogy általánosan elég stabil a kiadásra. Az a baj, hogy az UE4-nek is van DX12 módja, de az elég rossz. Az ARK-nál írták egy módosítást X1-re és szerintem eddig jutottak. Az lenne a legjobb, ha a Microsoft DX12 leképezőjét beleraknák az UE4 main branch-be, mert az működik a Fable-ben.
DX12 drivert használó IGP kell és elég a GPUMMU mód. -
-
#13318
Abu85
HÁZIGAZDA
huskydog17
#13311
Abu85
HÁZIGAZDA
válasz
huskydog17
#13311
üzenetére
Többször írtam már, hogy az UE4-nek két leképezője van, és a PC-s leképező optimalizálása nagyon rossz. A Microsoft sem ezt használja, hanem írtak egy sajátot. Ez van. Az Epic számára a mobil leképező a fontos, és az nagyon is jó.
-
#13305
Abu85
HÁZIGAZDA
huskydog17
#13293
Abu85
HÁZIGAZDA
válasz
huskydog17
#13293
üzenetére
A Tencent több pénzt akar rakni a kutatásba, így nekik a GPUOpen nagyon fontos. Ők egy olyan modellt akarnak kialakítani, mint az EA, hogy mindent házon belül csinálnak. Ez amiatt is fontos, mert saját konzolt csinálnak, illetve ezt kiterjesztik egy saját operációs rendszerre, így bárki tervezhet a Tencent OS-hez konzolt. Szóval elég durván le fogják támadni a kínai piacot a közeljövőben. Van még VR projektjük is csak még nem jelentették be hivatalosan, de azt már elmondták, hogy a teljes kínai VR-piacot uralni szeretnék.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13267
üzenetére
A Feature levelt furcsamód a D3D12 legacy funkcióként specifikálja. Ergo egyetlen program sem írható meg aszerint, hogy a Feature level szintet lekérdezi a fejlesztő. Helyette egyenként kell lekérdezni az egyes funkciók meglétét. Ilyen formában ez egy szükségtelen paraméter, mert semmit sem definiál a program számára.
-
Abu85
HÁZIGAZDA
válasz
Areturus
#13264
üzenetére
Köszi. Igen az "and" egy hiba. Ki fogom javítani.
A sztereó 3D kötelező. A shader modell esetében is mindenki a legjobbat kell, hogy támogassa. SAD4 is kötelező lett, akinek nincs rá hardvere írnia kell a driverbe egy emulációt, de ezt a funkciót átrakták a DXGI-ba, hogy ne csak a DirectX érhesse el. A dedikált atomi számláló is kötelező lett, ha nem tudja a hardver, akkor emulálni kell annyit, amennyit az API megkövetel. Emiatt van kétféle ajánlás a DX12-nél. Az AMD azt ajánlja, hogy használj Atomicot, mert gyors, míg az NV és az Intel ennek az ellentétét ajánlja, mert az API már nem különbözteti meg a hardvert az emulációtól.
Az is. De a Full Heap mérete architektúránként más.
A Tiled Texture3D nem emulálható. Alternatív algoritmus írható csak.
Nem bírtak volna már várni pár órát. ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Pécs és környéke adok-veszek-beszélgetek
- Eredeti játékok OFF topik
- Fotók, videók mobillal
- Allegro vélemények - tapasztalatok
- Telekom mobilszolgáltatások
- Ilyen olcsó sem volt még egy Apple notebook
- Autós topik
- Hobby elektronika
- Samsung Galaxy Felhasználók OFF topicja
- World of Tanks - MMO
- További aktív témák...
- Beszámítás! Asus ROG Strix Scar Edition G533Z notebook-i7 12700H 16GB DDR5 1TB SSD RTX 3060 6GB W11
- Xiaomi Redmi Note 13 Pro 8/256GB - Kártyafüggetlen, Fekete - 1 Év garanciával
- Új Honor X7d 128GB, Kártyafüggetlen, 1 Év Garanciával
- Dell Latitude 7280,12.5",FHD,i7-6600U,8GB DDR4, 128GB SSD,WIN11, 2 KAMERA
- Új FULL HD webkamera + Számla
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest