Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
Drizzt
#31917
üzenetére
Nem a VGA-kra. Az Intel csak reagálni akar egy eseményre. A PCI Express egyre korlátozóbb lesz és a Microsoft már dolgozik egy olyan strukturális átalakításon a Windowst érintően, ami gyakorlatilag megszünteti azt, hogy a GPU kernelek csak rendszerhívásokon keresztül legyenek futtathatók. Ergo a GPU a CPU-val közös logikai szintre kerül, és ha ezt egy gyors memóriakoherens interfésszel be tudják kötni a CPU mellé, akkor az új konfiguráció tökéletesen megfelel a Microsoft új irányának. Raja ezért ment oda, mert ő igazából már részt vett ilyen projektekben, és persze ismeri az AMD hardvereit, addig amíg az Intelnek nem lesz sajátja a CPU mellé a tokozásba. Az Intel VGA-kat nem akar, ezt nem is értékelik jövőképnek (a teljes piac 90%-a lefedhető nélkülük), de mondjuk a zárt vagy nyitott, memóriakoherens interfészen bekötött GPU a CPU-val közös tokozásban már igen kedvező jövőkép számukra. Nem beszélve, hogy tudják, hogy az AMD is erre megy, elvégre ott van nekik a GMI, az Infinity Fabric, a HBCC, mind-mind olyan technológia, ami erre való. És az Intelnek mindene megvan ahhoz, hogy ezeket lemásolják, és kövessék az irányt, csupán kellett egy szakember, aki ezt le tudja vezényelni. Nyilván első körben puhatolózással, de 4-5 év múlva úgyis lesz saját hardverük.
Azt nem tudni, hogy ebben a jövőképben a PCI Express-es VGA-knak milyen szerep jut. Simán elképzelhető, hogy az Intel és az AMD úgy dönt, hogy nincs tovább, és lelövik az egész VGA-piacot. Persze sokkal valószínűbb, hogy valami alternatív irányt dolgoznak ki, mert a VGA-k azért gyorsak, még akkor is, ha buták. Tehát például lehet olyan opciót kidolgozni, hogy a Microsoft vagy a Khronos csinál egy olyan specifikációt, amivel az árnyalást általánosan átrakják az objektumtérbe, és ekkor magát az árnyalási feladatokat a VGA-k még el tudják végezni, ráadásul ilyen modellel akár 2-3-4-5-6... VGA-t is beköthetsz, azok skálázódni fognak. A többi feladatot pedig elvégzi a CPU melletti GPU.Aztán egyébként az is lehet még, hogy az Intel, az AMD és az NV megegyezik arról, hogy a PCI Express helyett csináljanak egy új csatolót a nyílt CCIX-re építve, de ettől nagyon messze állunk, mert az NV a saját NVLinkjét erőltetné, de az Intelnek ez nem kell, sőt a Intelnek az lenne a jó, ha a PCI Express helyett nem jönne semmi, mert az fájna leginkább a VGA-knak, amit ugye ők nem is gyártanak. Az AMD érdekei is igazából az NV szívatásához fűződnek, tehát ők se biztos, hogy egy ilyen egyezményt támogatnának.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Leginkább az a baj, hogy nagyon sok piacra megy a Vega 10. Ott a gamer, ott a félprofesszionális, ott a szerver, ott a professzionális, ahol ráadásul van az SSG, ami ugye pont egy olyan dolog, amire a filmkészítők nagyon buknak, mert 2 TB memóriába már elég sok adat belefér, így nem kell darabjaira szabdalni a tartalmat a vizualizáláshoz. És akkor még ott az Apple, aki adná ki az iMac Prót. Ez az egész egyébként tisztán az AMD hibája. Egyszerűen elszámolták magukat az igényekkel kapcsolatban, és amikor nagyobb az igény, mint amennyire számítottak, akkor az már eleve egy hátrányos helyzet, mert lassan lehet rá reagálni. Sokkal célszerűbb lett volna a professzionális modellek kiadását csúsztatni, de persze gondolom kellett a Project 47-be is a hardver, tehát belekergették magukat ebbe az ellátási problémába. És hiába hoznak be egy harmadik partnert a tokozásra, az is jó két hónap, mire ténylegesen tudja éreztetni a nagyobb kapacitást. Jobban ki kellett volna számolni, hogy mik a piac igényei.
-
Abu85
HÁZIGAZDA
Az FE és a referencia RX verzió az ugyanaz. Két külön partner tokozza a GPU-t és a memóriát, de ugyanaz a hardver. Időközben már lett egy harmadik cég is, aki beszállt a tokozásba, de ők csak az Apple rendeléseit szolgálják ki. Utóbbi miatt lassan tényleg utoléri majd a kínálat a keresletet. A referenciák gyártását is leállítják, hogy minden lapka+memória mehessen a custom modellekre.
Most azzal a harmadik partnerrel jóval többet gyártanak a tervezetthez képest. Eredetileg úgy tervezték, hogy az Apple igényit is ki tudják majd szolgálni két tokozó partnerrel. Emiatt csúszik az iMac Pro hivatalos bejelentése, de persze az sem segít, hogy az Apple sokat kér, első batch-re mindig szokásuk nagy készletet rendelni.
-
#31877
Abu85
HÁZIGAZDA
Petykemano
#31867
Abu85
HÁZIGAZDA
válasz
Petykemano
#31867
üzenetére
Sokkal olcsóbb. Ennyi. Az Mi25-nek is megvan az előnye, ahogy a Teslának is, de például az egyedi support előnye egy csomó potenciális vásárlónak nem kell, ezért jobb nekik a Titan és a Frontier.
(#31874) Petykemano: Kiderült már, hogy a Wolf 2-ben működnek. Nem általános, hanem per game alapú jelenleg a profilozás.
Csodadriver egyébként nem létezik. Ezek nem csodák.(#31876) Szaby59: Relax, az Adrenalin meghajtóval nem fogod megnyitni a vezérlőpultot. Majd az ágyból átállítod, amit szeretnél.
-
#31856
Abu85
HÁZIGAZDA
Petykemano
#31854
Abu85
HÁZIGAZDA
válasz
Petykemano
#31854
üzenetére
Igazából a ROCm nem akarja áttörni a CUDA-t. Ennek a konstrukciónak a CUDA egy fontos eleme, amivel fel tudják használni az AMD GPU-kra az eddig megírt CUDA kódokat. Emiatt van az, hogy az AMD manapság nem arról beszél, hogy a CUDA rossz, annak mennie kell, hanem arról, hogy a CUDA az jó, használjátok a HIP-en keresztül, és tudjátok célozni az NV, illetve az AMD hardvereit. A CUDA tehát ma a stratégia része lett, amit még reklámoznak is, mert már megvan az eszköz (HIPify), amivel ezeket a kódokat lehet futtatni a saját GPU-ikon.
[link] - itt bővebben beszélnek a CUDA-HIP kapcsolatáról.
-
Abu85
HÁZIGAZDA
Pontosan.
És akkor tételesen. HIP-re van ugyanolyan gyors Tensorflow, mint a CUDA-ra. Dedukcióban egy Vega tud neked adni ~25 TFLOPS-ot, míg egy Titan Xp ~10 TFLOPS-ot. Miért is éri meg a Titan Xp-t, ha az alternatívája két és félszer gyorsabb és nincs szoftveres hátránya?
Most pedig jött a Titan V, ami már képes ~25 TFLOPS-ra, sőt igazából többre is, erről majd a hírben, tehát ez már egy nagyon is megfontolandó alternatíva.
-
Abu85
HÁZIGAZDA
Miért törném magam azon, hogy provokáljalak titeket? Szimplán önmagatoktól képesek vagytok olyan dolgokat látni a hírekbe, amelyek benne sincsenek.
Láthatod most is. Szó se volt itt arról, hogy mennyire szuper a Vega. Egyszerűen csak leírtam, hogy picit gyorsabb nála FP16-ban a Titan V, és pont azért jött, mert a korábbi Titan Xp nem tudott 25+ TFLOPS-os FP16-os tempót felmutatni. Ebből a tényből sikerül azt leszűrni, hogy mennyire szuper a Vega. Ez itt a szövegértelmezési problémát tipikus esete, amit "provokációzással" palástoltok.
-
Abu85
HÁZIGAZDA
Az én lelkem nem bántja. Örülök neki, hogy van miről írni, és nektek lesz mire sivalkodni.
(#31845) ÁdiBá: Igen csak az a hardver marha drága. Van egy réteg, ami nem tudja megfizetni az annyira drága hardvert, így az NV és az AMD ide vezette be a Titan és a Frontier opciókat. Nem annyira durvák a terméktámogatásban, de elég jól működnek, és relatíve olcsók. Ez a réteg amúgy sem a Tesla vagy az Instinct verziót venné, hanem választana GeForce-ot és Radeont, ha nem lenne Titan és Frontier.
-
Abu85
HÁZIGAZDA
Nem hiszem, hogy ez géming kártya. Azt írták páran, hogy az NV azért titkolja a ROP-ok számát, mert 48 van benne. Ezért sem esett szó a géming felhasználásról, csak a gépi tanulásról. Én próbáltam rákérdezni a ROP-ok számára, de csak az volt a válasz, hogy ez nem géming hardver, így ezek száma lényegtelen. Ez igazából megkerülése volt a kérdésnek.
-
Abu85
HÁZIGAZDA
Az lesz kiemelve a hírben. Hova készült és mit tud. És ha visszaolvasol egyedül én hoztam számokat, szóval rajtam számon kérni ezek hiányát finoman fogalmazva is vicces.
(#31840) Locutus: A tényeket nem lehet tálalni. Azok tények. Az már más kérdés, hogy mit képzeltek bele, de ez nem rám tartozik.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#31838
üzenetére
Sokkal többen választják. A problémát az adja az NV számára, hogy a Tensorflow HIP konverziója pöcre ugyanolyan gyors, mint a CUDA kód. Csak amíg utóbbit nem tudod futtatni olyan hardveren, ami ~10 TFLOPS-nál többre képes, addig a HIP konverzió fut 25+ TFLOPS-os hardvereken is. És mit ad isten, az NV kihozott egy 25+ TFLOPS-os hardvert. Ha ezt nem tudjátok összerakni, akkor az nem az én gondom.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#31831
üzenetére
Semmiféle hírforrás nem kell ide. A dolog egyértelmű. Az AMD-nek a ROCm csomagja nagyon gyorsan fejlődik, és egyre többen választják a Vegát gépi tanuláshoz. Hogy miért? Mert megközelítőleg sincs olyan relatíve olcsó és gyors hardver, ami 27,5 TFLOPS-ot leadna FP16-ban. A Titan V most képes 27,6 TFLOPS-ra, ami sokkal-sokkal-sokkal több, mint amit a korábbi Titan Xp tudott. És a gépi tanulás szempontjából a 3000 dollár relatíve olcsónak számít. Leginkább azért, mert a memória miatt úgyis a Frontierben gondolkodtak a "dezertőrök". A CUDA sem lényeges kötés már, a ROCm támogatja a HIP-en keresztül.
-
#31829
Abu85
HÁZIGAZDA
Petykemano
#31825
Abu85
HÁZIGAZDA
válasz
Petykemano
#31825
üzenetére
Semmi ilyesmi nincs. Az Radeon Vega Frontier Edition egyre kedveltebb a gépi tanuláshoz, mert a ROCm mellett egyre erősebb. Már sokkal veri a Titan Xp-t. Utóbbi pedig nem elég jó hardver, mert nagyon lassú FP16-ban, Tensor magja pedig nincs. Tehát aki ma olcsó gépi tanulásra kínált hardvert akar, annak egyedül a Radeon Vega Frontier Edition, vagy akár a pici consumer Vegák kínálnak 25+ TFLOPS-os teljesítményt. Ezt a tempót más hardver meg sem közelíti. A Titan V erre reagál csak. Nem véletlen az sem, hogy számítási teljesítményben hova érkezett: a top RX Vegára 0,1 TFLOPS-ot ver FP32-ben és FP16-ban.
-
Abu85
HÁZIGAZDA
válasz
korcsi
#31681
üzenetére
Mert nincs összefüggés. Akármilyen memóriával működik a HBCC, csak a külföldi fórumokon beszélnek össze-vissza.
Az AMD csak azért használ a HBCC-hez HBM2-t, mert ezzel elég csak egy vagy két HBM2 stacket vásárolni, ami olcsóbb és energiahatékonyabb, mintha vásárolnának hasonló sávszélességre 12-16 GDDR5(X) stacket. Amúgy semmi hátránya nem lenne az árán és a fogyasztásán kívül a GDDR5(X)-nek. Maximum annyi, hogy a NYÁK bonyolultsága jelentősen megnőne, de a HBM-nek ott az interposer, mint nehézség, tehát mindkét opció hasonló komplex, csak más területen. -
Abu85
HÁZIGAZDA
Rövid időn belül nem. Az alapprobléma nem olyan, hogy azt egy hónapon belül meg lehet oldani. Hosszabb időn belül bármi lehet, de a hosszabb időnél is olyan három hónapos távlatra gondolj minimum.
(#31642) RareParrot: Nem fut jobban.
(#31645) Dtomka: Ezekhez szerződések kellenek. Az AMD-t csak a Far Cry 5 érdekelte. A Microsoft komoly erőforrásokat tett az AC Originsbe, de ennek a hatásait csak Xbox One-okon láthatod. A PC-s verziókkal csak akkor törődik az MS, ha azok UWP-re jönnek.
Ott a Wolf 2. Az csak Vulkan, és nem véletlenül használ csak explicit API-t.
-
Abu85
HÁZIGAZDA
válasz
Fred23
#31632
üzenetére
Teljesen mindegy a VGA típusa. Láthatod, hogy GeForce mellett is akad a fórumozóknak. A különbség az, hogy az egyes architektúrák máshol akadnak. De a jelenség teljesen általános. A wrapper okozza, amit az Ubi használ. Az NV és az AMD nem tud vele mit kezdeni. Annyit hallottam, hogy mindketten figyelmeztették az Ubit, hogy nem lesz jó, amit csinálnak, de az Intel volt a fejlesztői partner, és ők azt mondták, hogy működni fog. Ilyenkor nem az NV-re és az AMD-re fognak hallgatni, mert nekik eleve kevesebb rálátásuk volt a projektre.
-
Abu85
HÁZIGAZDA
válasz
Fred23
#31630
üzenetére
A driver nem segít rajta. Az 1.05-ös patch tartalmaz javításokat a különböző konfigokon előforduló mikroakadásokra (de a korábbi 1.04 is tartalmazott optimalizálásokat). Elméletben persze, mert valakinek ezek megszűntek, valakinek pedig eddig nem voltak és az 1.05-ös után lettek.
[link] - általánosan nem túl jók a tapasztalatok. Szinte mindenki küzd valamivel.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#31572
üzenetére
Ez nem ilyen egyszerű. Alapvetően egyik teszt sem különb a másiknál. A probléma az, hogy rengeteg környezet valósítható meg VR alatt, így egy teszt nem tudja optimálisan visszaadni a hardverek teljesítményét. Emiatt a Futuremark csinált három félét. Az Orange a mai környezetre vonatkozik. A terhelés tipikusan olyan, amilyet egy mai átlagos VR játékban látsz, és itt az átlagos alatt nyilván ne a gagyikat nézd, hanem mondjuk például egy Serious Sam VR-szerű megoldást. A Blue tulajdonképpen ugyanazt a technológiát használja, mint az Orange, csak lényegesen több grafikai számítás történik benne, így azt próbálja megmutatni, hogy mire mész a mai környezetek mellett, ha a program grafikája az átlagosnál komplexebb. A Cyan teszt azért készült, mert a Futuremark azt is meg akarta mutatni, hogy mire képesek a hardverek azokkal a környezetekkel, amelyeket a mai VR játékok még nem használnak. Nem véletlen, hogy most jelent meg, ez tipikusan a Windows 10 MR platformjának a környezetét prezentálja. Persze ettől a VR runtime akármi lehet, de a Cyan tesztet a Microsoft VR koncepcióját figyelembe véve tervezték meg. Emiatt a Cyan room már lényeges hangsúlyt fektet a jelenetre is, nem csak a nyers grafikai dolgok számítanak benne, hanem a hardverekhez tartozó implementációk többletterhelése, a bekötés hatékony kezelése, stb. Tehát alapvetően a Cyan tesztben a hardver ereje mellett nagyon számít a D3D12-es meghajtó hatékonysága. Hosszabb távon valószínűleg nem lesz ekkora különbség az AMD és az NV között a Cyan tesztben, csak az AMD tudja, hogy nekik a D3D12 implementációjuk sokkal jobb, mint az NV-nek, és amíg az NV fel nem zárkózik, addig erre lehet teszteket mutogatni. Az eltérést valójában nem a hardver, hanem a driver okozza.
-
Abu85
HÁZIGAZDA
válasz
#45997568
#31554
üzenetére
Ezekből nem lesznek eladások. Ezek fejlesztőknek való technológiák.
Alapvetően az NGG pathból a user csak a teljesítményt fogja érezni. Mást nem igazán. A GPU-driven pipeline-ben utazó fejlesztőket viszont érdekelheti a dolog egy driveren túlnyúló megoldás formájában is. Csak kérdés, hogy mennyire nyúljon túl. Elég a kiterjesztés, vagy vissza kell hozni az AMD API-ját? Erre nem most lesz válasz. Valszeg megvizsgálják mindkét lehetőséget. Az API-nak annyi az előnye, hogy azzal gyakorlatilag teljesen átfogó megoldás készülhet a mostani futószalag lecserélésére, míg a kiterjesztés bizonyos specifikus igényekre bőven elég lehet.
-
Abu85
HÁZIGAZDA
válasz
imi123
#31552
üzenetére
A primitive shader sokféleképpen használható. De ez még kialakulóban van. Az AMD első körben egy driveres megoldást fejleszt, ami egyszerűen a meglévő kódokat ismeri fel és primitive shaderbe fordítja. Ez korlátozott formában működik, mert az API mögött lehet ügyködni a meghajtóban. A második körös megoldás kérdéses, de nyilván vissza lehet hozni a Mantle API-t. Ezekért a lehetőségekért nem állították le a támogatását. Viszont ez csak akkor lesz visszahozva, ha a fejlesztők igénylik. Kisebb specifikus igények például teljesíthetők SPIR-V kiterjesztésből vagy AGS-ből - ha valakinek nem elég jó "a driver megcsinálja helyetted" opció.
A konzolhoz igazodik mindenki. A PC specifikus optimalizálása a fejlesztés nagyon késői szakaszában jön képbe.
Én amúgy nem tartanám jó ötletnek, ha a primitive shaderre új szabványos futószalag lenne felhúzva. Ez nem kiegészítés lenne, hanem alapvető reform. És ha már meglépünk egy ilyet szabványos szinten, akkor inkább az egyénileg definiálható shader lépcsők felé kellene menni.
-
#31543
Abu85
HÁZIGAZDA
Petykemano
#31538
Abu85
HÁZIGAZDA
válasz
Petykemano
#31538
üzenetére
A profilozó már be van építve a driverbe, ehhez szükséged van a Developer Panelre, hogy elindítsd a szervizfolyamatot. Utána működik a rendszer nyomkövetést támogató hardvereken. [link] - részletes videó a kipróbáláshoz.
Ha a Microsoft a primitive shadert implementálni akarja, akkor azt az API-ban tehetik meg. De ki kell dobniuk hozzá a vertex, domain és geometry shadert. A hull shadert pedig érdemes compute shaderrel kiváltani. Ez a legacy kompatibilitást eléggé megtörné, amit nem szerencsés eljátszani ilyen sűrűn. Persze nyilván a gpu-driven pipeline rendszerekhez sokkal jobban illik a primitive shader, mint a régebbi problémákra kitalál, de az új problémák kezelésére teljesen használhatatlan shader lépcsők.
-
Abu85
HÁZIGAZDA
Micro-stuttering occurs in games when GPU monitoring tools are monitoring GPU power (“Power” monitoring enabled). [2016377] - [link]
(#31525) Dtomka: Emiatt nem szeretik a programfejlesztők ezeket az OSD-ket. Az UWP-s megoldás sokkal jobb, mert ott külön rétegen fut, így ha esetleg megpusztul, akkor csak a hozzá tartozó réteg pusztul vele. UWP-ben mindenki azt csinál, amit akar, kárt nem tud okozni egy 3rd party OSD. Maximum lefagy, megdöglik a hozzá tartozó réteg, de ezen kívül minden fut tovább. A Win32 ezzel szemben sokkal sérülékenyebb.
-
Abu85
HÁZIGAZDA
Ugyanez igaz az NV-nél is. A 3rd party programok náluk is generálnak hibákat, amelyeket javítgatni kell, lásd a legutolsó GeForce meghajtó erre vonatkozó, mikroakadásokat megszüntető javítása. Nem ez az oka annak, amiért az AMD elmegy ebbe az irányba, hanem az, hogy a DX12/Vulkan programokban az OSD felületek nem igazán működnek, és hiába próbálják ezeket kezelni külsőleg, az eredmény egyszerűen nem jó. Emiatt az AMD inkább integráltan kezdi el kezelni a problémát, mert egyre több programfejlesztő direkt olyan kódokat ír a programba, hogy a 3rd party OSD működését akadályozzák az újabb API-kkal. Viszont a meghajtó mögött ezt nem tudják befolyásolni, így a program oldali mesterséges korlátokat az AMD könnyen ki tudja kerülni.
-
Abu85
HÁZIGAZDA
A Destiny 2 végleges verziója elég sokat változott a bétához képest. Ezért a korábbi béta profilok nagyon szarok lettek teljesítményben. Ezért tudott az AMD a 17.10.2-ben 43-50%-ot javítani a korábbi profilokhoz. Most az NV ugyanezt a váltást hozta, mert eddig a bétához írt profillal működött a játék náluk.
Tehát a megjelenés óta mindkét gyártó pumpált bele átlag 40%-nyi teljesítményt. Valószínűleg az NV-nek is kész lettek októberben az új rutinok, csak amíg az AMD-nél egy csapat írja a meghajtót, addig az NV-nél három részre van osztva a fejlesztés. Tehát előfordulhat, hogy úgy jön ki egy újítás, hogy annak a megjelenésig még két környi frissítést kell várnia a WHQL miatt, mielőtt megoldható a committelés. -
#31421
Abu85
HÁZIGAZDA
cskamacska
#31418
Abu85
HÁZIGAZDA
válasz
cskamacska
#31418
üzenetére
Egyáltalán nem állunk jól grafikailag. Inkább messze állunk az elvárhatótól. A voxel cone tracing se ray tracing.
Tudom, hogy sokszor linkeltem már, de érdemes ezt a részt megnézni, hogy miképp is zajlik a fejlesztés a programozói és a tervezési oldalról. [link] - igazából minden szava arany, mert hallod, hogy akarják a tervezők a fejlődést, de elmondja, hogy miért nem tud ezzel a fejlődéssel lépést tartani egy programozó.
(#31420) Raymond: A multis lövölde még nagyon speckó dolog is. Ott leszinkronizálni egy rakás változást eléggé nehézkes lenne. Akkor már fusson a felhőből, ahogy például a BF4-ben a víz hullámzása is úgy volt megoldva.
-
#31417
Abu85
HÁZIGAZDA
cskamacska
#31416
Abu85
HÁZIGAZDA
válasz
cskamacska
#31416
üzenetére
A rombolhatóság most is jöhetne mainstreambe. Két dolog tartja igazán vissza. Egyrészt az Intel nem nagyon rakott pénzt a Havok újabb moduljainak PC-re portolásába, így sok régebbi fejlesztés még mindig PS4/X1 only. Másrészt, ahogy korábban is mondtam a rombolhatóságnál az AI beragadása komoly problémaforrás, és ezt rendkívül nehéz jól kezelni. Emiatt is gondolkodik a Microsoft a fizika szempontjából inkább a felhős megoldáson.
Az AI igazából már nem akkora probléma. Az explicit API-kkal rengeteg munka került le a CPU-ról, így egyre több erőforrás fogható be erre is. A GPU-s útkeresés persze egyfajta mass-AI-ra nem rossz, de itt teljesen reális megoldás lenne az aszinkron compute is, és az így számolt adat az n+1 frame-ben megjelenne.
-
#31415
Abu85
HÁZIGAZDA
cskamacska
#31411
Abu85
HÁZIGAZDA
válasz
cskamacska
#31411
üzenetére
Sajnos nagy innovációkat nehéz multiplatform szintre fejleszteni.
Elég sok PC-s innováció volt terítéken. Például signed distance fields ray tracing vagy voxel cone tracing. Ezek azért léteznek ma csak a PS4-en, és nem PC-n, mert nehéz a PC-n megoldani a problémákat.
A voxel cone tracingre példa a The Tomorrow Children. PC-n viszont eddig jutottunk el: [link] - statikus minden, mert az animáció rosszul viselkedik, illetve a VXGI csak egymenetes, szemben a Sony kétmenetes+szimulált megoldásával.
A signed distance fields ray tracingre már kellemesebb. PS4: Dreams ... multiplatform: ClayBook.
-
#31414
Abu85
HÁZIGAZDA
cskamacska
#31408
Abu85
HÁZIGAZDA
válasz
cskamacska
#31408
üzenetére
A gyártók már az implementációkat prezentálják, mivel a HSA specifikációi elkészültek. Mostantól a saját HSA implementációk kapják a marketinget. Lásd AMD ROCm. A Linux már támogatja.
Windows verzióhoz meg kell várni a Microsoft módosításait. Ezt célozza az Intel is az új divíziójával, amit vezet majd Raja. Nem a GPU-piac dGPU-kkal elérhető alig 20%-át akarják, hanem azt a potenciálisan nagyra hizlalható területet, amit a változásokkal meg lehet majd fogni.
Azokkal a szabványos modellekkel, amik készülnek nem feltétlenül szükséges a lapkaszintű integráció. Elég, ha a CPU és a GPU össze van kötve egy memóriakoherens interfésszel. Utóbbi lehet saját (GMI, NVLINK), vagy szabványos, lásd CCIX.
-
Abu85
HÁZIGAZDA
válasz
Raggie
#31404
üzenetére
Ha nem állnak be a CCIX mellé, hogy ezt a részt szabványosítsák, akkor igen, a gyártók keverése megszűnne. De még az sem biztos, hogy érdemes külön foglalatba kivezetni a GPU-t. Simán jobb ötletnek tűnik odarakni a CPU mellé ugyanabba a tokozásba, és akkor alacsony marad a rendszermemória elérésnek a késleltetése is a dedikált GPU számára.
Van még számos ötlet a tarsolyban. Az egyik ilyen a texel shading. Ez eleve teljesen függetlenítené a shadinget a raszterizálástól, tehát utóbbira jó lenne a tokozásban lévő GPU, míg a shadinget ki lehet helyezni egy PCI Express kapcsolaton beköthető gyorsítóra. Ilyen formában még a multi-GPU is baromira skálázódna, mert annyi szolgagyorsítót rakhatsz a rendszerbe, amennyi csak befér a házba.
-
#31403
Abu85
HÁZIGAZDA
FollowTheORI
#31396
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#31396
üzenetére
Igazából lesz belőle desktop is, nem csak mobil megoldás a Kaby Lake-G.
Hosszabb távon a PCI Expressnek mindenképpen problémái lesznek. Nem véletlen lett ennyire a 4.0-ra tolva az 5.0. Ezekkel az új API-kkal, a különböző kísérleti technikákkal még a 4.0-s sávszél is rohadtul kevésnek tűnik. Emellett a PCI Express nem memória-koherens. De probléma ebből nincs, az AMD-nek és az NV-nek is van saját memória-koherens interfésze a PCI Express helyére, és az Intel csinálja a sajátját. Ráadásul ezeket is ki lehet vezetni foglalatba, csak nem lesznek kompatibilisek egymással.
Alternatív lehetőség a CCIX. Az egy szabványos memória-koherens interfész. De ezt például az Intel és az NV nem támogatja. Még!?
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#31392
üzenetére
Kukázni nem fogják, mert kell másra is, de például az Intel nem úgy gondol a dedikált GPU-kra, mint mások. Ők reagálni akarnak egy potenciális változásra, aminek a PCI Express eleve nem része, mivel nem memória-koherens az interfész. Ilyet fejleszt az Intel, az AMD-nek már van GMI-je, míg az NV-nek NVLinkje.
Utóbbi miatt nehezen tudják megölni az NV-t, mert ha az AMD és az Intel procijai már nem lesznek használhatók a számukra, akkor csinálnak a GPU mellé egy ARM-os saját procit. Még a Windows is telepíthető lenne rá, hiszen hamarosan ARM-os Qualcomm gépeken lesz ott a rendszer az ultramobil szinten. Tehát önmagában az az irány, amerre az AMD és az Intel elindult nem probléma az NV-nek. Megvan minden komponensük a követésükre. -
#31355
Abu85
HÁZIGAZDA
huskydog17
#31336
Abu85
HÁZIGAZDA
válasz
huskydog17
#31336
üzenetére
A Bethesda igazából nem barátot keresett, hanem R&D partnert. Ők is azt akarják, amit az EA, hogy egy motor és sok játék, mert az összköltséget tekintve igen kellemes így fejleszteni, még akkor is, ha kell egy combos stúdió a motorhoz, de hát ott az id software. Amíg azonban az EA az R&D-t megoldja a SEED részleggel, addig a Bethesda ezt túl költségesnek tartja, és részben lepasszolja az AMD-nek. Ilyen formában azért hatékony fejleszteni, mert a Bethesda megcsinálja a kutatást, az AMD pedig megmondja, hogy azt hogyan érdemes implementálni, ráadásul úgy képesek megmondani, hogy az jó legyen a konzolokra is. Gyakorlatilag az egyik legdrágább részét az R&D-nek megosztják az AMD-vel. Ez azért vonatkozik csak az id tech 6+-ra, mert egyetlen korábbi motoron sem dolgozik már az id software.
-
#31353
Abu85
HÁZIGAZDA
huskydog17
#31332
Abu85
HÁZIGAZDA
válasz
huskydog17
#31332
üzenetére
A Frostbite-nak is vannak különböző verziói. A Ghost még mindig a három éves alappal dolgozik, mert a Frostbite Team nem igazán törődik a szükséges versenyzésre írt modullal. Egyetlen egy játékért túl nagy erőfeszítés lenne minden motorverzióhoz portolni. Ráadásul nincs is különösebb haszna, mert arra a terhelésre, ami az NFS-hez kell, jó az öreg motor is. Például a Battlefront 2 Frostbite verziója sokkal modernebb. Abban már benne van az új tiled light trees eljárás, ami váltja a Half Z-t, bár teljes funkcionalitással a bétában még csak a DX12 alatt működött. DX11-re továbbra is egy speckó Half Z volt az alapértelmezett. Azt nem tudni, hogy a véglegesben hogyan alakul.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#31245
üzenetére
Elég nagy tévedés. A Khronos Group egy nagyon nagy konzorcium, amelyben rengeteg cég és alapítvány van benne. Az AMD csak egy tag az ARB-ben, és pont annyi joguk van, mint az NV-nek, az Intelnek, az ARM-nak, az Imaginationnek, a Qualcomm-nak, stb. Amikor tehát egy cég számára úgymond kedvezőtlen döntések születnek, azokat az adott cég mindig jóváhagyja. Bár tudja, hogy rövidtávon kedvezőtlen, de ismeri már, hogy 2-3 év múlva milyen architektúrát fognak hozni, és ahhoz lehet, hogy a új modell a jó.
Annak sincs igazából jelentősége, hogy a Vulkan a Mantle-re épül. Ezt az ARB-ben mindenki jóváhagyta. Ráadásul ezek a döntések eleve nem többségi szavazósak, hanem mindenki beleegyezését igénylik. -
#31244
Abu85
HÁZIGAZDA
FollowTheORI
#31243
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#31243
üzenetére
Igen, csak ezek már nem kaphatók. De valóban, ezekre lehetett lőni.
Amúgy szerintem tök sokan félreértik ezt az egészet. Ahogy ez alakult az senkinek sem a hibája. Talán a Khronos felelős egy picit érte, de nekik kellett nagyon gyorsan egy API a D3D12-vel szemben és a Mantle pont jó volt. Talán átírhatták volna más részeit is nem csak a bekötést, de utólag ez már mindegy, viszont kiterjesztésekkel kezelhetők a problémák. Látszik a Wolf 2-n, hogy nagyon is jól, tehát nem reménytelenül GCN-orientált a Vulkan API, csak kell egy alternatív path a GeForce-okhoz. Látható, hogy az id is csinál két külön pathot a gyártókra, és ez nem akkora teher igazából. Ha már írnak 1000 sornyi menedzsmentet, igazán nem kézzsibbasztó meló még 50 sort beírni a dedikált allokációhoz. Nem véletlenül támogatja az id tech 6 (jó ez csak egy későbbi patch-csel) és 6.5 motor, de egyébként az AotS Vulkan módja is ilyen. Eltérő AMD-n és NV-n. Nem nagy meló a különbséget lekezelni programszinten.
Hosszabb távon pedig úgyis úgy fognak működni a hardverek, ahogy a GCN, és akkor a Khronos lesz a nagy előrelátó, mert ilyen memóriakezeléssel egyszerűbb lesz az élet. Ugyanígy a bekötés is nagyon kellemesen kiegészíthető bindless-re, tehát egyáltalán nem hülyeség, amit a Khronos csinál. Egy réteg járt csak rosszul, méghozzá a 3 GB-os 1060 tulajok, de most őszintén, eleve nagyon ajánlott volt azt a terméket 6 GB VRAM-mal venni.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#31241
üzenetére
Ha megnézed itt a 4 GB-os kártyák jól érzik magukat, de a 3 GB-osak nem. Az AMD-nek pedig nincsenek már 3 GB-os VGA-i.
A Doom esetében sem volt máshogy. Az AMD-nél 1 GB volt a minimum, míg az NV-nél 2 GB. Sőt, Windows 7-tel 3 GB kellett a GeForce-ra. De aztán jött a dedikált allokáció és ez levitte a VRAM-igényt 1,5 GB-ra az NV-n.Már a Vulkan implementáción is látszik, hogy mennyire máshogy van rámappelve az NV az API-ra, szemben az AMD-vel.
AMD memtype implementáció:
Memory type 0
Heapindex 0
Flags DEVICE_LOCAL_BIT
Memory type 1
Heapindex 1
Flags HOST_VISIBLE_BIT
HOST_COHERENT_BIT
Memory type 2
Heapindex 2
Flags DEVICE_LOCAL_BIT
HOST_VISIBLE_BIT
HOST_COHERENT_BIT
Memory type 3
Heapindex 1
Flags HOST_VISIBLE_BIT
HOST_COHERENT_BIT
HOST_CACHED_BITNVIDIA memtype implementáció:
Memory type 0
Heapindex 1
Flags none
Memory type 1
Heapindex 1
Flags none
Memory type 2
Heapindex 1
Flags none
Memory type 3
Heapindex 1
Flags none
Memory type 4
Heapindex 1
Flags none
Memory type 5
Heapindex 1
Flags none
Memory type 6
Heapindex 1
Flags none
Memory type 7
Heapindex 0
Flags DEVICE_LOCAL_BIT
Memory type 8
Heapindex 0
Flags DEVICE_LOCAL_BIT
Memory type 9
Heapindex 1
Flags HOST_VISIBLE_BIT
HOST_COHERENT_BIT
Memory type 10
Heapindex 1
Flags HOST_VISIBLE_BIT
HOST_COHERENT_BIT
HOST_CACHED_BITMuszáj trükközni a program szintjén is, mert a Vulkan a memória kezelése szempontjából nem került módosításra a Mantle-höz képest, így utólag kell egy külön kiterjesztésben kezelni az erre vonatkozó potenciális problémákat.
Ha megnézed az id Doom Vulkan előadását, akkor ki van emelve, hogy voltak az NV-vel memóriakezelési gondjaik. Akkor még csak tesztszinten létezett a dedikált allokáció.
És ha lényegtelen lenne a memóriakezelés, akkor nem szarakodnának a dedikált allokációval, hanem hagynák az API-t rendeltetésszerűen működni, de ez már a Doomnál sem vált be. -
#31236
Abu85
HÁZIGAZDA
cskamacska
#31222
Abu85
HÁZIGAZDA
válasz
cskamacska
#31222
üzenetére
Ez nem igazán a fejlesztőkön múlik. A gond az, hogy amikor a Khronos átemelte a Mantle kódját a Vulkan API-ba, akkor igazából egy dolog komoly módosítása mellett döntöttek, méghozzá a bekötési modellén. Ugyanakkor a memória kezelését szimplán átemelték a Mantle-ből, ami utólag elég nagy hiba volt, mert a GCN-re volt írva az egész. Az a lényeg, hogy csak a GCN képes úgy kezelni dedikált VRAM-os memóriahalmazt a Vulkan API-ban, hogy ne rendeljen hozzá flaget, és ez számottevő hátrány a többi hardvernek, mert így az NV és az Intel olyan implementációra kényszerül, amelyben a flag nélküli memóriahalmaz a rendszermemória, vagy annak egy része. Ez az Intelnél opcionálisan kihagyható, lévén IGP-ről van szó, eleve látja a grafikus rész a rendszermemóriát, de egy GeForce-nál nem, itt meg kell határozni, hogy maximum mekkora halmazt olvashat és írhat a hardver a processzorral együtt.
Erre a problémára reagál a dedikált allokáció, ami tulajdonképpen még a lokális flages memóriahalmazból ki tud jelölni olyan allokációkat, amelyeket a program elszakíthat a meghajtótól. Ezek ugyan a lokális memóriahalmazba tartoznak, de a kijelölt részre nem vonatkozik a flag. Ennek az előnye, hogy utólagosan kezelhető a Vulkan API rendkívül GCN-orientált memóriadizájnja, viszont hátránya, hogy az így írt alkalmazások máshogy kezelik a memóriát az érintett hardvereken, ami limitációkkal jár.
Jelen formában az id úgy döntött, hogy inkább memóriát áldoznak be a sebességért, ami persze a 3 GB-os GeForce-okat rosszul érinti, de a 4+ GB-osakat már jól. Nyilván a 3 GB-os 1060-nak jól ki lett baszarintva, de a többi erősebb hardver inkább nyer ezen. -
Abu85
HÁZIGAZDA
válasz
Fred23
#31133
üzenetére
Már ami megmaradt belőle. Azért az Ubisoft Montrealt jól lerabolták az elmúlt években. A két nagy 3D ninja Bart Wronski és Michal Drobot már nem dolgozik nekik. Steve McAuley maradt ott mint utolsó nagy mohikán, de őt meg rárakták teljesen az új Dunia motorra. Persze Steve McAuley még önmagában is marha nagy név, de azért látszik, hogy az igazán neves szakemberek száma csökkent. Ez már csak azon is észrevehető, hogy a Massive Entertainment lehagyta őket a Snowdroppal. Egyre nehezebbé válik egy stúdión belül két motort fenntartani, megcsappant szakembergárdával.
-
Abu85
HÁZIGAZDA
Igen, csak a PC nem konzol. Ott elhiszem, hogy ez működik, de az AC Originsre az a legfőbb panasz, hogy rendkívül kicsi a teljesítménykülönbség a full low és a full high grafika között. Nyilván ennek az oka a rossz hatásfokban keresendő. PC-n emiatt egy rakás grafikai beállításnak nincs is értelme. Hiába veszed le, semmit sem gyorsulsz.
(#31134) Raymond: Konkrétan az nyomja agyon, hogy a CPU egy rakás olyan munkára van kényszerítve, amelyek szükségtelenek lennének, ha nem kellene a bekötéseket ennyire körülményesen kezelni. Kb. olyan, mintha elindítanál egy OCCT-t szálra és úgy játszanál mellette egy játékon. Haszna nincs, mert csak azért működik így, mert a fejlesztés egy szakaszában hoztak egy hibás döntést, és már túl drága lenne kijavítani.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#31129
üzenetére
Azért ne tekintsünk már úgy a motorstruktúra szempontjából a leképezőkre, mintha teljesen más lenne az elfogadott modell két játéknál. Abszolút nem más, függetlenül attól, hogy a játék stratégia vagy kaland. Emiatt van egységes ajánlás arra, hogy milyen a következő ideális motorstruktúra. Senki más nem mond mást a gyártók közül, ugyanis az az ideális, ha a régi leképező->iRenderSytem-szerű rendszereket úgy alakítják át, hogy két jól elkülönülő részre bontják az egészet. Ajánlott egy magas szintre helyezett leképezőrész, mi tulajdonképpen tartalmazza mindazt, amiben a célozható API-k megegyeznek. És ez alá kell behúzni legalább két alacsony szintre helyezett leképezőt, ami tartalmazza azokat, amikben a célozható API-k eltérnek (például bekötés, hazardok kezelése, memóriamenedzsment, erőforrás-korlátozások, stb.). A cél ezzel az, hogy az explicit és a legacy API-kra is tudjál egy motorban natív pathot kínálni, így nem kell wrappert bevetni, mert esetleg egy olyan dolgot a közös, magasabb szintű leképezőrészbe raktál, amit az egyik célzott API pont nem támogat. Működik wrapperrel is persze, csak rohadtul rossz lesz a hatásfoka. Ez még addig oké, amíg egy program lehetőséget ad a natív path használatára, mert akkor kit érdekel, hogy ott a wrapper. De amikor úgy jön ki valami, hogy nincs natív path-ra sem lehetőség, akkor nyilván felkiáltanak ott a gyártóknál, hogy "erről pofáztunk 2-3 GDC-n át, hogy ezt ne".
-
Abu85
HÁZIGAZDA
válasz
Raymond
#31127
üzenetére
Annyiban nem mindegy, hogy a Nitrous alapján egyáltalán nem a mai hardverekkel és a beállításokkal van a gond, hanem azzal, ahogy az új AnvilNext alatt nagyon rossz hatásfokkal működik a D3D11 path. Fentebb le is írtam, hogy miért.
Amúgy nem baj, hogy ilyen lett, mert legalább az AMD és az NV tud példát is hozni a jövő évi GDC-re, hogy miért ajánlják a bindless átálláshoz a motorstruktúra jelentős átírását, és a high-level->low-level rendering modellt, a jóval egyszerűbb mid-level forma helyett. -
Abu85
HÁZIGAZDA
válasz
Raymond
#31125
üzenetére
Nem lenne szükség rá. A probléma ugyanis nem az objektumok/fényforrások száma vagy a LOD. Ezeknél az ugyanúgy bindless rendszerrel dolgozó Nitrous motorral Ashes of the Singularity mérföldekkel többet jelenít meg. Az AC Origins terhelésének akár a 20-sorosát, és még jobb is a sebesség, ráadásul egy stratégiánál agresszív LOD-ra nincs is igazán lehetőség, tehát még a szituáció is sem a Nitrousnak kedvez. A probléma tehát nem a hardverekkel vagy a beállításokkal van. Ha ez lenne a gond, akkor az Ashes of the Singularity maximum 3-5 fps-sel futna a csúcsgépeken, de nem ezt látjuk.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#31122
üzenetére
Nem kellene annyit dolgoznia rajta. Számos módja van annak, hogy a D3D11-et támogassák újszerű motorstruktúrával. Például kaphat a motor kétféle low-level back-endet. Egyet bindlessel, és egyet a D3D11 binding API-jára írva, amelyeken keresztül támogatható akármelyik API.
Ezzel lenne egy ilyen rendszer:
'
Játék
||
High-level leképező
|| ||
Low-level leképező Low-level leképező
|| ||
OpenGL/D3D11 Vulkan/D3D12Ennek az előnye, hogy mindegyik API-ra wrapper nélküli, gyakorlatilag natív a path, viszont hátránya, hogy eléggé melós, mert kétféle low-level leképezőt írnak a kétféle bindinghez, és a közös high-level leképező miatt a gyártóknak egy külön drivert is kell írni a játékra a jó D3D11/OpenGL sebességhez. Így működik egyébként a Nitrous, és csak azért fut jól D3D11-ben, mert az AMD és az NV írt rá egy külön, alternatív D3D11 implementációt.
A másik megoldás ez:
'
Játék
||
Mid-level leképező
|| ||
Binding wrapper Low-level leképező
|| ||
OpenGL/D3D11 Vulkan/D3D12Ennek az előnye, hogy sokkal kevesebb meló a programfejlesztő oldalán, főleg úgy, hogy elég sok kód van meg régebbről, mivel nem nulláról készült a motor, illetve nem kell két különálló low-level leképező. A modernizált mid-level rész támogat mindent, amivel működhet a D3D11/OpenGL, és csak egy wrapper kell alá a bindinghez, míg a bindless kód működhet a Vulkan/D3D12-vel egy low-level leképezőt berakva, ami tartalmazza a memóriamenedzsmentet és kezeli a hazardokat, ugye a bekötés eleve mid-level szinten van itt kezelve. Emellett járulékos előny, hogy nem kell külön legacy implementációt írni a gyártóknak hozzá. Ilyen az AC Origins motorja. Az egész hátránya persze, hogy rohadt lassú a legacy path, és egy rakás felesleges munkát ró a CPU nyakába.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#31118
üzenetére
Az Intel csomagolja az egyes CPU-i mellé. Az AMD és az NV nem valószínű, hogy addig ezzel foglalkozni fog, amíg a binding wrappert használ a játék. Ezzel csak egy rakás CPU-erőforrást elköltenek a semmiért, aminek a GPU issza meg a levét. Ezt így nem lehet kitenni az ablakba. Főleg úgy, hogy az AMD és az NV is régóta olyan előadásokat tart, ahol erről az irányról lebeszélik a fejlesztőket, mert oké, hogy egyszerűen beépíthetővé teszi a bindlesst, de borzalmasan lassúvá válik általa egy potenciális D3D11/OpenGL mód, amire mondjuk esetleg még szükség lehet, ha a D3D12 mód mégsem működne jól a startra.
-
#31119
Abu85
HÁZIGAZDA
->Raizen<-
#31101
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#31101
üzenetére
Arról van szó, hogy mindegy, hogy mi az átlagos sebesség a játékra eléggé jellemző, hogy bezuhan az fps, majd visszamegy. Ez eléggé jellemző dolog a Steam fórum alapján, bár hardverenként eltérő a mértéke. A másik jellemző tényező, hogy a városokba érve az fps összeomlik. Ott ez a sebességfluktuáció extrémmé válik még 1080 Ti-vel is [link], illetve a cutscene-ek konkrétan akadoznak mindenkinél [link].
Az egésznek az az oka az, hogy az új AnvilNext már nem az a régi iRender stílusú motor, hanem átrakták bindlessre.
De mivel a D3D12 támogatást még csak az Xbox One kapta meg, így PC-n a bindless miatt még van egy extra binding wrapper is a leképező és a D3D11 API között. Mert a D3D11 az alapértelmezetten írt bindless leképezőt nem tudja kezelni, ha egy wrapper nem fordítja át neki bekötést. Ez a wrapper egyébként az Intel és az Ubi közös fejlesztése.
-
#31064
Abu85
HÁZIGAZDA
huskydog17
#31063
Abu85
HÁZIGAZDA
válasz
huskydog17
#31063
üzenetére
Tehát építettek egy időgépet, és visszautaztak a holnapi patch-csel. Nice.
Gondolom ezért cserélik a preview kódokat holnap az Influence programban. A preview nem frissíthető, míg az Influence-en belül küldött kód az retail minősítésű, ami így frissíthető is a patch-ekkel. Persze újra le kell tölteni a játékot, de belefér a mai netes sebességek mellett. Azt amúgy kötve hiszem, hogy ők mindenki más előtt kaptak hozzáférést az Influence kódokhoz. Ez példátlan lenne, mivel ezek egységesen kerülnek kiküldésre, méghozzá holnap. Ez mindig így volt, a Prey-nél, a The Evil Within 2-nél és erősen kétlem, hogy most megváltozott. Szóval bocsánat, ha jobban hiszek az programot szolgáltatónak, mint a ComputerBase-nek, elvégre én is a részese vagyok ennek a programnak, tudnák róla, ha módosultak volna a feltételek, vagy ha itt lenne a végleges kód a mailboxomban.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#31060
üzenetére
Miért? Nekem is van már hozzáférésem az aktuális journalist preview verzióhoz, de hozzá van írva, hogy a végleges csak 27-én lesz elérhető. Ahhoz később jön meg a PH-s kód, mert az Influence programon belül kapott hozzáférés nem szűnik meg novembertől, az olyan, mintha megvettük volna (ehhez van review guide a mérések megkönnyítésére), míg a journalist preview verzió csak októberben használható, utána lejár a licenc.
Ebben egyébként van Denuvo is, remélhetőleg a véglegesben nem lesz.Legalábbis abból kiindulva, hogy a The Evil Within 2-nél a journalist preview Denuvós volt, míg a végleges nem. Tök jó, hogy ezeket a dolgokat jobban tudod azoknál, akiknek konkrétan van hozzáférésük a programhoz.Szerk.: Bocs. Megnéztem még egyszer és Denuvo nincs a journalist previewben sem. Erre tévesen emlékeztem. Úgy néz ki, hogy a The Evil Within 2 volt az utolsó mohikán.
-
#31059
Abu85
HÁZIGAZDA
huskydog17
#31058
Abu85
HÁZIGAZDA
válasz
huskydog17
#31058
üzenetére
Akkor nem végleges kódjuk van, mert ~5%-ot gyorsít a deferred a binning architektúrákon. A többin ~1-2%-ot lassít. Azért van kikapcsolva, mert a régebbi hardvereken lassít egy picit, amelyek amúgy sem elég gyorsak, míg azokon gyorsít, amelyek újak, és alapból elég gyorsan számolnak. Viszont az új architektúrákhoz ajánlott bekapcsolni.
A GPU-culling hatása leginkább az átlagos CPU-kon látszik meg. Ha van már hat magod, akkor gyakorlatilag mindegy, hogy ki vagy be van kapcsolva. De ha nincs minimum hat magod, akkor nyilván többet ér a GPU-val számoltatni, hiszen elég sok vektormatematikai műveletről van szó, amit nem feltétlenül jó ráereszteni a procira, hiszen annak van más dolga is, míg a GPU-n sokszor pihennek a multiprocesszorok, és oda be lehet szúrni a számítást. Tehát arról beszélünk, hogy messze nem arról van szó, hogy az NV-n kikapcs, az AMD-n pedig be.
Csak nálunk nincs olyan, hogy az egyik hardveren aktiválunk valamit, míg a másikon nem. Vagy be van kapcsolva, vagy nincs. Ez a lényege az azonos tesztkörülménynek. -
#31056
Abu85
HÁZIGAZDA
huskydog17
#31055
Abu85
HÁZIGAZDA
válasz
huskydog17
#31055
üzenetére
Én a review guide alapján írom ezt. A deferred renderinget azért rakták bele, mert az utóbbi időben jöttek olyan "binning" architektúrák, amelyeknek ez jobban fekszik. Ilyen a Maxwell, a Pascal és a Vega. Ezek ezen a beállításon nyernek. Elképzelhető, hogy a többi architektúra veszít rajta, de most őszintén ez kit érdekel? Úgyis a legmodernebbeket nézi mindenki. Csak azért hülyeség kikapcsolni valamit, mert a Kepler/GCN1/2/3/4 ettől egy picikét lassabb lehet, a modern hardverek viszont komolyabbat ugranak tőle.
Csak a Kepler és Maxwell esetében érdemes ezzel élni, mert a GPU-culling aszinkron compute-tal valósul meg, és ezt a Pascal már támogatja Vulkan alatt. Azt pedig sajnos nem jegyzik meg, hogy ha ezt kikapcsolod, akkor erősen ajánlottá válik a hat-nyolcmagos proci is, mert a CPU futtatja le AVX-en azt a sok vektormatematikai számítást, amit a GPU csinál aktivált móddal. Mivel a legtöbb embernek négymagosa sincs, így még az is lehet, hogy Kepler/Maxwell esetében is gyorsabb marad a bekapcsolt állapot. A végleges verzióra én ezt jobban kifejteném a menüben, mert túl általános, hogy az NV-n ki, az AMD-n be. Valójában nagyon konfigurációfüggő, hogy mi az előnyösebb. Az persze világos, hogy a PCGH nem futott teljesítményproblémába 16-szálas core i7-6900K-val, amit még fel is rántottak 4 GHz-re, csak kételkedek benne, hogy a felhasználóknak is ilyen gépük van otthon.
-
#31054
Abu85
HÁZIGAZDA
Firestormhun
#31051
Abu85
HÁZIGAZDA
válasz
Firestormhun
#31051
üzenetére
Nincsenek, mert a deferred rendering pont a mozaikos optimalizálást használó hardverekhez készült. Vega, Pascal, Maxwell. Direkt azért rakták bele, mert a forwardhoz képest lényeges előnyt tud felmutatni. Kár volt kikapcsolni. A régi hardverek úgyis halottak, lásd GTX 770. Vagy akkor a Pascal, Maxwell, Vega trióra kapcsolják be, a többire pedig ki. De úgy sem lesz olyan játékos, aki nem fogja bekapcsolni egy modernebb architektúrán, hiszen sebességet ad minőségvesztés nélkül.
Az meg kicseszés az NV-vel, hogy a GPU-culling náluk nincs bekapcsolva, hiszen így a CPU végzi el ezt a feladatot. Azért az nem kevés extra meló, amit egy négymagos 4 GHz-es Core lehet, hogy megold, de egy gyengébb procit azért meggyötörne. Most vagy vágja ki a nem látható háromszögeket a GPU, vagy mindkettőn csinálja ezt a CPU. Szóval finoman szólva is furcsa a teszt.
-
Abu85
HÁZIGAZDA
válasz
Fred23
#31028
üzenetére
A Vulkan nem jelenti a Linux Gaming feltámadását. Az csak egy API, ami megold egy apró problémát a tucatnyi közül. Ettől a Linux még ugyanúgy széttagolt lesz. Dave Airlie, a Red Hat szoftvermérnöke elég jól összefoglalta, hogy mire lenne szüksége a Linuxnak, hogy játékra alkalmas legyen. [link]
-
Abu85
HÁZIGAZDA
válasz
Fred23
#31023
üzenetére
A DX11-gyel nincs gond. Azzal van baj, ha csinálsz egy bindless motort, és azt rétegezed be a DX11 binding API-jába. Ez így nem natív, hanem emulált támogatás lesz, ami nem egy sebességbajnok megoldás. Nem véletlen, hogy az Xbox One X 4K-val is 30 fps fölött van, míg ugyanúgy high grafikán PC-n erre csak a legerősebb VGA-k képesek, pedig ezek aztán számítási teljesítményben jó háromszor az Xbox One X fölött vannak.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#31018
üzenetére
Nem az effektek jelentik a problémát, egy rakás eljárást szállított bele az Intel, az AMD és az NV egyszerre. Ezek effetek, vagyis lelőhetők. Kockázatos viszont egy olyan váltás, ahol az AnvilNextet átállt bindlessre, de egy olyan megoldásra, amit soha senki nem próbált ki előttük, majd végül esetleg nem is használja. Így viszont, hogy már bindless a motor, nem kompatibilis a DX11 CPU oldali binding API-jával, amihez kell írni egy extra kompatibilitási réteget. Ezek a beavatkozások csak lassítják a teljesítményt.
Igazából az AnvilNext rétegezett bindless modellje mindig kérdéses volt. Ha annyira bízna benne az Ubisoft, akkor a Dunia is így készült volna, vagy mondok közelebbit ... már az AC Origins konzolverziói sem használnának teljesen eltérő struktúrát.
Az meg, hogy egyelőre egyedül az Intel élt az opciós jogával az AC Originsre, nem túl biztató. Könnyen lehet, hogy az AMD és az NV nem tartja elég jó minőségűnek a portot. Nekik ott a Wolf 2 és a Destiny 2. Azokra simán fel lehet építeni az ünnepi szezont, és igazából sokkal több erőforrást öltek ezekbe a címekbe.A szerződéstől függ majd a gyártók reakciója. Valószínűleg az AMD hagyja a fenébe, mert nekik eleve exkluzív joguk van a Far Cry 5-re. Az NV esetleg vásárolhat némi kulcsot, hogy egy-két hétig elég legyen, így letudják ezt is lényegében csendben, megúszva egy újabb AC Unity botrányt. Abból ítélve, hogy mennyire sok Destiny 2 kulcsot vettek egyértelmű, hogy nem az AC Origins-szel akarják felépíteni az ünnepet. Én is inkább a Destiny 2-re építenék, bármennyire is elavult a grafika, az optimalizálása elég jó, és elég nagy cím is. Az AMD meg viszi erre az időszakra a Wolf 2-t. Kb. ugyanaz a szituáció.
-
Abu85
HÁZIGAZDA
válasz
Fred23
#31012
üzenetére
Eredetileg ugye a DX12 új bekötésére készült, tehát a DX11 is úgy van a motorban, hogy emulálja a régi binding API-val való kompatibilitást. Szóval ez a DX11 igazából senkinek sem jó.
(#31017) Fred23: Igazából az AMD-nek és az NV-nek nem sok köze van az AC Origins-hez, mármint fejlesztési szerződés szintjén. Az Intel volt a legfőbb fejlesztési partnere erre a címre az Ubisoftnak. Ettől függetlenül a játék használ technikákat mindhárom gyártótól, de a többieknek reklámszerződésre volt lehetőségük.
Annyit tudni, hogy volt az Ubinál egy nagyon ambiciózus projekt, hogy átrakják bindlessre az AnvilNextet. De olyanra, hogy már maga a motor lekezelje a root signature különbségeit, és elfedje a hardverek eltéréseit. Nem tudni, hogy ez mennyire jött be, ettől függhet a DX12 elérhetősége is. De az beszédes, hogy a Far Cry 5 esetében a Dunia új verziójára egy teljesen más megoldást választottak. Persze az AnvilNext csapatának az Intel és az NV adott tanácsokat, míg az AMD inkább exkluzív szerződést kötött a Dunia csapatával.
-
Abu85
HÁZIGAZDA
válasz
Remus389
#31002
üzenetére
Azért nagyon fontos, hogy az up to nem azt jelenti, hogy minden gyorsul, hanem azt, hogy akár 10% is lehet bizonyos konfigurációkon a frissített game móddal. De az up to miatt bármi lehet még 0 és 9% között. Főleg a gyengébb teljesítményű gépek gyorsulnak. Minél gyengébb a proci, annál több a boost. A tesztoldalaknál ezt nem fogod meglátni, mert mindig a leggyorsabb procikat használják. Náluk nem lesz több 1-2%-nál.
-
Abu85
HÁZIGAZDA
válasz
-FreaK-
#30975
üzenetére
Hivatalosan azt lehet mondani, hogy egy "up to 10%-ot" vállalt be az MS az optimalizált game módra, de kerülik az általánosítást, leginkább az az üzenet, hogy teszteld magad. Viszont az "up to" dologban ugye benne van a 0 is. A 10% fölötti javulás az nem az MS miatt lehet, akkor up to 20%-ot írtak volna.
-
Abu85
HÁZIGAZDA
Frissített az MS, írták is, hogy kb. 5-10% közötti a boost aktivált game móddal, de nehéz általánosítani a gép- és programfüggőség miatt. A kisebb teljesítményű gépeken nagyobb lehet a javulás. Nagyjából ugyanezt mondták a gyártók is. A Vega azért lehet látványosabb, mert az egyetlen Fall Creators drivere a 17.40-es, amiben ugye a Redux bétája, aktivált NGG-vel, míg a korábbi meghajtókban ez eleve nincs benne. A 17.40 pedig nem jó a régi Windowsra, eléggé instabil alatta. Azt is tudni már, hogy az NGG a jelenlegi állapotában ott segít, ha egy játék érzékeny a memória-sávszélességre. Ha nagyon, akkor az NGG sokat hoz a konyhára, mert rengeteg terhet levesz a GPU válláról azzal, hogy még azelőtt kidob egy rakás nem látható, de amúgy fals pozitívnak ítélt háromszöget, mielőtt egyáltalán beterhelnék a felesleges számításokkal a memóriabuszt. Egyelőre ennyit tudni.
-
Abu85
HÁZIGAZDA
A TSMC-nél sorban állnak a gyártósorért. Ott már nincs alkupozíció. Ha a legtöbb pénzt kínálja egy cég, akkor az övé a gyártósor. Ennyire egyszerű.
A HBM-es megoldások esetében nem pont a node határozza meg a választást. Sokkal inkább az számít, hogy kinek a tokozása a kedvezőbb az előállítási lánchoz. Az AMD hosszú távon a Samsunggal képzeli el ezt az irányt, tehát nekik a Common Platform bérgyártói a kedvezőbbek. Az NV a Hynix partnere, így számukra a TSMC az ideális.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#30902
üzenetére
Igazából ez nem probléma elvi szinten. Rá kell licitálni az Apple és más konkurensek ajánlataira. A TSMC-t csak az érdekli, hogy ki fizeti a legtöbbet a gyártósorért. Az, hogy annak a cégnek Apple vagy NVIDIA a neve, vagy akárki, gyakorlatilag teljesen mindegy. Szóval kapacitást szerezni igen egyszerű a TSMC-nél, csak borzalmasan drága.
-
Abu85
HÁZIGAZDA
Nem előnytelen a TSMC-nél gyártani. Attól függ az egész, hogy milyen lapkák készülnek ott. Ha drágán kerül eladásra a termék, akkor akár licitháborúzni is lehet az Apple-lel. Az NV a Samsunghoz a kisebb lapkákat viszi, ahol nincs igazán lehetőség nagy árcédulát szabni, a GP107-nél már előnytelen lenne a TSMC, mert nem kiszámítható. A Samsung a GTX 1050-es sorozat árszintjére, illetve ez alá, sokkal jobb ajánlatot tud adni. És arányaiban a GTX 1050-es sorozat fontos, mert messze többet adnak el belőle, mint a gyorsabb modellekből, tehát számít, hogy ezek milyen áron készülnek.
A mennyiségkülönbség határozza meg az eredményeket. Ha az AMD adna el annyit, amennyit az NV, akkor az NV-nek lenne problémája a profittal. -
Abu85
HÁZIGAZDA
válasz
lezso6
#30894
üzenetére
Igazából ma már nincs tipikus ételemben vett High Performance node. Ilyen alacsony csíkon már nem tudsz akkora különbséget betervezni. A manapság élő modell az, hogy lesz egy LP node tervezve, és azt alakítják a továbbiakban. A GloFo 7 nm-es node-jánál azért alakult ki ez a nézet, mert az IBM technológiája, de ez nem fog drámai különbséget okozni.
Az AMD leginkább a Common Platform miatt marad, mert a Samsung és a GloFo még mindig együttműködik bizonyos technológiákkal kapcsolatban. Ráadásul elég szorosan. A GloFo új eljárásai például támogatni fogják a Samsung második generációs I-Cube tokozását, ami már lehetőséged ad a szilícium nélküli interposer alkalmazására.
-
-
Abu85
HÁZIGAZDA
válasz
Anubris
#30886
üzenetére
Ez nem érdekes. Ez a normális. Attól, hogy a textúra részletessége nő, még ugyanannyi mintavételezés történik a hardver részéről, mintha low lenne a beállítás. Egyedül memóriából kell több, de ha az megvan, akkor a textúrarészletesség állítása nem okozhat érezhető sebességkülönbséget.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#30882
üzenetére
API interoperability-vel létezik ilyen. Valszeg ID3D11Device5-ös interfészt használ Windows 10 alatt a program. Ezért is ajánlott hozzá a Creators. Ezzel az interfésszel az API-n belül szinkronizálhatók a létrehozott eszközök. Nem kell hozzá NVAPI-t vagy AGS-t használni. Cserébe Creators frissítés alatt nem is szinkronizál, tehát jelentős hatékonyságot veszít a több eszköz kezelése. Emellett ezzel elérhető az OS által menedzselt shader cache is, cserébe a driver által menedzselt módok ugranak. Ezzel hiába DirectX 11-es a program, jó minőséget csak a Windows 10 Creators biztosít, mert a Device5-ös interfészre írt funkciók Device1-gyel nem futnak, és a Microsoft a Device5-ös interfészt egyetlen korábbi OS-be vagy frissítésbe sem portolta vissza.
A feature_level itt lényegtelen, egyszerűen azért igényli, mert a Device5-ös interfész a legmagasabb szinteken van definiálva.
-
Abu85
HÁZIGAZDA
Van a szerződésnek árnyoldala. Az AMD bizonyos események teljesülése után büntetést fizet, cserébe rohadt olcsón kapja a wafert. Az AMD-nek ebben az az üzlet, hogy így mindenkinél olcsóbban tud gyártatni, viszont ha az egyik kritérium bukott, akkor büntetést fizet érte. A GloFo-nak ebben az az üzlet, hogy az AMD termékei szolgálnak alapként a gyárak kihasználtságához, ezért cserébe nagyon olcsón adja a wafert.
Ha nem kötik meg ezeket a feltételeket, akkor nem kapnak olcsón wafert.
(#30879) Loha: Valójában az NV sem gyártat mindent a TSMC-nél. A kisebb GPU-kat a Samsunghoz viszik, mert egyszerűen túl drága a TSMC, hogy ezek egy licitálós modellel nyereségesek legyenek. A Samsung kiszámíthatóbb, és olcsóbb.
-
Abu85
HÁZIGAZDA
Ez nem ilyen egyszerű. A szerződés is sokat számít. Az NV a TSMC-nél licites ügyfél, míg az AMD a GloFo-nál take-or-pay modellel van. Ez azt jelenti, hogy az NV úgy szerez kapacitást, hogy licitál a gyártósorra az Apple-lel, és más konkurens megrendelőkkel, és a TSMC annak adja el, aki a legtöbbet fizeti. A GloFo és az AMD előre meghatározott mennyiségre kötött szerződést, vagyis az AMD nem licitál, de van például büntetés. A két modell alapvetően különbözik. A licitálás hátránya, hogy eléggé drága lehet a wafer a versenyhelyzetben, viszont annyit rendelsz, amennyi igazából kell, tehát nagyon jól lehet igazodni az igényekhez. A take-or-pay modellnél a bérgyártó számít arra, hogy az igényelt kapacitást tuti kihasználja a partner, ez garantálja, hogy a gyár normális kihasználással üzemeljen. Cserébe olcsó a wafer, viszont ha mégse teljesülnek a szerződési feltételek, akkor a megrendelő büntetést fizet, így ennek a modellnek ez az igazi hátránya.
A memóriák helyzete sem egyszerű. A memória akkor olcsó, ha legalább két gyártó kínálja. Ugyanis így versenyhelyzet alakul ki, és a memória kezdeti ára folyamatosan lefelé halad. Az a memória hátrányos, amit csak egy gyártó kínál, mert a kezdetekhez képest az ár folyamatosan növekszik. Utóbbi azért van, mert az adott gyártó nem tudja elfogadtatni a megoldását a többi konkurenssel, így alapvető érdeke lesz egy generáció alatt visszatermelni a befektetett pénzt (elvégre nem lesz következő generáció), azt pedig csak folyamatos árnövelés mellett lehet megtenni.
A memória mennyisége is számít. Nem mindegy, hogy elég 1-2-4 lapka az adott kapacitás eléréséhez, vagy szükséges 12-16-24-32 lapka.Az interposer legalább annyira előnyös, mint amennyire hátrányos. A rendkívül sok lábas routing nem egy olcsó dolog a méretesebb VGA-knál. Azért a legerősebb VGA-kon 12-16 memóriacsatorna kivezetésre kerül.
-
#30849
Abu85
HÁZIGAZDA
FollowTheORI
#30847
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#30847
üzenetére
Meg igazából a D3D12-ben a kernel driver tűnt el, és nem a user mode driver. Utóbbi ugyanúgy megvan, és például shader cserékkel, fordítóoptimalizálással, bekötésre vonatkozó rutinokkal ugyanúgy lehet még optimalizálni. Az NV-t ma inkább az hátráltatja, hogy volt egy relatíve jól összerakott D3D12 implementációjuk, de ezt a nyáron kicserélték egy másikra. Tehát két év munkát csak úgy kidobtak. Az meg világos, hogy egy három hónapos implementáció lehet, hogy stabil, de az is biztos, hogy messze van még az optimálistól. De mondjuk egy-másfél éves távlatban simán elképzelhető, hogy ez az új implementáció jobb lesz, mint a leváltott verzió. Valszeg számítottak arra is, hogy az első fél-egy évben lesznek problémáik vele.
-
#30848
Abu85
HÁZIGAZDA
cskamacska
#30844
Abu85
HÁZIGAZDA
válasz
cskamacska
#30844
üzenetére
Nem érdemes a Vulkan API-t általánosítani az ID software játékokra. Az ID ugyanis nem úgy dolgozik, ahogy egy másik cég. Az ID tech6 abban mindenképpen egyedi, hogy amikor szállítják rá a portot, akkor nem egységes a motor. Két csoport van a programfuttatás szempontjából. Egy általános, amelynél szabványos GLSL kódot fordítanak SPIR-V-re, és egy speciális, amelynél PSSL kódot fordítanak SPIR-V-re. Előbbi esetben a SPIR-V kód csak KHR előtagú SPIR-V kiterjesztést használ, míg utóbbinál KHR, EXT és AMD előtagút (itt vannak a kiterjesztések: [link]).
-
Abu85
HÁZIGAZDA
válasz
Raymond
#30788
üzenetére
Nincs alcsoportozás. Összesen ennyi felhasználó vett részt eddig a surveyben. Direkt megkérdeztem tőle, hogy ez hónapról-hónapra, miképpen változik. Szeptemberben ehhez a 975 283 felhasználóhoz kerülnek hozzáadásra a szeptemberi kitöltők. Októberben a szeptemberihez, és így tovább. Emiatt írom, hogy a minta rendkívül kevés, és nem kontrollált.
(#30789) Locutus: A Valve-tól ezt régebben kérdeztem, és azt írták, hogy azt a GPU-t találja meg, amelynek az eszközazonosítója a legkisebb a Windowsban az elérhető GPU-k közül.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#30786
üzenetére
[link] - elvileg megközelítőleg sincs 125 millió felhasználó.
Én csak azt jelzem, hogy nálam biztosan nem azt méri, hogy mit használok, hanem amilyen hardvert elsőnek talál és azt hiszi, hogy azt használom. Ha úgy gondolod, hogy ez így reprezentatív, akkor OK.
Én elég sokáig tanultam statisztikát ahhoz, hogy tudjam miképp lehet valami reprezentatív, és miképpen nem. -
Abu85
HÁZIGAZDA
válasz
Raymond
#30784
üzenetére
Nem. Sajnos ez nem látszik. A Steam csak az első talált GPU-ig keres. Például nekem is csak a GeForce GT 240-et találja meg, holott monitor sincs rákötve. Emellett még aktív két Radeon a gépben (az egyiken egy monitorral és tévével, a másikon egy tévével). Ezeket nem látja. Nem is tudom neki megmondani, hogy "te hülye nem azt a hardvert használom megjelenítésre, amit megtaláltál".
-
#30783
Abu85
HÁZIGAZDA
Petykemano
#30782
Abu85
HÁZIGAZDA
válasz
Petykemano
#30782
üzenetére
A piackutató cégek azt mérik, amit megrendelsz, vagy azt, amire általános igény van, utóbbi utólag eladható. Nem véletlen kerül rengeteg pénzbe a például a JPR jelentése. Sokezer dollárt elkérnek érte.
A Valve is tudna jól mérni, mert az egész csak statisztika, ez pedig egy külön tudományág, csak be kell tartani a szabályait. A probléma az, hogy a Valve ebbe nem akar pénzt rakni. Nekik nem ez a profiljuk, nem jön belőle bevétel, így le se szarják, hogy rossz a mintájuk, illetve az se különösebben érdekli őket, hogy a rendszer amit kidolgoztak folyamatosan mintavételi hibákhoz vezet. Ezeket utólag korrigálni nem tudják, illetve valószínűleg felvenni sem akarnak statisztikával foglalkozó szakembereket, mert ha ebből nincs bevétel, akkor feleslege egy külön csapatot megfizetni.
-
#30781
Abu85
HÁZIGAZDA
Petykemano
#30780
Abu85
HÁZIGAZDA
válasz
Petykemano
#30780
üzenetére
Mert alapvetően rossz az a mintavételi forma, hogy bárki kitöltheti aki akarja, illetve az sem célravezető, hogy négy survey lesz összevegyítve, ahogy az is rengeteg hibát generál, hogy nem mindenkinél jelenik meg a kitöltés lehetősége.
Itt nincs semmiféle csalásról szó. Egyszerűen a mintavétel formája minden statisztikára vonatkozó szabályt felrúg. Ezt a Valve úgy kezeli, hogy nem reprezentatív statisztikának tekinti.
Ez akkor lenne működő formula, ha a userek gépét a steam minden bejelentkezésnél ellenőrizné és elküldené az anonim statisztikába. Ezzel biztosítható lenne, hogy aki bejelentkezik az részt vesz benne, illetve egy user csak egy gépadatot küld, ráadásul folyamatosan frissülőt. Ugyanakkor ez még anonim formában sem számít sok országban törvényesnek, ha nem fogadja el a felhasználó, mint használati feltételt, tehát ezzel a Valve nem tud kezdeni semmit. Illetve az egész nem ér annyit, hogy ezzel foglalkozzanak, mert nekik pénz ebből nem származik. A stúdiók és kiadók úgyis külön megbíznak cégeket, hogy mérjék fel nekik a piacot.
Arról nem is beszélve, hogy ha a Valve ezt csinálná, akkor abból mekkora műbalhét kreálnának a userek, hogy mi köze van az adataimhoz, stb. Szóval önmagában egy kötelező adatküldést bevezetni egy komoly presztízsveszteség lenne a Valve számára.Ez nem a felülreprezentálásról szól. Az Intel például borzalmasan alul van reprezentálva, holott a GPU-piac 70+ százaléka az övék.
-
#30776
Abu85
HÁZIGAZDA
cskamacska
#30775
Abu85
HÁZIGAZDA
válasz
cskamacska
#30775
üzenetére
Ez egyáltalán nem ilyen egyszerű. Maga a mintavétel jellege a probléma, és nem az, hogy valaki kitölti-e vagy sem, vagy ismeri a titkot, hogy miképp lehet négyszer is kitölteni.
(#30774) solfilo: Az a baj, hogy a mindfactory.de is ugyanúgy nem reprezentatív. Ami a Steam hw survey-re elmondható, az elmondható a mindfactory.de-re is. De hasonlóan nem reprezentatív a Passmark submission survey sem. Ha ezeket nézed, akkor folyamatosan csak azt kapod, hogy egymásnak ellentmondanak. Ezért vannak reprezentatív statisztikák, amelyeknél kiemelten ügyeltek a megfelelő mintavételre.
-
Abu85
HÁZIGAZDA
válasz
solfilo
#30770
üzenetére
Ezt írom. Amíg egy statisztikában nem biztosítják minta sokaságát, és nem foglalkoznak olyan dolgokkal, mint az információkiértékelés, a korreláció és a regresszió, addig az a statisztika nem tudja követni a piaci valóságot. Ez nem találgatás, felhívja rá a figyelem a Valve, hogy ez egy nem reprezentatív statisztika, ezáltal a közölt adatok leginkább informális jellegűek, de a piaci valóság akár teljesen más is lehet. Semmilyen formában nem tudják biztosítani azt, hogy a mintavétel az általános statisztikai szabályok betartásával történjen. Még az sem biztosított, hogy a Steam survey mindenkinél megjelenjen, illetve ahogy fentebb írtam négy survey van összevegyítve, vagyis az sem biztos, hogy egy gép csak egyszer lesz benne és nem négyszer.
(#30771) Raymond: Tudom, hogy nem volt ott, ezért említettem meg, hogy most változik az egész. Annyira messze van a valóságtól, hogy valamit kezdenie kell vele a Valve-nak, még akkor is, ha ez egy nem reprezentatív statisztika. Az első lépés erre a korlátozások bevezetése, hogy mostantól az összesítésben csak az első három tételt mutatja meg. Ebből már nem jön le első ránézésre, hogy a reprezentatív statisztikák homlokegyenest mást mondanak, mint a Valve saját statisztikája.
(#30773) Raymond: A növekedés mindegy: [link] - itt korábban írták, hogy mennyi adatból van meg a statisztika. Akkor számítana a növekedés, ha mindenki rá lenne kényszerítve a kitöltésre.
-
Abu85
HÁZIGAZDA
válasz
solfilo
#30768
üzenetére
Ez a nem reprezentatív a statisztika, nem tudják követni a piaci realitást.
Probléma az is, hogy ez ellen a Valve nem próbál tenni. Például ma már VGA-k összesítésénél csak az első három tételt teszik láthatóvá. A többit besorolják az "Other"-be. Ezzel próbálják elrejteni a szabad szemmel is látható hiányosságait a felmérésnek. Valószínűleg előbb-utóbb már ez is el fog tűnni, és ugyanúgy ahogy a procinál csak egy multiprocesszorok számára vonatkozó érték lesz feltüntetve. Ezzel a statisztika az értelmét nem vesztené el, továbbá nem ordítana róla, hogy mennyire más a reprezentatív statisztikákhoz képest. -
Abu85
HÁZIGAZDA
A piac 70+ százaléka Intel IGP-t vesz. Ha tetszik, ha nem. Ez tény. Azzal, hogy ezt megkérdőjelezed, sőt rám akarod vetíteni, hogy én megkérdőjelezem, a vita értelmetlenné válik.
A grafikus vezérlő pedig grafikus vezérlő, függetlenül attól, hogy milyen formában csatlakozik a PC-hez. Az IGP-ket már csak azért sem lehet kihagyni, mert a PC-s GPU-piac 82%-át teszik ki. -
Abu85
HÁZIGAZDA
válasz
solfilo
#30760
üzenetére
A steam hw survey nem reprezentatív statisztika. Ez benne is van a Valve általános UELA-ban. Ez az egész csak azok között a felhasználók között van mérve, akik elfogadták a feltételeket. Ráadásul nem egy mérés van, hanem konkrétan négy. Tehát egy felhasználó akár négyszer is be lehet számolva az anonimitás miatt. Attól függ, hogy hány surveyt dob fel a Steam, lehet hogy egyet sem.
steam://takesurvey/1
steam://takesurvey/2
steam://takesurvey/3
steam://takesurvey/4
A fenti sorokat egyenként beírva a böngészőkbe máris négyszer felvitted a gépedet, ami az összesítésben meg fog jelenni.
Ezek mellett a Steam hw survey bevallottan egy úgynevezett torzított mintavételű statisztika, amelyen belül a becsült hiba nem kerül meghatározásra, és nem is kerül korrigálásra. Tehát alapvetően csak a mintavétellel foglalkozik, míg a minta sokaságának kérdésével, az információkiértékeléssel, a korrelációval és a regresszióval egyáltalán nem. Emiatt van olyan óriási különbség a steam hw survey és a reprezentatív statisztikák között. -
-
#30753
Abu85
HÁZIGAZDA
huskydog17
#30749
Abu85
HÁZIGAZDA
válasz
huskydog17
#30749
üzenetére
Mi a normális? Ezek a játékok adatra építenek. Minél több autó van a Forzában, minél több pálya, minél nagyobb részletesség, minél jobb textúrák, minél nagyobb felbontású videók, annál több helyigénye lesz. És ilyen nagy projekteknél tartani határidőt rendkívül nehéz. Nem véletlen, hogy a demót a legtöbb AAA cím inkább hanyagolja. Nincs rá idő.
Kezdjük ott, hogy a játékosok 93%-a nem is nyúl hozzá a grafikai beállításokhoz (ez friss adat az NV-től). Nem is nézik meg a sajtó méréseit. Egyszerűen nem érdekli őket. Ez a sajtónak is egy problémája. Rendkívül szűk az a réteg, amely egyáltalán tudja azt, hogy a felbontás átállítható egy játékban. A nagy többség, mondjuk úgy, hogy 10-ből 9 ember nem tudja, hogy mi az az fps. Ez a réteg ráadásul bővül, mert ma már a fiatalokat eleve úgy nevelik, hogy dobd be a lemezt a konzolba és play. Szóval ha a vásárlók többségét nézzük, akkor őket marhára nem érdekli az, amiről én írok, de az sem amiről te.
-
#30746
Abu85
HÁZIGAZDA
huskydog17
#30745
Abu85
HÁZIGAZDA
válasz
huskydog17
#30745
üzenetére
Az indiek nem 100 GB-os programokat fejlesztenek, még csak ennek a tizedét sem. Egyébként nem a pénz a probléma, hanem az idő.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#30740
üzenetére
Pont erről beszéltem. Nincs rálátásotok arra, hogy mekkora munkával jár egy demót kiadni.
Ellátható a teljes játék mondjuk időlimittel, de a problémát ilyenkor az jelenti, hogy le kell szedni a 100 GB-ot egy órás játékért, amit sokan nem tennének meg.
Miért baj az, hogy ez is egy opció az MS-nél? Sokan már demót sem adnak ki, mert borzalmasan időigényes elkészíteni. Akinek pedig nem kell a demó, megveszi a teljeset. Nem kötelező letölteni a próbaverziót. -
#30741
Abu85
HÁZIGAZDA
huskydog17
#30739
Abu85
HÁZIGAZDA
válasz
huskydog17
#30739
üzenetére
Szerintem nagyon sokan nincsenek tisztában, hogy a demó elkészítése mekkora teher. Egy ilyen AAA címnél, ha nem vonnak be egy alternatív csapatot, akkor egy demó három hónappal tolja meg a teljes játék kiadását. Emiatt szokás azt csinálni, hogy kiválasztanak egy stabilan futó verziót a gold előtt két-három hónappal és arra csinál egy demót pár fő. Ezzel lesz próbaverzió és nem csúszik az eredeti játék sem. A másik lehetőség, hogy nem lesz demó, de az, hogy a demó is ugyanaz legyen, mint a teljes játék csak pár hónappal a teljes megjelenése után lehetséges.
(#30740) Crytek: Akár a Steamben is megvásárolható lenne, ha a Valve beépítené az UWP támogatását. Ha a technikai akadály elhárult, akkor onnantól kezdve az egész már egy üzleti kérdés.
-
#30738
Abu85
HÁZIGAZDA
huskydog17
#30727
Abu85
HÁZIGAZDA
válasz
huskydog17
#30727
üzenetére
A demó régebbi verzió, mint a teljes játék. Szóval ahhoz nem, hogy patch nem lesz, de még rosszabbul is fut, mint ami kijött.
(#30731) TTomax: A G-Sync lehetséges, de ahhoz támogatni kell a drivernek a swapchain API-t, amin keresztül a Microsoft kezeli a variálható frissítési frekvenciát az UWP programokban. A Win32-es direkt elérés itt nem lehetséges, vagy a swapchain API vagy semmi.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#30681
üzenetére
Nem sok köze van a Vega eredményének a DX12-höz. Azért ennyivel gyorsabb, mert dupla olyan nagy a felhasználható LDS, mint a korábbi GCN-ekben. Mivel a Forza shaderjeit nem írják PC-re, hanem az Xbox One shaderekből konvertálják egy programmal, így már a korábbi részre is jellemző volt, hogy az LDS kapacitása limitálta a futtatható wave-eket lényegében minden architektúrán. A Vega azonban kezeli ezt a problémát, így ennél az architektúránál már több wave futhat, mint mondjuk a Polarison, még akkor is, ha ugyanaz a shader. Vagyis végeredményben a GPU kevesebb időt tölt el azzal, hogy vár az adatra. Az Xbox One-on ez azért nem probléma, mert ott ismerik azt a hardvert, amire fejlesztenek, és direkten képesek kontrollálni a GPU-n belüli erőforrás-allokációt. Ilyet PC-n nem lehet tenni. Túl sok az eltérő hardver, és nincs is olyan felület, amivel ez egyáltalán megoldható. Majd a Volta itt is jobb lesz, mert az NV összevonta az LDS-t és az L1-et, így a Vegához hasonlóan több LDS kapacitást ad.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#30641
üzenetére
Meggyőződésem, hogy most nem erre kutatják a választ, mert ezt könnyen el lehet érni a shaderekkel. Ezek viszont kicserélhetők, akár egy későbbi patch-ben, akár a driverben.
Én azért remélem, hogy ez az eredmény nem a bindless általános hatását mutatja, mert akkor csúnya lesz itt az AC: Origins és a Far Cry 5. Esetleg ha meghajtóban van a gond, akkor addigra megtalálják a probléma forrását. De elméletben nem kellene esnie a hardverek teljesítményének ennyit a bindlesstől. Kb. úgy kellene viselkedniük, mint a Vegának és a Polarisnek. A sample-ök sem mutattak eddig problémát, na persze az is igaz, hogy egy sample és egy játék között hatalmas a különbség.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#30631
üzenetére
Tudtommal a Warhammer 2-t egyik cég sem támogatja. Amolyan árva játék ilyen szempontból.
Igazából a DX12-ben nem kellene ekkorát esnie az 1070-nek. Elvégre a bindless egy sebességnövelő funkció, aminek +1-3%-ot kellene hoznia. Ez megkérdőjelezi a bindless használhatóságát, és akkor tudjuk, hogy az Ubisoft is erre áll át a következő körben. Lehet, hogy korai még. Az is kérdés, hogy az NV jól tette-e, hogy a 384.76-os meghajtónál bindless emulációra váltott át. Nem-e jobban jártak volna, ha marad az eredeti megoldásuk? Esetleg arról van csak szó, hogy még kevés erről a tapasztalatuk és lehet, hogy úgy egy éves távlatban mégis ez a jó megközelítés.
Azért vártam az első bindless játékot, mert sok kérdést tisztázott volna, de mondjuk úgy, hogy csak még több kérdés merült fel. A Polaris és a Vega működik ez megállapítható, viszont más szempontból csak pislogni lehet az eredményeken.
Ú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.
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Luck Dragon: Asszociációs játék. :)
- Hosszú premier előzetest kapott az Arknights: Endfield
- CURVE - "All your cards in one." Minden bankkártyád egyben.
- Vezeték nélküli fülhallgatók
- Milyen külső akkumulátort mobileszközökhöz?
- Kormányok / autós szimulátorok topikja
- Facebook és Messenger
- Meghozta a régóta várt asztali Ryzen APU-kat az AMD
- További aktív témák...
- BESZÁMÍTÁS! 2TB Samsung 980 PRO NVMe SSD meghajtó garanciával hibátlan működéssel
- Garmin Forerunner 405 GPS óra
- HIBÁTLAN iPhone 13 Pro Max 256GB Gold -1 ÉV GARANCIA - Kártyafüggetlen, MS3685
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- GYÖNYÖRŰ iPhone SE 2022 128GB Red -1 ÉV GARANCIA - Kártyafüggetlen, MS4535, 100% AKKSI
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest