- Hivatalosan is bemutatta a Google a Pixel 6a-t
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Friss koncepciót hoz a Nothing Phone (3)
- Xiaomi 15 Ultra - kamera, telefon
- Íme az új Android Auto!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Xiaomi 15 - kicsi telefon nagy energiával
- iPhone topik
- Azonnali mobilos kérdések órája
- Yettel topik
Új hozzászólás Aktív témák
-
telpapa
csendes tag
"..Szerintem a DLSS 2 ok miatt létezik:."
Véleményem szerint több oka is van mint kettő és ezek nem feltétlenül szoftveres problémák. Mint például:
- A Jelenlegi technologia korlátai.Jelenleg 4 nm-nél járnak és itt már sokat nem reszelnek.
- Hűtés problémája, méret növekedés. Már így is a hűtés teszi ki a kártyák 80%-át.
10-15 éve még akár 50-70%-os ugrásokat is láthattunk a teljesítményben egy-egy generáció között, ami már elég régóta nem jellemző.
Mellette a kártyák mérete fokozatosan nőtt. Az 5090 már be sem fér egy normál házba, nem beszélve arról, hogy 4 slot-ot foglal.
A DLSS, és társai, egyenlőre számomra csak mentőövnek tűnik addig, amíg nem jön egy ujabb technologia amire át lehet állni. -
hapakj
őstag
De, igazából de
Hát pl amikor a hw-ek alkalmasak lettek rá teljesítményben és képességekben is, akkor a túltolt Motion Blur, HDR és Bloom kifejezetten ronda volt szerintem. Alapvetően első dolgom volt ezeket valami szolidabb beállításra kapcsolni. Aztán a későbbiekben ezeknek a használata is kikupálódott.
A TAA használata talán tényleg túl tolt manapság, bár én még nagyon rondának egy implementációt sem találtam. S szerintem maga az Upscaling megoldások sem egyértelműen, csak az RT miatt vannak. -
telpapa
csendes tag
Így van. Csak éppen nem realtime-ban, és akkor még ugye processzor számolta (volt hogy órákig is 1 frame-et)
Még Prerender-ben is iszonyatosan számításigényes a sugárkövetés, és picit másképpen is működik.
Véleményem szerint, komoly áttörés még évekig nem lesz. Egyszerűen nem elég erősek még ehhez a mai hardverek - ezért is megy a lopok, csalok, hazudok - ráadásul a magasabb felbontáson, még a Vram is nagyon kevés. Vram-ból 32+ alatt olyan mintha fingot reszelnél reszelővel. -
Abu85
HÁZIGAZDA
Alapvetően az eljárás nem csak sugárkövetésre jó. Mindenre hatással van, hiszen tényleg tömöríti a geometriát. De ennek a legnagyobb haszna a sugárkövetésnél van, mert sokkal olcsóbbá teszi a BVH kezelését, ami az egyik legnagyobb probléma jelenleg.
Az egész probléma egyébként nem tipikusan a sugárkövetésből ered, hanem abból, ahogy a DXR megoldja a sugárkövetést. A BVH-t ugyanis mindenképpen a driver építi fel, és ez azért van, mert maga az alkalmazott BVH formátum zárt. Tehát ezzel egy program nem tud csak úgy mit tenni, hanem el kell fogadnia, hogy valami történik a driverben, és az úgy van, ahogy lesz, tök mindegy, hogy esetleg ez a működés a program számára nagyon káros-e vagy sem.
Ugye erre a problémára koncentrál a Microsoftnak a traversal shader koncepciója, amit már nagyon régóta ígérnek. [link] - a traversal shader önmagában teljes megoldás arra a kolosszális szarra, ahogy a DXR működik ma, de nincs megegyezés a gyártók oldalán. Emiatt az Intel, az AMD és az NVIDIA is dolgozik azon, hogy ezt a kolosszális szart, ami ma a DXR, valahogy javítsák saját ötlettel.
Az Intel Lazy Build-féle Scalable Real-Time Ray Tracing megoldása tulajdonképpen az, amit a Microsoft akar a traversal shaderrel, csak egy külső API-val, a DXR-en kívülről megoldva. És persze ez is megoldás, de a gond az, hogy különálló programkódot igényel, akár minden gyártóra. De ez ettől még tényleges megoldás, csak amíg nincs szabványosítva, addig nem tud jól működni.
Az NV a Mega Geometry technikája valójában a probléma fingreszelése. Próbálják kevés programkódon keresztül megoldani, de igazából csak olyan limiteket teremtenek, hogy a DXR API-nak egy csomó függvényével nem is kompatibilis. És ha azokat a függvényeket, amikkel nem működin nem használod, akkor jó, de ezek komoly korlátok a fejlesztői oldalon, plusz itt is kell per gyártói alternatíva. De ez egyébként sokkal kevésbé valós megoldás, mint az Intelé vagy a Microsoftté, mert nem programozható.
Az AMD-féle DGF is igazából fingreszelése a mostani limiteknek, viszont abból a szempontból van egy nagy előnye, hogy marhára nem kell hozzá semmilyen specifikus kód a sugárkövetéshez. A tök szabványos DXR kódokkal teljesen kompatibilis. Nem kell per gyártó szállítani semmi extrát, vagyis amit a DXR tud, azt a DGF-fel is 100%-ban használni lehet, és egyetlen kódbázisból támogatható minden gyártó. Az AMD ilyen formában máshonnan közelít, az a cél, hogy ne bontsák meg a kompatibilitást, hanem olyan helyen oldják meg a DXR gondjait, ami nem jelent extra programozói munkát a fejlesztőknek, amikor írják a sugárkövetéses effekteket. De ez is sokkal kevésbé valós
megoldás, mint az Intelé vagy a Microsoftté, mert ugyanúgy nem programozható.Tehát összességében a gondokra, amire reagálnak a gyártók az Intel és a Microsoft mutatott be igazán használható valós megoldást. Az NV és az AMD megoldása kevésbé jó, de az AMD DGF legalább szabványos kódból 100%-ban támogatható. Az NV megoldása pedig úgy kevésbé jó, hogy közben nem is megoldható szabványosan, sőt, a szabványos függvények egy része nem is kompatibilis vele.
Egyébként az egész probléma nem létezne, ha a DXR nem lenne olyan hígfos, amilyen most. Például a konzolokon nem is létezik erről vita, és nem azért, mert azok más hardverek, hanem azért, mert a konzolokon van olyan módja az API-nak, ami lehetővé tesz programozható bejárást. Tehát ott ezekre a fingreszelésekre nincs is szükség.
-
-
hapakj
őstag
Csak ugye az van, hogy amikor a raszterizáció bontogatta szárnyait, akkor alacsony felbontásban, így nézett ki:
Nem értem, honnan jön az elvárás, hogy az RT egyből a mai raszterizáció minőségét adja rögtön megjelenéskor. Ha nem lenne lehetőség használni, honnan jönne a tapasztalat vele kapcsolatban, hogy merre érdemes menni, milyen technikákat érdemes használni.
Egyébként sok ideig még így is úgyis hibrid rendering megoldások lesznek, s hogyha az RT hw egységek nem lennének a GPU-kban, akkor a fejlesztők hasonló megoldásokat implementálnak az ALU-kra szoftveresen. Nem látom hol lennénk előrébb. -
Szerintem ilyen a 3D grafika az elejétől fogva.
Pl. a bump/normal mapping is arról szólt, hogy legyen egyszerűbb a geometria, majd a texturát úgy rendereljük, hogy a fényforrásokat figyelembe véve úgy tűnjön mintha recés lenne a fal - de csak kellően nagy szögből.A sprite-okból épített, soha el nem forduló bokrokról ne is beszéljünk.
Én ezt a nostani geometria tömörítést sem látom rosszabbnak.
A realtime 3D grafika mindig is a kamuról szólt, mert a hardver nem bírta a jobb minőséget.
-
Abu85
HÁZIGAZDA
Igen nézem a videóit. Írtam is néha neki a hozzászólások közé, amikor próbáltam a marhaságait helyre tenni, de mivel mindig törli, amikor kijavítom az ostobaságait, ezért már ráhagytam. Ez a gyerek egy nagy kamugép, aki félremagyaráz dolgokat, és pénzt gyűjt arra, amit pénz nélkül is megtehetne akár ma is.
Szerencsére van olyan személy, aki elmagyarázza helyettem: [link]
-
-
Doratov
csendes tag
Én el tudok képzelni egy on/off beállítást, sőt, akár egy csúszkát is, aminél a fejlesztők által az egész programra előre definiált beállítások összességét lehet kiválasztani. Minden objektum geometriájához tartozhat gondolom több tömörítési precizitás, de ha valakinek elegendő mennyiségű memóriás kártyája van, akkor teljesen ki is kapcsolhatja. Érdekes lenne jövőbe skálázódó játékokat látni, ahol a tényleges memória igény többszöröse tömörítetlenül, mint amennyi egy aktuális csúcskártyán van.
-
hapakj
őstag
Lehet benne ráció, hogy működik. Lényegében ha már gond, hogy olyan részletes a geometria, hogy probléma a helyigénye, akkor már tömöríthető is olyan szinten, hogy annak ne legyen érzékelhető hatása. Igazából a textúra tömörítés is emiatt működik. A normal mapek / displacement mapek, amik szintén geometria információt tároltak szintén veszteségesen tömörítve voltak.
Lényegében a hw-ek fejlődésével a probléma dimenziója változik. Már hatalmas geometriát is kezelni tudnak, s ami részletek eddig textúrákban voltak tárolva, most már ténylegesen geometriában vannak.
Ha jól értettem az nVidia ezt még jobban tovább gondolta, s ők lényegében mindent (a részletes geometriát, material és textúrát) egy tömörített adathalmazban akarnak tárolni, aminek dekódolását a tensor coreokkal hatékonyan meg tudják oldani. Nah az már igazán egy radikális újragondolása és egységesítése lenne a content kezelésnek.
Sokan vannak így, próbálják a semmiből kitalálni, amit már eleve nem értettek.
Új hozzászólás Aktív témák
Hirdetés
- Bomba ár! Dell Latitude E7450 - i5-5GEN I 8GB I 256SSD I 14" FHD I HDMI I Cam I W10 I Garancia!
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- Telefon felvásárlás!! Huawei P20 Lite/Huawei P20/Huawei P30 Lite/Huawei P30/Huawei P30 Pro
- Zebra ZP505 EPL - Hőpapíros címkenyomtató
- Telefon felvásárlás!! Samsung Galaxy S23/Samsung Galaxy S23+/Samsung Galaxy S23 Ultra
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest