Finomszemcsés preempcióval gyakorlatilag garantált az aszinkron timewarp elkészülte. Az NV-féle rajzolási szintű preempció is jó, addig amíg 2 ms alatt van az üzemmódváltás. Ha valami beragad 2-nél több ms-ra, akkor a timewarp garantáltan lekési a szinkronablakot. Ezek eléggé nyíltan beszélt problémák a fejlesztők és az Oculus/Valve, illetve a gyártók által.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Ahogy mondod, azok "VR szarok", nem játékok. Egyelőre egy normális, teljesen támogatott, ne adjisten AAA játék nincs VR-ra...

LG 27GL83A 27'' UltraGear™ QHD IPS 1ms Gaming Monitor with G-Sync®

Ne szaladjatok annyira előre, előbb DX12-es játék legyen már

[ Szerkesztve ]

* + jó AMD driver

Egyelőre VR sincs

[ Szerkesztve ]

© asszongya'hogy

És ez mit jelent geforceokra nézve?
Vagy most ez nem annyira erőforrás igényes?

Csak azt tudom, hogy Xbox One-on hogyan csinálják. Ott az OIT-t ordered atomicsre építve használják és mutexszel zárolják a wavefrontokat. Ennek az előnye, hogy memóriakímélő és gyors. Ezzel a módszerrel az OIT az Xbox One-on 1 ms-os feladat. A gond az, hogy a PC-be ezt csak GCN-re lehet átmenteni jó eredménnyel, mert nem minden hardver tudja a feldolgozási sorrendet. Láthatod a Lichdom Battlemage című játékban (patch előtt), hogy a mutex zárolás más hardveren is lefut, de az eredmény hibás lehet. A másik megoldás a PPLL adatstruktúra használata, amely megoldja a problémát minden hardveren jó eredménnyel, de 3-4 ms-ba kerül, tehát sokkal lassabb, mint a mutexes megoldás. A harmadik opció az OIT kikapcsolása, de akkor olyan ronda lesz mint a HairWorks.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Ezek a hardveres különbségek, a kérdéseim pedig a szoftverre, ill. a közönség érzékenységére vonatkoznak. Nyilvánvaló, hogy a GCN (még az első is) sokkal jobb hardver-alap VR-hez, mint a Maxwell (talán a Pascalnál is) - viszont ez nem magától fog kijönni, hanem a szoftverektől.
Ha egy játék stabil 400 FPS-sel megy, akkor nem kell preempció.
Ha egy játék állandóan droppol, akkor nem fog segíteni az aszinkron timewarp sem.
Ha ellenben másodpercenként 3-5 frame lesz eldobva, akkor könnyen lehet, hogy az AMD-n szuperül fog futni, míg az nVidia csomagolhat VR-ready zacskókat a cucca mellé.

Van legalább 3-4 olyan VR-ready AAA játék, amit ki lehet próbálni, és választ lehet adni ezekre a kérdésekre? Amíg nincs, addig szerintem felesleges nagy mondásokat tenni.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

A ritka drop nem számít. Nem kellemes, de viszonylag könnyen túléli az agy. A problémát az jelenti, ha folyamatosan lecsúszik a timewarp a szinkronablakról. Itt van egy olyan jelenség, hogy az aktuális grafikus API-kon belül nincs frame megszakítás. A megkezdett munkát be kell fejezni, még akkor is, ha már tudjuk, hogy a szinkronablakról lecsúszott. Ez akár még 3-5 ms-nyi extra számítást is jelenthet, de ugye már mindegy. Viszont a hardver innentől folyamatos hátrányba kerül, mert a még futó, de már felesleges számítás miatt késik az új, de fontos számítás.
Erre lesz egy megoldás idén, de csak a Mantle-be. Ez az instant killnek gúnyolt képesség, ami tulajdonképpen a szinkronablak lekésése után azonnal megöl minden késői timewarp-hez tartozó számítást.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

hm. szóval még gcn 1.0-n és/vagy 1.1en is problémás (különben nem lenne rá szükség).

Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.

Ha elköltök szumma 1200-1500 USD-t arra, hogy VR-ezzek, akkor a "nem kellemes, de viszonylag könnyen túléli az agy" kb. ekvivalens azzal, hogy "vigyétek a sz**otokat a p****ba" De lehet, hogy csak nekem magasak az elvárásaim.
Ha a program sűrűn lekési a szinkronablakot, az minden architektúrán gond lesz, mert abban látatlanban is biztos vagyok, hogy az aszinkron timewarp folyamatos használata csúnyán fog hatni a képminőségre. Szóval eleve úgy kell belőni a cuccot, hogy az idő elég magas %-ában biztosan tudja a 2x90 FPS-t - kérdés, hogy ez kinek mennyire sikerül jól. Ahol nem, akkor AMD-n ronda lesz az eredmény, nVidián pedig majd csak étkezés előtt lesz javasolt játszani...

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Nyilván, ha nem számít a pénz, akkor megveszed a Falcon Northwest Tiki-t és le van tudva. Vagy DIY alapon veszel egy Dual Fiji kártyát. Ezzel biztosan nem lesz gond, mert erre lett tervezve. Csak ennyiért autót is vehetsz majd.
Nem akkora gond a timewarp. Bőven megéri használni, mert biztonságos, hogy ha megkétszerezed a valós frame-számítás szinkronablakát.
Az AMD ma még nem alkalmaz semmilyen képminőséget csökkentő módszert a saját SDK-jában. Az NV alkalmaz egy multi-res shading eljárást, ami a kép szélét csökkentett minőségben számolja. Ezt a fejlesztő aktiválhatja, vagy letilthatja attól függően, hogy mennyire van a programja a "hányáshatáron".
A multi-res shading célja egyébként pont a timewarp szabadabb alkalmazása. Kevesebb számítással csökken a késés esélye.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Be szabad ezt ide vágni ? Nekem ez nagyon tetszett jól összefoglalták
beszélgetés az OCULUSról
"75 FPS a belépő hogy ne legyél tőle rosszul..."

[ Szerkesztve ]

Ha jól értem a VR tervezett működését, timewarpolni akkor is kell, ha fix 90FPS-sel megy a cucc, mert a gyors fejmozgás miatt a 11ms-os késés is sok, azt is érdemes utánhúzni. Ez talán még működik is jelentős torzítás nélkül, bár a "hiszem ha látom" alapelv itt is érvényes. Nekem azzal van problémám, ha a frame lekési a szinkronablakot, és akkor már 22ms-nyi mozgást kell utánhúzni - érzésem szerint ez már ronda lesz. Persze jobb a ronda, mint a hányás, de (szerintem) a ronda sem elég jó.
Ill. érdekes kérdés még, hogy ha a VGA fogja is bírni a 2x90FPS-t, vajon a CPU is fogja-e tudni a 90-et (gondolom, a scene-t elég egyszer számolni).

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Maga a timewarp eléggé általános megoldás, tehát többféle felhasználási módja van. Most, ha csak arról beszélünk, hogy mi az ideális, akkor nyilván egyértelműen az, ha minden kész nyers képkockát timewarpolunk. De ezt elsődlegesen azért tesszük, mert az aktuális szabványos grafikus API-k csak a jelenet kamerapozícióját fogadják el. Alternatíva a LiquidVR LDL funkciója, amely képes a jelenet kamerapozícióját megváltoztatni a képszámítás előtt. Ilyen módon úgy is kaphatsz felezett késleltetést, hogy nem timewarpolsz.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Ez a mondatod annyira zseniális hogy rá kellene nyomtati az Oculusra
"Jobb a ronda, mint a hányás"
De ha ennyire fontos az FPSt akkor azt hogy oldják meg hogy 90 alá ne essen le?
Mert akkor az kellene hogy azt fixre beállítod és ismerve a kártya adatait pl 970 és akkor magától beállítja a kártyához a grafikát, szóval hogy érted ne engedje be 90 alá semmiképpen.

[ Szerkesztve ]

Dinamikus felbontás, mint pl. a Halo 5-ben

Xbox Series X GT: Mcwolf79xy PSN ID: x_mcwolf_79_x

Komoly előrelépés a GDDR5X memóriaszabvány

Érdemes összehasonlítani a hwsw-s cikket, a ph-n a témában megjelent cikkekkel - érdekes különbségekre derül fény...

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Öööööö... Én azt hittem, hogy a kamerapozíció változtatása render előtt alap Akkor még 90FPS esetén is 22ms a késleltetés, ha pedig a frame késik, akkor 33ms. Az már nagyon sok, akár 8-10 fokot is kellhet korrigálni. Ouch.

(#13567) Pepeeeee: IHV oldalról fix FPS-t csak akkor tudnál, ha meg tudnád előre mondani a kép számítási idejét, az meg nem megy. Becsülni lehet, de az csak javítja a problémát, nem oldja meg. Továbbra is masszív overkill kell sztem...

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Lemaradt az Oculus?

A PH és a HWSW hír mintha nem is egyezne A hasonlóság kb annyi, hogy GDDR5x Ha ez így igaz, akkor várhatóan kb csak a csúcskártyákon lesz HBM2

Amugy is csak a csucskartyakon lesz mar egy ideje lehet tudni.

Én azért bíztam benne, hogy 980/280x szerinti új termékskálán is HBM2 lesz, de ilyen értékek mellett szinte már a csúcskártyán sincs olyan sok értelme. X2 megoldásokon jó lehet a helytakarékosság miatt.

Azert ebbol meg nem lattunk semmit, hogy tenylegesen mennyi az annyi, a HBM meg mar bizonyitottan tetemes elony a fogyasztasban.

A mi cikkünk nem a specifikációból származik, hanem a gyártói leírásokból, amelyek részben tartalmazták a specifikációt, de részletezve van, hogy az EMI, a tokozás, illetve az árnyékolás miatt, valamint a dupla órajel fogyasztásnövelő hatása miatt miket kell módosítani. Ez sajnos nem egyszerű. Csak akkor kell kevés módosítás, ha a GDDR5X GDDR5 módban működik, de ekkor nincs magas órajel. Viszont nem gond az EMI.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Az itteni cikk azt sugallja, hogy a GDDR5X sz*r (naná, nyilván csak a HBM lehet a király... ). A hwsw-s cikk alapján viszont komoly előrelépést hozhat (nyilván elsősorban az alsó- és középkategóriában).
Csak a negatívumokat sikerült kiemelned (nem igazán lett kihangsúlyozva, hogy a nagyobb fogyasztásért cserében dupla tempót kínál, illetve hogy bár az érintkezők száma nőtt, azonos tempó eléréséhez értelemszerűen fele széles memóriabusz elég, ergo a GDDR5-höz képest igenis jelentős fogyasztás-csökkenés és egyszerűbb nyák érhető el vele (azonos tempó mellett). Kimaradt, hogy a chipek mérete is csökkent.).

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Egon ha egy focicsapat az NB2 ben játszik az nem feltétlenül azt jelenti hogy sz rosszul játszik.
Lehetnek kifejezetten jó meccsei, de az akkoris csak az NB2-ben számít jónak.

Látom nem én vagyok ezzel egyedül. PH cikkben a GDDR5 egy elavult szar ramnak van írva, ahol szinte a gyártási értelme is meg van kérdőjelezve, míg HWSW, vagy Ipon

"Az alacsonyabb feszültségek és az újítások jóvoltából a GDDR5X memóriachipek azonos órajelen alacsonyabb fogyasztás mellett üzemelnek, mint GDDR5-ös társaik, ám a Micron szerint a helyzet változik, ha a gyorsulásban rejlő előnyt, azaz a magasabb effektív órajelet is kihasználják. Utóbbi esetben a GDDR5-ös memóriachipekével azonos, illetve némileg magasabb fogyasztásra kell felkészülni. A GDDR5X ennek ellenére is vonzó, hisz az azonos vagy picivel magasabb fogyasztás mellé jóval nagyobb teljesítmény társul, így az energiahatékonyság mindenképpen jobb."

Ez PH-ra fordítva: kell bele hőérzékelő, mert leolvad a nyákról.

Malibutomi: hol a bizonyíték? Hol vannak a mérések? Csak, mert itt nagy mendemondák elhangzanak, attól még nem bizonyít semmit sem. GDDR5 fogyasztása is bizonyított az összes nvidia kártyán. Szegény AMD-s gárda hirtelen vissza is bújt az asztal alá, hogy reszeljenek kicsit a kártyáikon.

[ Szerkesztve ]

A meresek a kartyak tesztjeiben vannak.
Fury X GPU-ban mindenbol ketszer annyi van mint az R9-380-ban, memoria dupla annyi rajta, a fogyasztasa megis csak kb 40%-al tobb.
A 290x-hez kepest kb 45%-al tobb cucc van a GPU-ban, a kartya fogyasztasa megis kevesebb mint az elode.

Szoval a GDDR5X lehet ugyanolyan gyors mint az elodje kevesebb fogyasztassal, vagy gyorsabb ugyanolyan de inkabb tobb fogyasztassal. A HBM pedig gyorsabb, joval kevesebb fogyasztassal, viszont dragabban.

Mindkettonek megvan a maga felhasznalasa, nem igazan utkoznek egymassal velemenyem szerint. Mas-mas kartyakon fognak feltunni.

[ Szerkesztve ]

A Tonga GPU valamelyik Apple cuccban szerepel és sokkal alacsonyabb TDP-vel, mint ami van nekünk asztali fronton. Emellett még tovább csiszolhattak a gpu-n is, hogy jobb legyen a fogyasztás.

290x pedig más architektúra, így összehasonlítani nem igen érdemes. Fury X pedig annyit fogyaszt, mint a 290X. Az a pici eltérés ami van, az bárminek betudható. Itt egy friss mérés, ahol nem is olyan rossz a fogyasztás.

Nem fikázom a HBM-et, nem akarok én rosszat neki, de az egész téma abból kezdődött, hogy hogyan állnak bizonyos hírportálok a GDDR5x-hez.

A másik, hogy kb minden legyártott Fruy/Nano cucc csíkoz, mert ilyen jól sikerült implementálni a HBM-et. A végén kiderül, hogy nem is lehet épkézláb terméket gyártani ezzel a memóriatípussal.

[ Szerkesztve ]

Én is így kezdtem,felébredtem,elszállt a köd...majd 980ti lett belőle amin állítólag radirgumi van memória helyett és még is körbefutja az összes jelenleg vga-t.

[ Szerkesztve ]

atszallhatott ide a kod

© asszongya'hogy

Dehogy szállt el. Most ereszkedik!

Milka magàval fog húzni engem is. Hüllő is napi szinten mondogatja, hogy térjek àt.

Na ezt megnézném!
Bár amióta olvasom a hszeid, egyszer már volt piros kártyád.

Ó... volt nekem több is! [link]

Biztos atszallt a kod az nvidiahoz, hogy ok is HBM-el adnak ki kartyat. Meg ok is megettek Abu teriteset...

Gddr5 esetén tudtommal a java részt a hosszú busz etetese fogyasztott sokat. Ezt meg csak a hbm esetén küszöbölték ki.

May the Force be with you!

Nem hiszem, hogy HBM-mel adnának ki kártyát. HBM2-vel inkább. A HBM pilotnak jó volt, és az AMD-nél szerencsés (balszerencsés?) módon volt is rá valós műszaki igény, a másik oldalon nem lett volna semmi értelme.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

HBM (high bandwith memory) mint technologia vs GDDR5. Ebben a kontextusban mindegy hogy 1 vagy 2.
A hangsuly azon van hogy a csucskartyaknal ok is valtanak a masik memoriatipusra.

[ Szerkesztve ]

Hogy lenne mindegy? Egy új technológia akkor válik relevánssá, ha a gyakorlatban is bizonyít. A HBM-nek ez nem igazán sikerült - bízzunk benne, hogy a HBM2-vel nem lesz semmi komoly gond, és akkor 12-18 hónappal a "pilot" után beszélhetünk arról, hogy a HBM sikeres, mint technológia.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Osztottképernyős móddal bővül az Xbox One-os ARK: Survival Evolved
"
A kérdés már csak az, hogy ez milyen hatással lesz a játék egyébként sem kiemelkedő teljesítményére. Ahogy a Digital Foundty rámutatott, az ARK: Survival Evolved nem fut éppen jól Xbox One-on: a 30fps-t sem tudja tartani, és egészen sokszor esik le 15fps környéki mélységekbe. Az osztottképernyős mód pedig jellemzően negatívan befolyásolja egy játék teljesítményét"
15 fps Mennyitől számít képregénynek ?

[ Szerkesztve ]

Nem szar csak van sokkal jobb.
Előrelépést a HBM hoz. A GDDR5X egy kényszermegoldás, mert az implementálása nagyon nehéz. Az EMI régóta probléma ezeknél a magas effektív órajelű rendszereknél. 6 GHz az, ameddig úgy relatíve egyszerű leárnyékolni a VGA-t. Efölött már egyre nagyobb probléma az EMI. 7-8 GHz még talán megoldható, de például a 14 GHz-es GDDR5X+FPGA tesztszett 256 bites busszal 37 cm-es. Egyszerűen nagyon hosszú NYÁK-ot kell tervezni, hogy az EMI ne jelentsen gondot.
A másik gond a fogyasztás, bár az csak hűtés kérdése. Ugyanakkor a 14 GHz-es effektív órajelen 3,5-5 watt egy ilyen lapka kapacitástól függően. Szimpla GDDR5 módban fogyaszt kevesebbet, de akkor 8 GHz a max órajel.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Valójában HBM2 nincs. A HBM az egyetlen specifikált szabvány, csak a magasabb órajel miatt HBM2-nek hívják, de szabvány szinten csak egy HBM update. A két rendszer, amit mi külsőleg számmal megkülönböztetünk, valójában ugyanabba a JESD235 specifikációba van besorolva. Tehát pontosan ugyanaz a technológia.
Akkor beszélünk külön technológiáról, ha más besorolást kap. Például GDDR5 (JESD212), illetve GDDR5X (JESD232).

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Megint elbeszelunk egymas mellett.

Azert mindegy mert nem azt irtam hogy HBM1-el adnak ki kartyat, hanem hogy HBM-el. A HBM2 memoria is HBM, a technologia alapja ugyanaz.

A hangsuly azon volt, hogy az nvidia is a HBM technologiat valasztotta a GDDR technologia helyett a csucskartyaira (most nem irtam a GDDR utan sem szamot). Ennyi.

A sikeressegrol en nem beszeltem, arrol vagy a bukasrol majd beszelunk egy jo ido mulva ahogy te is irod.

(#13594) Pepeeeee
Nem no duplajara a grafikai terheles pont az osztottkepernyo miatt.

[ Szerkesztve ]

Előrelépést a HBM hoz.

Nem igaz. A GDDR5X is hoz előrelépést: kisebb fogyasztással (és egyszerűbb nyákkal) ugyanakkora sávszél, vagy akár dupla sávszél, cserében nagyobb fogyasztás. Ha ez nem előrelépés, akkor mi?
Hadd ne idézzem már be a komplett Oliverda-féle cikket: ciki lenne...

A GDDR5X egy kényszermegoldás, mert az implementálása nagyon nehéz.

False. Idézet a konkurenciától: "az implementációhoz csak kisebb módosítások szükségesek. "
No meg a HBM-et olyan könnyű implementálni (interposer), nemdebár?

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Akkor még egyszerűbb a dolog. A HBM jelenleg egy olyan technológia, aminek még nincs releváns implementációja (ami van, az egy szűk niche-ben piacképes, és alulteljesíti az elvárásokat). Ettől még mindenki hisz a technológiában - az nVidia is, és 2016H2-ben látja azt az időpontot, amikor kommerciális terméket lehet rá építeni. Happy?

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Happy
Korbeertunk, abbol indult az egesz hogy itt irtak olyat hogy a GDDR5X mellett nincs is szukseg HBM-re, de ahogy irod a piaci szereplok hisznek benne. Ezt peldaztam fentebb en is az NV valasztasaval, csak belegabalyodtunk a megnevezesekbe

Egyebkent kivancsi leszek a HBM2 kartyakra. Leboges lenne ha azok is csikoznanak.