- DVB-T, DVB-S (2), DVB-C eszközök
- HiFi műszaki szemmel - sztereó hangrendszerek
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Fejhallgató erősítő és DAC topik
- Apple notebookok
- Azonnali alaplapos kérdések órája
- Milyen videókártyát?
- Vezeték nélküli fejhallgatók
- Milyen TV-t vegyek?
- Szünetmentes tápegységek (UPS)
Hirdetés
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Elérhető Európában a Samsung Galaxy M15 és M55
ma Megfizethető teljesítmény és sebesség az M-széria mottója, egyelőre a hivatalos magyar kínálatban még nincsenek bent, de közeli országban már listázták és beárazták az egyiket.
-
Acer Nitro V 15: amikor az jó ár-érték arány a cél
ph A Nitro sorozatban több, vásárlásra ajánlott notebookot is láttunk már, most az egyik legújabb modellt próbáltuk ki.
Új hozzászólás Aktív témák
-
Szerintem Nem nevezhető az eljárás igazából interpolációnak, maga cikk jól megfogalmazza. Nem kép alapú a frame megalkotása, csak 1/8 ad részben inteprolácó, 7/8 ad részben mozgásvektorból, árnyékokból következetessel számolja ki a a GPU a következő képkockát a CPU pipeline kihagyásával.
[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Én is így gondolom,,de Ha jól értelmezem a harmadik képkocka még nincs kész egyáltalán, tehát nem ment végig a szalagon kizárólag a mozgásvektor adatok alapján a GPU kiszámol egy saját képkockát és valamelyest eltolva beszúrja az akkor éppen készülő normál pipeline alapú 3 képkocka elé remélhetőleg eltalálva a végeredményt ami valójában nem feltétlenül felel meg a mozgásra és egér irányításra szánt adatoknak .
Gondolom egyáltalán nem tartalmaz egér/ bill adatot ,mert nincs benne a CPU egyáltalán a generálásba és ez miatt több az FPS de kevesebb a mozgásadat és nő a késleltetés.
Tehát összesen egy képkocka van kész a másodikat szinte teljesen a GPU számolja( 7/8-ad rész) és azután érkezik a kész 3. amit felhasznál megint egy saját képkocka generálásához.Az interpoláció két kész képkockából általában kész képadatok alapján számol 3. képet ez szerintem annál sokkal finomabb dolog.
A DLSS 3.0 mellé kötelező az Nvidia reflex támogatás és azzal együtt szerintem jó lesz a késleltetés és az FPS növekedés jelentős lesz jobb képminőségel párosítva. Az AMD-s oldalak és emberkék az késleltetést veszik elsősorban képbe és erre hivatkoznak hogy ez szar, az Nvidiások pedig az FPS-t és a képminőséget, azt gondolom a tesztek eldöntik majd a dolgot 1 héten belül.
[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
CB cikk azt írja 4 képkockát néz visszafelé és a jelenlegit és abból következtet az 5. kockára ( azaz a jelenlegi utánira mozgás adatokat is de az nem a CPU ból származik).
Igen,Nekem kicsit ezért furcsa ez a késleltetésdolog ,mert valójában nem szabadna növekednie ó ettől mert szerintem úgy van ahogy leírtam. Tehát van egy játékod 60 FPS / 30 ms ha ez felmenne 120 FPS re tegyük fel csökenne a késletteés 15 ms -ra
DE ha így van ahogy leírtam feljebb akkor itt annyi történik hogy marad 30 ms 120 FPS nél és nem csökken le. Tehát max az egérnél lehetne észrevenni artifactot meg azt hogy a késleltetés nem követi le a magas FPS számot, de nem romlik.[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
eight
senior tag
Elnézést, ha hülyeséget kérdezek, de biztosan interpolációról van szó? Nem lehet hogy nincs benne következő kép és csak az előző kettő és inkább extrapoláció történik az optical flow-val, tehát csak compute, azaz nem kell ahhoz a kockához várni a motortól kapott infóra (pl.: mozgásvektorokra)?
-
eight
senior tag
Egyet értek, ahogy korábban is írtam szerintem üzleti döntés folytán használják a DLSS performance módot minden slideon. Master race/enthusiast szempontból használhatatlannak tartom. El tudom képzelni, hogy van létjogosultsága egy RTX3050-es kártya tulajnál, aki hétvégi fotel-szórakozáshoz felköti a gépet a 4K-s tévére, és nem is érdekli/érzi mi az ultra meg a medium között a különbség, de aki 4090/4080-at vesz az DLSS quality-t fog használni (amit én is nagyon szeretek és használom is ahol tudom), vagy esetleg pár év múlva el tudja fogadni a DLSS balancedet kompromisszumként.
Ezzel a fogással simán a legrosszabb verzióval reklámoznak, és szerintem direkt csinálják.
Persze a mérnöki oldalt is megértem. A DLSS performance sok számítást igényel a többi módhoz képest. Talán azt lehetne csinálni, hogy a DLSS3 az Amperen csak Quality és Balanced a Turingon meg csak Quality módban futhatna, de ez meg lehet, hogy a QA csoporton nem menne úgy át. -
Nem lehetne ezt így?
[]: számolt
[1] 2 [3] 4Tehát:
számolt
[1] 2 [3] 4
megjelenített:
__[1] 2 [3] 4Tehát A 4-ik, interpollált képkockát nem lehetne az [5] bevárása nélkül csak a korábbiakból kiszámítani a sebességvektorok illetve a korábbi interpollációk utolagos validálása alapján?
A, 4 = 2 + [3]
B, 4 = [1] + [3]
C, 4 = [3]A: Ideális esetben a mozgásvektorok nem változnak jelentősen ezért a mozgásvektorból és az időintervallumból jó közelítéssel meg lesz a 4-es interpollált kocka a 2 és [3] felhasználásával. Tehát nem két meglévő ismert pont között interpollálunk, hanem előre következtetünk (x + vx*dt jelleggel, ahol folyamatosan mérjük a becsüljük a vx-et és utólag korrigáljuk).
Azt, hogy az A modszer alkalmazható-e, a 4-es kiszámítására, a [1]-es és [3]-as képkocka validálni tudja, hiszen meg tudja utólag nézni, hogy a ([1], [3]) => 2 interpolláció teljesül -e. Ha nem, akkor a 2-es képkocka nem volt jó ezért bár már kiraktuk, de további interpollációhoz nem használjuk.
Itt jön a B vagy C:
Felhasználjuk az [1]-et a [3] mellé vagy ha semmilyen lövésünk nincsen, hogy mit kéne csinálni, akkor duplázzuk a [3]-at.Így legalább a késleltetés nem növekedne jelentősen.
[ Szerkesztve ]
-
eight
senior tag
Ebben eltér a véleményünk, szerintem meg pont hogy win-win, ha jól implemetálják, azaz egyszerre több fps és azonos minőség (sőt, láttam már olyat is, hogy több részlet volt a DLSS képkockán a natívhoz képest).
Szerintem mindenképpen jót tett az iparággal a DLSS megjelenése, persze ettől még lehet csúnya vége, hogy egyszer majd utálni fogjuk, hogy már alig látunk tiszta, zajmentes, riccenésmentes, stb. grafikát, de talán még képlékeny az irány, én reménykedem
[ Szerkesztve ]
-
a problémát a prediktív megközelítéssel mindig az okozza, amikor kívülről jövő változás érkezik.
...ha az általad leírtakban a 3-as kocka környékén a user csűr egy 180 fokosat az egérrel, akkor ezt az 1->3 átmenetből nem tudod kitalálni, a 4-es kocka elég hülyén fog kinézni, és (szerintem) kevés FPS esetén ez észrevehető is lesz. Ha megvan az 5-ös mozgásinformációja, akkor már igen.
a konkrét eset kapcsán szerintem semmi komoly probléma nem lesz, csupán az input lag érzést növeli.
ha az általad leírtakban a 3-as kocka környékén a user csűr egy 180 fokosat az egérrel, akkor ezt az 1->3 átmenetből nem tudod kitalálni
Ha előtte semmilyen extrém input nem volt, akkor a 2, [3] -ból találod ki a 4-et. Ha a user a [3] környékén csűrt egyet az egéren, akkor a 4-es képkocka a 2, [3] folytatása lesz a meglévő mozgásinformációk alapján. Tehát a karakter megy tovább ahelyett hogy fordulna, a 4-es képkocka egyáltalán nem fog hülyén kinézni, jól fog illeszkedni az eddigi képfolyamba, csupán le lesz maradva a bemenettől.
Az érkező [5] -ös kocka illetve a már korábban meglévő [3]-as kocka detektálja, hogy a 4-es "piszkos", tehát majd nem használható fel egy (4, [5]) => 6 interpollációhoz.
Mivel az [5] ös képkocka már detektálja a mozgásállapot megváltozását, ezért a ([3],[5])=>6
interpolláció még mindig jó lehet, ha csak nem valami nagyon drasztikus dolog történt.
a 2[3]4[5]6 kirakott képkocka sorozatban a 4-es a 2,3 folytatása lesz, míg [5]-nél indul be hirtelen a mozgás.[ Szerkesztve ]
-
Köszi!
Igen, a 6-ik frémnél a semmiből jövő rángás zavaró lehet, a második frém után történő túl gyorsan induló fordulás szerintem nem drasztikus, hiszen a user az input hatását várva már számít erre.
A hatodik frémnél viszont könnyen megtörténhet, hogy a user már célra rántotta az irányzékot, és ahelyett, hogy az ellenfél fején maradna a célkereszt, az tovább fordul majd visszaugrik
[ Szerkesztve ]
-
Szerintem valamit nem jól számolsz. 30 FPS esetén 1 frame /33 ms ( ami harmincad másodperc, nem tized)) alatt 60 fokot nem fordulsz játékok alatt. Ha mégis akkor Általában egy low-mid-high sens játékos <10-20 cm egérmozgás alatt fordul 180 fokot . Az általad felvázolt esetben minden 3. képkockának el kellene térni az algoritmus által következtetettől, mert mozgásirányt váltasz. de mivel 5 képkockát elemez vissza fele ezért kör vagy ív mozgás esetén a 8 .frame már ugyan oda esik ahova eredtileg esne. eltérés abból adódhat ami a táblázatod végén van amikor egy folymatos egyirányú mozgásnál hirtelen irányt váltasz, de itt milisecundomokról van szó, nem váltasz irányt 1 másdpercen belül 2x vagy 6x mert nem vagy képes rá fizikailag.
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Bocs lejárt a keret ez a komment lett teljes, nem az előző.
Szerintem( lehet tévedek , csak leírom én hogy látom) valamit nem jól számolsz. 30 FPS esetén 1 frame /33 ms alatt 60 fokot nem fordulsz játékok alatt. Ha mégis profi Quake champion vagy akkor is egy low-mid-high sens játékos <10-20 cm egérmozgás alatt fordul 180 fokot . Az általad felvázolt esetben minden 2. és 6. képkockának el kellene térni az algoritmus által következtetettől, mert mozgásirányt váltasz. de mivel 5 képkockát elemez vissza fele ezért kör vagy ív mozgás esetén a 8 .frame már ugyan oda esik ahova eredtileg esne.
Eltérés abból adódhat ami a táblázatod végén van amikor egy folyamatos egyirányú mozgásnál hirtelen irányt váltasz, de itt milisecundomokról van szó és az eredeti FPS hez képest ugyan annyi időn belül de fél frame eltolással l megfordul a mozgásirány mert minden másdik generált FPS az előző képkocka mozgásvektorait tartalmazza. ( 60 FPS esetén 16,6 ms,de 120 FPS esetén is de itt erre az időre 2 képkocka esik amiből az egyik generált a másik viszont már az eredetivel megegyező irányba mutat.) + szerintem nem váltasz irányt 1 másodpercen belül 2x vagy 6x mert nem vagy képes rá fizikailag de ebben sem vagyok biztos hogy így van mert ha jól értelmezem minden generált frame az előző képkocka mozgás vektorát tartalmazza de itt egységnyi idő alatt 2x annyi frame megy le.
A nyilak azt mutatják hogy a generált kép melyik eredeti képkockából veszi a mozgávektort. Itt amíg 1 tized másodperc alatt 6 képkocka megy az eredetiben a DLSS 3.0 nál mondjuk 12 .
[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
értem mire gondolsz csak szerintem itt speciális működésről van szó.
2 dologban is lennének ezzel kapcsolatban kérdéseim, de inkább csak az egyikre térnék ki.natív 60 FPS= 16.6 ms
natív 120 FPS = 8.3 ms
DLSS 3.0 Frame generrálás 120 FPS = 16.6 msUgyan annyi a késleltetés mint 60 FPS nél.
Tehát ugyan annyi időre jut egy eredeti 60 FPS frame és egy generált frame ami az előző eredeti frame mozgásvektorára épül ( akár ugyan az is).valójában szerintem ezek mozgás szempontjából fél frame-nek felelnek meg és kettő fut le ugyan abban az idő intervallumban amíg a natívban egy és itt a második frame arra épül ami valós mozgásvektort tartalmaz.tehát azért tettem be azt a képet hogy nem érezhetnél mozgás elugrást mert a 16.3 ms ban benne van egy olyan frame ami tartalmazza ugyan azt a framet-t amit 60 FPS nél is megtalálsz annál az időszakasz elején és és még egy generált frame-t ami erre a z eredeti framera épül és az van a 16.3 ms végén. Az általad sorolt ábrák akkor lennének problémásak ha a késleltetés is feleződne mint a natív 120 FPS nél és egy az egyben felelne meg minden alsó frame a felsőnek.
Na mindegy meglátjuk mert csak találgatok , tökre lehetséges hogy igazad van, mert nem látok még rá a működésére.
Azt továbbra is úgy gondolom hogy ahhoz véletlenek egybeesése kell hogy pont úgy essen a generált frame váltás minta mozgás irányváltása.
[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Abu85
HÁZIGAZDA
És ezt a DF videója be is mutatja, ugyanis a DLSS 2+Reflex alacsonyabb késleltetéseket ad. Tehát igazából a késleltetés látványosan növekszik DLSS 3-mal. Viszont DLSS 2-re ugyanúgy bekapcsolhatod a Reflexet, és rögtön nem szép a hatás, amit a frame generálás ad.
Ez azoknak lesz jó, akiknek 120 Hz-es kijelzőjük van, mert amúgy az NV is 120 fps fölé ajánlja.
#90 Moby : Sajnos a processzorigény a jövőben elég sokat fog változni, mert a DirectStorage az nem pusztán egy GPU-s technológia, hanem nagyon komoly processzorerőt is igényel a működése a rendszermemóriába történő dekódolás miatt. Azokat nem a GPU végzi, ez csak a saját VRAM-jáért felel. És ez alaposan ront majd a helyzeten.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egészen egyértelmű, hogy növeli a késleltetést. Nem véletlenül teszi kötelezővé az NV a Reflexet. De az is egyértelmű, hogy ha DLSS 3-mal csinálsz magadnak 120 fps-t, akkor az nagyjából olyan lesz, mint 60 fps DLSS 2-vel a késleltetést tekintve. És ezen nem változtat az, hogy a homokba dugjuk a fejünket, mert nem akarjuk elfogadni ezt a tényt.
Alapvetően a DLSS 3 haszna ott lesz, ha valakinek van 120 Hz-es kijelzője. Ott jó lehet, mert a 120 fps elég magas ahhoz, hogy a késleltetéshátrányt elfedje.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Viszont 60 fps-sel már 33,2. Ezért növeli a késleltetést. Mint írtam ez csak azoknak lesz jó, akik ki tudják használni a 120 fps-t. Mindenki másnak nincs haszna belőle. Mínusz az eSport, ott ez egy helyből kikapcsolandó dolog lesz, de most ezt ne tekintsük annyira fontosnak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Új hozzászólás Aktív témák
ph Mindenféle bemeneti adat nélkül képes képkockát generálni, ami egyszerre az erőssége és a gyenge pontja.
