Hirdetés
- Mobilinternet
- QNAP hálózati adattárolók (NAS)
- ASUS routerek
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- DIGI internet
- Synology NAS
- DIGI kábel TV
- Greenwashing miatt támadják az olaszok a Sheint
- Az irodákba kéri a dolgozóit a Dell, az Ubisoft is próbálkozik
- Álláskeresés, interjú, önéletrajz
-
IT café
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz Pakmara #57745 üzenetére
A konnektoros mérés azért messze a legjobb, mert abban ugyan vannak torzító hatások, de ha minden más hardver ugyanaz, akkor ez minimalizálható, illetve a konnektorból felvett fogyasztás nem csak a kártya fogyasztását méri, hanem a processzor többletterhelését. Ez kifejezetten fontos, mert a különböző meghajtók különböző többletterhelést eredményeznek, és ez nem mindegy a processzor fogyasztását tekintve. Ha valaki ezt nem méri ki, akkor pont úgy nem ad teljes képet, mint a szoftveres mérések.
Rácsodálkozhatunk erre évente/félévente egy cikkben, de ettől a fenti tényező már legalább tíz éve nem változott.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Petykemano
veterán
válasz Pakmara #57749 üzenetére
Megnéztem az utolsó 3 GPU benchmarkot a PH!-n. Bár csak átfutottam, de sem a tesztkörnyezet, sem a fogyasztás lapon nem találtam leírva, hogy a fogyasztási értékeket falból mérve nyerik.
Úgy rémlik, Időről időre (évente) szokott születni egy cikk arról, hogy módon, milyen játékokkal, milyen géppel történik abban az évben a mérés. Elképzelhető, hogy egy ilyen cikkben le van írva.
Hát ha Abuék nagyon korrektek és alaposak akarnának lenni, akkor lehet, hogy fent nevezett két oldal egyikében a jövőben elhelyeznek egy bejegyzést, amiben esetleg hivatkozhatják Igor méréseit a megközelítésük megerősítéseként.
Találgatunk, aztán majd úgyis kiderül..
-
félisten
Bocs de nem bírom ki.
Tehát megint az van hogy ez az AMD valamiben úgy rosszabb hogy közben sokkal jobb.( aka Raytracing, RT mag, Tensor core, fogyasztás monitoring stb.)[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Abu85
HÁZIGAZDA
Az adaptív skálázás természetesen sokkal jobb, mint a dinamikus, mert figyelembe veszi a környezetet. Ezért adaptív. Alkalmazkodik a körülményekhez, míg a dinamikus erre képtelen.
Az más kérdés, hogy sokan túl bonyolultnak tartják az adaptív skálázást, ami egyébként reális is lehet, mert az AMD-nek is 8 évbe telt, mire összerakta az első ilyen rendszerét. Tehát nem egy könnyen megoldható problémáról van szó.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
vezeralmos2
senior tag
Sziasztok.
Akármilyen architektúrával és akármilyen memóriával számolunk, szerintem egyenesen SZÁNALMAS hogy fél KILOWATT lesz egy csúcs videókártya áramigénye.
Könyörgöm, hova süllyedt az ipar?
2011-ben, a 45nm es HD 6990 a 375 wattos TDP-jével ufónak számított, az más kérdés hogy valóságban nem vesz fel annyit.
De az utóbbi pár évben csak azt látom hogy a teljesítményigény megy fel az egekbe mind intel mind nvidia téren, csak nem tudom hogy milyen réteget kívánnak ezzel megcélozni, akiknek biztosan van pénze nagy teljesítményű klímára is ami kompenzálja a gamer kártya által termelt rohadt sok hőt.
Nem tudom erről mi a véleményetek, nem is olyan régen még 250 watt elég soknak számított, most pedig már egy kisebb hegesztő teljesítményével vetekszünk gamer téren.
Nem jó irányba halad az ipar.A Sandy Bridge legendája
-
Feketelaszlo
senior tag
válasz vezeralmos2 #57757 üzenetére
Régen nem feltétlen azért nem terveztek 3-4-500 W-os bővítőkártyákat, mert ne akartak volna, ha azzal el lehet hozni a "leggyorsabb VGA" címet, hanem mert nem nagyon lehetett PC-s mércével értelmezhető tápáramkört építeni a piacon akkor kapható alkatrészekből. Tajvanon és Kínában nagyjából így ~15 évvel ezelőtt kezdtek elterjedni azok a jó minőségű és magasabb teljesítményszinteket is bíró feszültségszabályozók, tekercsek és kondik amik kerekítési hibahatáron mozognak a teljes gyártási költséghez képest és tényleg milliárdos mennyiségben gyártják őket. Előtte ez rétegigény volt amihez japánból vagy a nyugati világból kellett alkatrészt keresniük. Ekkor lett szállóige a "japán kondis" áramkör - amit ugyanúgy valamelyik Kínában gyártottak, de rá lehetett írni a dobozára, hogy a nyákon levő kondenzátorok márpedig japán származásúak amihez magasabb minőséget társítottak a vevők. Lásd még, hogy a 2000-es évek elején mennyire ócska volt ezekben az országokban a minőségbiztosítás: kondenzátorbetegség.
Ettől függetlenül továbbra is fenntartással kezelendőek a következő generációval kapcsolatos spekulációk - elképzelhető, hogy az Engineering Sample darabok amikről kiszivárog információ csutkáig vannak tekerve tesztelés céljából, a valóságban meg akár 100W-al alacsonyabb lesz a tényleges teljesítménykeretük. S mivel a másik aktív téma, hogy a raktárak roskadoznak a jelenlegi generációs videokártyáktól a végső terméken a teljesítményhatárok letekerése olyan húzás, amit néma egyetértésben mindkét cég megléphet, hogy a túl nagy generációk közti fejlődéstől ne váljanak eladhatatlanná a korábbi termékeik. Kiadják a középkategóriát 250W-al, majd ha jön a félidős frissítés Super/xx50 néven akkor feltekerik 300W-ra, hiszen már eleve így tesztelték. AMD RDNA3-nál pláne gyanúsan magasak a pletykált 3Ghz+ órajelek. -
Petykemano
veterán
Megjelent pár tábálzat arról, hogy milyen számokkal leírható architekturális változtatás érkezik az RDNA3-ban. A változtatásokat említése különös fókusszal irányul a raytracing képességekre
BVH, VODP, WMMA, ML
[link]"RDNA3 will have double (2x) the L0 and L1 cache to better fit the BVH for massive RT perf gain! By taking pressure off L2 & Inf cache. (RDNA2 RT was L2 BW limited)"
[link]"For RDNA3 a 3KB L0 can fit over 1,000 BVH nodes per dual CU. L1 can fit 8x as many. Due to L2 latency it is vital that BVH nodes be read from L0/L1 as much as possible."
[link]
Számok a WCCF-en: [link]
A jelek azt mutatják, hogy Abunak talán igaza lehetett, hogy a RayTracing leginkább memória/cache sávszélesség probléma. Legalábbis az AMD architektúrájában.Szerintem lélekben mindenképpen készüljünk Abu többoldalas tátottszájú ámuldozására, amelyben azt taglalja, hogy az AMD milyen csodálatos és fantasztikus megoldásokkal
zárkózikkészül fel az RT korszakra.
(Szerintem már írja is. )Találgatunk, aztán majd úgyis kiderül..
-
Yutani
nagyúr
válasz Petykemano #57759 üzenetére
A változtatásokat említése különös fókusszal irányul a raytracing képességekre
...amelyekkel végre utolérik az Ampere hatékonyságát.
#tarcsad
-
Abu85
HÁZIGAZDA
válasz Petykemano #57759 üzenetére
A réjtrészing az mindenhol memória/sávszél probléma. Igazi réjtrészinget eleve nem láttunk még, mert ahhoz kellene a programozhatóság.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Semmit. Ugyanazokat a problémákat, amiket mindenhol. Egészen rövid sugarakat, és másodlagos sugarakat alig-alig. Amíg nem lesz programozhatóság, addig ezeket nem lehet megoldani. Esetleg úgy, hogy elkezdünk 100 GB-os VRAM-okat pakolni a VGA-kra, de az overkill, akkor már igazán jobb megoldás, ha programozható lesz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
félisten
Ettől függetlenül ez Ray tracing. Nem lehetett észre venni hogy a sugarak rövid távon mennek, igazából az összehasonlításban jobban néz ki az RT verzió még DLSS-sel is.
Minden jó ami itt születik. ( Ettől függetlenül elhiszem hogy jó lesz)[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
imi123
őstag
Szia Abu!
Inkább VS-be tartozik de megkérdezem itt.
Intel RT-s video-ban láttam pár diát ahol a traversal RT-t említik.
Ez vajon a Traversal shading megfelelője?DXR1.1 vajon tudja ezt kezelni. Gondolom RDNA3-ban is fogunk valami hasonlót látni.Srácok bocsi az off-ért
Tévedni emberi dolog, de állati kellemetlen.
-
Abu85
HÁZIGAZDA
Korábban már linkeltem az Intelnek egy régebbi prezentációját, amiben kifejtik, hogy ez miért nem jó réjtrészing.
A lényege ennek annyi, hogy ahhoz hogy jó legyen nagyon-nagyon-nagyon sok GB-nyi VRAM kellene, és amíg ez nincs, addig rendkívül limitáltan tud az egész működni. Ezért sem jutott el olyan szintre a réjtrészing, hogy a usereket érdekelje. Egyszerűen keveset ad nagyon drágán. De maga az eljárás nem ilyen fos. Az aktuális implementáció teszi csak szarul alkalmazhatóvá.
Az Intel is felhozza a saját előadásában, hogy jójó, de az UE5-ben mit csinálsz? Számolsz akár 1 GB-nyi többletterheléssel AS-t? Nincs annyi memória a VGA-kon, hogy megtedd, még két év múlva sem lesz. Ezért sincs az UE5-ben alapból RT. Nincs rá elég memória, márpedig az UE5 nagymértékben épít a geometriai részletességre, és részletes geometriával a mostani RT nem tud működni.
#57765 imi123 : Lényegtelen a hardver. A programozható traversal eleve a shadereken fut. Nem kell hozzá külön részegység. Azért programozható, hogy ne is kelljen traversal unit. Szóval akármelyik RT-s hardver jó erre, csak a szoftveres háttér hiányzik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
imi123
őstag
Eddig nem azt mondtad hogy jelenlegi hardverek közöl egyik sem támogatja?
Tévedni emberi dolog, de állati kellemetlen.
-
Abu85
HÁZIGAZDA
válasz imi123 #57767 üzenetére
Miért ne támogatná? A traversal shader az csak shader lesz, arra pedig vannak feldolgozók. Amit mondtam, hogy a mai hardverek ezt a folyamatot esetenként fixfunkciós egységgel csinálják. Ez az egység fog elveszni, hiszen ha programozható lesz a folyamat, akkor nincs rá szükség. De ettől bármelyik mai RT-s hardver ki tudja számolni a shadereken keresztül.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Petykemano
veterán
Hja', mégiscsak kellett volna az a 256GB-os RDNA3...
(ami persze nem 256GB GDDR6 ramot jelent, hanem a VRAM mögött/mellett pl egy 256GB-os SSD-t, amit a GPU DirecStorage és/vagy CXL segítségével elér és sajátjaként kezel, mintha csak VRAM lenne, aminek a valódi VRAM a puffere, mint ahogy azt a Vega esetén láttuk a HBCC esetén a HBM és a rendszermemória között.)
Találgatunk, aztán majd úgyis kiderül..
-
Abu85
HÁZIGAZDA
válasz Petykemano #57770 üzenetére
Annak az elérése pedig lassú. Ráadásul a réjtrészing problémája az, hogy a másodlagos sugarak nem koherensek, tehát nehezen cache-selhetők. Sokkal jobb megoldás erre a programozhatóság.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Yutani
nagyúr
Egyszerűen keveset ad nagyon drágán.
Nem értek egyet a "keveset ad" megfogalmazásoddal. Kisfiam sok Minecraft videót néz(ett, de letiltottam róla), és baromi sokat számít, hogy van-e RT vagy nincs a felvett videóban. Ennél az egyszerű játéknál olyan sokat ad hozzá az RT a látványhoz, hogy elképesztő.
#tarcsad
-
GeryFlash
veterán
Milyen szerencse hogy a gyartok nem kepesek HBM memoriakat hasznalni helyette megy a szenvedes a GDDR-rel
Hi, i'm new to APHEX TWIN, so i was wondering how much the IQ requirements was to enjoy his stuff. and understand all the underlying themes, because its really complex stuff. I have IQ of 119 but i heard that you need atleast 120 is it true?
-
Abu85
HÁZIGAZDA
válasz Yutani #57772 üzenetére
[link] - aminél jobb minőséget is el lehet érni raszterizálással.
Ugyanaz a Minecraft baja is. Hiányzik a programozhatóság, és ez extrém módon limitálja a biztosítható minőséget.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Petykemano
veterán
"Hiányzik a programozhatóság"
Bocsánat, gondoltam, belekérdezek, hátha csak én nem tudom, mit kell ez alatt érteni pontosan.
A játék motor nem eléggé programozható?
Vagy a Sugárkövetés implementációja? (fekete doboz effektus)
Vagy a DXR?Kinek és mit kéne tennie a megfelelő eredményért?
(Elnézést kérek a tisztelt közönségtől, légyszi harapjatok rá egy gumikacsára, ha most az következne, hogy mit rontott el az Nvidia)
[ Szerkesztve ]
Találgatunk, aztán majd úgyis kiderül..
-
Abu85
HÁZIGAZDA
válasz Petykemano #57776 üzenetére
Itt az a lényeg, hogy a BVH gyorsítóstruktúrát hogyan generálod. Ez több szintből áll. A BLAS az a szint, amikor már a háromszögeket lövöd ki a sugarakkal, de előtte egy csomót kivágsz a fölötte lévő BLAS és TLAS szinteken, amikor még csak dobozokat nézed, hogy a sugár metszi-e. Na most ezek az AS szintek össze vannak kötve, mert mindegyik háromszögnek megvan a maga doboza, mindegyik doboznak van egy nagyobb doboza - amennyi szintre le van ez generálva. Az ezek közötti összeköttetés programozhatóságáról van szó, ami a mostani API-ból hiányzik, ugyanis az összeköttetés is szimplán fixfunkciós. Ez azért nem jó, mert ugyan az AS-t több szintre legenerálja, de fogalma sincs, hogy bizonyos háromszögekkel vagy dobozokkal kell-e egyáltalán foglalkoznia. Akkor derül csak ki, amikor már kiszámolt a hardver mindent, hogy hopp, azokat ott pont nem kellett volna. Na mindegy most már, -50 fps. A programozható bejárás például azt biztosítja, hogy még a valós számítások előtt le tudsz vele futtatni egy extra úgynevezett visibility shadert, ami megmondja, hogy mi az, ami látszik egyáltalán a kamera nézőpontjából. Ami nem látszik, arra nyilván tök felesleges bármennyi erőforrást elkölteni, mert a végén úgyis ki lesz vágva. Ez a programozhatóság lényege, hogy még azelőtt vágj el minden AS összeköttetést, mielőtt egyáltalán erőforrást költenél rá. Vagy a dinamikus LOD esetében olyan formában számolj vele, amilyen formában megéri. A mostani API implementációnál még az AS generálása előtt el kell dönteni a LOD-ot, és később ez nem módosítható. A programozhatóság biztosítaná azt, hogy ez menet közben módosítható legyen, ha esetleg kiderülne, hogy az a százezer háromszögből álló szobor végül csak 4 pixelnyi területen látszódik. Akkor ugye elég lenne rá egy ötven háromszögből álló modellel számolni, mert ugye úgyis csak egy pötty lesz a monitoron.
Az ilyen jellegű programozhatóság hiánya az, amiért az RT implementációk olyan szarok a játékokban. Alig van hatásuk, nagyon korlátozott távolságra működnek, és minőségileg is eléggé rondák. Egyszerűen nincs programozhatóság, amivel korlátozni tudnád az erőforrásokat csak a látható területekre, így mindent számolsz a lehető legnagyobb részletességgel, majd amikor a végén kiderül, hogy nem is látszódnak, csak akkor tudod kivágni őket, de közben már elment rá az erőforrás. Ezt úgy szokták ma korlátozni, hogy a sugarakat csak nagyon-nagyon korlátozott távolságra lövik ki, hogy ne legyen sok számítás, de ugye pont nem ez a sugárkövetés lényege. Mehetne ez nagyon messzire is, csak meg kellene előre mondani, hogy mivel kell foglalkozni, és mivel nem. Na ezt programozhatóság nélkül nem lehet megtenni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
félisten
Csak ez nem azt jelenti, hogy nincs RT és eddig nem láthattunk.Ez egy más dolog amiről beszélsz.
Ez azt jelenti, hogy erőforrás igényes ,mert mindenre számol és közben szerinted azért nem igazi RT mert nem a végtelenbe számol ütközést csak megadott távolságig vagy megadott ütközés számig.
Ezen állítás szerint akkor az sem igazi RT, ami nem számol azokra a felületekre ütközést ami nem látszik. tehát pont ugyan úgy ráfordítható erre is a dolog.
Egy játékos nem igazán látja meddig van kilőve az a sugár, legalább is én egy Metroban vagy BF-ben vagy Controlban nem vettem észre hogy jah ez a sugár csak addig ment.
Amíg normális látótávolság volt és számított az árnyék vagy a tükröződés addig működött az RT is, kivéve PÓkemberben és CP2077 ben városi területeken eljött azért már ez a dolog, de nem volt zavaró. Egy programozó sem hülye hogy ezt ne így oldotta volna meg.
Ennek az ára az erőforrás igény volt API nélkül. szükséges hozzá a hardver vagy nagy mennyiségű számítási teljesítmény.( mindegy hogy dedikált vagy sem, ez gyártói megközelítés kérdése)
Amúgy BF5 ben sem volt ütközés minden felületen ,csak ami látszott, hisz ezt már 4 éve promózták [link] pedig akkor sem volt hozzá API.
Ezek szerint ezt meg lehetne oldani játékmotoron belül is bizonyos szintig, persze az lenne a jó ha az API-ban működne már alapból és a kettő, Nvidia szerint három ötvözete adná a jó és gyors megoldást.( Dinamikus LOD + Látható felületekre particionálás + Nvidia szerint egyelőre Dedikált hardver.)[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Abu85
HÁZIGAZDA
Ez azt jelenti, hogy nem tudod úgy használni, hogy látványos legyen, mert túl sok olyan dolgot számolsz a mostani pipeline-nal, ami nem is látszik. Ezért tartják sokan gimmicknek.
A dinamikus LOD-hoz programozhatóság kell, amit kizár a dedikált hardver. Tehát nincs olyan, hogy mindkettő van. Vagy programozhatóság van, vagy fixfunkciós hardver a bejárásra. A kettő együtt kizárja egymást.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
félisten
Szerintem nem szabad ezt így gondolni, vagy nem annak tartani, mert az RT nek nem igazán van határa.
Elég megnézni a Filmeket. Ha lesz erőforrás majd akár ilyen LOD vagy látható terület spórolással, akkor növelik az ütközések számát vagy rátolják a hangzásra, effektekre, a maradék erőforrást vagy több látványosabb textúra lesz majd ami növeli az RT számítási igényét.
Legalább is ha látványos előrelépést akarnak akkor egyelőre nem biztos, hogy a mostani effektekkel megfelelő sebeséggel is elég az RT látványvilága, miközben sokkal de sokkal több van benne. Most már ilyesmit látnának szívesen az emberek azt gondolom: [link][ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Abu85
HÁZIGAZDA
Most pont nagy korlátokat szabunk neki azzal, hogy maximum pár virtuális méterig működhet, és másodlagos sugarak nélkül. Ezért nem ad látványos különbséget. Olyan elképesztően tragikus korlátok közé van szorítva a mostani RT implementáció, hogy nyilván nem lehet vele látványos dolgokat elérni. És persze a userek sem hibáztathatók, hogy csak a sebességcsökkenést veszik észre, mert a minőségelőny az minimális.
Csak ez nem egy hardveres probléma. A jelenlegi helyzetet pusztán a programozhatóság hiány idézi elő.
Ó igen, az nagyon igaz... olyasmit szívesen látnának az emberek, csak az ugye két darab NVLINK-kel összekötött V100-on futott, mert 64 GB VRAM kell neki. Ahhoz, hogy ez fusson 10 GB környéki VRAM-mal, kell a programozhatóság.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
félisten
A hardveres sebesség is probléma , elég megnézni hogy Hány filmstúdió van korlátok közé szorítva brutális szerverparkokkal.
Jelenleg a Pixar tud megfelelő de a valós és szükséges maximális sebességű rendereléstől még így is elmaradó szerverparkkal dolgozni. Ahhoz hogy nagyot lépjünk előre a mostaniaknál többszörösen gyors hardverek kellenek megfelelő mennyiségű memóriával az otthoni gépekbe, pl V100 x4.Na pont én is ezt írtam
[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Abu85
HÁZIGAZDA
Ez maximum a keleti stúdiókra igaz, ahol az ár miatt muszáj GPU-kat használniuk a feladatra. A nyugati filmstúdiók tehetősek, oszt megveszik a legtöbb magos procit több terabájt RAM-mal. Ők azért annyira nem érzik magukat korlátok között. Jövőre 12 TB-os szörnyeket tudnak építeni, míg keleten be kell férni 128 GB-ba és kész.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
félisten
Pixarnak van legfejlettebb studiója raytracing területen - ŐK GPU és CPU hibrid renderelést használnak Nvidia kártyákkal XEON és most már TR CPU--kal.
Mondjuk jah brutál szörnyek az biztos de hát ott aztán van miből vissza hozni az árát[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Devid_81
nagyúr
Mi ez a sok off, minnya szolok ma'n valami modinak
...
-
Abu85
HÁZIGAZDA
A Pixar igényeit egyszerű kielégíteni, mert nem a realisztikus látvány a lényeg. Emiatt ők megengedhetnek sokkal kevesebb memóriával rendelkező rendszereket. A valódi Hollywoodi igények viszont nagyon realisztikus modelleket igényelnek, hogy ne tudd kiszúrni a filmben az igazi és a CGI fát. Ehhez már nincs elég memória a gyorsítókon. Ezért is van Hollywood előnyben, mert nekik nem téma 4 TB-os memóriával rendelkező CPU-kat összerakni. Jövőre pedig kapnak olyan játékszert, amibe 12 TB-nyi tartalmat is pakolhatnak. És ők ezt nagyon ki is használják tartalomvizualizáció során, mert rengeteg munkaórát spórolnak meg azzal, hogy a modelleket nem kell 60-80 GB-os darabokra bontani.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
paprobert
senior tag
Szerintem a hardvergyártók ennél többet nem is akarnak egyelőre, sőt, örülnek is a jelen állapotnak. Azért, mert
1. Működik (valamennyire).
2. Nagyobb, új hardver -> jobban működik. (skálázhatóság)
3. Csak az elméleti hatásfok a probléma, amelyet a 2. pont tud idővel tökéletesíteni.Így legalább lesz értelme az RX5700 erősségű konzolokat meghaladva 3-4-5x-ös GPU erőt elkölteni valamire.
A gyártók nem akarnak a jelenkor hardverével tökéletes rélytrélyszinget. Nekik megfelel 10-20 évre előre kimérve, generációnként egyre több dolgot átvinni a hibrid renderből az RT irányába.
Illetve nem ártana megemlíteni, hogy a programozhatósággal két dolog is jár:
1. sebességvesztés, hardverből. (vagyis annak hiányából)
2. a low level API-ra(DX12, Vulkan) váltáshoz hasonló "hogy a f*szba csináljam" programozói fejfájás is.[ Szerkesztve ]
640 KB mindenre elég. - Steve Jobs
-
félisten
válasz Petykemano #57788 üzenetére
Ez Függ a szofveres tamogatástól és a konkurenciától.
[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
T.Peter
őstag
"Ezért sincs az UE5-ben alapból RT."
Ez igy azert ebben a formaban nem pontos, de ezzel te is tisztaban vagy, olvastad a dokumentaciot.
Van rt, csak nem haromszogekkel szamol, hanem sdf-fel. Ha pedig bekapcsolod hogy haromszogekkel szamoljon, akkor a nanite mesh helyett egy proxy mesh-t hasznal, de ezzel is tisztaban vagy mar.
Amellett, amit irtal, hogy miert nem megvalosithato az rt abban a formaban ahogy jo lenne, tekintve, hogy az egyik oldalon 2, a masik oldalon csak 1 generacio tamogatja a dxr-t a jelenlegi formajaban, semmi ertelme nem volt nekik tobb energiat fektetni ebbe. Konzolon igy is orulnek ha a lumen-t megcsinaljak 60 fps-re ugy, hogy sdf-re szamol utkozest. Majd a pc-k izzadhatnak ha rakapcsoljuk az osszes haromszoges rt feature-t.Itt amugy meg lehet nezni honnan indult az egesz nanite otlete:
HPG 2022 Keynote: The Journey to Nanite - Brian Karis, Epic Games -
Abu85
HÁZIGAZDA
válasz paprobert #57787 üzenetére
Ironikus módon a konzolon ez nem probléma, mert ott PS5-ön már a start óta van programozhatóság a bejárásra, illetve a Microsoft konzolján is megoldható ez Radeon Rays egyik kiegészítése által.
Ez egy csak PC-t érintő gond, mert itt igazából nincs túl nagy haszna például a Radeon Rays megoldásának, ugyanis az csak AMD-n fut. Ez Xboxon elfogadható, de PC-n nem.
#57790 T.Peter : Ami ugye önmagában eléggé korlátozott, mert a DirectX 12/Vulkan API alól csak a triangle és az axis-aligned bounding box intersection gyorsítható, a signed distance field nem. Utóbbi struktúrát nem támogatják a GPU-kba épített fixfunkciós egységek, mert nincs definiálva az API-ban. Szoftveres RT-t pedig eddig is lehetett csinálni, ebből a szempontból nem az UE5 az első.
A hardveresen gyorsított RT-t pedig a nanite-ra nem működik, ahogy azt írod, és ez is baj, mert amúgy működne, ha a bejárás programozható lenne, csak a fixfunkciós bejárás annyira, de annyira nagy limitáció, hogy képtelenség a borzalmasan gyenge hatásfokát ellensúlyozni mikropoligon render mellett. Ennyi háromszögnél nem jó, hogy előre kiszámolunk mindent, majd a végén dobjuk el azokat, amiket nem kellett volna. Az lenne a jó, hogy előre megnézzük mi látszik, és csak azokat számoljuk ki. Úgy működne, és például PS5-re van is olyan UE5 verzió, amivel működik a nanite-tal is a hardveresen gyorsított RT, mert azon a konzolon, azzal az API-val meg tudod írni a visibility traversal shadert, amivel még azelőtt el lehet dobni a nem látható részeket, mielőtt bármi számítás történne. Ez csak PC-n probléma. Persze az Epic építhetne a Radeon Rays kiterjesztésére, de azzal csak az AMD-re oldja meg ezt a gondot, és akkor még ott az Intel és az NVIDIA, tehát ide egy szabványos megoldás kellene.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Yutani #57792 üzenetére
A Sony nem licenceli az UE5-öt, tehát nekik ez igazából nem téma. A Microsoft licenceli viszont, és eléggé átírták, hogy a limiteket feloldják benne.
A Sony viszont már használ a játékaiban traversal shadereket. Ezt az API-juk lehetővé teszi a start óta.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
paprobert
senior tag
Ha elértük volna a pusztán hardveres gyorsulásnak a határát, akkor érteném a hozzáállásodat. Szükség lenne kiaknázni az elherdált sebességet, a hardveres bottleneck szoftveresre való cserélésével a további gyorsuláshoz.
De jelen állapotban -amikor minden arányosan gyorsul- ezért lobbizni kicsit olyan, mint a GeForce FX megjelenésekor Vulkan-ért kiáltani.
[ Szerkesztve ]
640 KB mindenre elég. - Steve Jobs
-
Alogonomus
őstag
válasz paprobert #57794 üzenetére
Egész eddigi PC-s pályafutása során a sugárkövetés megítélése ugyanúgy csak hit kérdése volt, mint anno az élsimítás kérdésköre. A sugárkövetés bekapcsolása jelenleg drasztikus sebességcsökkenést okoz, majd ezt próbálják a különböző képrekonstrukciós eljárásokkal "emészthető" szintűre visszatornázni a sugárkövetéses címekben.
Eleinte az élsimításból is legfeljebb a legkisebb x2 szintet volt értelme bekapcsolni, mert a 20+ évvel ezelőtti kártyákat már az is jelentősen megterhelte. Aztán szép lassan már egy x8 érték is beállítható lett, végül nagyjából a Pascal/Polaris éra környékétől már az x16 is reálisan választható lehetőséggé vált, mert már eljutott a technológia és a kártyák teljesítménye odáig, hogy már felvállalható sebességcsökkenést okozott csak a sokat javuló képminőségért cserébe.
A valós idejű sugárkövetést lehetővé tevő kártyák még csak a második generációjuknál tartanak. Az első élsimításhoz tervezett kártya a Geforce 3 volt 2001-ben, és tizensok generációt követően jutottunk el odáig, hogy már nem nagyon számít a képkockasebességben, hogy az MSAA értéke x2 helyett x16. A valós idejű sugárkövetés még bőven a kísérletezős szakasznál tart, és talán további 2-3 mostanihoz mérhető teljesítményugrást követően már elég erősek lehetnek az akkori kártyák a használható sebességű teljes értékű sugárkövetéshez, amilyet a mozifilmekben látunk. -
Cyberboy42
senior tag
De ha ez így van, akkor mégis mokor dobja el az nvidia a fixfunkciós egységét, hogy mindenhol működhessen ugyan az, és akkor mehet a fejlődés, már ha jól étem hogy tulajdonképpen ez a probléma.
[ Szerkesztve ]
...A teknős ezután pszichoanalitikusként kezeli az identitászavaros krokodilt...
-
félisten
válasz Cyberboy42 #57796 üzenetére
Nem jól érted szerintem.
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Abu85
HÁZIGAZDA
válasz Cyberboy42 #57796 üzenetére
Igazából azt nem kell eldobni. A hardverbe beépíthető, maximum nem lesz használva. Az API-t kell frissíteni csak.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
KillerKollar
őstag
Azt lehet már tudni, hogy a Navi 31 is az új fajta 1x16 tápcsatit fogja használni?
-
Abu85
HÁZIGAZDA
válasz KillerKollar #57799 üzenetére
A mérnöki mintákon még klasszikus 8 tűs van. De azt tudom, hogy az AMD nem tiltja meg az új tápcsati használatát a partnereknek, viszont nem ragaszkodnak hozzá, mint az NV. Az Ada úgy van tervezve, hogy annak nagyon hasznos az ATX 3.0 és az új tápcsati, míg az RDNA 3-nak nincs nagy haszna az új szabványokból, mert nem szükségszerű az extrém áramtüskék elviselése.
Ez egy dizájnbeli eltérés lesz. A Navi 31 pillanatnyi maximális terhelhetősége 450 watt alatt marad. Tehát ennél többet még pillanatnyi tüskékben sem fog felvenni. Az NV-nél az AD102 pillanatnyi maximális terhelhetősége 810 watt. Ugyan tartósan messze nem fogyaszt ennyit, de szüksége van az ATX 3.0 pillanatnyi 180%-os túlterhelhetőségére, amit az új tápcsati biztosít neki.
Az AMD partnerei is felszerelhetik persze az új tápcsatit, de nem tudják majd kihasználni, mert az Navi 3x nem az ATX 3.0 specifikációkhoz lett tervezve, képes maximum teljesítményen működni ATX 2.x-szel is. Az NV GPU-ja is tud ilyen tápokkal működni, csak megszűnik az extrém túlterhelhetőség, ami nélkül a turbó nem fog úgy működni, ahogy ATX 3.0-s tápokon.
[ 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
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
- ZOTAC RTX 3070 8GB GDDR6 AMP HOLO Eladó! 107.000.-
- PowerColor RX 6600 XT 8GB GDDR6 FIGHTER Eladó! 65.000.-
- Akció! MSI GTX 1650 VENTUS XS OC 4GB GDDR6 Videokártya - Eladó! 31.990.-
- ASUS DUAL GeForce RTX 3060 Ti V2 MINI OC Edition 8GB
- Keresek Megvételre több db RTX 3080/ RTX 3080 Ti/ 3090 GPU-kat Árak megegyezés szerint!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Ozeki Kft
Város: Debrecen