- Olcsó sportkamerák (GoPro alternatívák)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Fujifilm X
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Amlogic S905, S912 processzoros készülékek
- Milyen belső merevlemezt vegyek?
- Melyik tápegységet vegyem?
- AMD GPU-k jövője - amit tudni vélünk
- A régi node-okra koncentrál a szankciók miatt Kína
- LG LCD és LED TV-k
Hirdetés
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
Érkezőben a Poco M6 4G
ma 5G-s és 4G-s Pro modell már van, hamarosan lesz Poco M6 4G-s alapváltozat is.
-
VR játék lesz az Alien: Rogue Incursion
gp Az év végén érkező program PC-re, Meta Quest 3-ra és PlayStation VR2-re érkezik a tervek szerint.
Új hozzászólás Aktív témák
-
#259
Abu85
HÁZIGAZDA
huskydog17
#205
Abu85
HÁZIGAZDA
válasz
huskydog17
#205
üzenetére
SMAA vs. 4xSSAA. Ennyi az oka csak a változásnak.
A Vulkan miatt került vissza, de ahhoz, hogy Vulkant mérjünk vele később ott kell lennie a tesztgépen. Ezért van már most benne. Sokkal egyszerűbb egy tesztgépen tanyázó játékban egy kapcsolót módosítani, mint később telepíteni, konfigurálni, menténi, stb.
[ 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
#00137984
#296
üzenetére
Ha lenne béta driver kiadták volna. De a SIGGRAPH-on az NGG path előnyeit mutató grafikonnál prototípusként jellemezték a 17.320-as drivert. Prototípus meghajtót nem adnak ki.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Se HBAO+ nincs a BF1-ben, se VXAO, amit később írtál.
A BF1 egy rendkívül régi HBAO verziót használ, amit a DICE módosítgat egy ideje. A HBAO+-ra nem fognak áttérni, mert DRM-et igényel, ahogy a VXAO is. DRM-et pedig nem építenek a Frostbite-ba csak pár effektért.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Valószínűtlen, hogy az AO okozza az eltérést. Egyrészt a BF1-ben az érintett VGA-kon ez egy 0,5 ms-os effekt, tehát alig terhel. Másrészt egyáltalán nem néz ki úgy, mintha az AO lenne a gond. Inkább a felvevőprogramban van a hiba.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Másba aligha lehet hiba. Már kiderült volna, de egyelőre senki sem panaszkodik eltérő képminőségre. A sebességkülönbségnek pedig van logikus magyarázata is. A BF1 nagyon fekszik a GCN-nek, hiszen tele van olyan specifikus optimalizálással a motor aktuális verziója, amelyek GeForce-on le se futnak. A különbség itt annyi, hogy a GeForce jóval lassabban vágja ki a nem látható háromszögeket, mert nincs olyan fordítója az NV-nek, ami tudja értelmezni az mbcnt függvényt. A Frostbite egy ilyen motor.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az akkor jelent előnyt, ha PC-re ugyanazokat a shadereket rakják be. De ma HLSL 5.1 egy rakás függvényt fel sem ismerne a konzolra írt shaderekből. Ugyanez igaz a SPIR-V-re is.
Vannak már kiterjesztései az AMD-nek, amelyekre át lehet rakni a konzolra írt shadert, de ezeket többen csak kevés shaderre használják. Viszont van ellenpélda is lásd a Doom esetében, ahol ID tulajdonképpen a PS4 PSSL shadereit konvertálja majd fordítja SPIR-V-re, és az így kapott nem szabványos kóddal eteti a Radeonokat. Ugyanez igaz a Battlefield 1-re, amely AMD-hez az Xbox One HLSL shadereit konvertálja és fordítja le, ami szintén nem szabványos PC-n.A Microsoft ezt a különbséget fogja kezelni az év végén a shader modell 6.0-val. Ergo lehetővé teszik, hogy mostantól a PC-re ne kelljen külön shadereket írni, hanem egyszerűen le lehessen fordítani az Xbox One shadereit, és ez legyen a szabványos alap minden hardveren. Ezzel együtt a régi shader modelleket nyugdíjba küldik.
[ 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
Ren Hoek
#809
üzenetére
Semmi köze az absztrakció szintjéhez. Ez szimplán a programnyelv és az IR kérdése. A két konzol esetében a shader nyelv sokkal dinamikusabban fejlődött, míg PC-n tulajdonképpen ez évek óta stagnál. A SPIR-V egy jó kezdeményezés, de egyik konzol sem eszi meg. Viszont a HLSL 6-ot megeszi az Xbox One és a Fall Creators mellett meg fogja enni az összes DX12-es PC-s implementáció is, amelyhez biztosítottak DXIL támogatást (lényegében majdnem mindegyik DX12-es hardver, kivéve a legrégebbieket). Ezzel a lépéssel a Microsoft a PC-re is elérhetővé teszi az új shader nyelvét, amivel az Xbox One optimalizálásai áthozhatók direkten PC-re. A GPUOpen shader kiterjesztései is elvesztik a hasznukat emellett, maximum Vulkan API-ra lesznek jók. De ott is arra készül a Khronos, hogy az OpenCL-t beolvasztja, hogy OpenCL-ről is célozható legyen a SPIR-V grafikai verziója, és az is egy lényeges ugrás lesz az egységesítés felé.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Attól függ, hogy milyen függvényt használnak a shaderben. Az SM6 preview alapján viszonylag rosszul futnak NV-n és Intelen ezek az intrinsic függvények: WavePrefixSum, GlobalOrderedCountIncrement, WaveBallot. A többivel nincs igazából gond. A fenti három intrinsic függvény is csak azért fut rosszul, mert Xbox One-ra vannak tervezve, így az Intel és az NV nem tudja jól mappelni a hardverre. Az AMD csak szerencsés, hogy sok szempontból nagyon hasonló a hardverük az Xbox One-hoz, illetve a WavePrefixSum esetében az a mázlijuk, hogy a GCN3-tól kezdve dedikált utasításuk van rá.
Hosszabb távon ez nem lehet gond, mert mivel a Microsoft elzárkózott az Intel és az NV javaslatai elől, így mindenki tudta, hogy az SM6-ban nagy változás nem lesz, tehát a fenti három függvényre is lehetett tervezni a 2018-as hardvereknél.[ 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
Raysen623
#947
üzenetére
A drivernek korlátozott mértékű jelentősége van a kihasználtságlimit kezelésében. Azt csak olyan hardveres megoldásokkal lehet javítani, mint a Vegában az LDS dinamikus particionálása, vagy a Voltában az L1 és az LDS összevonása. Hogy ez mit ér? Nézz meg egy Dirt 4-et olyan beállítással, ahol nem a sávszél a limit. [link] - Jó a Volta nincs benne, de az L1-LDS összevonásnak, egy megfelelő fordítóval kvázi ugyanez lesz hatása.
Nem véletlen, hogy például a Frostbite Team is erre koncentrálja a kutatásait, mert ők is esnek bele a kihasználtságlimit problémáiba, amit nem nagyon tudnak kezelni a régebbi hardvereken. Amikor ezeket tervezték még nem volt tényező az az igénybevétel, amit ma elvétve már megkapnak, és ez az idő előrehaladtával rosszabb lesz. Szóval lehet, hogy a Vega és a Volta a nyers specifikációkban nem valami nagy dobás, de pont ott ahol számít, mindkettő egy erős lépés a jó irányba.
Egyébként a Vega és a Volta távolról sem old meg minden problémát. A valós megoldások később jönnek. Ez a két rendszer csak időt nyer.
Érdemes szemügyre venni ezt a tanulmányt, mert rengeteg aktuális problémát kezel, és kevés hardveres változást igényelne: [link]
A Vega architektúrát elég lenne azzal kiegészíteni, hogy egy wavefront is módosíthassa a saját bázis- és méretregiszterét, és máris implementálható lenne a rendszer. A többi architektúránál azért sokkal nagyobb változásra lenne szükség, viszont egy prototípus kódot azért jó lenne látni egy létező hardveren, hogy megkezdődhessen a gyakorlati vizsgálata a tanulmánynak, és akkor van esély, hogy ez lehet az alapja a következő DirectX-nek.[ 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 a probléma. Látható most az Unreal Engine 4-en. Eddig Maxwell, majd Pascal hardveren fejlesztették, de most átváltanak Vegára. Viszont egyáltalán nem a konzolok miatt, vagy azért, mert az NV-vel nem akarnak partnerséget, hanem annyi az oka, hogy lényegesen rosszabbak a fejlesztési feltételek GeForce-on. Elképesztően sok teljesítmény marad benne a kódban, mert az NVIDIA NSight egyszerűen nem mutatja ki, hogy bugos a kód, ami egyre kritikusabb probléma, hiszen fél éven belül jön az explicit parallel RHI, amivel a default render is D3D12/Vulkan lesz. Emiatt a jövőben az UE4-et Renderdoc+Radeon GPU profilerrel fejlesztik. Utóbbival az a baj, hogy nem szimpla performance counteres profilozó, mint ami mondjuk van az NSightban, hanem hardveres nyomkövetést használ. Emiatt is tud sokkal több bugot kimutatni, viszont ahhoz, hogy ezeket kimutassa kellenek a hardverben elhelyezett nyomkövetők, vagyis muszáj GCN3/4/5-öt használni.
Én nem akarom a fejlesztőket védeni, de sokszor nem rajtuk múlik. Ők is eszközökkel dolgoznak, és ha az adott eszköz, teszem azt profilozó nem mutatja, hogy a kódban vannak komoly hibák, akkor a fejlesztő elől is rejtve maradnak. Ezen a ponton pedig lényegesen romlik annak az esélye, hogy jól optimalizált programot kapj. És ez a teljes iparágat érinti, mert akármennyire fájdalmas dolog ez, de hardveres nyomkövetést alkalmazó GPU-s profilozó PC-n a nyár közepéig nem volt. Amelyik stúdiónak nincs pénze megfizetni a világ legjobbjait, hogy megfelelő eszköz nélkül ciklusonként átmenjenek a kód kritikus részein szimplán fejben, a dokumentációkat használva, az eleve hátrányból indul.
A jobb portok is nagyrészt a fejlesztőeszközöktől függnek. El tudsz vágni te is egy falécet egy konyhakéssel, de fűrésszel hatékonyabb, és sokkal gyorsabb is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A játékipar nem toporog egy helyben. Most jön a shader model 6.0 az új Windows frissítéssel, ami megint egy komoly fejlesztés. Igaz, az egyik legfontosabb függvénycsoportot utólag kivették, mert az Intel és az NV azt mondta az MS-nek, hogy nem képesek támogatni még az érkező generációval sem. De opcionálisan elérhető lesz. De mindegy, ez igazából két függvény. Ennyi előnye maradt az Xbox One-nak, és ebbe a PC sem pusztul majd bele.
Attól, hogy szerinted felesleges az Epic nem így gondolja. Már +10%-nál járnak sebességben és még messze a január. Valószínűleg +30-40%-kal végeznek.
A konzolra írt kódot nem portolják vissza PC-re, mert az az NV-nek és az Intelnek nem jó. Sokkal kedvezőbb a PC-s kódot külön optimalizálni.Megfelelően támogatva volt a DX12 a hardverek tekintetében. Ha az összes fícsőr érdekel, akkor pedig már ott a Vega, ami támogat mindent az API-ból. SM6.0-ból is mindent támogat a GCN2/3/4/5. Az alapfunkciókat támogatja az NV Maxwell és Pascal is, illetve az Intel Gen9.
A driverben csak shadereket cserélnek. Minden más változatlan. Nem muszáj telepítened az új meghajtókat.A multi-GPU egész kellemes a DX12-ben. Azért nem reklámozzák annyira, mert van pár gyártóspecifikus hiba a WDDM szabványos AFR kódjában. Eredetileg úgy volt, hogy a Creators ezt kiszűri, de az NV még mindig igényel módosításokat, mert akadozgat, de a Fall Creatorsban már jó. Az AMD már reklámozza ezt a módot, nekik már a Creators előtt is hibátlan volt: DX: MD és SE4. Sajnos a Microsoft túlságosan az AMD-re írta az alapimplementációt, amit végül alakítgatni kellett, hogy szuperül működjön NV-vel is. De végeredményben működni fog az év végére, így a CF-et és az SLI-t leváltja a szabványos AFR, és az előbbi linkekből láthatód, hogy egy extra GPU 100%-hoz közeli gyorsulást ér, ráadásul integrált frame pacing van. Ez egyértelműen haladás a mostani DX11-es skálázódáshoz képest.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mit csináljak, ha a GCN támogat valamit, míg a többi nem? Nem én döntök erről.
Egyébként egyetlen GCN sincs legacy státuszban. A shader model 6.0 elérhető lesz a GCN2-re is, de ez az alapján nem nagy meglepetés, hogy a Microsoft bevallottan erre az architektúrára tervezte. Egyébként meg örülhetünk annak, hogy sikerült egy egységes alapban megegyeznie a cégeknek, így lesz úgy 18 wave instrinsics függvény, amit az AMD, az Intel és az NV is támogat. Szerintem ez elsőre nem egy rossz lépés. Aztán ha valakinek kevés, mehet a kiterjesztés. Ebből a szempontból nagyon megengedő lesz a rendszer: [link]
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A shader model 6.0 elsődlegesen azért jön, mert a konzol és a PC shader nyelve között oltárian nagyra nőtt az eltérés. A shader model 6.0 DXIL 1.0 által támogatott verziója, lényegében pár függvényt leszámítva megegyezik azzal a shader nyelvvel, amit az Xbox One használ. Tehát effektíve a Microsoft azt teszi lehetővé, hogy majdnem minden shader, amit konzolra írtak a fejlesztők, áthozhatók legyenek PC-re a teljes optimalizálással. Ilyen szempontból kifejezetten kedvező lesz a portolás. A mai állapotnál biztosan sokkal jobb, hiszen jelentős módosítások kellene a PC porthoz és ez nagyon rányomhatja a teljesítményre a bélyeget.
Nagyon kedvező egyébként a továbbfejlesztés is. Már létezik DXIL 1.1 és 1.2 is, amelyekkel jön a shader modell 6.1 és 6.2. A 6.1 abból a szempontból lesz lényeges, hogy hozza a baricentrikus koordináták elérését, ami az Xbox One utolsó lényeges feature előnye a PC-vel szemben. A 6.1 már a Fall Creatorsban elérhető lesz tesztelésre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mert technikailag nem az AFR-rel van a gond, hanem a driveres kényszerítéssel. A WDDM-be integrált szabványos AFR már nem egy kényszerített megoldás, hanem egy fejlesztő oldaláról direkten kérhető. Szabványosított a pufferkreálás, megválasztható a transzferek vezérlése, stb. Emiatt van az, hogy a WDDM szabványos AFR-jével a GPU-k duplázása konkrétan is dupláz a teljesítményen, miközben ugyanannak a játéknak a CF/SLI módja maximum +60-70%-ra képes. Egyszerűen sokkal jobban működtethető az új formában az AFR.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
s.bala31
#968
üzenetére
Ha ezért vetted, akkor nem sokat nyertél. Egyrészt többféle UE leképező van. Az NV-n csak a deferred fut jobban, míg a mobil leképező az AMD-t szereti inkább. Az új tiled forward megoldásnak is inkább az AMD tetszik, bár ez nem annyira meglepő, mert ezt az AMD tette bele a motorba. Szóval NV-n akkor fog jobban futni az UE4, ha a deferred leképezőt használja.
Inkább a Unity lesz a legtöbbet licencelt. Eddig is az volt, és nem igazán látszik, hogy megváltozna.
A mostani profilozás nem arra szolgál, hogy egy gyártó jól járjon, hanem a teljesítményre vonatkozó bugokat akarják kigyomlálni. Az AMD-nek ez maximum csak abból a szempontból előny, hogy ha már így átmennek rajta, kiterjesztik az async compute használatát is.
[ 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 Nagy csinnadrattával érkezett az első Vega videokártya – végre letesztelhettük, mit tud a gyakorlatban.
- Olcsó sportkamerák (GoPro alternatívák)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Fujifilm X
- Autós topik látogatók beszélgetős, offolós topikja
- gban: Ingyen kellene, de tegnapra
- Windows 11
- Vodafone mobilszolgáltatások
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- PHP programozás
- Cyberpunk 2077
- További aktív témák...
