- Milyen billentyűzetet vegyek?
- Milyen videókártyát?
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- TCL LCD és LED TV-k
- Házimozi haladó szinten
- NVIDIA® driverek topikja
- Fujifilm X
- Máris befutott a hibajavításoktól duzzadó GeForce driver gyorsjavítása
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Saját márkás HDD-ket követel meg az egyes NAS-okhoz a Synology
Új hozzászólás Aktív témák
-
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. -
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.
-
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. -
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.
-
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. -
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.
-
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.
-
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.
-
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.
-
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.
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.
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? 
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.
- Milyen billentyűzetet vegyek?
- PlayStation 5
- Milyen videókártyát?
- Gitáros topic
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Samsung Galaxy S23 Ultra - non plus ultra
- Nagyon erős ajánlat lett CMF Phone 2 Pro
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Ubiquiti hálózati eszközök
- Villanyszerelés
- További aktív témák...
- LG 65C3 - 65" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox!
- Csere-Beszámítás! Prémium vizhűtéses számítógép! I9 11900K / RTX 3090 / 64GB DDR4 / 1TB SSD
- A Panasonic Toughpad IPS touch Budapest, MPL Foxpost
- BESZÁMÍTÁS! Asus ROG B450-F R5 5600X 16GB DDR4 512GB SSD RTX 3060 12GB CM MasterBox NR600 650W
- Bomba ár! Lenovo ThinkPad T14 Gen3 - i5-1245U I 16GB I 256SSD I 14" WUXGA I MAGYAR I W11 I NBD Gar!
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest