Új hozzászólás Aktív témák
-
Dyingsoul
veterán
Olvasgatván a cikket és a hsz-eket azért elég sokmindent meg lehet tanulni ezekből a kommentekből, ha az ember picit is hajlandó odafigyelni a másikra, ne idegesítsd fel magad az olyanokon, akik nem képesek elfogadni a tényeket!
Egyébként csak ötlet szinten felmerült bennem az, hogy nem lehetne-e megjósolni a következő kameraállás pozícióját mondjuk az accelerometerrel és a többi szenzor segítségével? Teszem azt a fej bizonyos sebességgel mozdul egy vektorba, a következő képkockát egy bufferbe ki lehetne rajzolni (vagy ha a teljes képkockát nem is, akár alapvető számításokat elvégezni ebbe a bufferbe)?
Ezt a feltevést arra alapozom, hogy ha a fejed egy bizonyos sebességgel mozog, vannak helyzetek amikor nem tudod pontosan megállítani, elletve nem állítod meg olyan gyorsan, ahogy akarod. Példának hoznám fel akár egy BF jelenetet vagy alien isolation jelenetet.
Ha pedig egy adott tárgy felé pontosan fordítod a fejed, kb egyenletes sebességgel mozog a fej, esetleg meg lehetne írni úgy ezt az algoritmust, hogy adott fejmozgási sebesség fölött bekapcsol a "kamera jóslás" ami rajzolja a buffereket. Esetleg folyamatosan menne ez a jóslás egy bufferbe és megjelenítés előtt lenne egy ellenőrzés, ami ellenőrzi a jósolt pozíció helyességét és ha nem helyes, elveti azt és számol a szokásos módon.
Az async timewarp (?talán?) hasonlóan működik az én elgondolásomhoz, de az enyém abban különbözik, hogy konkrét bufferbe dolgozna és ha lehetséges teljes képkockkákat előre számolna és a sikere teljes mértékben a jósló algoritmus pontosságában rejlene.
Csak ötletelek, de lehet, hogy teljesen hülyeséget beszélek ezért kérdezlek téged, hogy szerinted lehetséges-e ilyesmi (vagy esetleg meg is valósítottak már valami hasonlót?).
-
Mister_X
nagyúr
Abu, szerintem mindenki nyugodtabb lenne, ha írnál egy kövér wall of textet pár forrással, hogy akkor tulajdonképpen mi is az a timewarp, hogy működik a gyakorlatban, mit csinálnak az API-k és a GPU-k. Itt hárman állítanak háromat, már azt se tudom, hogy ki áll elő a negyedik tézissel
-
-Solt-
veterán
Nem stimmel valami... abban a két legokosabban benne van kedvenc sakálunk!
Ha ő azt mondja, hogy ez probléma, akkor márpedig az probléma még akkor is, ha az iparág két zsenije ezt másképpen látja! Szerintem akkor jársz a legjobban, ha lefordítod a kételyeit angolra, és elküldöd nekik, hogy tudjanak tanulni belőle! ![;]](//cdn.rios.hu/dl/s/v1.gif)
Szerintem tuti azonnal felveszik a stábba... elrettentő példának! Neked utalja majd a fizetése 50%-t, és mindenki jól jár! Főleg mi, mert legalább eltűnne innen!
-
#55
egyedülülő
őstag
Jack@l
#53
egyedülülő
őstag
Most már mindent értek. A történelemben sokszor lett volna szükség ilyen önfeláldozó, hősökre kik telve igazságérzettel, hátukra veszik az emberek sorsát és megkűzdenek a népbutítás igaztalan intézményét uraló elemekkel. Akkor ma minden netes portál és forum egy jobb hely lenne.
Mással magyarázni ezt a lekesedést és vehemenciát tényleg nem lehet. -
#53
Jack@l
veterán
egyedülülő
#52
Jack@l
veterán
válasz
egyedülülő
#52
üzenetére
Még mindig nem érted hogy mi a baj azzal ha akarva vagy akaratlanul félre vagy tájékoztatva?
Én ezeket kiszúrom általában elég hamar, de a nagy átlagnak erről fogalma sincs.
Elsősorban a megbecsülés és a szeretet hajt, ami ezen a fórumon körbevesz -
#50
Jack@l
veterán
egyedülülő
#49
Jack@l
veterán
válasz
egyedülülő
#49
üzenetére
Jobb kérdés lenne hogy mitől, de gyanítom neked fogalmad sincs még mindig róla.
-
Abu85
HÁZIGAZDA
JAJ! Nem, nem, nem!
A timewarp eleve nem számol új jelenetet, tehát ahhoz nem kell Latest Data Latch, hogy a lehető legfrissebb fejpozícióval számoljon. Ezek teljesen különálló dolgok.
Jaj istenem!
Dehogy is. A timewarp csak ahhoz kell, hogy egy kész képkocka után ne kelljen még egyet az elejéről számolni, hanem elég, ha az előző képkocka adatait felhasználva lesz egy eltólt kamera az új fejpozíció alapján. Ez nem lesz valódi képkocka, de lényegében segít abban, hogy a magas képfrissítést elérje a rendszer anélkül, hogy ténylegesen számolna 90 képkockát például. Timewarp mellett elég 45 képkockát számolni, és abból a 45-ből lehet még 45 timewarp. -
Loha
veterán
És ennek semmi köze a timewarphoz, mert azt külön kell végezni.
Az AMD-nél a Latest Data Latch gondoskodik arról, hogy a timewarp a megfelelő időben kapja meg az utolsó fejpozíciót, ugyan úgy ahogy az NV-nál a Context Priority.
A Context Priority a timewarphoz kell, de csak az NV-nél, mert az AMD hardvereinek nem kell megvárni a rajzolád befejezését.
Az egész timewarpnak az a lényege, hogy megvárja amíg mindennel elkészül a GPU, aztán a legfrissebb fejpozíció alapján igazít a képen, közvetlenül mielőtt kimenne a kép a VR szemüvegre.
Jack@l: Igen csak ennyi az egész, de azért fontos, mert a fejforgatás esetén érzékelhető késleltetés az, ami nagyon zavaró tud lenni VR-ben.
-
Jack@l
veterán
Jaa, ennyi hogy nagyobb képet számol és utánaforgatja/levágja?
Értem már, ez így a lagon nem sokat segít mert plussz munka, de a végeredmény közelebb lesz az éppen addigra kialakult elforduláshoz.
Thx.
UI: ehhez se kell semmi low level varázslat, a render végén egy post processing azt jóvan. Nem sok meló maga az arrébb tologatás pár pixellel. -
Abu85
HÁZIGAZDA
Ne keverjük a szezont a fazonnal. A Latest Data Latch egy teljesen szoftveres funkció, amit a Mantle tesz lehetővé. Hardver oldali támogatást nem igényel. Ezért sem értette az Oculus, hogy az MS és a Khronos miért utasította el a tervezetüket, amivel 2016 elejére lett volna rá szabvány. Valójában az API-knak is csak az input assembler részét kell kiegészíteni. És ennek semmi köze a timewarphoz, mert azt külön kell végezni.
A Context Priority a timewarphoz kell, de csak az NV-nél, mert az AMD hardvereinek nem kell megvárni a rajzolád befejezését, mivel a GCN-en az üzemmódváltás nem ehhez van kötve. Az NV-nél is azért van szükség a prioritásra, hogy lehetőség szerint a timewarp prioritása nagy legyen, míg a többi munkáé kicsi. Ez azért fontos, hogy a felvett rajzolások közül a driver a timewarpot előre rakja, hogy csökkenjen annak az esélye, hogy esetleg beragad egy hosszú ideig tartó rajzolás mögé. Ha ez megtörténik, akkor nem lesz kész időre a számítás.
-
Loha
veterán
Az benne a trükk, hogy lekér egy fejpozíciót amiből kiszámolja a képkockát, majd mielőtt kitolná a VR szemüvegre, frissíti a fejpozíciót, de csak azonos pozícióból vett szögelfordulással, amihez semmit nem kell újraszámolni, csak kicsit elfordítani a képet, ez a timewarp.
Az egeres + monitoros játéknál nem túl bonyolult stabil 60+ fps megvalósítani, míg a VR a sztereó kép miatt dupla annyi melót igényel a GPU-tól, amit CF-el vagy SLI-vel lehet kielégíteni (ami 2x olyan drága), vagy kicsit csalni kell ami a timewarp.
Az AMD Latest Data Latch -ja meg kb. ugyan az, mint az NV Context Priority -ja...
-
Jack@l
veterán
Ja, arra hbm2-re, amit a csúcskategóriába belerak, a többit meg olcsón elszórja gddr5x-el.
A lényeg hogy majd ha lesznek erről teszteredmények és ha kijön hogy jócskán kissebb lag van amd-n mint nvidián, akkor lesz majd alapja a nagy belengetésnek. Addig ugyanolyan mese, mint a DX12-ben sokkal jobb az amd és előtte sok más dolog.
Tudom csak addig kell trtani a hype-ot, amíg az ember megveszi a kártyát reménykedve, ha utána pofára esik az már kit érdekel. -
Abu85
HÁZIGAZDA
Arra a HBM technológiára gondolsz, amit az NV bevet jövőre? Gondolom akkorra már jó lesz.
Nem is értem, hogy az NV miért nem rád hallgat, és miért az általunk jónak gondolt, de általad halálra ítélt technológiára épít. Biztos nekik is olyan idióták magyarázzák el a lényegét, mint nekünk, és ezzel kimossák az NV mérnökök agyát, ahogy az enyém ugye? 
-
Abu85
HÁZIGAZDA
Én hogyan értemén meg az aggályaid, amikor a világ talán két legokosabb embere nem érti azokat meg? Ha probléma lenne az, amiről írsz, akkor el sem indult volna Carmack és Abrash ezen az úton, és le se lenne adva szabványosításra a Latest Data Latch az Oculus által.
Neked nem aggályod van ezzel, hanem csak az a bajod, hogy ez most még csak az AMD-n fog működni, de már írtam, hogy erre 2017-ben épülni fog egy szabvány. Szóval nyugi, menni fog NV-n és Intelen is.
Persze addig felőlem leírhatod, hogy ez egy rossz technológia. Majd szólok mikor lesz szabványos, és akkor utána remélhetőleg jónak fogod tekinteni. -
Jack@l
veterán
-
Abu85
HÁZIGAZDA
Ma úgy működnek a játékok, hogy a kamera pozíciója a jelenetszámítás előtt már ismert. Ez kerül bele a jelenetbe, és ezzel történik a képkocka számítása. Amit Carmack és Abrash elgondolt az az, hogy ez a pozíció nem jó a VR-re, mert ennél még a képszámítás megkezdése előtt lesz sokkal frissebb, amire ki lehetne cserélni a kamerát. Viszont egyetlen szabványos API sem engedi meg, hogy ezt megtedd. Ezért adott le az Oculus egy módosítást még 2014-ben, hogy 2017-re az MS és a Khronos lehetőség szerint elfogadja, és akkor tényleg lesznek szabványos VR API-k a piacon. A mai szabványok tervezésénél a VR-t nem vették figyelembe.
Szerk.: Ha nem akarod megérteni, akkor nem próbálom elmagyarázni. Nekem olyan mindegy, hogy elfogadod-e a tényeket vagy sem.
-
Jack@l
veterán
Minden játék úgy működik, hogy a képkocka számítás előtt lekérdez egy pozíciót. Már vagy 25 éve...
Amikor kiadtad hogy draw, onnantól kezdve nem lehet változtatni rajta büntetlenül. (se low levelben, se vr apiban és egyetlen shader futószalagos megjelenítésben sem, előtte eddig is lehetett)
Mivel mindent a kamera pozícióból számolnak egy képnél, olyan mintha azt mondanád, hogy süti sütésnél neked nem kell tojás(vagy csak 1), a többit majd a végén ráütöd, ha kisült a süti.Vagy ha megmondod konkrétan a futószalagon mi az a pont és a képalkoztásnak nagyjából mennyi százalékán spórolható meg a lag, hinni fogok neked. (csak hogy legyen valami konkrét állításod is amit utána bárki hozzáértő szétcincálhat )
-
Abu85
HÁZIGAZDA
A fényképező teljesen más. Annak az optikájától függ, hogy mennyire képes stabil képet csinálni rángatás mellett. A számítógép számol. Kap egy pozíciót és arra felállít egy kamerát, majd tűéles képet számol a látószögre. Ezt extra effektekkel lehet torzítani, ha el akarod érni a motion blur hatását, de a VR esetében ezzel finoman kell bánni. De ha azt adod meg a gépnek, hogy ne legyen tűéles a kép, hanem vegye számításba a motion blurt, akkor természetesen megcsinálja.
A low-level nem fog változtatni rajta. Az csak áthelyezi a kontroll nagy részét a motorba.
Itt arról volt szó mindig is, hogy Carmack a 20 ms-ot nagyon minimumnak tekinti, de sokkal jobb lenne 10-12 ms. Viszont ezt csak úgy lehet elérni, ha a képkoca előtt mintavételezel egy pozíciót, de a kamera módosítását a szabványos API-k közül semmi sem támogatja. Majd támogatni fogják 2017-ben. Addig is, aki akarja beépítheti ezt a funkciót, ha megvannak hozzá az eszközeik, itt nyilván egy saját grafikus API kell.
Olyan sincs, amit írsz, hogy máshol vannak a textúrák és az árnyékok. A Latest Data Latch csak és kizárólag azt csinálja, hogy frissíti a kamerapozíciót. Semmi mást. Ugyanazt fogod kapni eredménynek, csak jóval kisebb késleltetéssel. A világon, a jeleneten, a textúrákon nem változtat. Az árnyékokat is ki lehet számolni tökéletesen, mert az input assembler szint előtt módosult a kamera, és nem utána.
Ha nagyon le akarjuk egyszerűsíteni, akkor a LiquidVR annyit csinál, hogy a futószalagon belül a D3D12 vagy Vulkan input assembler szintjét kiegészíti egy Mantle input assembler szinttel, és itt van egy API interoperability. -
Jack@l
veterán
Akkor a fényképezővel se torzul a kép, ha menet közben berántom? Jó lenne ehhez az alapokkal tisztában lenni. A low level nem fog változtatni a kép kiszámolásán, se azon hogy 1 fix fejpozícióbol számolnak mindent...
Vagy neked az is jó, hogy az objektum csúcspontjai X helyen vannak, de az árnyékát vagy a textúráinak a megvilágítását már másik pontból számolja? -
Abu85
HÁZIGAZDA
Az egér, a billentyűzet, a gamepad, a VR szemcsi nem ugyanaz. Az LDL csak a szemcsire vonatkozik. A irányítást végző eszközökre nincs hatása, mert a jelenetet azzal már leszámolták.
Semmi gond nincs vele. A gyakorlatban 100%-os tökéletességgel működik. Ezt várta tőle Carmack és Abrash is, de nekik nem volt grafikus API-juk a koncepciójukat a gyakorlatba önteni. Viszont az MS és a Khronos 2017-re elvileg megoldja. Addig csak az AMD-nél lesz rendkívül alacsony késleltetés.
Semmiféle torzulás nem lehetséges, mert szimpla kameraadatot kapsz, méghozzá ugyanolyat, amilyen számolnál, csak LDL-lel ez ps ms-mal frissebb.
(#29) kikikirly: A nem függ tőle az pont azt jelenti, hogy se nem gyorsul, se nem lassul. Egyszerűen ez egy program oldali probléma, és az Oculus SDK szempontjából csak annyiban érdekes, hogy a fejlesztők jól oldják meg.
-
kikikirly
senior tag
Az világos hogy nem függ tőle,működik olyan procin is aminek nincs.Pont azt kérdezném hogy tudja e használni,gyorsabb lesz-e tőle.Van alkalmazás ami nem tudja használni vagyis nem gyorsul tőle semmit sem,sőt olyan is van ami lassabb tőle de ezt te is tudod.Megfelelő Alkalmazást feltételezem tudnak írni hozzá ha van értelme.
-
Jack@l
veterán
Már hogyne csökkenthetné? Ugyanaz a beviteli eszköz...
A gond nem csak a kivbágással van, hanem eleve a képalkotással. Szóval találd ki hogy torz lesz a képe ilyenkor a rendernek, vagy gyaklorlatilag alig tudnak időt nyerni a későbbi kiolvasással.
Mint mikor valaki rángatja a kamerát fényképezés közben, csak itt máshogy fog lecsapódni az elmozdulás. (mondjuk vertex shader közben, vagy tükröződésnél, árnyékoknál nem is abból a nézőpontból számol amiből a háromszögeket) -
Abu85
HÁZIGAZDA
A kamerának.
Ez a nehézsége a koncepciónak. Emiatt a kivágás nagyobb kameralátómezővel történik. Ez probléma lenne az elavult API-kkal, de nem gond az újakkal.
Egyébként ez nem igazán az AMD találmánya, hanem Carmack és Abrash koncepciója, de nem fejezték be az eredeti kutatást, mert az MS és a Khronos nem volt vevő arra, hogy az API-kat VR-re tervezzék. Az AMD csak leporolta az ötletet, mert van saját API-juk a problémamegoldásra. Ma már le van adva a szabványosítási javaslat az Oculus által.Az egér és a billentyűzet, vagy a gamepad input lagját ez nem csökkenti.
-
kikikirly
senior tag
Igen jövőre jönnek az új Chipek széleskörűen AMD oldalon is.Ezek minden szempontból jobbak lesznek,PC játékra,VR-ra, és fogyasztásban is.Méghozzá elég nagy előrelépés lesz,hiszen a 300as sorozat lényegébem a 200-as újra kiadva csak 3-as GCN-el,VR szempontból jobb aztán csókolom!Fury X király,csak drága és a HBM se olyan nagy vas ist das,jövőre jön a HBM 2,az már kiforrott lesz.És ne feledjük az Nvidia is alkothat valamit.Én várnék a helyedben azzal a VR-al 2 okbók:Az első pillanatban mindig drága,utána lemegy 10K-val az ára.Második: Nincs vagy csak nagyon kevés játék van hozzá.Én is gondolkoztam hogy vegyek-e de aztán úgy döntöttem hogy csak a 2.generációs Vr-ból veszek,az még jobb lesz,Hardver Tapasztalat,Játék ,minden szemontból.Ha te mindenképp akarsz venni már most én akkor is kivárnék vele jövőre, mivel véges a költségvetésed, ezzel csak csúnya ráfizetés lesz a vége,ha egy, ha két kártyás rendszert akarsz építeni.
Természetesen továbbra is tied a döntés joga
-
Jack@l
veterán
Minek kell a jelenet számolásához a fejpozíció?
Ha meg a képalkotáshoz kell, mi lesz abból ha a modell háromszögeit, egy nézöpontból számolja, a vágását shadinget és tükröződéseket meg másikból? (hgyengébbek kedvéért arrébb rángatod a kamerát miközben már levágtad a képből kilógó háromszögeket)Utolsó ultimate kérdés: ha ez ennyira nagyszerű találmány, és állítólag nagyon nagyon sok lagot megspórol, mért nem használták már eddig is egeres bevitelnél gyors fps-ekben?
-
Abu85
HÁZIGAZDA
A motion-to-photon késleltetés csökkentésére az AMD tisztán szoftveres rendszert használ. Ha a program a LiquidVR környezeten keresztül dolgozik, akkor a Latest Data Latch megoldja a késleltetés csökkentését. A preempciónak a timewarp számításához van köze. Oda valójában jó a durvaszemcsés preempció is. Az a lényeg itt, hogy ha befut a kérés, akkor ne kelljen ms-okat várnia. Durván 10 ms van egy timewarp számítására, és ha abból 3-7 ms csak várakozásra megy el, akkor az konkrétan egy akarást fog jelenteni. Nyilván figyelembe kell venni, hogy a timewarp aszinkron módban fut a következő valós képkocka számításával, tehát egymást akadályozni fogják valamilyen mértékben, mert ugyanazokra az ALU-kra pályáznak.
-
Abu85
HÁZIGAZDA
Egyszerű. Az Oculus SDK úgy dolgozik, hogy minden jelenet számítása előtt lekér egy fejpozíciót, amit felhasznál, de a szabványos API-k nem engedik meg, hogy ez módosuljon, így ezt használják a képkockára is. A LiquidVR viszont megengedi, hogy a fejpozíció 1 ms-onként le legyen mentve egy memóriaterületre, és a jelenetszámításkor ezt olvassa ki, majd a képszámítás előtt kiolvas egy új pozíciót, amit átad a Mantle-nek. Ezután ezt a pozíciót kapja meg a játék által használt API. Ezzel a M2P késleltetés kb. a felére csökkenthető. Az Oculus ugyanezt a funkciót adta le szabványosításra az MS-nek és a Khronosnak, és 2017 körül elvileg meg is lesz oldva.
-
Jack@l
veterán
Bullshit:
"Ennek a koncepciónak az előnye, hogy az úgynevezett "motion-to-photon" késleltetés durván a felére csökkenthető, mivel a képkocka számításához felhasznált fejpozíció nem a jelenet kalkulációjának megkezdésekor született meg, hanem pont a jelenetszámítás befejezésekor."Hogy a csába számolhatna jelenetet valami kamera nélkül? Vagy te is csinálsz egy fényképet és a végén a jó irányba forgatod a fényképezőt?
-
Tyrel
őstag
válasz
kikikirly
#16
üzenetére
Hát gondolkodtam a 390-en is, de hála AMD energiahatékonyságának és gyenge gyárainak, 2 lehetőségem van:
1. nVidia-t veszek
2. maradok AMD-nél de videokártya mellé veszek egy új tápot isA keret 100 pénz... Ezért gondolkodom a 380X-ben.
Na meg nem tudom igazán eldönteni hogy jó ötlet-e így 2016 hajnalán nem-GCN3-as kártyát venni... Para hogy gáz lehet belőle, főleg VR-el, én meg ott leszek a Rift első előrendelői közt, ha a fene fenét eszik is...
Na igen meg van még egy olyan problémám is hogy kb. ~24cm-es videokártyánál hosszabb nem fér el a házamban, a 390-ek meg elég nagyra hízott szörnyek...
3. lehetőség hogy most lesz egy 380X meg egy combos táp, aztán valamikor jövőre kap maga mellé havernak egy másik 380X-et. Mondjuk ennek meg a fogyasztása lesz katasztrofális, plusz jövő ilyenkorra már a GCN3 is elavult lesz.
Igazán nekem az se tiszta hogy az a 10-12ms késletetés amit AMD emleget az csak a finomszemcsés preempcióval ill. GCN3-al lehetséges, vagy a durvaszemcsés is sokat hoz ill. jó eredményt produkál a zöldekhez képest?
-
kikikirly
senior tag
Szerintem is jóval erőseb volna,és itt látszik meg hogy a nyers erő nem sokat ér a direkt tervezéssel szemben.Olcsóbban ki lehet hozni jobb teljesítményt.Titan X PC játékra király,de VR-ban messze nem ugyanazt a teljesítményt nyújta mert nem erre tervezték elsődlegesen,nem hiába a rendezvényeken AMD kártyákat futtatták a játékokat,kivéve persze az Nvidia saját VR-jat.Na szép is lett volna
.De tök jó ötlet. -
kikikirly
senior tag
A hivatalos minimum gépigény: R9 290-GTX970. A 970 nem valami hűde jó ebben,a 290 okés viszont azon csak 2 genrecáiós GCN van,a 380X-en pedig harmadik ami jobban fel van készítve VR-ra.Szerintem elég lesz Medium néhol a High grafhoz is,de én inkább Sima 390-et vennék a helyedben ha 1GPU-ban gondolkozol.Ugyanis az X-ket mindíg elég durván felárasak ahhoz képest ami többlet teljesítményt nyújtanak.Rá pakolsz még néhány ezer forintot és Hardveraprón vehetsz R9-390-et sokkal többet tud mint egy 380X vagyis ár érték arányban jobban jársz, és persze jóval tartósabb megoldás és bírná High grafot is.Természetesen tied a döntés.
-
Ren Hoek
veterán
válasz
#45185024
#12
üzenetére
Tippre:
GCN2 Hawaii
-Szebb grafika - stabil (90 FPS) - de nem Tonga /Fury preempció => kisebb hányás, ne egyél előtte 10 turmixot vagy túl sok indiai csípős kaját
-Max grafika (90 FPS>) - sikítva hányás: se finomszemcse, se smooth FPS. Vegyél pelenkát és készítsd a Viledát.GCN3 Tonga
-Gyengébb grafika - stabil FPS mellett. (90) => no hányinger. Max besz.rsz a horrortól, bár eléggé polygonos a szörny feje.
-Szebb grafika gyenge FPS mellett (90>) => potenciális hányás, mert akadozik a kép, ahogy rohansz monster elől.GCN3 Fury
- Max grafika - stabil (90 FPS) => No rókamóka, de benned a móka, hogy nem ultrázod a grafikát?GCN3 Fury VR
- Ultra grafika - stabil (90 FPS) => Nó rókamóka + Besz.rsz, beh.gyozol a látványtólMaxwell2:
Nvidia, úgyhogy bárki bármit mond úccse lesz jó. Titan X SLI mellett felveszed a Riftet és egyből besz.rsz, bepi.sálsz, beh.nysz mint egy szekrényszagú öregember az Életöröm Idősek Otthonában... -
jedis
senior tag
Hmmmm
. Akkor ha minden igaz, az R9 380-asok GCN3-as architektúrára épülnek, ami elég jól fekszik a VR-nek. Szóval ha ebből csinálna az ember egy CF-et, lehet már el lehetne játszogatni vele FHD-ban alap HIGH beállításokon, és az ára se lenne horribilis, mivel 2db 4GB-os 380-as, már 150 alatt meglenne . -
kikikirly
senior tag
Abu ha jól tudom a játékok 4 magos processzornál a Hyper Threadingből a játékok nem tudnak profitálni,legalább is néztem már több i5-i7 tesztet,legutóbb most a napokban i5-4690K 4,7 GHz és i7-4790 4,7ghz-n és nem volt szinte semmi különbség vagyis olyan minimális eltérések voltak mindkét oldalon ami mérési hibának látszik.A VR tud valamit kezdeni a HT-val,vagy ugyanúgy semmi plusz teljesítményt nem ad hozzá?
-
#6
kikikirly
senior tag
darealkilla
#5
kikikirly
senior tag
válasz
darealkilla
#5
üzenetére
+1 -
#5
darealkilla
aktív tag
darealkilla
aktív tag
VR SLI = ViRSLI
-
Abu85
HÁZIGAZDA
Valójában ez nem SLI, hanem VR SLI. Bár a neve hasonló, de a normál SLI-hez semmi köze. Az AMD ezért nem nevezi CrossFire-nek, hogy ne keverjék a felhasználók.
A GeForce-szal nem a memória lesz a probléma, hanem a preempció. Egyáltalán nem úgy tervezték az architektúrát, hogy az élettartama alatt lesz olyan terhelés, ami azonnali választ kér egy számításra (szerintem senki sem gondolta, hogy ilyen egyáltalán lesz). Szóval a 4 GB az bőven elég. Hamarabb fog akadni a hardver attól, hogy becsúszik egy 4-7 ms-os rajzolás a timewarp elé, minthogy elfogyna a VRAM. Főleg nem Windows 10-ben WDDM 2.0-val.
-
Igen,örömmel olvastam az SLI támogatást.
És azt is örömmel olvasom,hogy az SLI-vel csökkenthető lesz az az érték.
Mintha nekem találták volna ki.Sajna engem nem érint az amd megoldása.
Remélem elég jól muzsikál majd az SLI is.
A 4Gb vram az mennyire lehet majd határon ?Mondjuk előzetes infók alapján egy 970 volt megadva ajánlott vga-nak.
Akkor elég lehet a kártya,pláne SLI formájában. -
Abu85
HÁZIGAZDA
Picit igen. Érezhető csökkenést azonban csak szoftveres oldalon lehet elérni olyan koncepcióval, amit az AMD csinál. Szerintem ezt az Oculus is be akarta építeni, de annyira lassan halad a VR szabványosítása az MS és a Khronos portáján, hogy inkább elfogadták azt, hogy 16-19 ms-ot tudnak minimum hozni a saját SDK-jukkal. A 10-12 ms-hoz vagy ez alá mindenképpen az AMD-féle linkelős módszer kell.
Ami még csökkenti az M2P késleltetést az két GPU használata. Ott az Oculus cuccával is hozható a ~12 ms, de ezen a ponton meg az AMD cucca már ~6 ms-nál jár, tehát a linkelés mindenképp ajánlott. -
Ez a funkció az AMD számára lényeges, mert a cég szerint az Oculus rosszul hiszi, hogy a picivel kevesebb mint 20 ezredmásodperces késleltetés elfogadható – a vállalatnál úgy gondolják, hogy ennek inkább 10-12 ezredmásodperc alatt kell lennie.
Ez az érték csökkenthető lesz egy erősebb vassal ?
Ha ő azt mondja, hogy ez probléma, akkor márpedig az probléma még akkor is, ha az iparág két zsenije ezt másképpen látja! Szerintem akkor jársz a legjobban, ha lefordítod a kételyeit angolra, és elküldöd nekik, hogy tudjanak tanulni belőle! ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Dehogy is. A timewarp csak ahhoz kell, hogy egy kész képkocka után ne kelljen még egyet az elejéről számolni, hanem elég, ha az előző képkocka adatait felhasználva lesz egy eltólt kamera az új fejpozíció alapján. Ez nem lesz valódi képkocka, de lényegében segít abban, hogy a magas képfrissítést elérje a rendszer anélkül, hogy ténylegesen számolna 90 képkockát például. Timewarp mellett elég 45 képkockát számolni, és abból a 45-ből lehet még 45 timewarp.
Persze addig felőlem leírhatod, hogy ez egy rossz technológia. Majd szólok mikor lesz szabványos, és akkor utána remélhetőleg jónak fogod tekinteni. 
Új hozzászólás Aktív témák
Hirdetés
ph Az AMD és az NVIDIA helyenként eltérő funkcionalítást kínál a saját zárt csomagon belül, de ezt a gyártóknak nem kell feltüntetniük.
- iKing.Hu - Apple Macbook Pro 13 Touchbar M2 -2022 - Használt, karcmentes
- Bomba ár! Lenovo ThinkPad P50 - i7-HQ I 16GB I 256SSD I Nvidia I 15,6" FHD I Cam I W10 I Gari!
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- Bomba ár! Lenovo ThinkPad X395 - AMD Ryzen PRO 5 I 8GB I 512GB SSD I 13,3" FHD I Cam I W11 I Gari!
- Wilbur Smith könyvek (15 db) egyben
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest