Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
Locutus
#29131
üzenetére
Mindenki erre tervezi már generációk óta a hardverét. Egyetlen olyan hardvert sem találsz a piacon, amely legalább ne a mintavételezőbe kötné be az erőforrást. Az utolsó hagyományos működésű architektúrának a Fermi, a TeraScale 2 és a Gen7.5 számított.
A játékbeli problémák nagy része még mindig abból ered, hogy több gyártó ma sem alakította még ki megfelelően a meghajtóra vonatkozó hátteret. Folyamatosan változtatnak rajta, mert keresik, hogy miképp működhetne jobban. Egyedül az AMD háttere nem változik egy ideje, de őket ne vegyük számításba, mert két és fél évvel több idejük volt az alapvető implementációt kifejleszteni mindenki máshoz viszonyítva.
A legtöbb probléma abból ered, hogy túl gyorsan jönnek a játékok, és túl kevés a gyártók többségének a tapasztalata.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Elég sokat profitáltak belőle. Azért van jóval kevesebb teljesítményprobléma AMD hardverrel a DX12 és Vulkan API-val, mert jóval több idő van a meghajtó implementációjában.
Eleve rendkívül speciális az AMD meghajtója. Van egy PAL rétege és több ICD fölötte. A PAL-t a Mantle-höz fejlesztették ki és az ICD-t (legyen az Mantle, Vulkan vagy DX12) erre a rétegre húzzák fel. Ergo már a DX12-nek is úgy fogtak neki, hogy ott volt a PAL és csak húztak fölé egy másik ICD-t. Mára az NV is áttért erre a modellre, de az elején másképp csinálták. Viszont ezek a stratégiai váltások sok erőforrást elvisznek, és rövidtávon inkább károsak, amellett persze, hogy a hosszabb távú előnyük vitathatatlan. Most is láthatod, hogy az NV megint változtatott a DX12 meghajtón, még nem találják az optimális működést.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az UE4 kapcsán eléggé az volt a probléma, hogy sok erőforrást a motor PC-s leképezőjére nem fordított az Epic. Igazából a deferred leképező még ma sem kap igazán nagy figyelmet, de az új Forward+ megoldás, amit a VR miatt fejlesztettek igen kellemes, 30%-kal gyorsabb a régi deferrednél, plusz ott az MSAA használatának lehetősége. Hosszabb távon rendbe rakják ezt a motort. Igaz ennek főleg a Vulkan mobilon való terjedése és a VR az oka, de végeredményben ebből profitál a PC is. A DX12 leképező sem annyira rossz már, mint egy éve, aminek valószínűleg szintén a Vulkan az oka. Egy kritikus PC-s bug kigyomlálásával pedig legalább 10-15%-ot fog még gyorsulni az év végéig. Most már az eszközök is megvannak a további optimalizáláshoz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#29377
üzenetére
Attól, hogy UE4 a motor neve, a Microsoft verziója igen jelentősen eltér. Ugye az MS igazából még az elején vett egy teljes licencet, és azóta azt saját maguk fejlesztik. Kis túlzással ez már egy saját motor, nem sok köze van ahhoz, amit az Epic csinál.
A HB grafikai részletességben meg sem közelíti a GoW4-et, mármint a számok tekintetében. Lényegesen kevesebbet dolgoznak a hardverek alatta. Ha kicserélnék a motort, és átdolgoznák rá a játékot, akkor a Microsoft UE verziójával futna vagy 100 fps-sel a legtöbb hardver.
Ez a különbség nagyrészt azért van, mert a Microsoft iszonyatosan komoly erőforrást tud a saját motorjára ráállítani, megvan hozzá a pénzcsapjuk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29405
Abu85
HÁZIGAZDA
cskamacska
#29404
Abu85
HÁZIGAZDA
válasz
cskamacska
#29404
üzenetére
Nem lesz olyan. A bekötési modell problémája miatt. Vagy a DX12-re tervezed vagy egy legacy API-ra. Igen jól látszik ez a problémakör a Wolf 2-nél, ahol két API lesz, de mindkettő explicit (Vulkan/DX12). De ott az AnvilNext következő verziója is, ami DX12-t támogat, míg a DX11 egy wrapperen keresztül megy. Nem megoldható a kettő együtt. Vagy az egyiknek lesz rossz, vagy a másiknak. Manapság értük el, hogy a legacy API-nak legyen rossz.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29427
Abu85
HÁZIGAZDA
cskamacska
#29424
Abu85
HÁZIGAZDA
válasz
cskamacska
#29424
üzenetére
A Vulkan aktuális, és igazából a startra felhasználható verziója nem tud mindent, ami kell. Például nincs benne multi-GPU, míg a DX12-ben van. Emellett hasznos, ha van egy alternatív API-d. Igazából csak két back-end kell a motorba. A teljes költséghez képest ez elhanyagolható költség és számos előnnyel jár, hiszen kapásból kedvezőbb döntéshelyzeteket teremt, hogy xy játékba melyiket aktivált (opcionálisan akár mindkettőt).
A Unity-ben már van Vulkan és DX12 is. Főleg a Vulkan leképező, ami jól áll.
Az Epic a SIGGRAPH-on beszélt erről. A Vulkan elég jól áll a 4.17-es verzióban. Már az SM5-ös leképező és RHI (ez a layer, ami a motor és az API között van) az alapértelmezett a Vulkan desktop implementációihoz. Lényegében mindent tud, amit a DX11-es verzió, csak pár apró effekt hiányzik, amit később hozzáadnak. De a rendszer stabil és működik. Hamarosan ez lesz Linuxon a default RHI az OpenGL 4.3 helyett. Windowson még marad a DX11 és a DX12, de később ki tudja.
Azt is elmondták, hogy a következő időszakban optimalizálják a bekötéseket és párhuzamosítják az RHI-t. A GPU oldalon a még hiányzó effekteket pótolják, majd nekimennek a motor optimalizálásának a Radeon GPU Profilerrel és a RenderDoc párosával. Ehhez Sweeney már kapott egy saját Vegát, és úton a többi is. Ezek most a prioritások.Az async compute-ot tudja, csak egy időre kikerült, mert furcsán viselkedett, de aztán készült hozzá egy másik implementáció, amivel újra visszakerült.
A mostani DX12 játékok leginkább semmit nem használnak a nagyobb feature_levelekből. A hardverek a bekötési szintjüknek megfelelően dolgoznak, de igazából sok esetben a motor bekötési modellje még mindig a DX11-hez illeszkedik.
A következő lépés a DX12 bekötési modelljéhez való illeszkedés. Ez az, ami most történik a motorokban. Ezzel kihasználásra kerülnek a resource binding és a resource heap fícsőrök. A resource bindingről eléggé sokat beszéltünk, és ismert az is, hogy mi a különbség a Tier szintjei között. Megjegyzem, hogy belinkelt képen lévő táblázat tuti hibás, mert ha Tier3-as a resource binding szint, akkor nem lehet fix értékben meghatározni az UAV slotok számát. Mindenképpen a teljes halmaz lesz felhasználható, vagyis akár egymillió. Ha a hardvert nem készítették fel erre, akkor ezt emulálni kell a videomemóriában, de Tier3-as visszatéréssel ez nem korlátozható.
A resource heapről kevésbé beszéltünk. De ennek is van két szintje. Röviden a fícsőr több típusra kategorizálja az erőforrásokat. A Tier1 szinten az alkalmazás csak olyan halmazokat hozhat létre, ahol a flagek csak egy kategóriába sorolt típust engednek használni. Tier2 szinten értelemszerűen olyan halmazok is létrehozhatók, ahol a flagek megengedik az összes típus használatát. Utóbbival hatékonyabban működtethető a hardver. Ennyi.
Feature_Levelből 11_1-re ugrunk, mert ez minimum szükséges a DX12 bekötési modelljének optimális használatához. Bizonyos motorok ugorhatnak 12_0-ra, leginkább a shader modell 6 miatt.A ROVs lehet potenciálisan probléma, de ez a Vegát leszámítva rendkívül lassú minden eddig megjelent dedikált GPU-n. Az Intel IGP-in gyors még, azokból csak a nyers erő hiányzik. Főleg emiatt nem használták eddig a DX12-ből ezt a képességet. Valamit támogatni nem minden, a teljesítményt is alá kell rakni. A hiányokat megtalálod az Intel Pixelsync játékok összehasonlító képeinél. Páran csináltak ilyet. A ROVs ugyanezt kínálja.
A konzervatív raszterizálás iránt a legtöbben a GPU-s occlusion culling lehetősége miatt érdeklődnek. Ezt ma leginkább egy CPU-s feladat, de ezzel az újítással áttehető GPU-ra. Viszont ez mindenképpen igényli az inner input coverage funkciót, ami csak Tier3-as szinttől van, tehát ebből maximum csak sebességhátrány lehet, mert egy CPU-s occlusion cullingot úgyis megtartanak a motorokban fallbacknek. Ezt leginkább az Intel erőlteti, mert ők ebből sokat nyernének, és nyilván a Vega mellett az AMD-nek is érdeke lesz. Más hardveren nincs sok érdek mellette, mert nincs támogatva az inner input coverage. Opció lehet még használni a sub-pixel shadow map, ami értékes, és Tier1-től támogatható, illetve gyorsítható vele a mozaikos leképezés is. A Tier2 eléggé haszontalan szint önmagában, valószínűleg csak azért került be, mert az NV Pascal nem támogatta a inner input coverage-et, de képes volt arra, hogy ne vágja ki a degeneratív háromszögeket.Az FP16-ra nyilván az AMD nagyon rá fog feküdni, de ezzel igazából csak teljesítményt nyernek a GCN3/4/5-nek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Sehol nem írtam ilyet? Felesleges hazudnod erről. A Volta más felépítésű lesz, és ott lesz gyorsabb, mint a Pascal, ahol az számít a következő évben.
4 tipikus probléma van az iparágon belül, amire reagál a Vega és a Volta:
Háromszögkivágás: A Vega oldaláról primitive shader, az NV oldaláról lesz egy fast Geometry Shader, ami lecseréli a normál GS lépcsőt.
Memóriamenedzsment: A Vega oldaláról HBCC, míg az NV rak a VGA-ira egy rakás VRAM-ot.
Erőforrás-allokáció: A Vega oldaláról 64 kB-os LDS kihasználás és javított előbetöltés, míg az NV oldaláról összevont LDS+L1.
Overdraw probléma: A Vega oldaláról TBDR-szerű mód, míg az NV félig szoftveresen Z-trükközik.Ezekre a korábbi architektúrák nem reagálnak. Persze, hogy gyorsabbak lesznek az újak, de főleg akkor, amikor erősen belefutnak a programok a problémába. És a sebességelőny jelentős lesz. Csak éppen nem a mai programokban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29484
Abu85
HÁZIGAZDA
Petykemano
#29477
Abu85
HÁZIGAZDA
válasz
Petykemano
#29477
üzenetére
Semmi baja nem volt a Fiji sávszéljével, csak kevés volt az 512 GB/s. A Vega 10 esetében is kevés, de csak akkor, ha a legacy módban fut a hardver. Binning módban például jóval jobban érzi magát. Ez a mód a BF1-re és a hasonló típusú Frostbite motort használó címekre engedélyezve van.
A geometria ma még annyira nem korlátozó tényező, mert ott a GeometryFX, ami sokat segít. Persze, ahol sok a háromszög, és ezt kihagyták a motorból, az problémás, de az nem csak az AMD hardvereit érinti, hanem mindent.
A legnagyobb korlátozó tényező egyébként a shader. Ma a HLSL+D3BC egy olyan nyelv+IR, ami "egyszálú" feldolgozást enged meg a GPU-nak. Nem a CPU-n ismert paradigmákkal kell ezt értelmezni, hanem a barrierek tekintetében. A HLSL 2017+DXIL ezt lecseréli "többszálúra".[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29490
Abu85
HÁZIGAZDA
Petykemano
#29487
Abu85
HÁZIGAZDA
válasz
Petykemano
#29487
üzenetére
A Fiji nem küszködik a BF1 alatt semmilyen szűk keresztmetszettel, mert a BF1 Frostbite verziója eleve GeometryFX-es. [link]
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az NXP-hez képest biztosan. Ez a mennyiség hozzájuk képest nem tényező. Nem véletlenül akar a Qualcomm 38 milliárd dollárt adni az NXP-ért. Ezzel bevásárolnák magukat ebbe a piacba, és rögtön megvennék maguknak a piacvezető szerepet.
Az NV sem azért a 140 millió dollárért csinálja, mert mérföldekre vannak az NXP-től. Abban bíznak, hogy az önvezető autók újrarendezik a lapokat, és akkor 2021 körül már egy egészséges 400-500 milliós bevétel jöhetne innen. A Qualcommnak is csak ez érne meg a 38 milliárd dollárt. Persze nyilván a Qualcomm milliárdos tételekben gondolkodik, hiszen megveszik az NXP piacát.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A GloFo már nem fizet az AMD-nek. Olyan csak régen volt. Egy előre fixált szerződásük van, fix árral és fix mennyiséggel, és bizonyos exkluzivításra vonatkozó kitételekkel. Ilyet például szokott kötni a Samsung is, mert ekkor az adott partnernek akkor is ki kell fizetnie a megrendelt wafereket, ha végül nem használják fel őket. Cserébe a wafer sokkal olcsóbb a garantált rendelés miatt, amivel a partner több ponton is kockáztat.
Az NV sem gyártat mindent a TSMC-nél. A középkategóriás lapkákat átvitték a Samsunghoz, mert a TSMC-nél jóval drágább a wafer, és ez az árérzékeny területeken probléma lenne.
Adhatnák olcsóbban, de annyiért fogják adni, amennyiért nagy biztonsággal eladható a legyártott készlet.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#29671
üzenetére
A hardverek az API-któl függetlenül belefuthatnak az erőforrás-allokációval kapcsolatos problémákba. [link] - itt elég részletesen leírtam magát a gondot. A Dirt 4 ebbe szalad bele. A Polarist és a Vegát pedig valamennyire kirántja belőle az utasítás-előbetöltés, a Vegának úgy néz ki, hogy segít a nagyobb LDS is. A többi architektúrában ilyen viszont nincs, így sok ideig csak malmozik a multiprocesszor.
(#29665) Oliverda: Ennek semmi értelme nem lenne. Azért fogyaszt sokat a GCN, mert programozható skalár egységet tartalmaz, és ilyen más architektúrákban nincs. De az új API-k bekötése úgyis ezt igényli, tehát vagy emulálni kell, és akkor a regiszter oldali túlterhelés lesz (lásd Dirt 4, hogy ez mit okoz, ha nincs valamilyen alternatív limit), vagy tervezni kell egy tök ugyanilyen architektúrát. A programozhatóságot meg lehetett úszni 2017-ig, de idén már egy csomó motor kidobja az RB pathot, és a helyére bindless kerül.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#29679
üzenetére
Nagyon leegyszerűsíted, pedig maga a probléma sokkal bonyolultabb. Amikor a Microsoft megszabta a bindless specifikációkat, akkor két modellt különítettek el. Egyet kapott az NVIDIA, leginkább azért, mert külön kérték ezt, és természetesen bekerült az alapvetően tervezett pure bindless koncepció, amit tulajdonképpen az Xbox One-ra szabtak, de ezáltal nyilván a GCN is jó, és az Intel is támogatja már a Gen9-cel, mert ezt is finomították a véglegesítésre. Ez akkor magát a végleges állapotot tekintve nagyon jó volt, de hosszabb távon nagyon rossz, mert mindenkit bezár a második szintre, aki DX12 CPU-n futó binding API-ját valamilyen formában is használja a meghajtó implementációjában. Ilyenkor a meghajtó elhelyez egy erőforrás-leírót egy tömbbe. Amikor a wave-ek elkezdenek futni a multiprocesszoron, ezt a tömböt fogja a multiprocesszor igényelni. Ennyi lényegében a bekötés. De a probléma az vele, hogy a processzor segítségére van szükség ahhoz, hogy a GPU tudja honnan kell mit betölteni a memóriából. Ennél Tier2-es bindless szint, vagyis amit az NV-re csináltak, annyiban különbözik, hogy az SRV-ket és a samplereket be tudja tölteni a mintavételezőbe a branch egység. De a többi buffer view-re már a CPU kell. A Tier3-es pure bindless szint alapvetően annyi, hogy nem kell használni a DX12 CPU-n futó binding API-ját, mert a GPU-ban van egy programozható integer skalár egység, ami a CPU munkáját teljesen ki tudja váltani. Minden memóriahozzáférés, akár a szűrt adattal visszatérők is beleprogramozhatók a shaderekbe, mert lényegében erről szólnak a bindless szintek, hogy a CPU-t ne terheljék a fejlesztők ezzel a feladattal. Na most a programozhtóság megkövetelése miatt ezt nem tudod csak úgy fixfunkciós blokkal megoldani, ide kell egy olyan programozható integer skalár egység, ami megcsinálja a proci feladatát.
Az NV idén már váltott, amiből arra lehet következtetni, hogy rájött arra, hogy második szint bezárja őket, mert ha a Voltában nincs programozható integer skalár egység, vagy ennek a funkcióit hatékonyan emuláló koncepció, akkor például hiába tud a Pascalnál több CBV-t, UAV-t kezleni, vagy esetleg hiába támogat minden bufferhalmaz esetében unpopulated RS bejegyzést, a DirectX 12 nem fogja megengedni neki az extra tudás kihasználását. Emiatt a Tier2-es bindless szint rendkívül korlátozóvá és haszontalanná vált.
A Maxwell és a Pascal esetében az NV átváltott a pure bindless szintre, amit a végleges specifikációkkal szerencsére nem nehéz emulálni, mert volt esze a Microsoftnak, és tudták, hogy 5-6 éven belül az Intel és az NV nem fog memóriaalapú, a bekötési állapot szempontjából transzparens hardvert tervezni, vagyis nem fogják lemásolni a GCN-t. Igazából a Gen9 esetében az Intel is emulál. Náluk az IGP melletti procimagok megcsinálják azt, amit az AMD CU-iban található skalár egységek. Ezután az IGP multiprocesszorai az utolsó szintű gyorsítótárban elérhetik az információkat. Az egyetlen hátránya ennek (a procimagok extra terhelésén kívül persze) a divergens indexelés, de egyrészt a Gen9 multiprocesszorain nem sok lane fut, másrészt tele van vektorregiszterrel az architektára. Az NV-nek ez a megoldás valamivel károssabb, mert a SM-enként 4 KB-nyi vektorregisztert is bukhatnak, ami a regiszterszegény Maxwell és Pascal architektúrákban jóval több, mint az egészséges határ, de valószínűleg 10-15%-nál nagyobb büntit nem szereznek vele, és innentől kezdve a bindless motorok nem jelentenek problémát, tehát egyedül az erőforráshalmazok problémájával kell foglalkozni, mivel a Maxwell/Pascal csak olyan halmazokat hozhat létre, ahol a flagek csak egy kategóriába sorolt típust engednek használni. A Volta állítólag már olyan halmazok is létrehozhat, ahol használható az összes típus. Utóbbival hatékonyabban működtethető a hardver, és a GCN, illetve a Gen9 is így működik. Ez amúgy egy nagyon egyszerűen kezelhető dolog. Maximum romlik a hatásfok.
Valószínűnek tartom egyébként, hogy amit ma látunk az NV implementációjában, az a Volta miatt van benne, mivel az sem kap majd programozható integer skalár egységet, viszont össze lesz vonva az L1 és az LDS. Ilyen formában az L1 kapacitása felhasználható az SM-ken belüli regiszterterület tehermentesítésére a bekötés szempontjából. Tehát a Volta egy ilyen emulációból valószínűleg 3-5%-nál többet nem veszít, és a futtatható warpok számát sem csökkenti majd a módszer.
Egyébként egyetlen mai hardver sem kap EOL-t idén.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#29686
üzenetére
A többletterhelés miatt. Rengeteg teljesítmény vesztesz ilyen módon. Például attól, hogy az Intel a pure bindlesst részben emulálja a meghajtójában már sokat nyer ahhoz képest, mintha az általános binding API-t futtatná az implementáció. Emellett a bindless lehetővé tesz igen érdekes eljárásokat, mint például a dererred textúrázás egyszerű és hatékony implementálását. Ezzel elég sok sebességet lehet nyerni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#29688
üzenetére
Programfüggő, illetve konkrétan kimérni sem lehet, mert ha egy motor átállt a bindless modellre, akkor a régebbi RB modellt már csak wrapperen keresztül tudja kezelni. Annyit tudni erről, hogy az Ubisoft szerint az új AnvilNextben ezzel a váltással elég sokat nyertek minden hardveren. De az architektúrától is függ. Az Ubisoft például próbálja elfedni a különbségeket, ahogy az RS 1.0-1.1 eltéréseket is, viszont így is számít a hardver. Főleg az a döntő tényező, hogy a bekötést mekkora regiszterterheléssel valósul meg. Ebből a szempontból az Intel hardvere viselkedhet majd a legjobban, mert ott van vektorregiszter bőven.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#29701
üzenetére
A skalár egység alapvetően hozzájárul a hardver vezérléséhez, hiszen számos fixfunkciós egységek kivált, amellett persze, hogy felkínálja a programozhatóságot, így optimálisan rámappelhető a hardver rengeteg API-ra. Gyakorlatilag teljesen mindegy az API által használt bekötési modell, a GCN-en csak le kell programozni és működik. Más hardveren esetleg emulációhoz kell nyúlni. Szerinted az Apple miért nem tért még vissza NV-re? Nem igazán tudják hatékonyan rámappelni a Metal 2-t.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#29703
üzenetére
Az NV is nagyon vissza akar kerülni, még a meghajtót is erősen fejlesztik, csak az AMD Metal implementációja sokkal hatékonyabb. Ha nem lenne fontos az Apple, akkor az Intel is hagyná, hogy az AMD vigye el az egészet, mert nem éri meg, de a helyzet az, hogy nagyon megéri. Ezért is tervez az Intel AMD GPU-val dolgozó terméket.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#29705
üzenetére
Megfelelt akkor, amikor még nem próbálták ki. Azóta már nem az eredeti implementációt használják, hanem átálltak emulációra. Ezzel ugyan sebességet vesztenek, de sokkal jobban tudnak igazodni a készülő motorokhoz. Valószínűleg ezt ők a laborjaikban már látják, hiszen számos ilyen játék készül őszre és télre. Tehát a pro-kontra érveket átnézve úgy gondolták, hogy az emulációval jobban járnak, még a sebességcsökkenés ellenére is.
Leginkább abból, hogy a Kaby Lake-G-hez az Intel is az AMD-t választotta. Holott választhatott volna NV-t is.
(#29706) Oliverda: Sokat a TB3-mal nem érnek el. Az Apple kemény nulla devkitet szállított GeForce-szal. Akkor érne ez valamit, ha legalább egy dizájnba visszakerülnének.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#29708
üzenetére
Hogyne sikerülne. Meg is oldják, csak nem mindegy, hogy milyen hatékonyan.
Nem csak nekik készül, de valószínűleg megkérdezték őket, hogy mit látnának szívesen. A véleményük minden bizonnyal komoly szempont volt.
(#29709) Oliverda: Mert vissza akarnak kerülni. Az pedig csak úgy megy, ha megmutatják, hogy tudnak legalább annyit, mint az AMD. Ha vakargatnák a tökeiket, akkor soha többet nem választaná őket az Apple.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Már elmondták korábban, hogy milyen címekre szerződött specifikusan az AMD: Quake Champions, The Evil Within 2, Wolfenstein 2: The New Colossus, Far Cry 5, illetve keletnek a Justice (alternatív néven Treacherous Waters) Online. Ez megy a King of Wushu ellen, ami az NV keleti címe, bár utóbbit az eredeti tervekhez képest átalakították, így végül MOBA lesz és nem MMO, ezért is csúszik lassan két éve.
A Gamesconon a Quake Championsön volt a fókusz, mert az jön leghamarabb. Illetve a VR tekintetében a Fallout 4 VR számított. E mellé még a VR-es AMD-s cím a Skyrim VR és a Doom VR is.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mert velük szerződtek. A Square Enix keleti divíziói az NV-vel állnak szerződésben, míg a nyugatiak, főleg az Eidos Montreal az AMD-vel.
A PES 2018-at az NV azért húzta be, mert az AMD reklámszerződést kötött a FIFA 18-ra. Rájöttek, hogy ezek a focis programok PC-n is fontosak, így elkezdik ezeket is támogatni. Egyelőre csak reklám szintjén.
Az EA-nek nincs általános szerződése. Már nem foglalkoznak ezzel. Bizonyos címekre van az NV-nek és az AMD-nek előszerződési joga. Az NV-nél ilyen a Mirror's Edge, a Mass Effect és a Need for Speed sorozat. Az AMD-nél ugyanez van csak a Battlefield és a Dragon Age sorozatra, illetve a Star Wars játékokra. A Frostbite-hoz az AMD-t és az NV-t nem engedik közel. Van egy külön Frostbite Team és mellé létrejött még a SEED, amely csapatok minden fejlesztést és R&D-t elvégeznek. Kikérik az AMD és az NV tanácsát, de végül maguk döntenek mindenről.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez normális. A QC a nyáron kapott egy nagy update-et, ami 16 GB-os rendszermemória meglétéhez kötötte a két legnagyobb textúrabeállítást. Nem biztos, hogy ez így marad, később érkeznek még fejlesztések. A nagy változások majd a Vulkan leképezővel jöhetnek, mert a motor struktúrája is eléggé átalakul, és akkor az aktuális limitek is változhatnak, emellett azt is tudni, hogy a QC egy későbbi verziója támogatni fogja a Vega HBCC-t is, ami tulajdonképpen minden beépített hard limitet megszüntet.
Szóval egyelőre ezek a paraméterezések az aktuális béta verzióra vonatkoznak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A high-ot WHQD-hez, míg az ultrát 4K-hoz szabták. Későbbre tervben van egy extrém szint a 8K-hoz igazítva, de ez külön opciós DLC-ként jöhet csak és nyilván előbb megvárják a 8K terjedését. A HBCC támogatása is valószínűleg ezért került fel a todo listára.
(#29788) HSM: Attól függ, hogy milyen móddal támogatják. A Saber motor elsődlegesen azzal küzd, hogy nagyon rossz hatásfokkal menedzseli a rendszermemória GPU számára is látható részét, illetve a GPU saját memóriáját. Ezért van most meghúzva egy minimum limit 16 GB-nál. Az a gond, hogy valamiért extrém nagyok maguk az allokációk, amiket a VRAM-ban és a RAM-ban is tárolni kell. A HBCC-vel ez a probléma nem létezik. Elképzelhető egyébként, hogy szimplán egy meghajtóprofil is elég ehhez, de ez majd később kiderül, nyilván a limiteket mindenképpen fel kell oldani, mert a profil csak a működést biztosítja, de a lekódolt hard limitet nem oldja automatikusan fel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem tud a rendszermemória kárára dolgozni. Most is sok rendszermemória kell a hagyományos vezérlésnek, mert a rendszermemóriában van tárolva rengeteg CPU és GPU számára is elérhető adat. A különbség annyi, hogy a HBCC-vel elég csak az igényelt lapokat bemásolni, míg a hagyományos vezérléssel a teljes allokációt el kell helyezni a VRAM-ban, annak ellenére is, ha csak a 0,1%-ára van szükséged belőle. Aztán ha ideálisan tekintünk a menedzsmentre, akkor lényegében arról szól az egész, hogy az allokációkat ide-oda helyezgesse a rendszer a VRAM és a rendszermemória között. A gyakorlatban azonban ez nem feltétlenül valósul majd meg és onnantól kezdve, hogy valami gikszer van a menedzsmentstratégiában rögtön drámaian elkezd nőni a memóriaigény. A HBCC ezekre a gikszerekre immunis.
Az, hogy a QC-nek ma 16 GB RAM és 8 GB VRAM igénye van ultra beállítással egy gikszer eredménye. Nem működik jól a motorban a menedzsment. Később meglátjuk, hogy mire mennek, amint itt a Vulkan és azzal a motorstruktúra frissítése.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nyilván, ha a motorok többsége nem működne rosszul ilyen szempontból, akkor a HBCC ötlete sem merült volna fel.
Abszolút tök jó lenne, ha olyan lenne a PC, mint a konzol, hogy az OS-től elvehető lenne a rendszermemória egy része és a VRAM, így a program ezeket közvetlenül vezérelhetné. De annyiféle konfiguráció van, hogy ilyen sosem lesz. Szóval lábon vagyunk lőve, és gondolkodni kell a PC-ben is alkalmazható megoldáson. 
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem teljesen. Itt arról lenne szó, hogy az OS az elvett memóriát ne is lássa. Ez van a konzoloknál. Innentől kezdve nem az Mm kezelné a CPU memóriáját, hanem a program. A VidMm folyamatot is kiváltaná az alkalmazás.
Azok inkább explicit API-k. És az Mm, illetve a VidMm folyamatok még futnak alattuk.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Shaq-34
#29834
üzenetére
Elvileg az Ansel, de a startra nem lett kész, így még nem aktiválható.
A külsős effektek leginkább az Intel és az AMD megoldásai, főleg az Intel dolgozott ezen a címen is, ahogy a Dirt 4-en.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Shaq-34
#29841
üzenetére
Belerakni belerakhatják, de erre az SSAO-ra van szabva a játék. [link]
Az a baj a tipikus SSAO injektálással, hogy erre tervezni is kell a játékot, hogy ne adjon az AO fake hatást. Az F1 2017-ben az ASSAO adja a legjobb eredményt. Ezért se mindig verik nagy dobra a HBAO+ meglétét, mert sokszor rosszabb a minősége, mint a játékra alapból rátervezett SSAO-nak.
Amíg ezek a valóságban jelenetszintre való effektek képkocka szintjén dolgoznak, addig állandóan azzal fognak küzdeni a játékok, hogy rengeteg hamis eredményt generálnak, és ezeket célirányosan kell eltüntetni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29892
Abu85
HÁZIGAZDA
->Raizen<-
#29889
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#29889
üzenetére
Mert nem éri meg kifejleszteni, ha csak úgy tud bekerülni egy játékba, hogy fizetnek érte. Egy effekt akkor éri el a célját, ha a fejlesztők beintegrálják az adott motorba. Jelen piacon már az is siker, ha csak egyetlen egy kiadó úgy dönt, hogy ezt megteszi. Már csak azért is, mert az elmúlt pár évben egyetlen effekttel történt meg ez, méghozzá a TressFX-szel. Minden más komolyabb effektnél kizárták a szoros integráció, tehát a TressFX-en kívül az elmúlt három-négy év gyártói effektfejlesztése totális bukás (leszámítva a morfológiai és egyéb post-process szűrők sokadik iterációját). És ez vonatkozik az AMD többi effektjére is. Ez tökéletesen látszik a legtöbb gyártói effekten, egy csomó kód leragadt az első verziónál és vérzik ezer sebből, de nem éri meg belerakni a pénzt, hogy kijavítsák, mert önálló döntésből nem kell senkinek. A TressFX is kizárólag azért fejlődik, mert érdeklődés van rá, egyébként az is leragadt volna az elején.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29893
Abu85
HÁZIGAZDA
->Raizen<-
#29891
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#29891
üzenetére
Nem az effektfejlesztés a macerás. Az érdeklődés hiány a probléma.
A fejlesztők egyébként meg vannak kérdezve erről. A nagy többség azt mondta, hogy nem kell nekik effekt, ilyeneket ők is tudnak csinálni. Ellenben csak elenyészően kevesen képesek arra, hogy normálisan profilozzák a PC-s kódot, mert a PC-re kínált profilozók mérföldekkel kevesebbet mutatnak, mint a konzolra elérhetők. Ez például az Epic egyik nagy problémája, mert hiába fejlesztik az UE4-et veszettül, nagyon messze vannak a Frostbite teljesítményétől, és ezt be se tudják hozni, mert rendkívül költséges egy olyan 20-30 fős csapatot fenntartani, ahol az dokumentációkból kiindulva, részben az emberi agy erejéből profilozzák a program kritikus részeit, ciklusonként elemezve. Ez lehet, hogy az EA-nek realitás, mert meg tudják fizetni a világ 20 legjobb rendszerprogramozóját, de rajtuk kívül nagyjából senki másnak nem az, már csak azért sem, mert nem marad elég ember, aki képes erre a feladatra.
Szóval végeredményben a fejlesztők eszközöket akarnak, mert látják, hogy a Frostbite milyen versenyautóvá fejlődött, és esélyük sincs behozni őket, ha nem tudják ugyanazt a munkát egyszerűbben elvégezni, amire az EA Frostbiten Team és SEED részlege képes. Egyszerűen nincsenek meg az előrelépéshez szükséges adatok. Az egyik oldalról látják egy tipikus profilozóból, hogy minden fasza, a másik oldalról pedig látját, hogy a Frostbite mégis sokkal gyorsabb.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29897
Abu85
HÁZIGAZDA
->Raizen<-
#29895
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#29895
üzenetére
Messze van a Hellblade a Mass Effect Andromedától, főleg az effektjeitől. De leginkább a geometriában vannak lemaradva. A Mass Effect Andromeda tipikusan a négyszer több háromszöggel dolgozik jelenetenként. Az arcmimika pedig animáció és nem effekt.
A Hellblade is küzd ugyanattól, amitől az Epic úgy általánosan, ezért tudnak sokkal kisebb tereket megjeleníteni, mint az új Mass Effect. Pontosan emiatt döntött úgy az Epic, hogy a Vulkan beépítésével tartanak egy optimalizálási fázist. Nemrég kezdték meg ténylegesen, és úgy januárra lesz igencsak látható eredménye. Nyilván nehezíti a munkát, hogy lassan futnak be a hardverek, de úgy az ősz végére kész lesznek a "gyomlálással", míg decemberre marad az aszinkron compute hatékonyabb alkalmazása, illetve leteszik az alapokat a multi-GPU-hoz. Később még beépítik a tesszellációt minden RHI-be.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29904
Abu85
HÁZIGAZDA
->Raizen<-
#29901
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#29901
üzenetére
Ennek nem sok köze van a Vegához. Ez az egész az optimalizálásról szól. Az Epic csak azért vált teljesen Vegára, mert szükségük van a profilozóra, hogy optimalizálják az explicit API-ra írt RHI-ket. Ha lenne mondjuk ilyen az NV-hez vagy az Intelhez is, akkor nem cserélnék le a fejlesztői gépeiket. De hardveres nyomkövetést használó profilozója csak az AMD-nek van, nem számolva a konzolokat, amelyekkel PC-n amúgy sem lehet mit kezdeni. A lényeg viszont továbbra is az, hogy a végeredményt tekintve ez csak az eszköz. Az így elvégzett módosítások univerzálisan érvényesek lesznek az NV és az Intel hardvereire is. Az a +10% teljesítmény, amit augusztus végén megtaláltak mindenhol +10%, nem számít, hogy csak Polarison tudtak rálelni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#45997568
#29932
üzenetére
Az normális, hogy jól fut. Az lenne gáz, ha ilyen idejétmúlt grafikával rosszul futna. A Bungie a Destiny után lefagyasztotta az új motorjának a fejlesztését, és a régi rendszernél oldották meg azt a problémát, hogy ne legyen nehéz hozzá tartalmat készíteni. Ezért lesz sokkal több tartalom a Destiny 2-ben, aminek a hiánya az első rész nagy hibája volt. Viszont cserébe a technikai fejlesztésekkel gyakorlatilag nem léptek előre semmit, mert minden energiájuk a tartalomfejlesztés optimalizálására ment el. Persze nem rossz koncepció ez, mert többször is bebizonyosodott már, hogy a kopottas grafika nem rontotta az eladásokat. Lásd CoD.
Egyébként még gyorsulni fog a játék a megjelenésig, mert lesz egy day0 patch, így a mostani teljesítmény eléggé béta jellegű.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29955
Abu85
HÁZIGAZDA
huskydog17
#29946
Abu85
HÁZIGAZDA
válasz
huskydog17
#29946
üzenetére
Érdemes a Windows Store verziót tesztelni. Az sokkal gyorsabban fut, mivel az az Xbox One direkt portja. A Steam verzió nem kapta meg ennek az optimalizálásait, mert a Microsoft az UE módosításait csak a saját boltjába kerülő verzióhoz engedte használni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az Epic meg tudja oldani. A Microsoft UE4 kódja annyiban jobb, hogy átmentek már rajta egy komolyabb optimalizálással. Innen egyébként átlagosan +60%-ot nyertek. Tehát ha a Microsoftnak sikerült ezt kihoznia belőle, akkor az Epic is tudna legalább +30-40%-ot. Csak ők sosem estek még neki az optimalizálásának. Részben ugye joggal, mert nem kaptak hozzá fejlesztőeszközöket a partnereiktől. Most csinálják ezt a munkát a Radeon GPU profilerrel. Ez az első fejlesztőeszköz PC-n, ami hardveres nyomkövetésre épít, így sokkal több bugot lehet vele látni. Csak akadályozza őket, hogy lassan kapják meg a Vegákat. De +10%-ot két hét alatt hoztak, tehát jó az irány, ha a profilozó megmutatja a bugot, akkor azt ki tudják javítani. Az ígéretek szerint januárra meglesznek. Ha azt befrissíti az ARK, és aszerint módosítják a programot, akkor úgy egy év múlva jó lehet a Steam verzió is.
Az lényegtelen, hogy levették a programról az early access feliratot. Ez még messze van a véglegestől, csak lassan elfogy a pénz.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29975
Abu85
HÁZIGAZDA
cskamacska
#29972
Abu85
HÁZIGAZDA
válasz
cskamacska
#29972
üzenetére
Mindenen jobb. A Microsoft UE4 optimalizálásai nagyjából annyiból állnak, hogy végigmentek rajta a PIX Xbox One verziójával, és az így optimalizált kódot visszaportolták PC-re. Természetesen a shaderek jellemzően Xbox One-ra vannak optimalizálva, de maga a leképező sokkal hatékonyabban működik, tehát abból már minden hardver nagyon sokat nyer.
(#29973) huskydog17: Nekem olyan mindegy, hogy ki melyik verzión játszik. Én csak elmondtam, hogy van egy sokkal jobb port is.
Ha nem adnák háromszor többért, akkor elfogyna a pénzük. Aztán majd eldöntöd, hogy megveszed-e. Ők is csak kényszerből cselekednek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29982
Abu85
HÁZIGAZDA
huskydog17
#29980
Abu85
HÁZIGAZDA
válasz
huskydog17
#29980
üzenetére
Konzolokon is a legmagasabb szintű eléréssel fut. Eredetileg nem ezt a motort használta volna a második rész, de végül nem cserélték le, mert nagyobb probléma volt a tartalom hatékony tervezése. Viszont ezt a motort eredetileg a PS3 és az Xbox 360 limitjeire tervezték, így sosem kapta meg az újabb explicit API-k támogatását. Ezért is fut nagyon jól mindenen, mert technikailag egy prev-gen játék.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29991
Abu85
HÁZIGAZDA
huskydog17
#29988
Abu85
HÁZIGAZDA
válasz
huskydog17
#29988
üzenetére
A konzolok lockolva van a frame rate. Méghozzá azért, mert az Xbox One stabilan annyit tud Dirext3D 11.x API-val, amin fut a játék. Minden erősebb konzolon ehhez van állítva a sebesség, akkor is, ha sokkal erősebb a gép. A grafikai skálázás is limitált, mert 2012-es a motor. Nem volt elég idő a régi motor leváltására. Emiatt elég kopottas a grafika, de úgysem ez számít.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30042
Abu85
HÁZIGAZDA
cskamacska
#30041
Abu85
HÁZIGAZDA
válasz
cskamacska
#30041
üzenetére
A PUBG azért ilyen, mert nagyjából másfél éves az UE4 alapja. Ez a Vega számára nem nagy gond, mert tud vele mit kezdeni az új raszterizálójával, ami kapott új profilt is a 17.8.2-es meghajtóban, tehát nem itt van a vége, amit a linkelt tesztben látsz. A régebbi hardvereknek hiányzik az a másfél év, amiben benne volt a 4.16-os UE4 frissítés is, amiben pont kapnak egy megfelelő kezelést azok a hardverek, amelyekben nincs draw-stream lehetőség. Ezért is tud a Vega az 1080 Ti nyakára mászni, ha nincs bandwith limitje a még nem aktivált pseudo channel mód hiányában.
Szóval ez nem szeretethiány. Egyszerűen a Vega hardverből képes bizonyos problémákat kezelni, amit más hardver nem tud, és nem is lett beépítve a játékba a problémák szoftveres kezelése sem. Nyilván ebben benne van Early Access is.Az ARK fentebb ki lett beszélve. A Windows Store verzió lényegesen gyorsabb mindenen. Érdemes azt vásárolni, ha a Steam verzió teljesítménye nem elég.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#30043
üzenetére
Akkor használjátok a sokkal lassabb portot.
Az MS-nek semmi célja nincs ezzel. Ők csak felrántották technikailag elfogadható szintre a játékot, hogy jól működjön Xbox One-on, és ha már lett Store verzió, hát leportolták oda is. Ugyanezt egyébként kiadhatnák Steamre is, ha a Steam támogatná az UWP-t.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#30045
üzenetére
Nem ugyanaz a port. A Steam verzió Win32-s, míg a Store verzió UWP-s.
Azt meg lehetne csinálni, hogy az UWP-s verziót kiadják Steam-re is, ha a Steam támogatná a platformot, de nem támogatják. Innentől kezdve választani kell.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#30048
üzenetére
Nem értem, hogy miért ők a szemetek. Úgy gondolták, hogy az a minőség, amit a Studio Wildcard lerakott egy fos. Részben az egyiptomi Instinct felelt számos programozási munkáért, viszont a Microsoft fogta magát és magára vette ezt a terhet az Xbox One-ra vonatkozóan. Mivel ennek minőségbiztosítási célja volt, így nyilván a fejlesztők sem ellenkeztek. Ezután ezt a verziót megkapta a Windows Store is.
Megtehette volna a Valve is, hogy odaáll és azt mondja, hogy technikailag híg fos, amit csináltok, így átveszem tőletek, hogy a Steam-re kikerülő port értékelhető minőségű legyen, de nem tették meg.Bár az áruház fenntartója kismértékben felel a partnerek minkáiért, a Microsoft valószínűleg úgy gondolta, hogy az ARK nem üti meg a minimum mércét, ezért besegítettek. Ez miért paraszt lépés? A saját pénzüket tették fel a Windows Store portra, ami ráadásul semmivel sem drágább, mint a Steam port.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#30053
üzenetére
Ugyanúgy kiadhatja a fejlesztő az UWP-s verziót a Steamhez, amint a Valve beépíti az UWP támogatását a platformba. Nem először látnánk külső áruházhoz való linkelést, lásd UPLAY az Ubisoft címeknél. Az nem a Microsoft hibája, hogy egyedül ők tartották fontosnak a minimális optimalizálást. Mondhatták volna azt is, hogy elég nekik is a gyenge minőség, de gondolom van egy minimum elvárt színvonal a saját értékeik szerint, amit megcéloznak.
Nem az ARK az első, ahol a Windows-Steam párosításnál van jobb. Lásd Mad Max és a Warhammer 40,000: Dawn of War III, ahol a Linux-Steam párosítás gyorsabb.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#30055
üzenetére
A Quantum Break a Remedy játéka volt. Az MS abba nem avatkozott bele. Nekik csak a PC-Xbox exkluzivitás kellett.
Nem az ARK az egyetlen cím, amit felkaroltak. Számos UE4-es játéknál segédkeznek az Xboxra portoláson, és világos, hogy ezeknek lesz majd egy PC Windows Store változata is. A Microsoftnak ez nem akkora teher, mert nagyon ismerik az UE4 problémáit, és tudnak rajta segíteni a tapasztalatukkal.
Aztán, hogy értékeled-e ezt a hozzáállást, vagy azt a portot vásárolod, amelyik nem kapott ennyi figyelmet már a te döntésed lesz. Nem fogják rád kényszeríteni a jobb verziót, de a saját minőségbiztosítási elveik miatt megcsinálják a "master race" PC-s rétegnek. Neked ebből hátrányod nem lesz.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30058
Abu85
HÁZIGAZDA
cskamacska
#30057
Abu85
HÁZIGAZDA
válasz
cskamacska
#30057
üzenetére
A Windows Store pont olyan bolt, mint a többi. Maga az UWP verzió akármelyik áruházban üzemképes lenne, ha az adott áruház támogatná az UWP platformra írt alkalmazások futtatását.
Az meg nem olyan egyszerű, hogy elérhetővé teszi mondjuk az MS a saját UE4 kódját a fejlesztőknek, mert az a kód natívan Windows 10 komponensekre van fejlesztve, mindenféle legacy API támogatása nélkül, tehát marha sok idő lenne az egészet már szimplán Steamre portolni. Ez már csak azért is nehéz, mert az eredeti UE4 a sok támogatott platform miatt használ egy alapvető réteget arra, hogy ne kelljen annyi OS-t dedikáltan támogatni, és elég legyen magát a motort egy amolyan keresztrendszeres keretre ráemelni. Ez az alsó réteg az OS-ek és azok egyedi komponenseinek direkt támogatását megoldja, míg felette egységes lehet a kód. A Microsoft ezt teljesen kidobta, és náluk az egységes kód natívan UWP-t, DirectX-et, és egyéb Windows 10 komponenseket céloz. Ezért nem lehet rengeteg dolgot visszaműteni az Epic motorjába, annak ellenére, hogy a Microsoft is UE4-et használ.
Úgy képzeld el ezt az egészet, mint egy autót. Az UE4 egy szimpla utcai járgány, tök általános beállításokkal. Ezt az MS megvette, és átépítette egy versenygéppé. Sokkal gyorsabb és hatékonyabb lett így, annak ellenére, hogy maga a kocsi, főleg a motorja ugyanaz. Viszont az MS kocsija így már csak száraz aszfalton (Windows 10-UWP-DirectX 11.L-WDDM 2.0) üzemképes, míg a normál UE4 még megy esőben (Windows 7/8-Win32-Vulkan), sárban (Linux-Vulkan), hegyen (Linux-OpenGL), homokon (Android/iOS), bármin (képzeld ide, amit még nem írtam), de persze sokkal lassabban. De az MS sose akarja kivinni esőbe, nekik tök elég az, ha csak száraz aszfalton megy.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30066
Abu85
HÁZIGAZDA
huskydog17
#30065
Abu85
HÁZIGAZDA
válasz
huskydog17
#30065
üzenetére
A HPG-n volt róla szó, hogy a Microsoft UE4 verziója jó 50-60%-kal gyorsabb, mint az alap UE4. Ez ilyen nagy átlag. Bizonyos körülmények között kisebb a különbség, de esetenként akár két és félszeres is. Az ARK-ba ebből a verzióból emelték át az optimalizálást.
Ettől még a Vulkanon futó Linux verzió gyorsabb.
Egyáltalán nem volt katasztrófa. A Quantum Break azzal küzdött, hogy a legtöbb DX12-es játékkal ellentétben a fejlesztők nem hagyományos bindinget használtak, hanem elsőként rámentek a bindlessre. Azt sajnos nem tudták, hogy ilyen körülmények között nem működik az NV D3D12-es implementációja. Viszont AMD-n és Intelen jó volt a kód. Igazából már NV-n sem olyan katasztrofális, mivel azóta javult a meghajtó, de a régi implementációval tényleg nagyon szar volt. Ezért viszont nem a Remedy a felelős, ők csak jóhiszeműen kihasználták a D3D12 egyik fő újítását, bízva abban, hogy a piacon lévő hardverek hatékonyak vele.
A Steam verzió azért kapott DX11-et, mert az NV kérésére visszatértek az eredeti motorstruktúrára, mivel a GeForce egyszerűen nem alkalmas ezekre a modernebb bekötésekre. Emellett utólag kiderült, hogy a Steam verziónál minden gyártó külön paraméterezhette az effekteket, hogy ebből se legyen gond. Ezért van nagy különbség a képminőségben az egyes hardverek között.
Az meg, hogy szebben futott relatív. Intelen és AMD-n még mindig a D3D12-es verzió a jobb. Esetenként jelentősen.
Az nagyon tipikus egyébként, hogy a GeForce architektúráknak egyszerűen nem fekszik a bindless, illetve az a fajta motorstruktúra, amivel ez elérhető, mivel lezárja a hardverbe épített összes fast pathokat. Az Intel és az AMD architektúrák viszont pont erre vannak tervezve, memóriaalapú rendszerként működnek (az Intel ezt csak brute force-ból emulálja, de kétmillió slot van beépítve tehát az eredmény ugyanaz) kevés fast path, és kigyúrt általános pathok.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Dtomka
#30073
üzenetére
Nem igazán fog változni. A problémát a memória menedzselése jelenti. Egyszerűen egy csomó szemét keletkezik a VRAM-ban, mert rossz az allokációs stratégia, amit nagyon nehéz lenne javítani. Minél több memóriád van, annál jobb lesz a helyzet.
(#30074) Szaby59: A Vega speciális hardver a BF1 problémáját tekintve. A HBCC szegmens aktiválásával teljesen ki tudja kerülni azt a programhibát, ami az akadozásokat okozza. Direkt emiatt lett kifejlesztve a HBCC, hogy ha egy alkalmazásnál az allokációs stratégia valamiért problémás, akkor a hardver átvegye a vezérlést a programkódtól.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#30076
üzenetére
50-50%. Elvileg az alapproblémájuk az, hogy támogatni kell a WDDM 1.x-et is, ami kényszeríti őket nem kívánt döntésekre. Mert a BF1-et már úgy tervezték, hogy csak WDDM 2.0-tól fog működni.
Ezt már megnézték a fejlesztők a Vegával. Direkt rákérdeztem, hogy ezt a bugot javítja-e a HBCC aktiválása és az volt a válasz, hogy teljesen megszünteti a jelenséget. De azt is írták, hogy továbbra is dolgoznak azon, hogy a program oldalán is javítsák a vezérlés hatékonyságát a régebbi hardvereken.
Azért inaktív alapértelmezetten, mert a Radeon Settings default beállításait egyszer tesztelik Win7-re és Win10-re. Mivel Win7-re nincs HBCC, így ha az aktív lenne, akkor különálló tesztelés kellene, ami dupla idő és dupla költség. De amúgy a funkció működik. Az AMD mondta is nekünk, hogy ha nem hisszük el, akkor teszteljük nyugodtan aktív HBCC-vel az összes tesztjátékot. Meg is tettük, és nem tapasztaltunk hibát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30148
Abu85
HÁZIGAZDA
huskydog17
#30147
Abu85
HÁZIGAZDA
válasz
huskydog17
#30147
üzenetére
High-Performance Graphics. Egy rendezvény volt, ahol Tim tartott egy előadást.
[link] - Itt fog megjelenni, amint engedélyt adtak rá. Lassan kerülnek fel az anyagok. Elvileg a keynote Q&A session is felkerül, ott volt erről szó.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
[link] - emiatt. Amikor a BF1-hez tervezték a Frostbite-ot, akkor ez az eljárás még csak a Maxwellig volt optimalizálva, és így is került a módosított verziója a Frostbite akkori verziójába. Természetesen az új hardverek is futtatják, mert rá lehet húzni az újabb NVAPI-ra és AGS-re, de a hatékonyság nem biztos, hogy jó lesz direkt optimalizálás nélkül.
Az sem kedvez a Frostbite Team oldalán a Pascalnak, hogy ha valamit nem ismernek az architektúrából, akkor arra úgy tekintenek, hogy az adott rendszer pontosan úgy működik, mint a GCN. Ez a Maxwellnél bejött, de a Pascalnál sok esetben nem túl kifizetődő ez az optimalizálási stratégia.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Ú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.
- Suzuki Swift 2005 1.3 GLX CD AC - AndroidAuto & CarPlay
- Bomba ár! HP Elite X2 1011 G1 - m5 I 8GB I 256GB SSD I 11,6" FHD Touch I CAM I W10 I Gari
- Bomba ár! Lenovo ThinkPad T490 - i5-8GEN I 8GB I 256GB SSD I 14" FHD I Cam I W10 I Garancia!
- 8db GeForce RTX 3090 Egyben
- VAST AI - VAST AI - VAST AI - GeForce RTX 3090
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs