Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz cyberkind #15283 üzenetére
Az összehasonlítást behatárolja, hogy mi létezik. Működő Pascalt még senki sem látott. Működő Polarist már igen. Legutóbb a GDC-n három napig lehetett Hitmanezni egy Polaris 10-en.
A Pascalt nehéz megfejteni, mert az OEM-ek sem kaptak még semmit. De persze áprilisban kapniuk kell valamit, különben a Computexre nem tudnak működő mobil prototípusokat vinni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz TTomax #15295 üzenetére
Az a baj, hogy a memóriát úgy képzelitek el, hogy biztosan vagytok benne, hogy minden csak egyszer kerül bele. Nos igen úgy is lehet csinálni, de például az NVIDIA driverei a Maxwell óta alkalmazzák azt a vezérlési sémát, hogy ugyanazokat az adatokat egy GPU-nak a memóriájába többször rakják bele, mindig másik VRAM szeletbe, hogy ne kelljen a Crossbarnak keresztbe címeznie, mert úgy csak felezett sebességű lehet az elérés. Tehát attól, hogy egy adat kétszer van a memóriában, még nem duplikált a memória. A DX12-ben a két GPU-s memóriaelérés elvben nem különbözik attól, amit az NV csinál DX11-ben egy GPU-ra. Azon lehet vitázni, hogy ilyen formában mennyi az annyi, de felesleges. Egyszerűen mindenkinél van valami egzotikus vezérlési séma, ami miatt az x GB a gyakorlatban csak x-y 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 TTomax #15297 üzenetére
Jó, csak ha ezt te kikötöd, akkor éppenséggel azt várod el, hogy olyan minimum memóriaszelet legyen megadva a specifikációban, amiben garantáltan nem lehet duplikált adat. Ilyen formában egy R9 Fury X 3,5 GB-os, míg egy GTX 980 Ti 1 GB-os. Szóval ez marhára nem egy egyszerű összeadós matek, mert architektúraspecifikus vezérléstől függ a duplikálás mértéke.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Fermi idején ez inkább egy rossz optimalizálás volt, amit orvosoltak. A Maxwellhez azért kell, mert a memóriaelérést keresztbe megfelezték, tehát az egyik SMM csak az egyik memóriavezérlő memóriaszeletéből éri el az adatokat teljes sebességgel. Ha nem ott van az adat, akkor a keresztbe kötött busz már rögtön csak fele olyan széles, így az adatelérés elméleti maximuma is felezett lesz. Ezért az NV ma nagyon ráállt arra, hogy duplikálja az adatokat, mert az kedvező, ha nem felezett sebességű az elérés.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A csatorna 64 bites. A belső vezérlő 128. A Maxwell egy csomó trükkös dolgot bevezetett, hogy tranyót spóroljon meg. Ilyen például az, hogy két csatornát kifelé egy olyan vezérlő kezel, ami nem különálló. Ezért volt célszerű a keresztbe címző buszok szélességének felezése, mert egy vezérlőnek nagyobb memóriaszeletre van rálátása. Maga a koncepció nem rossz egyébként ha a vezérlés jól van hozzáillesztve. Itt arra kell gondolni, hogy érdemes sokszor duplikálni az adatokat, mert kifizetődik. Az NV sosem riadt vissza ettől a módszertől, csak most nagyon ráerősítettek.
A GTA5 például pont emiatt a működés miatt számol az NV-nek több memóriát ugyanarra a beállításra, mert számításba veszik, hogy a driver az adatok nagyjából 25%-át duplikálja, így a default számolást megszorozzák 1.25-tel.[ 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 namaste #15305 üzenetére
Régebben mondta az NVIDIA, hogy így érdemes csinálni. De ugyanezt mondta az AMD is, csak ők azért tértek váltottak át memóriakímélésre, mert már nem crossbart használnak, de ha azt használnák, akkor valószínűleg ők is így csinálnák, mert előny teljes sávszélességgel elérni az adatot, mintsem felezettel. Azt kell figyelembe venni, hogy a memória olcsó lett. Régen nyilván nem volt célszerű duplikálni az adatot, de ma már az, mert annyira olcsó a GDDR5-ös és a DDR3-as memória, hogy megéri 3+ GB-os kártyákat tervezni. Gyakorlatilag belépőszinten sem találsz 2 GB-nál kevesebb VRAM-ot, tehát az NVIDIA számára célszerű hasznosítani a memóriát, ha már így alakult. Valószínűleg, ha az NV is vált a crossbarról, mert HBM mellett már nem ártana, és az explicit API-k sem a crossbarnak kedveznek, akkor átgondolják a menedzsmentet 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 namaste #15307 üzenetére
Gondolhatod, hogy az NV nem fog azzal kiállni, hogy ezt meg azt butítottuk a Keplerhez képest a Maxwellben.
Pont azért nincs anomália, mert a driver menedzseli a memóriát. Egyszerűen a programnak nincs kontrollja. Ha nem így működne, akkor beleütköznél ezekbe az anomáliákba.
Jaj azt ne úgy képzeld el, hogy minden négyszer van benne. Ha a bracnhing úgyis elfedi a feltöltést, akkor felesleges többször belerakni a memóriába az adatot. Ha nem fedi el, akkor mehet.
Szép lenne, ha az NV-re vérmókusokat küldenének, csak mert az ilyen trükkökkel nagyobb tempót ad.HUB!
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz namaste #15312 üzenetére
De most emlékeztetőül arról beszélünk, hogy az NV a DX11-hez tartozó kernel driverben alkalmaz egy speciális memóriavezérlést, amivel sebességet nyernek annak az árán, hogy több VRAM-ot használnak. Ez alapvetően egy jó dolog, mert több lesz tőle az fps. Még ha marginálisan 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 FLATRONW #15380 üzenetére
Nem jelent problémát. Röviden létezik a WCCFtech/BitAndChips és a valóság. Amíg ezek az oldalak képtelenek megérteni, hogy az async compute még csak nem is egy D3D12-es fícsőr, addig azt is felesleges elvárni tőlük, hogy megfelelő helyiértéken kezeljék ezeket a "saját forrásból származó" híreszteléseket.
Nagyon sokan, nagyon sokszor leírták nekik, hogy olyan, hogy async compute nem igazán van. A D3D12-nek ez a funkciója a multi-engine, amit kötelező minden implementációnak támogatni. Olyan nincs, hogy valaki nem támogatja. Azt az implementációt a Microsoft egész egyszerűen nem fogadja el. Konkrétan ahhoz vezet az egész, hogy az alkalmazás nem fog elindulni egy multi-engine-t nem támogató hardveren. És nagyjából ez az, ami számít. Nincs tovább, kész, pont. A programozónak a feladata, hogy a multi-engine implementációkra írjon megfelelő kódot, amit aztán a DXKG, az UMD és az OS minden hardveren megfelelően futtat. Akár az is opció, hogy maga a kód single-engine legyen, vagyis a program egyszerűen direkt kikerüli a DXKG-t és az UMD-t, de ez azért nem ajánlott, mert ilyenkor a parancsok betöltéséért az OS felel, ami jó dolog a grafikai futószalagoknál, de nagyon rossz dolog a copy és a compute futószalagoknál. Emiatt a single-engine kódot a Microsoft csak nagyon indokolt esetben ajánlja, és csak device ID-hez kötve, mert lehet, hogy pár hónap múlva módosítanak az OS betöltőmodulján, amit nem terveztek arra, hogy normálisan kezelje a copy és a compute futószalagokat. Ilyen esetben például egy OS módosítás futtathatatlanná teheti az alkalmazást a single-engine kódot kapó hardvereken. Többek között ezért is használ mindenen multi-engine kódot a Rise of the Tomb Raider, a Hitman és az Ashes of the Singularty az aktuális verzióra vonatkozóan. Egyedül a Gears of War: Ultimate Edition aminek két kódútja van, egy default a egy csomó hardverre, és egy single-engine az Intel Gen9-re, illetve az NVIDIA Maxwell2-re. De ezek a multiadapter beépítése után le lesznek cserélve a default kódra, mert nem jó dolog nyitva hagyni annak a lehetőségét, hogy ezeken a hardvereken egy D3D frissítéssel futtathatatlanná váljon az alkalmazás.
Az async compute és async copy magából a multi-engine kódból dolgozik, és direkten semmi köze a D3D12-höz, de közvetve nyilván a DXKG-n és az UMD-n keresztül működik. Ezért aktív például az összes DX12-es játékban, mert csak az eleve megkövetelt multi-engine kód kell a működéséhez és nem valami nagyon specifikus, komoly szaktudást igénylő, hónapokig tartó programozói munka. És itt jön a lényeg. Maga az async compute és az async copy leginkább arra való, hogy a hardverben kitöltse az idle buborékokat. A gyorsulás mértéke is attól függ minden kódnál, minden hardver esetében, hogy az adott kóddal és adott hardver párosításával mennyi idle buborék maradt, amelyeket potenciálisan le lehet fedni. Szóval a média egy totális tévúton van azzal kapcsolatban, hogy igazából ez az egész hogyan működik. Ez jó táptalaj a szenzációhajhászásnak is.Hosszabb távon egyébként a multi-engine egy nagyon fontos funkció, mert ahhoz, hogy a GPU-k a jövőben skálázódjanak egyre inkább úgy kell őket tervezni, hogy egyre több szálon dolgozzanak, amitől persze nőhet az idle buborékok száma és mérete is, amelyet a multi-engine funkció fog kezelni. A Microsoft pedig azért ennyire erőszakos ezzel a funkcióval kapcsolatban, mert látják, hogy a multi-engine kód bizonyos hardvereken nem hatékony, holott a hardver amúgy képes lenne bizonyos mértékű aszinkron végrehajtásra. Tehát ők ezt nagyon alaposan átrágták és úgy alakították ki a specifikációkat, hogy kiválasztottak a jelenlegi hardverfelhozatalból egy dizájnt, amit jónak tartanak (ez a GCN), és arra írtak egy követelményrendszert, hogy az Intel és az NVIDIA azt lemásolhassa, és a jövőben érkező hardvereik már a GCN-hez hasonlóan működhessenek. Tehát amikor elérjük azt az időt, amikor az általános skálázódás érdekében a hardverek egyre nagyobb problémamegoldásra lesznek tervezve, akkor a multi-engine funkció a ma szigorúnak tartott specifikációk miatt nem engedi, hogy a piac beleessen a potenciális limitációkba.
[ 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 FLATRONW #15392 üzenetére
Ez még ennél is bonyolultabb. Mivel buliban vagyok, tényleg nem akarok ennek nagyon a mélyére ásni, de mielőtt még totál részeg leszek leírom, hogy a Maxwell támogatja az async compute-ot, csak olyan GMU-kat használ, amelyek nem támogatják az erőforrás-korlátozást. Lényegében ezt kell beépíteni mindegyik GMU-ba és megvan oldva az, hogy a hardver semmilyen multi-engine kódtól ne lassuljon. Azt tényleg nincs időm kifejteni, hogy ez miért van így, meg hasonló, de szerettem volna jelezni, hogy ezek a cikkek totál szenzációhajhász bullshitek. Lehet róluk beszélni, de felesleges. A százalékos változás pedig folyamatfüggő, de amit az NV ki akar védeni az a lassulás bekövetkezése.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azért elég szépen átírták a motorstruktúrát, szóval ez már tekinthető D3D12-es dizájnnak. A pálya viszont nem az. Full statikus tele ugyanolyan fákkal és látható, hogy a rajzolás is kevés.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz FollowTheORI #15460 üzenetére
Az a baj, hogy a SteamVR teszt semmit sem ér, mert egy ősrégi SDK-ra épül, amiben semmi olyan dolog nincs, ami lesz például a játékokban. A gond itt az OpenVR, ami hozzávetőleg egy-másfél évvel van lemaradva az Oculus PC runtime mögött. Emiatt nincsenek olyan dolgok benne, mint TW/ATW/LL, és egy rakás egyéb tényező, amely szükséges ahhoz, hogy a VR jó sebességet adjon jó grafika mellett. Ezért nem az OpenVR-re épít egy csomó ma megjelent játék, mert technikailag képtelenek elérni azt a sebességet, ami szükséges. Persze majdnem egy évtizedes grafikai színvonalra így is jó, de pont ezért lesz előnyben az Oculus, mert ők modern grafikára is képesek.
Ha VR teszt kell, akkor a VRScore és a VRMark a mérvadó.[ 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 Dyingsoul #15466 üzenetére
Minden tesztben ugyanolyanok a körülmények. Ebben is, csak annyira régi a felhasznált runtime, hogy irreleváns, mert a piacra kerülő játékok nem ezt az ezer éves csomagot fogják használni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egyszerű a működés. A menüben kiválasztott felbontás négy darab korábbi kiszámolt képkockából születik meg. Ezeknek a felbontása a beállított kimeneti felbontás 67%-a. 1080p esetén például 4x720p, 1440p-vel 4x950p, 4K-val 4x1426p. Ilyen formában lesz leszűrve a textúraszűrés temporális zavara.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az NVIDIA-é nem. Csak az AMD-nek vannak ilyen multiprecision ALU-i. Az világos, hogy a multiprecision ALU-nak sok előnye van, de a tervezőasztalon iszonyatos mértékű munkával jár. És itt ezt úgy kell érteni, hogy nem elég magát az ALU-t jól tervezni, hanem konkrétan nulláról kell felépíteni hozzá az architektúrát. Az AMD is csak azért csinálta meg, mert a GCN-t nulláról építették. A Pascal még mindig egy Fermi származék az alapjait tekintve. Az NV valószínűleg akkor csinálja meg, amikor ők is a nulláról kezdik elölről.
(#15592) gV: Tökmindegy a játék. Az a pletyi, hogy ebben a lapkában se ROP, se setup nincs.
[ 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 daveoff #15621 üzenetére
Mert DX11-ben nem lehet mérni a driver által elrejtett részeket. DX12-ben viszont maga a program a driver, így monitorozhatóvá vállnak ezek a területek is. Ez ugyanaz, mint az Ashes mérése. Ott is több adatod ad a DX12-re csak azért, mert a driver már nem egy hatalmas feketedoboz, hanem egy teljesen nyitott könyv.
[ 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 füles_ #15655 üzenetére
De van DX11-re, már a megjelenés óta. DX12-re meg ugye nem lehet profilt csinálni, mert ott nincs kernel driver.
Az új Hitman alatt a Glacier 2 tartalmaz egy ilyen rendszert: [link] - nem ugyanezt, de hasonlóan működik. Ez segíti a Radeont, mert ehhez a rendszerhez DX11 kiterjesztésekben multi-draw, DX12-ben pedig executeindirect kell. Az ilyen multi-draw rendszerek agresszív használata nem fekszik az Intelnek és az NV-nek. Nem is nagyon ajánlják, hogy túlmenj egy bizonyos limiten. Az Intel sehogy sem ajánlja, mert ők ezt emulálják.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz daveoff #15662 üzenetére
Maga a hitelesítési folyamat a rossz a GeForce-nál. Minden mai hardveren van már variancia, de a GeForce esetében ez akár 10% is lehet. A 980 Ti esetében konkrétan ennyi, vagyis, ha bemész a boltba és leveszel két ugyanolyan 980 Ti-t, akkor azok között a legrosszabb esetben 10%-nyi teljesítménykülönbség van. Ezt kellene az NV-nek kisebb szintre szorítania. A gyári tuning esetében ez a variancia még rosszabb lehet, ott a maximális érték az EVGA-nál van, ahol 17% lehet a különbség két ugyanolyan gyári tuningos modell között. És a tesztekre amúgy a full bint küldik, nekünk is az van.
Szerintem az AMD és az Intel által elfogadott 5% alatti variancia, ami elmegy.[ 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 #85552128 #15667 üzenetére
Attól függ, hogy mivel méred. A PresentMon nem mér a CPU után, tehát a valós teljesítményt azzal nem kapod meg, ezért lesz olyan ugrálós az eredmény, mintha állandó mikroakadás lenne, de valóságban nincs, mert az a program csak egy részeredményt közöl a másik fontos eredmény nélkül. Az Action! sem jó erre, de biztosan közelebb van a valósághoz, mint a PresentMon, persze csak ha jól számolsz.
DX12 méréshez egyébként beépített bench vagy mérő szükséges. Külső programmal ez nem lehetséges, legalábbis nem lesz teljes a kép.
(#15668) Loha: Az ASIC Quality marhaságot nem nézzem, de írtam, hogy 12 bin aktív a kötelező 4-bő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 #45185024 #15761 üzenetére
A Quantum Break igazából nem fut rosszul GeForce-on, csak ahol sok a volumetrikus fényhatás és köd ott van egy kisebb ütés. [link] és [link] - Ennek talán lehet köze ahhoz, hogy ezeket a számításokat async compute mellett végzi a motor gyártóspecifikus kód nélkül, vagyis a GeForce-on is aszinkron fut a számítás. Ettől fekszik meg a Maxwell ezeken a területeken. A többi helyen közelebb van a Radeonhoz a GeForce.
[ 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 Malibutomi #15768 üzenetére
Ez nem a DX12 miatt van, hanem amiatt, hogy az új tervezésű motorok sávszéllimitessek ezekkel a PBR árnyalásokkal. Amikor a Maxwell kijött, akkor a PBR nem volt elterjedt.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz #85552128 #15773 üzenetére
Ennek semmi köze a konzolhoz. Van egy alapvető leképezőjük, amelyhez egy olyan temporális rekonstrukciós eljárást választottak, ami az elvégzett tesztjeiken a legjobb minőséget adta. Ennek megírt motorhoz van köze. Ha nem lenne konzolra ez a játék, akkor is így működne a PC-s port, mert ilyen motort írtak.
Van egy ismert, de egyelőre nem kezelt hibája a GeForce drivernek, ami a Tile Resource contract funkcióval befagyaszthatja az OS-ben a DXKG-t. Ez a Quantum Break és a Hitman alatt is előjön szinte mindig ugyanazokon a helyeken. Hozzávetőleg fél éve keresi az NV a megoldást a hibára. Előbb-utóbb kiadnak valami fixet. Legrosszabb esetben a Microsoft csinál egy OS update-et, ha a GeForce-ok mégse tudják lekezelni a GPUMMU specifikációt. Hasonló "fix" van Intel Gen7.5-re 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 #85552128 #15777 üzenetére
Azért találták ki ezt, mert radikálisan csökkenti a temporális zavarok jelenlétét. A cél egy grafikai probléma kezelése volt. Nem újdonság ez, más is kísérletezik hasonló modelleken, csak még nem jutottak el addig, hogy kész játékban bevessék. Elsődlegesen azért, mert komoly módosítást igényel a motorban.
Nyilván itt arról van szó, hogy volt egy kitűzött cél a képminőségre, amit el akartak érni, és mondjuk, ha minden jelentről születne négy eltolt 1080p-s 4xMSAA-s képkocka, akkor az sokkal jobban fájna, minthogy most születik egy 720p-s 4xMSAA-s, az előző három jelenet eredményeivel együtt.Akkor arról érdemes lenne szólni a fejlesztőknek, hogy nézzék meg, mert nálunk nincs ismert hiba feljegyezve AMD-re. Én is beleraktam már 15 órát fagyás nélkü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 #85552128 #15779 üzenetére
A temporális zavarokat a visszaskálázással nem lehet annyira javítani, amennyire ez cél volt a fejlesztőknél. A radikális előrelépésre az eddigi kutatások szerint négy képkocka számítása jelenti. Azon van a vita, hogy megéri-e ugyanarról a jelenetről készíteni négy eltolt képkockát, vagy jó lesz a korábbi három a negyedik friss mellé. Az aktuális eredmények szerint egyértelműen nincs akkora javulás a natív konstrukcióval, hogy azért megérje megnegyedelni a teljesítményt. Egyébként nyilván megtehetnék azt is, és akkor a mostani eredményeket osszátok el néggyel. Amúgy egy picit az biztos szebb lenne.
Akármilyen képarány támogatható csak be kell építeni a támogatását.
[ 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 #85552128 #15782 üzenetére
A GameWorks csak egy nehezítő tényező. Kapsz egy middleware-t integrálásra, és ha nem fut jól, akkor semmit sem tudsz vele csinálni. A DX12 ezen még annyit nehezít, hogy a GameWorks ilyen API-ba csak speciális emulációs réteg mellett építhető be. Ezért nincs még VXAO az új Tomb Raiderben DX12 alatt, mert még nincs kész rá az emulátor.
Összességében a zártság mindig nehezebb monitorozhatóságot tesz lehetővé. Tulajdonképpen ez a DX12 egyik alapja az, hogy eltűnjön egy nagy zárt réteg a fejlesztők elől, amit kernel drivernek hívtak, így a program teljesítménye teljesen monitorozható legyen. Aztán a toolok állapota egy másik kérdés. Ma nem igazán van stabil DX12 profilozó a PerfStudiót leszámítva. Ez nyilván nem könnyíti meg a fejlesztéseket. A Microsoft ezért hozza amúgy a PIX-et PC-re.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Számos motornak van valamilyen temporális élsimítási metódusa. Frostbite, ez a Snowdrop, és még sorolhatnám, de ez nem ad olyan jó eredményt, mint a Remedy konstrukciója. Persze nem is igényel annyi erőforrást, tehát megvan a pro-kontra érv mellette és ellene. A TAA leginkább a shader aliasingon segít, lásd a Need For Speed TAA-ját egy rakás specular map mellett.
[ 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 huskydog17 #15787 üzenetére
Minél több az ilyen temporális trükk a motorban, annál nehezebb a multi-GPU. Nem arról van szó, hogy nem lehet megcsinálni, hanem arról, amit az Epic mondott még az UE4-nél. Megoldható, de akkora befektetést igényel, hogy azért a 0,01%-os piaci rétegért nem éri meg ezzel a kérdéssel foglalkozni. Az más kérdés, hogy az Epic foglalkozik az IGP+dGPU-val, míg a Remedy nem.
Van benne exit gomb. Fent lejön a sáv, ahol be lehet zárni az alkalmazást egy kattintással. Mint egy Windows ablakot. De mivel sokan nem találták meg, így raknak bele egy jobban láthatót is.
(#15789) cyberkind: [link]
[ 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 schawo #15802 üzenetére
A GFLOPS/TFLOPS csak egy szám. Kb. annyi hatása van a teljesítményre, mint a shaderek számának. A program oldalán ez nem csak számháború.
Itt maga a problémakör tök egyszerű. A DX11-ben írtál egy programot, leadtad a gyártóknak, akik agyontesztelték az early kódokat és szállították a dev csatornákon neked a drivert. Beleraktad te a munkaórát és belerakták a gyártók. A DX12-ben ez megszűnt. Leadhatod a programod, de abba felesleges a gyártóknak munkaórát ölni, mert a kernel driver hiánya miatt csak például complier bugfixelni tudnak. Innentől kezdve az az architektúra kapja a legnagyobb teljesítményt, amelyiken a fejlesztők eltöltötték a legtöbb munkaórát. Ez multiplatform fejlesztésnél a GCN.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz TTomax #15818 üzenetére
Mert visszakérték a tesztkártyákat. Még mindig hiány van bizonyos piacokon ezekből a termékekből, így mindenhonnan visszakérik. Ezért tesztelünk mi is ASUS Fury-vel és nem Fury X-szel vagy Nanoval.
[ 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 Malibutomi #15820 üzenetére
Miért szerinted mit csinálnak a cégek a tesztkártyákkal? Kidobják őket a kukába? Esetleg kiállítják, hogy ezt megfogta Abu?
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz TTomax #15897 üzenetére
Akkor rosszul választottak, mert az AMD-vel kötött üzletük nagyon drága. Az AMD az egész Xbox 360-on nem tudott felmutatni 400 millió dollárnál több bevételt 10 éves életciklusra. Most pedig 1,5 milliárd dollárról beszélnek per konzol per 3-4 év. Ez minden csak nem költségkímélés a konzolgyártók számára. Maga az OEM konstrukció nem felel meg a spórolásnak, mert a kockázatot a beszállító viseli, és azért extra felárat kérnek. Persze az lehet, hogy a Sony és az MS kiszámolta, hogy nekik igazából az jobban megérné, ha a kockázatot a beszállító viselné, és akkor inkább fizetnek nekik többet egy konzol ciklusra, mert összességében így is jobban járnak az elszámolásnál, mintha ők tömnék a rendszerbe az R&D-t. Ennek a hátránya viszont az, hogy nem tudnak majd az AMD-től szabadulni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az a probléma a konzolnál az architektúrával, hogy amíg PC-n nem szállít senki binárist a GPU-ra, addig konzolon simán megteszik a stúdiók. Ergo nem lehet csak úgy kicserélni a hardverben az architektúrát, mert lehet, hogy eltűnt valamelyik utasítás, vagy megváltozott a büntetőciklusa, stb. Szóval GCN4 biztosan nem lesz a PS4K-ban, mert abból hiányzik egy csomó GCN2-es utasítás. Ellenben azt meg lehet csinálni, hogy a GCN2-t a Sony igényei szerint továbbfejlesztik a meglévő ISA képességeit csupán kiegészítve és nem módosítva.
Sokkal nagyobb egyébként a valószínűsége annak, hogy megfogták az IGP-t és belerakták még egyszer, így az APU-ban két IGP lesz. Ez a VR-hez is kedvezőbb, mert két IGP két szem számára számolhat külön képet.[ 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 Petykemano #15940 üzenetére
Nem ágyaz meg semminek, mert még ha két IGP is lesz a lapkában, akkor is ugyanazt a memóriát érik el. Egyszerűen nem lesz más logikai nézetben, mint a konzoljátékoknál ma is sűrűn használt statikus particionálás, csak a fejlesztőnek lesz két fix teljesítményű partíciója, amit természetesen továbboszthat.
VR-nek valóban jó, de a PS4-re készülő VR játékok eleve úgy készülnek, hogy IGP/2 logikailag elosztva, és akkor mehet a két szemnek külön.Bizonyos dolgok sosem lesznek átmenthetők konzolról, jöhet a PC-be akármilyen low-level elérés. A statikus particionálás ilyen. PC-ben a sok hardver miatt dinamikus particionálás kell, de annyira nehéz ezt belőni, hogy inkább nem használnak semmilyent.
Az NV egy helyen nem tudja majd tartani a lépést. Ezek a DirectX kiterjesztések. Hiába hoznak például ők is Ballot kiterjesztést a DX12-höz, ahogy az AMD, az NV kiterjesztése nem kompatibilis a konzolokra írt kóddal.
Nekik azt kell elérni, hogy a SPIR-V-t használják a fejlesztők, mert abban van Ballot és ReadFirstLine-hoz hasonló szabványfunkció. Ez sem kompatibilis a konzol kóddal, de legalább szabványos, tehát lehet azt mondani, hogy írjátok az alkalmazást arra, mert a konzolos kód csak az AMD kiterjesztésein fut. A rossz hír, hogy a Vulkan API-ban sincs swizzle, illetve manual barycentric. Utóbbit kvázi mindenki használja a konzolon különböző analitikai AA-kra, és ezt a HSLS shadert májustól elég csak bemásolni a PC-s portba és Radeonon automatikusan fut. Ilyenekre egyébként tudna írni támogatást az NV, csak nem sok érdeklődő van iránta. Az AMD-nél is csak az teszi ezeket a kiterjesztéseket izgalmassá, hogy copy-paste módon szállíthatók. Ha hozzá kellene nyúlni a kódhoz, akkor az AMD kiterjesztései is hidegen hagynák a fejlesztőket.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ennek semmi köze a technikai tudáshoz, hiszen ballot, readfirstline, swizzle, manual barycentric lehetséges NV-n is. A Fermi/Kepler/Maxwell is képes ra. Persze a barycentric nem könnyű, mert fel kell építeni rá egy új driver modult, de elméletben lehetséges. Ami itt történik az csupán arra megy ki, hogy az AMD olyan kiterjesztéseket csinál, amelyek helyből benyelik a konzolos HLSL shadereket. Például ott a ballot. Az AMD és az NV is csinált hozzá DX11/12 kiterjesztést. De amíg az AMD-hez elég a konzol shadert átmásolni, addig az NV-hez másik shadert kell írni. Világos, hogy ezzel mi a probléma. És ez az egész a shader modell lemaradása miatt van, mert például Vulkan alatt van szabványos ballot es readfirstline.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mindegyiknél.
Elég a copy-paste plusz 10-15 sor. Ilyen a Quantum Break például.
DCC-hez hasonló technika először a TeraScale 2-ben jelent meg, majd a Fermiben. Amik most vannak, azok már harmadik generációs megoldások. Ezek a leghatékonyabbak, mert más kódolást használnak. Ezek a GCN3-tól és a Maxwell2-től vannak. Előtte a DCC-féle konstrukciók igazából nem segítettek a sávszélhiányon, mert nem minden formátumra tömörítettek.
A DCC hatékonyságát egyébként abból lehet a legegyszerűbben lemérni, hogy a 3DMark Vantage Color Fill tesztjében a gyakorlati eredmény mennyire van közel az elméleti maximumhoz. Nyilván minél közelebb van annál jobb.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az első játék, ami kihasználta a BattleForge volt. A DX11 megelejenésenek héten jött. Utána igen gyorsan jöttek a DX11-es játékok.
Azt nem tudom, hogyan nézhette be ennyire a techreport, de a DCC-hez hasonló eljárások a textúrákra nem érnek semmit. A textúratömörítes az egy alternatív dolog. Ahhoz, hogy ezt elemezni lehessen látni kellene a forráskódját és a textúra formátumokat.
A DCC ellenőrzése persze elég bonyolult, de az NV ajánlott módszere a legjobb az átlagfelhasználónak, vagyis 3DMark Vantage Color Fill gyakorlat és elméleti max különbsége.[ 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 FollowTheORI #15998 üzenetére
Az sem mindegy, hogy miképp játszol. A Hitmant lehet úgy játszani, hogy lelövöd a célszemélyt, aztán ezer mentésbetöltéssel valahogy kimászol a slamasztikából. Vagy megoldod úgy, hogy egyszer sem töltöttél újra, ami egészen más élményt ad. Így azért erősen gondolkodni kell. Azt kell mondanom, hogy ilyen formában játszva a lehetőségek igen durvá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 huskydog17 #16012 üzenetére
Csak a Linux port sebessége töredéke a Windows portnak. Főleg max. grafikán. Ez így halott.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz huskydog17 #16026 üzenetére
A textúrák butításával nem lehet sebességet nyerni. Ugyanazt a mintavételezési munkát végzi el a GPU akármilyen textúrával. Itt az előkonfigurált textúrabeállításokat lehet látni. Ezen update-enként változtatnak, mert gondjuk van a streaminggel. A DX11-es megvilágítás azért néz ki másképp, mert a DX11-es kódban van egy bug, ami nem enged lefutni egy post-processt. DX12-ben ez lefut, és világosabb lesz a kép nappal. Ezt majd javítják. Megvilágítás szempontjából az a helyes, amit a DX12-es képeken látsz.
[ 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 Laja333 #16033 üzenetére
Az előre megadott beállításoktól függ. A jelenlegi kódban mindegyik VGA-hoz hozzá van rendelve egy textúrabeállítás aszerint, hogy a streaming az adott hardverre mennyire hatékony. A 8 GB-os 390-eken a leghatékonyabb, így az kapja a High beállításokat. A Fijis és egyéb 4 GB-os Radeonok a Mediumot, míg az összes többi hardver a Low-ot (automatikus a nem definiált hardverekre). Aztán ezt felül lehet bírálni (nemigazán működik valamiért). Ez valószínűleg módosítva lesz pár napon belül.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A megvilágításban az a helyes. Az, hogy rondább egyéni megítélés kérdése. Nyilván képzeld úgy, hogy a textúrák ugyanolyanok minden rendszeren, és akkor csak az a post-process effekt a különbség. Egyébként Surface Glare a motorban használt neve. Ez valamiért nem fut le DX11-ben. Egyfajta hamisan ragyogó hatást ad a nap által megsütött felületnek, ha oldalról nézed.
[ 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 Milka 78 #16044 üzenetére
Ne a homályosságot nézd, mert az a textúra beállítása miatt van. Amit nézni kell az az extra felületi ragyogás, ami egy post-process. A textúra lehet olyan részletes is, mint DX11-ben, csak az aktuális, nem túl jó frissítés miatt most kell hozzá egy 8 GB-os 390.
Attól nem gyorsul a játék, hogy a textúra beállításokat csökkented DX11-ben. Low és High mellett is ugyanaz a mintavételezés történik meg.
[ 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
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- LEGO klub
- Apple iPhone 15 - a bevált módszer
- Kerékpárosok, bringások ide!
- Hieronymus: Békésen legelészik a májusi hardvercsorda
- VR topik (Oculus Rift, stb.)
- Projektor topic
- Politika
- Skoda, VW, Audi, Seat topik
- Intel Core i5-7640X / i7-7740X "Kaby Lake-X" és i9-7xxx "Skylake-X" (LGA2066)
- Horgász topik
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs