Hirdetés
-
Megjelent a Moondrop audio-fókuszú telefonja Kínában, lesz globális verzió is
ma Középkategóriásak a specifikációk, ha az SoC-t és a kamerákat nézzük, de itt a kiemelt figyelem a hangra összpontosul, abban pedig egyedi dolgokat kínál a készülék.
-
Hosszabb bemutatót kapott a Steel Seed
gp A PC-re és konzolokra szánt teljes kiadás valamikor idén debütál, pontos dátumot még nem kaptunk.
-
Lopják az LG akkutitkait
it Inkább licenceli ezentúl az akkumulátoros szabadalmait az LG Energy Solution, mert túl sok a jogsértés. Az LGES mellett az UMC is az autóipar egyre lassuló keresletére figyelmeztet.
-
PROHARDVER!
Kérdés előtt olvasd el az összefoglalót!!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz belinho #6295 üzenetére
Ha nem optimális a memóriamenedzsment, akkor azt optimalizálva még teljesítményt is nyernek. Az kérdés, hogy mennyit. Attól függ, hogy hol van a probléma forrása. Lehet, hogy elenyésző lesz a különbség, de az is lehet, hogy 10-20%-ot is tudnak még boostolni.
(#6300) Tomix24: A memóriakezelés az hardveres. Itt a menedzsmentről van szó. Ezt a szoftver végzi, mivel a GPU-nak külön memóriája van, amit el kell rejteni az OS elől. Valszeg az itt a fő eltérés, hogy a GCN teljesen más rendszert használ, mint a többi GPU-architektúra. Nincsenek direkt elérésű blokkok, ahogy a régi vagy a konkurens architektúrában. Teljesen moduláris az egész hardver, így a teljes a különböző blokkok egymástól elkülönülnek, ám a működést szinkronizálni kell. A korábbi hardvereken ilyenre nem volt szükség, mert a memóriacsatornákhoz fel volt fűzve az L2 gyorsítótár és a ROP. A GCN-en ez nincs meg, így ez teljesen más szoftveres menedzsmentet igényel. Persze az előnyök nyilvánvalók. A memóriacsatornák közös L2 gyorsítótárral vannak fűzve és nincsenek hozzárendelve ROP-ok. Ezzel a kihasználás sokkal magasabb lehet, mint a régi megoldással, a menedzsmentért felelős modul viszont bonyolultabb, így azt nehezebb rá megírni.
[ 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 belinho #6304 üzenetére
Az kizárt. Ha nem optimális valaminek a menedzsmentje, akkor azzal eleve teljesítményt vesztesz. A mennyit az mondom, hogy kérdés, de lassulni nem fog, mert eleve a feldolgozás lesz hatékonyabb a menedzsment javításával, vagyis ugyanazzal a munkával gyorsabban végezhet. Az ilyen változások gyorsulást hoznak. Valószínű egyébként, hogy a 12.11-es driverrel már egy új menedzselés került be, amit tovább lehet optimalizálni. Ergo az elért gyorsulás eleve ennek lehet köszönhető, szerintem olyan hatalmas boostokra már nem érdemes számítani, de nyilván, ha bizonyos programokban spike-okat okoz valami a rendszerben, akkor azt kiszűrve gyorsulást lehet elérni.
(#6305) Attix82: A fejlesztőknek ezzel nincs dolguk. Erre nem kell optimalizálni, mert ez a driver belső működése. Teljesen független az alkalmazás működésétől. Maximum rutinokat lehet írni, hogy az adott programhoz jobban igazodjanak a pufferméretek, de ez nem a fejlesztők feladata.
[ 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 Attix82 #6308 üzenetére
Ez az egész egy specifikus dolog is. Most van nálam egy GTX 670 is, amivel tesztelgetek. Például BF3-ban Radeonon kevesebb a spike, mint GeForce-on. Borderlands 2-ben pont fordítva van és Radeonon több a tüske. DiRT Showdownban megint fordítva van, és a GeForce-val sokkal több a tüske. A Far Cry 3-ban MSAA-val tüskézik mindkettő. Egy részük megmagyarázható. A DiRT-ben a compute shaderek kikapcsolása teljesen eltünteti a tüskéket GeForce-on. A Far Cry 3-ban az MSAA-tól kell búcsúzni, és jóval jobb lesz. A HDAO levételével a GeForce tüskéi is eléggé kisimulnak. A Radeonon erre nincs szükség. A Borderlands 2-re van válasz, hogy ott pufferméretet kell változtatni. A BF3 esetében kevés tüske volt GeForce-on. Elképzelhető, hogy memóriabetöltés okozta, ez reális is lehet, mivel a GeForce memóriavezérlése nem egységesített, így ott ugyanannyi memória hamarabb fogy el, mint Radeonon. A BF3 pedig memóriazabáló játék. Ez a tüskézés egyébként az MSAA levételével megszűnt.
Ebből látszik, hogy az egész sok dologtól függ. Alkalmazás, driver, szoftver, hardverkonfiguráció, sőt sokszor a HT-s procira is visszavezethető.[ 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 adamssss #7066 üzenetére
Milyen jó neked. Az Intelt nem akarod megsarcoltatni?
Amúgy még +/-5% sincs. De ezt nehéz összemérni, mert más oldalak más beállítással tesztelnek. Az Anandot egyébként szoktuk összehasonlításra használni, szóval kifejezetten jól mérnek, ha ugyanaz a beállítás.
[ 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 KAMELOT #9270 üzenetére
Most nem kell aggódni, mert a béta kódhoz képest a végleges még gyorsul. Van egy Catalyst driver is, ami még nem szivárgott ki, de 1,3-1,6x-es gyorsulást hoz a végleges program megjelenésére. Ezt a 13.2 beta3-hoz mérték HD 7970 GHz VGA-val. Persze nem a bétán nézték, szóval ebben a programkódban bevetett optimalizálások is benne vannak.
Ezt a Crysis 3-at most tényleg nagyon jól összerakta a Crytek. Talán hatott a sok kritika a Crysis 2 kapcsán. Én nem vagyok nagy Crytek kedvelő, főleg a Crysis 2 technikailag igen értékelhetetlen megvalósítása miatt, de most el kell ismernem, hogy ez így rendben lesz.[ 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 Attix82 #9278 üzenetére
Arról nem tudok, hogy az NV hogy áll. Valszeg ott is lesz változás. Ezért nem érdemes ezekből a bétákból kiindulni.
Azt tudom, hogy a Crytek kereste fel az AMD-t, hogy vegyék be őket a Gaming Evolved programba, hogy közösen odapakolhassanak a GCN-nek. Gondolom a Crytek rájött, hogy a játékosok értékelik az optimalizálást.(#9281) belinho: Manapság a day0 patch-ek nem számítanak akkora újdonságnak. Nem mindenki szereti azt, hogy kapásból javítással kezdődik az egész, de ha jobb teljesítményt hoz, akkor adják ki. Jobb mintha nem tennék meg.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Szevasz
A demót megnéztem. Az maxon (levelxy AA nélkül, de FXAA-val) 1680x1050-ben (nem tud többet a monitor ) a 270X-en, lényegében ugyanolyan gépen, mint a tied (procim Q9550). Full esőben tömegjelenetben 30-40 fps, körözve stabil 40-45, míg egyedül körözve 50-60 és fölötte. Eső nélkül picit több.
A többit a srácok elmondták.
[ 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 Casanova* #36850 üzenetére
Dettó ugyanazzal az AFR rendszerrel működik mindkét technika. Ha valami nem jó AFR-rel, akkor az előjön CF-en és SLI-n is.
Egyedül a Mantle, ami nem AFR-t használ, tehát ott másképp működik a több GPU meghajtása. Technikai értelemben a több fizikai GPU egy logikaivá változik, így a fejlesztő eldöntheti, hogy mit melyik hardveren futtat.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Casanova* #36858 üzenetére
Nyilván preferencia kérdése, hogy ki hisz a teszteknek, és ki az anonim fórumozóknak.
Egyébként, ha az én véleményem bárkit is érdekel, akkor se CF-et se SLI-t nem szabad venni. Az AFR egy halott technológia lesz. A fejlesztők nem fogják alárendelni a fejlesztéseiket az olyan rendszereknek, amelyek a játékosok kis százalékánál található meg.
[ 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 ADAM1337 #102299 üzenetére
Nem a hardverrel lesz gond, hanem a nyers programlimitekkel. A 3 GB pont 4 GB alatt van, és ha hoznak egy nyers limitet a fejlesztők, akkor sokkal inkább 4 GB-nál húzzák meg a futtathatósági határt a sztenderdnek számító memóriamennyiség miatt. Olyan ez, mint a Doom volt. Ott sem igényelt a játék Vulkan módja 2 GB memóriát a GeForce-on. Beérte 1,5 GB-tal is, de mégis a sztenderd 2 GB-ot választották futtathatósági minimumnak. Az AMD-n is beérte a Doom Vulkan módja minimum 800 MB-tal, de mégis 1 GB volt a minimum limit. Mondjuk ez érthetőbb döntés volt, mint az NV minimumja, mert itt a 800 MB-tal sem esett volna bele több VGA a futtathatóság kategóriájába.
[ 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 killbull #149737 üzenetére
Azzal ugyan nem. A konzolok csak olyan alkalmazást futtatnak, amit a gyártó aláírt. Lefordítható tehát bármi a gépekre az SDK meglétével, de nem futtathatók addig, amíg a konzol gyártója rá nem adja az áldást.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz killbull #149739 üzenetére
Arról is vannak filmek a neten, hogy az UFO-k itt élnek közöttünk. A legtöbb abból ered, hogy az emberek nem tudják, hogy mi hogyan működik. Például itt nem tudja a Youtuber, hogy a PlayStation 5-ön nem lehet akármilyen programot futtatni. Ha nincs meg a Sony aláírása, akkor nem indul el semmi. Emiatt a konzolok sosem lesznek áldozatai a bányászatnak, a konzolok gyártói kivételes módon eldönthetik, hogy mit engednek futtatni, és mit nem.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz kolopele #154744 üzenetére
Ez nem driverhiba, hanem jobb lett a shader fordító. Hatékonyabb shadereket fordít. A sebesség persze nem biztos, hogy mindig több lesz, mert a processzor limitálhatja a teljesítményt, főleg egy DirectX 11-es címnél, de ettől maga a hardvert mostantól jobb kódot kap a fordítótól, amitől gyorsabban dolgozik, de ennek az ára, hogy többet is fogyaszt.
#154782 Balazska90 : Manapság a "népkártyát" úgy hívják, hogy PlayStation 5 és Xbox Series S/X. A PC-s árazás megszokod vagy megszöksz elvű lett.
[ 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 kolopele #154791 üzenetére
Persze, hogy jó. Ha hatékonyabban fordít shadert, akkor kevesebb idle buborék van a feldolgozás során. Az más kérdés, hogy esetleg a procilimit miatt ez nem érződik.
Az, hogy egy Afterburner-szerű "játékprogram" kiír 99%-ot semmit sem jelent. Ha ez jelentené a kihasználást, akkor nem ehhez hasonló programokkal néznék azt a fejlesztők: [link] - 9 perckor mutatja a GPU aktivitást. Elég foghíjas, ahhoz képest, hogy erre simán rámondaná a 99%-ot az Afterburner-szerű "játékprogram". Szóval mindig van hova fokozni.
Fun fact: Mi is RGP-vel profilozzuk a játékokat, hogy lássuk mi mennyire van optimalizálva.
[ 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 nubreed #154824 üzenetére
Nem a semmiért, csak nincs elég erős processzora, hogy látszódjon. Persze részben ez az API-nak is a hibája, viszont lesznek olyan játékok, amik jobb API-t használnak, és ott már érződni fog az a különbség, hogy az új shader fordítóval kevesebb az idle buborék.
Nem mellesleg 80°C-ról beszélünk, ha jól látom, ami bőven a 95°C-os üzemi hőfok alatt van.
[ 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 nubreed #154834 üzenetére
DirectX 11-ben nem hiszem. Itt az API is számít, de nincs minden API-nak külön shader fordítója a meghajtóban. Az nem érné meg. DirectX 12-ben sem valószínű, hogy látszódna Full HD-ben, mert az NVIDIA implementációja eléggé limites, de 4K-ban már azért lehet, hogy vannak helyzetek, ahol kimérhető az új fordító előnye. Az is kérdés, hogy konkrétan ez mit csinál, mert az NV csak annyit mond, hogy fejlesztettek rajta, de azt nem, hogy pontosan hol. Elképzelhető, hogy konkurens végrehajtásban javult, ami egyébként hasznos lenne, mert pont az a baja a GeForce-oknak, hogy tele vannak konkurensen elérhető feldolgozókkal, de marha kevés rájuk a regiszter és a cache. Ha ezeket jobban kezelik, akkor RT-nél, DLSS-nél jöhet ebből javulás.
[ 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 CJ4567 #154845 üzenetére
Önmagában az nem sokat jelent. Attól, hogy 9900k-ja van, még lehet procilimites, hiszen az API-ból és a meghajtóból is származhat. Szóval ez az egész erősen programfüggő.
[ 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 nubreed #155609 üzenetére
Nyilván nem megy ez egyik napról a másikra, de gondolj abba bele, hogy csomagban adják a CPU-t és a GPU-t. Az elég nagy szopás azoknak, akik erre nem képesek, mert az OEM nem fog ám drágán venni CPU-t meg mástól GPU-t, ha az Intel a saját CPU-jánál is olcsóbban adja a CPU+GPU csomagját.
Ezért erőlködik az AMD azon, hogy ne az Intel CPU mellé rakják be a Radeont. Bekerülni nehéz, de kikerülni könnyű, ha az Intel gyakorlatilag alacsonyabb árral fizet ezért, hogy a saját GPU-ját használja a gyártó. Gyorsan össze tud omlani úgy a megrendelői lánc.[ 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 kolopele #160981 üzenetére
A DX12 ma már inkább előnyösebb a DX11-nél. Bizonyos programoknál nem az, de azok alapvetően el vannak baszva, mint például a Dying Light 2. Ennél a játéknál korábban írtam, hogy hülyeséget csinál. Azért nem gyorsul a DX11-ről DX12-re váltásnál, mert a fejlesztők mindent amit lehet direkten a root signature-be mentenek. Ez azért nem ajánlott, mert maga a root signature nem támogat minden formátumot. Ahhoz, hogy ez működjön a Dying Light 2 veszi a konzolos formátumokat, beleírja a memóriába egy leíróhalmazba, majd ott átkonvertálja őket egy olyan formátummá, amit a root signature direkten kezel, és ekkor átmásolják oda a puffert, amivel dolgozik a játék. Majd minden frissítéskor visszamásolják a leíróhalmazba, ahol visszakonvertálják az eredeti formátumba. Ez olyan bődületesen nagy marhaság, hogy elmondani nem lehet, és csak ezen a konverzió-másolós hülyeségen teljesítményt buknak. DX11-nél ugye nem kell ilyen konverzió, de alapvetően a DirectX 12-nél se kellene, ha úgy használnák, ahogy a Microsoft ajánlja.
Ami látszik, hogy ez a játék alapvetően DX11-re készült, és az RT effektek miatt valahogy belehánytak egy alapszintű DX12 támogatást, amit szó szerint kerülőutakkal belehegesztettek "éppenhogycsakműködőre". A sebesség itt nem számított, mert arra nem volt idejük. Viszont ilyen hülyeséget már sok játék nem csinál, és ott már előnyös a DirectX 12.[ 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 C4mp3r #160973 üzenetére
Ha már ezt megemlítjük, akkor azt is meg lehet, hogy az NV-nek ugyanilyen gondja van DirectX 12-ben. [link]
De ugye ezek jellegzetessége, hogy gyengébb CPU-magokkal jönnek elő. Ha valaki Zen 2 és 3, vagy Cypress és Golden Cove magot használó CPU-t vásárolt, azoknál ezek a problémák csak egészen minimálisan jelentkeznek az AMD-DX11 és az NV-DX12 kombinációnál. Nyilván régebbi CPU-knál érdemes ezt is beletervezni, és DX12-re AMD-t, DX11-re pedig NV-t venni, de az újabb CPU-knál annyira nem kell ezen görcsölni.[ 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 kolopele #160984 üzenetére
Elavultnak nem számít, de ettől még nem biztos, hogy jól van megírva az alkalmazás DX12-re. Ahogy fentebb is írtam példaként. Vannak igen jól DX12-ra szabott játékok, ahol ez a helyzet már nem áll meg, és a DX12-es kód a gyorsabb.
Leginkább a motorstruktúra számít. Erről korábban írtunk is: [link] - a legtöbb mai motor ma stage 2 és stage 3 szintű. De például a Dying Light 2 még mindig Stage 1.
A gyorsulás a stage 2 szinttől jön, míg a stage 3 szintnél akkora hátrányt kap a DirectX 11, hogy implementálni is felesleges.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Sundesz #161012 üzenetére
Nem igazán ugyanaz. [link] - A legfőbb különbség, hogy az AMD-féle SAM hatékonysága jóval nagyobb, és kb. minden címben elég jól működik. AZ NV-féle ReBAR hivatalosan nyolc játékban támogatott, és nem is hoz annyi gyorsulást. [link]
Ez egy olyan technológia, aminek a hatékony működését nehéz megoldani úgy, hogy a processzorgyártók nem teljesítik a VGA gyártójának igényeit. És az AMD, illetve az Intel le se szarja, hogy az NV-féle ReBAR-hoz mire van szükség, igazodnak majd a saját megoldásaikhoz.
[ 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 PuMbA #161206 üzenetére
5 évre senki ne vegyen ilyen VGA-kat. Az AMD-nek a legkisebb idei új GPU-ja is csapkodja a 6900 XT hátát. És akkor még három dizájn érkezik fölé a 7000-es generációban.
Ha valaki minimum két évben gondolkodik, akkor vegyen egy szuperolcsó átmenetit, amíg meg nem jön a next-gen. Azon keveset bukik, és tud venni olyan hardvert, ami megfelel az új generációs igényeknek is.
[ 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 PuMbA #169403 üzenetére
Megnézve az Ubisoft előadását, egyik sem marad e kettő közül. Az új hívószó a HPRT, ami a High Performance Raytracing rövidítése. Kvázi motoron belül mélyre integrált nagy teljesítményű sugárkövetés, ahol a nagy teljesítményt a DXR szabványon túli kódrészek biztosítják. És egyébként egészen döbbenetes, hogy pusztán szoftverből mekkora minőségelőnyt és mennyi sebességet lehet így nyerni. Nem tudom, hogy mennyit lehet mondani, de a HPRT kód még natív felbontáson számolt RT-vel is gyorsabb, mint a szabványos DXR kód a felbontás nyolcadával számolt RT-vel. És eközben a HPRT kód VRAM-igénye nem megy 14 GB fölé, míg a DXR kódnál 25 GB.
[ 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 ribizly #169458 üzenetére
Nem a hardver szab ennek határt, hanem a szoftver, pontosabban maga az API. Ha a hardver lenne a probléma, akkor az Ubisoft nem tudná sokszor gyorsabban ugyanazt kiszámolni ugyanazon a hardvere másképpen. És ebből kifolyólag nem is költenének a HPRT projektjükre.
[ 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 ribizly #169461 üzenetére
Nem a hardver erőssége korlátoz. Egy nagyon erős szoftveres limit van az egyes lépcsőknél a programozhatóság hiánya miatt. Ezt feloldva a jelenlegi teljesítmény megsokszorozható a mai hardvereken. És nem kell hozzá semmi trükk, egyszerűen csak nem számolnak feleslegesen sok olyan dolgot, ami ma még kényszerűen kiszámítandó, de haszna az semmi. Ezért fejleszti az Ubisoft a High Performance Raytracinget.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz ribizly #169466 üzenetére
A HPRT-ről annyit tudni, hogy ugyanazt számolja, amit a DXR, ami nem csoda, hiszen a DXR az alapja, ezt csipán kiegészíti. Annyiban más, hogy ami nem látszik a kamerából, vagy a sugarat kibocsátó objektum nézőpontjából, azt előre megmondja, és nem is számol vele. A szabványos DXR előbb kiszámolja, majd utána mondja meg, hogy hoppá, ez mégsem látszik, kár volt erőforrást pazarolni rá.
Ez lehet, hogy egy Quake 2 RTX-ben nem nagy gond, vagy egy Portal RTX-ben, de egy modern játékban az, mert a mai részletességi szinten egyetlen egy karaktermodell annyi háromszögből áll, amennyiből az említett játékokban egy-egy teljes pálya. Sose gondolkodtatok el rajta, hogy miért csak a nagyon régi, háromszögekben nem bővelkedő játékokat portolják át sugárkövetésre?
[ 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 PuMbA #169468 üzenetére
A DXR API aktuális verzióiban nem. Jelenleg a ray generation shaderrel meg tudod határozni, hogy egy objektum bocsásson ki sugarat. Ennyi, ez az API maximális tudása. Amire szükség lenne az a már kibocsátott sugár későbbi konfigurálása bizonyos forgatókönyvek szerint, de ezt a DXR 1.0 és 1.1 sem támogatja. Ha nem kellett a sugár, vagy nem volt jó a meghatározott struktúra szerint kilőni, akkor így járt a hardver, számolt egy csomót tök hasztalanul.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem, ez gyártófüggő. Attól függ, hogy kinek a kiegészítéseire implementálják. Az Ubisoft az AMD-féle Radeon Rays-re dolgozik, de amúgy leportolható az Intel-féle oneAPI-ra is, mert ott is van a célzott problémára megoldás. Az NVIDIA programozhatóságot nem biztosít, tehát náluk másképp kell megoldani, de eredményre vezethet a Displaced Micro-Mesh Engine használata, tehát RTX 40 sorozatra alternatív módon megoldható a probléma. RTX 20/30 sorozatra nehézkes, mert arra se Displaced Micro-Mesh Engine, se BVH traversal programozhatóság nincs. Esetleg ki lehetne találni rá valami compute shader fallbacket, de nem optimális.
[ 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 PuMbA #169501 üzenetére
És mit kezdesz sokezer dinamikus területfénnyel? Az a neonokra jó, de van egy rakás korlátozása. Például nagyon rövid távolságig lehet vele számolni, és árnyékot sem vet. Nem mellesleg semmivel sem jobb a minősége és a sebessége, mint a hagyományos raszterizációs módszerekkel elért területfény effekteké. Az RTXDI úgy lenne jó, ha nem lenne masszívan limitálva a sugár távolsága, de muszáj limitálni, mert különben 20-30 GB-nyi VRAM-ot fog bezabálni. Limitekkel pedig nem meggyőző.
Az Unreal Engine 5 eleve egy extrém limitált motor DXR-rel. Ha ez a mód aktív, akkor a motornak egy rakás fő újítása fallbackre lesz rakva a sugárkövetéses pipeline-on. Például a Nanite is. A kettő együtt nem kompatibilis, és ezen egy darabig nem is tudnak változtatni. Egyébként ugyanez volt az Ubisoft problémája is. Ahogy növeli a geometria részletességét, úgy döglik le a DXR használhatósága. Tehát választani kell, hogy vagy sugárkövetés lesz, vagy részletes geometria. Aztán választottak egy harmadikat, hogy legyen mindkettő, és akkor túllépnek a DXR korlátjain egy alternatív API interoppal.
Egyébként meg lehet csinálni az RTXDI-t és RTXGI-t, de a geometriai részletességnek Portal szintűnek kell lennie. Ha jobb, akkor igazából hasztalan erre erőforrást pazarolni. Még a Cyberpunk belefér, geometriában az is eléggé low-poly-nak számít pár komolyabb címhez viszonyítva, de azért itt már érezhetően eszi a hardvert a DXR rossz hatékonysága.
[ 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 PuMbA #169504 üzenetére
Lehet benne DXR, de bizonyos új technológiákkal nem kompatibilis, tehát döntenie kell a fejlesztőnek, hogy ez vagy az, de mindkettő nem igazán működik.
Ugye maga az UE5 eleve tartalmaz egy Lument, tehát GI-ra nem kell DXR, innen ez a dolog pipa. Árnyékokra elég jó a virtual shadow map, reflectionre meg eddig is elvoltunk SSSR-rel. Szóval olyan nagyon az Epic nem pörög ezen. Nagyobb dolog a Nanite.
[ 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
Techpowerup VGA tesztek /VGA teljesítmény összehasonlítására alkalmas/
Az AMD grafikus feldolgozó egységek listája
Az Nvidia grafikus feldolgozó egységek listája
Az Intel/Intel Arc grafikus feldolgozó egységek listája
5+1 kritikus dolog, amire oda kell figyelned használt videókártya vásárlásánál
Videókártya tesztelések a King's Tech-től, amely nemcsak szórakoztató, de egyben tanulságos is
- BESZÁMÍTÁS! GIGABYTE WindForce 2X GTX 960 4GB GDDR5 videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! SAPPHIRE RX 460 2GB GDDR5 videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! Gigabyte AORUS MASTER RX 6800XT 16GB GDDR6 videokártya garanciával hibátlan működéssel
- GIGABYTE RX 6700 XT 12GB GDDR6 AORUS ELITE Eladó! 102.000.-
- PowerColor RX 6700 XT 12GB GDDR6 RED DEVIL Eladó! 105.000.-