Új hozzászólás Aktív témák
-
#30753
Abu85
HÁZIGAZDA
huskydog17
#30749
Abu85
HÁZIGAZDA
válasz
huskydog17
#30749
üzenetére
Mi a normális? Ezek a játékok adatra építenek. Minél több autó van a Forzában, minél több pálya, minél nagyobb részletesség, minél jobb textúrák, minél nagyobb felbontású videók, annál több helyigénye lesz. És ilyen nagy projekteknél tartani határidőt rendkívül nehéz. Nem véletlen, hogy a demót a legtöbb AAA cím inkább hanyagolja. Nincs rá idő.
Kezdjük ott, hogy a játékosok 93%-a nem is nyúl hozzá a grafikai beállításokhoz (ez friss adat az NV-től). Nem is nézik meg a sajtó méréseit. Egyszerűen nem érdekli őket. Ez a sajtónak is egy problémája. Rendkívül szűk az a réteg, amely egyáltalán tudja azt, hogy a felbontás átállítható egy játékban. A nagy többség, mondjuk úgy, hogy 10-ből 9 ember nem tudja, hogy mi az az fps. Ez a réteg ráadásul bővül, mert ma már a fiatalokat eleve úgy nevelik, hogy dobd be a lemezt a konzolba és play. Szóval ha a vásárlók többségét nézzük, akkor őket marhára nem érdekli az, amiről én írok, de az sem amiről te.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez az OEM-eken múlik igazán. Nem azért van az Intelnek 70%+ részesedése a GPU-piacon, mert ők a legjobbak, hanem azért, mert az OEM-eken keresztül ők nyomják át a legjobban a hardvereiket. Holott a GPU-ik a három választás közül a legrosszabbak.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
solfilo
#30760
üzenetére
A steam hw survey nem reprezentatív statisztika. Ez benne is van a Valve általános UELA-ban. Ez az egész csak azok között a felhasználók között van mérve, akik elfogadták a feltételeket. Ráadásul nem egy mérés van, hanem konkrétan négy. Tehát egy felhasználó akár négyszer is be lehet számolva az anonimitás miatt. Attól függ, hogy hány surveyt dob fel a Steam, lehet hogy egyet sem.
steam://takesurvey/1
steam://takesurvey/2
steam://takesurvey/3
steam://takesurvey/4
A fenti sorokat egyenként beírva a böngészőkbe máris négyszer felvitted a gépedet, ami az összesítésben meg fog jelenni.
Ezek mellett a Steam hw survey bevallottan egy úgynevezett torzított mintavételű statisztika, amelyen belül a becsült hiba nem kerül meghatározásra, és nem is kerül korrigálásra. Tehát alapvetően csak a mintavétellel foglalkozik, míg a minta sokaságának kérdésével, az információkiértékeléssel, a korrelációval és a regresszióval egyáltalán nem. Emiatt van olyan óriási különbség a steam hw survey és a reprezentatív statisztikák között.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A piac 70+ százaléka Intel IGP-t vesz. Ha tetszik, ha nem. Ez tény. Azzal, hogy ezt megkérdőjelezed, sőt rám akarod vetíteni, hogy én megkérdőjelezem, a vita értelmetlenné válik.
A grafikus vezérlő pedig grafikus vezérlő, függetlenül attól, hogy milyen formában csatlakozik a PC-hez. Az IGP-ket már csak azért sem lehet kihagyni, mert a PC-s GPU-piac 82%-át teszik ki.[ 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
solfilo
#30768
üzenetére
Ez a nem reprezentatív a statisztika, nem tudják követni a piaci realitást.
Probléma az is, hogy ez ellen a Valve nem próbál tenni. Például ma már VGA-k összesítésénél csak az első három tételt teszik láthatóvá. A többit besorolják az "Other"-be. Ezzel próbálják elrejteni a szabad szemmel is látható hiányosságait a felmérésnek. Valószínűleg előbb-utóbb már ez is el fog tűnni, és ugyanúgy ahogy a procinál csak egy multiprocesszorok számára vonatkozó érték lesz feltüntetve. Ezzel a statisztika az értelmét nem vesztené el, továbbá nem ordítana róla, hogy mennyire más a reprezentatív statisztikákhoz képest.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
solfilo
#30770
üzenetére
Ezt írom. Amíg egy statisztikában nem biztosítják minta sokaságát, és nem foglalkoznak olyan dolgokkal, mint az információkiértékelés, a korreláció és a regresszió, addig az a statisztika nem tudja követni a piaci valóságot. Ez nem találgatás, felhívja rá a figyelem a Valve, hogy ez egy nem reprezentatív statisztika, ezáltal a közölt adatok leginkább informális jellegűek, de a piaci valóság akár teljesen más is lehet. Semmilyen formában nem tudják biztosítani azt, hogy a mintavétel az általános statisztikai szabályok betartásával történjen. Még az sem biztosított, hogy a Steam survey mindenkinél megjelenjen, illetve ahogy fentebb írtam négy survey van összevegyítve, vagyis az sem biztos, hogy egy gép csak egyszer lesz benne és nem négyszer.
(#30771) Raymond: Tudom, hogy nem volt ott, ezért említettem meg, hogy most változik az egész. Annyira messze van a valóságtól, hogy valamit kezdenie kell vele a Valve-nak, még akkor is, ha ez egy nem reprezentatív statisztika. Az első lépés erre a korlátozások bevezetése, hogy mostantól az összesítésben csak az első három tételt mutatja meg. Ebből már nem jön le első ránézésre, hogy a reprezentatív statisztikák homlokegyenest mást mondanak, mint a Valve saját statisztikája.
(#30773) Raymond: A növekedés mindegy: [link] - itt korábban írták, hogy mennyi adatból van meg a statisztika. Akkor számítana a növekedés, ha mindenki rá lenne kényszerítve a kitöltésre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30776
Abu85
HÁZIGAZDA
cskamacska
#30775
Abu85
HÁZIGAZDA
válasz
cskamacska
#30775
üzenetére
Ez egyáltalán nem ilyen egyszerű. Maga a mintavétel jellege a probléma, és nem az, hogy valaki kitölti-e vagy sem, vagy ismeri a titkot, hogy miképp lehet négyszer is kitölteni.
(#30774) solfilo: Az a baj, hogy a mindfactory.de is ugyanúgy nem reprezentatív. Ami a Steam hw survey-re elmondható, az elmondható a mindfactory.de-re is. De hasonlóan nem reprezentatív a Passmark submission survey sem. Ha ezeket nézed, akkor folyamatosan csak azt kapod, hogy egymásnak ellentmondanak. Ezért vannak reprezentatív statisztikák, amelyeknél kiemelten ügyeltek a megfelelő mintavételre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30781
Abu85
HÁZIGAZDA
Petykemano
#30780
Abu85
HÁZIGAZDA
válasz
Petykemano
#30780
üzenetére
Mert alapvetően rossz az a mintavételi forma, hogy bárki kitöltheti aki akarja, illetve az sem célravezető, hogy négy survey lesz összevegyítve, ahogy az is rengeteg hibát generál, hogy nem mindenkinél jelenik meg a kitöltés lehetősége.
Itt nincs semmiféle csalásról szó. Egyszerűen a mintavétel formája minden statisztikára vonatkozó szabályt felrúg. Ezt a Valve úgy kezeli, hogy nem reprezentatív statisztikának tekinti.
Ez akkor lenne működő formula, ha a userek gépét a steam minden bejelentkezésnél ellenőrizné és elküldené az anonim statisztikába. Ezzel biztosítható lenne, hogy aki bejelentkezik az részt vesz benne, illetve egy user csak egy gépadatot küld, ráadásul folyamatosan frissülőt. Ugyanakkor ez még anonim formában sem számít sok országban törvényesnek, ha nem fogadja el a felhasználó, mint használati feltételt, tehát ezzel a Valve nem tud kezdeni semmit. Illetve az egész nem ér annyit, hogy ezzel foglalkozzanak, mert nekik pénz ebből nem származik. A stúdiók és kiadók úgyis külön megbíznak cégeket, hogy mérjék fel nekik a piacot.
Arról nem is beszélve, hogy ha a Valve ezt csinálná, akkor abból mekkora műbalhét kreálnának a userek, hogy mi köze van az adataimhoz, stb. Szóval önmagában egy kötelező adatküldést bevezetni egy komoly presztízsveszteség lenne a Valve számára.Ez nem a felülreprezentálásról szól. Az Intel például borzalmasan alul van reprezentálva, holott a GPU-piac 70+ százaléka az övék.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30783
Abu85
HÁZIGAZDA
Petykemano
#30782
Abu85
HÁZIGAZDA
válasz
Petykemano
#30782
üzenetére
A piackutató cégek azt mérik, amit megrendelsz, vagy azt, amire általános igény van, utóbbi utólag eladható. Nem véletlen kerül rengeteg pénzbe a például a JPR jelentése. Sokezer dollárt elkérnek érte.
A Valve is tudna jól mérni, mert az egész csak statisztika, ez pedig egy külön tudományág, csak be kell tartani a szabályait. A probléma az, hogy a Valve ebbe nem akar pénzt rakni. Nekik nem ez a profiljuk, nem jön belőle bevétel, így le se szarják, hogy rossz a mintájuk, illetve az se különösebben érdekli őket, hogy a rendszer amit kidolgoztak folyamatosan mintavételi hibákhoz vezet. Ezeket utólag korrigálni nem tudják, illetve valószínűleg felvenni sem akarnak statisztikával foglalkozó szakembereket, mert ha ebből nincs bevétel, akkor feleslege egy külön csapatot megfizetni.
[ 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
Raymond
#30784
üzenetére
Nem. Sajnos ez nem látszik. A Steam csak az első talált GPU-ig keres. Például nekem is csak a GeForce GT 240-et találja meg, holott monitor sincs rákötve. Emellett még aktív két Radeon a gépben (az egyiken egy monitorral és tévével, a másikon egy tévével). Ezeket nem látja. Nem is tudom neki megmondani, hogy "te hülye nem azt a hardvert használom megjelenítésre, amit megtaláltá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
Raymond
#30786
üzenetére
[link] - elvileg megközelítőleg sincs 125 millió felhasználó.
Én csak azt jelzem, hogy nálam biztosan nem azt méri, hogy mit használok, hanem amilyen hardvert elsőnek talál és azt hiszi, hogy azt használom. Ha úgy gondolod, hogy ez így reprezentatív, akkor OK.
Én elég sokáig tanultam statisztikát ahhoz, hogy tudjam miképp lehet valami reprezentatív, és miképpen nem.[ 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
Raymond
#30788
üzenetére
Nincs alcsoportozás. Összesen ennyi felhasználó vett részt eddig a surveyben. Direkt megkérdeztem tőle, hogy ez hónapról-hónapra, miképpen változik. Szeptemberben ehhez a 975 283 felhasználóhoz kerülnek hozzáadásra a szeptemberi kitöltők. Októberben a szeptemberihez, és így tovább. Emiatt írom, hogy a minta rendkívül kevés, és nem kontrollált.
(#30789) Locutus: A Valve-tól ezt régebben kérdeztem, és azt írták, hogy azt a GPU-t találja meg, amelynek az eszközazonosítója a legkisebb a Windowsban az elérhető GPU-k közül.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30848
Abu85
HÁZIGAZDA
cskamacska
#30844
Abu85
HÁZIGAZDA
válasz
cskamacska
#30844
üzenetére
Nem érdemes a Vulkan API-t általánosítani az ID software játékokra. Az ID ugyanis nem úgy dolgozik, ahogy egy másik cég. Az ID tech6 abban mindenképpen egyedi, hogy amikor szállítják rá a portot, akkor nem egységes a motor. Két csoport van a programfuttatás szempontjából. Egy általános, amelynél szabványos GLSL kódot fordítanak SPIR-V-re, és egy speciális, amelynél PSSL kódot fordítanak SPIR-V-re. Előbbi esetben a SPIR-V kód csak KHR előtagú SPIR-V kiterjesztést használ, míg utóbbinál KHR, EXT és AMD előtagút (itt vannak a kiterjesztések: [link]).
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#30849
Abu85
HÁZIGAZDA
FollowTheORI
#30847
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#30847
üzenetére
Meg igazából a D3D12-ben a kernel driver tűnt el, és nem a user mode driver. Utóbbi ugyanúgy megvan, és például shader cserékkel, fordítóoptimalizálással, bekötésre vonatkozó rutinokkal ugyanúgy lehet még optimalizálni. Az NV-t ma inkább az hátráltatja, hogy volt egy relatíve jól összerakott D3D12 implementációjuk, de ezt a nyáron kicserélték egy másikra. Tehát két év munkát csak úgy kidobtak. Az meg világos, hogy egy három hónapos implementáció lehet, hogy stabil, de az is biztos, hogy messze van még az optimálistól. De mondjuk egy-másfél éves távlatban simán elképzelhető, hogy ez az új implementáció jobb lesz, mint a leváltott verzió. Valszeg számítottak arra is, hogy az első fél-egy évben lesznek problémáik vele.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Ez nem ilyen egyszerű. A szerződés is sokat számít. Az NV a TSMC-nél licites ügyfél, míg az AMD a GloFo-nál take-or-pay modellel van. Ez azt jelenti, hogy az NV úgy szerez kapacitást, hogy licitál a gyártósorra az Apple-lel, és más konkurens megrendelőkkel, és a TSMC annak adja el, aki a legtöbbet fizeti. A GloFo és az AMD előre meghatározott mennyiségre kötött szerződést, vagyis az AMD nem licitál, de van például büntetés. A két modell alapvetően különbözik. A licitálás hátránya, hogy eléggé drága lehet a wafer a versenyhelyzetben, viszont annyit rendelsz, amennyi igazából kell, tehát nagyon jól lehet igazodni az igényekhez. A take-or-pay modellnél a bérgyártó számít arra, hogy az igényelt kapacitást tuti kihasználja a partner, ez garantálja, hogy a gyár normális kihasználással üzemeljen. Cserébe olcsó a wafer, viszont ha mégse teljesülnek a szerződési feltételek, akkor a megrendelő büntetést fizet, így ennek a modellnek ez az igazi hátránya.
A memóriák helyzete sem egyszerű. A memória akkor olcsó, ha legalább két gyártó kínálja. Ugyanis így versenyhelyzet alakul ki, és a memória kezdeti ára folyamatosan lefelé halad. Az a memória hátrányos, amit csak egy gyártó kínál, mert a kezdetekhez képest az ár folyamatosan növekszik. Utóbbi azért van, mert az adott gyártó nem tudja elfogadtatni a megoldását a többi konkurenssel, így alapvető érdeke lesz egy generáció alatt visszatermelni a befektetett pénzt (elvégre nem lesz következő generáció), azt pedig csak folyamatos árnövelés mellett lehet megtenni.
A memória mennyisége is számít. Nem mindegy, hogy elég 1-2-4 lapka az adott kapacitás eléréséhez, vagy szükséges 12-16-24-32 lapka.Az interposer legalább annyira előnyös, mint amennyire hátrányos. A rendkívül sok lábas routing nem egy olcsó dolog a méretesebb VGA-knál. Azért a legerősebb VGA-kon 12-16 memóriacsatorna kivezetésre kerül.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Van a szerződésnek árnyoldala. Az AMD bizonyos események teljesülése után büntetést fizet, cserébe rohadt olcsón kapja a wafert. Az AMD-nek ebben az az üzlet, hogy így mindenkinél olcsóbban tud gyártatni, viszont ha az egyik kritérium bukott, akkor büntetést fizet érte. A GloFo-nak ebben az az üzlet, hogy az AMD termékei szolgálnak alapként a gyárak kihasználtságához, ezért cserébe nagyon olcsón adja a wafert.
Ha nem kötik meg ezeket a feltételeket, akkor nem kapnak olcsón wafert.
(#30879) Loha: Valójában az NV sem gyártat mindent a TSMC-nél. A kisebb GPU-kat a Samsunghoz viszik, mert egyszerűen túl drága a TSMC, hogy ezek egy licitálós modellel nyereségesek legyenek. A Samsung kiszámíthatóbb, és olcsóbb.
[ 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
#30882
üzenetére
API interoperability-vel létezik ilyen. Valszeg ID3D11Device5-ös interfészt használ Windows 10 alatt a program. Ezért is ajánlott hozzá a Creators. Ezzel az interfésszel az API-n belül szinkronizálhatók a létrehozott eszközök. Nem kell hozzá NVAPI-t vagy AGS-t használni. Cserébe Creators frissítés alatt nem is szinkronizál, tehát jelentős hatékonyságot veszít a több eszköz kezelése. Emellett ezzel elérhető az OS által menedzselt shader cache is, cserébe a driver által menedzselt módok ugranak. Ezzel hiába DirectX 11-es a program, jó minőséget csak a Windows 10 Creators biztosít, mert a Device5-ös interfészre írt funkciók Device1-gyel nem futnak, és a Microsoft a Device5-ös interfészt egyetlen korábbi OS-be vagy frissítésbe sem portolta vissza.
A feature_level itt lényegtelen, egyszerűen azért igényli, mert a Device5-ös interfész a legmagasabb szinteken van definiá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
Anubris
#30886
üzenetére
Ez nem érdekes. Ez a normális. Attól, hogy a textúra részletessége nő, még ugyanannyi mintavételezés történik a hardver részéről, mintha low lenne a beállítás. Egyedül memóriából kell több, de ha az megvan, akkor a textúrarészletesség állítása nem okozhat érezhető sebességkülönbséget.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A kettő szorosan összefügg. Azért gyárt olcsón az AMD-nek a GloFo, mert ők biztosítják a gyárak alapvető kihasználtságát. Cserébe megkövetelik, hogy az AMD ne mozogjon, vagy ha mégis elmegy máshova, akkor élesednek a szerződés büntetései.
[ 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
lezso6
#30894
üzenetére
Igazából ma már nincs tipikus ételemben vett High Performance node. Ilyen alacsony csíkon már nem tudsz akkora különbséget betervezni. A manapság élő modell az, hogy lesz egy LP node tervezve, és azt alakítják a továbbiakban. A GloFo 7 nm-es node-jánál azért alakult ki ez a nézet, mert az IBM technológiája, de ez nem fog drámai különbséget okozni.
Az AMD leginkább a Common Platform miatt marad, mert a Samsung és a GloFo még mindig együttműködik bizonyos technológiákkal kapcsolatban. Ráadásul elég szorosan. A GloFo új eljárásai például támogatni fogják a Samsung második generációs I-Cube tokozását, ami már lehetőséged ad a szilícium nélküli interposer alkalmazására.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem előnytelen a TSMC-nél gyártani. Attól függ az egész, hogy milyen lapkák készülnek ott. Ha drágán kerül eladásra a termék, akkor akár licitháborúzni is lehet az Apple-lel. Az NV a Samsunghoz a kisebb lapkákat viszi, ahol nincs igazán lehetőség nagy árcédulát szabni, a GP107-nél már előnytelen lenne a TSMC, mert nem kiszámítható. A Samsung a GTX 1050-es sorozat árszintjére, illetve ez alá, sokkal jobb ajánlatot tud adni. És arányaiban a GTX 1050-es sorozat fontos, mert messze többet adnak el belőle, mint a gyorsabb modellekből, tehát számít, hogy ezek milyen áron készülnek.
A mennyiségkülönbség határozza meg az eredményeket. Ha az AMD adna el annyit, amennyit az NV, akkor az NV-nek lenne problémája a profittal.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#30902
üzenetére
Igazából ez nem probléma elvi szinten. Rá kell licitálni az Apple és más konkurensek ajánlataira. A TSMC-t csak az érdekli, hogy ki fizeti a legtöbbet a gyártósorért. Az, hogy annak a cégnek Apple vagy NVIDIA a neve, vagy akárki, gyakorlatilag teljesen mindegy. Szóval kapacitást szerezni igen egyszerű a TSMC-nél, csak borzalmasan drága.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A TSMC-nél sorban állnak a gyártósorért. Ott már nincs alkupozíció. Ha a legtöbb pénzt kínálja egy cég, akkor az övé a gyártósor. Ennyire egyszerű.
A HBM-es megoldások esetében nem pont a node határozza meg a választást. Sokkal inkább az számít, hogy kinek a tokozása a kedvezőbb az előállítási lánchoz. Az AMD hosszú távon a Samsunggal képzeli el ezt az irányt, tehát nekik a Common Platform bérgyártói a kedvezőbbek. Az NV a Hynix partnere, így számukra a TSMC az ideális.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Frissített az MS, írták is, hogy kb. 5-10% közötti a boost aktivált game móddal, de nehéz általánosítani a gép- és programfüggőség miatt. A kisebb teljesítményű gépeken nagyobb lehet a javulás. Nagyjából ugyanezt mondták a gyártók is. A Vega azért lehet látványosabb, mert az egyetlen Fall Creators drivere a 17.40-es, amiben ugye a Redux bétája, aktivált NGG-vel, míg a korábbi meghajtókban ez eleve nincs benne. A 17.40 pedig nem jó a régi Windowsra, eléggé instabil alatta. Azt is tudni már, hogy az NGG a jelenlegi állapotában ott segít, ha egy játék érzékeny a memória-sávszélességre. Ha nagyon, akkor az NGG sokat hoz a konyhára, mert rengeteg terhet levesz a GPU válláról azzal, hogy még azelőtt kidob egy rakás nem látható, de amúgy fals pozitívnak ítélt háromszöget, mielőtt egyáltalán beterhelnék a felesleges számításokkal a memóriabuszt. Egyelőre ennyit tudni.
[ 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
-FreaK-
#30975
üzenetére
Hivatalosan azt lehet mondani, hogy egy "up to 10%-ot" vállalt be az MS az optimalizált game módra, de kerülik az általánosítást, leginkább az az üzenet, hogy teszteld magad. Viszont az "up to" dologban ugye benne van a 0 is. A 10% fölötti javulás az nem az MS miatt lehet, akkor up to 20%-ot írtak volna.
[ 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
Remus389
#31002
üzenetére
Azért nagyon fontos, hogy az up to nem azt jelenti, hogy minden gyorsul, hanem azt, hogy akár 10% is lehet bizonyos konfigurációkon a frissített game móddal. De az up to miatt bármi lehet még 0 és 9% között. Főleg a gyengébb teljesítményű gépek gyorsulnak. Minél gyengébb a proci, annál több a boost. A tesztoldalaknál ezt nem fogod meglátni, mert mindig a leggyorsabb procikat használják. Náluk nem lesz több 1-2%-ná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
Fred23
#31012
üzenetére
Eredetileg ugye a DX12 új bekötésére készült, tehát a DX11 is úgy van a motorban, hogy emulálja a régi binding API-val való kompatibilitást. Szóval ez a DX11 igazából senkinek sem jó.
(#31017) Fred23: Igazából az AMD-nek és az NV-nek nem sok köze van az AC Origins-hez, mármint fejlesztési szerződés szintjén. Az Intel volt a legfőbb fejlesztési partnere erre a címre az Ubisoftnak. Ettől függetlenül a játék használ technikákat mindhárom gyártótól, de a többieknek reklámszerződésre volt lehetőségük.
Annyit tudni, hogy volt az Ubinál egy nagyon ambiciózus projekt, hogy átrakják bindlessre az AnvilNextet. De olyanra, hogy már maga a motor lekezelje a root signature különbségeit, és elfedje a hardverek eltéréseit. Nem tudni, hogy ez mennyire jött be, ettől függhet a DX12 elérhetősége is. De az beszédes, hogy a Far Cry 5 esetében a Dunia új verziójára egy teljesen más megoldást választottak. Persze az AnvilNext csapatának az Intel és az NV adott tanácsokat, míg az AMD inkább exkluzív szerződést kötött a Dunia csapatával.
[ 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
cyberkind
#31018
üzenetére
Nem az effektek jelentik a problémát, egy rakás eljárást szállított bele az Intel, az AMD és az NV egyszerre. Ezek effetek, vagyis lelőhetők. Kockázatos viszont egy olyan váltás, ahol az AnvilNextet átállt bindlessre, de egy olyan megoldásra, amit soha senki nem próbált ki előttük, majd végül esetleg nem is használja. Így viszont, hogy már bindless a motor, nem kompatibilis a DX11 CPU oldali binding API-jával, amihez kell írni egy extra kompatibilitási réteget. Ezek a beavatkozások csak lassítják a teljesítményt.
Igazából az AnvilNext rétegezett bindless modellje mindig kérdéses volt. Ha annyira bízna benne az Ubisoft, akkor a Dunia is így készült volna, vagy mondok közelebbit ... már az AC Origins konzolverziói sem használnának teljesen eltérő struktúrát.
Az meg, hogy egyelőre egyedül az Intel élt az opciós jogával az AC Originsre, nem túl biztató. Könnyen lehet, hogy az AMD és az NV nem tartja elég jó minőségűnek a portot. Nekik ott a Wolf 2 és a Destiny 2. Azokra simán fel lehet építeni az ünnepi szezont, és igazából sokkal több erőforrást öltek ezekbe a címekbe.A szerződéstől függ majd a gyártók reakciója. Valószínűleg az AMD hagyja a fenébe, mert nekik eleve exkluzív joguk van a Far Cry 5-re. Az NV esetleg vásárolhat némi kulcsot, hogy egy-két hétig elég legyen, így letudják ezt is lényegében csendben, megúszva egy újabb AC Unity botrányt. Abból ítélve, hogy mennyire sok Destiny 2 kulcsot vettek egyértelmű, hogy nem az AC Origins-szel akarják felépíteni az ünnepet. Én is inkább a Destiny 2-re építenék, bármennyire is elavult a grafika, az optimalizálása elég jó, és elég nagy cím is. Az AMD meg viszi erre az időszakra a Wolf 2-t. Kb. ugyanaz a szituáció.
[ 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
Fred23
#31023
üzenetére
A DX11-gyel nincs gond. Azzal van baj, ha csinálsz egy bindless motort, és azt rétegezed be a DX11 binding API-jába. Ez így nem natív, hanem emulált támogatás lesz, ami nem egy sebességbajnok megoldás. Nem véletlen, hogy az Xbox One X 4K-val is 30 fps fölött van, míg ugyanúgy high grafikán PC-n erre csak a legerősebb VGA-k képesek, pedig ezek aztán számítási teljesítményben jó háromszor az Xbox One X fölött vannak.
[ 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
Fred23
#31028
üzenetére
A Vulkan nem jelenti a Linux Gaming feltámadását. Az csak egy API, ami megold egy apró problémát a tucatnyi közül. Ettől a Linux még ugyanúgy széttagolt lesz. Dave Airlie, a Red Hat szoftvermérnöke elég jól összefoglalta, hogy mire lenne szüksége a Linuxnak, hogy játékra alkalmas legyen. [link]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31054
Abu85
HÁZIGAZDA
Firestormhun
#31051
Abu85
HÁZIGAZDA
válasz
Firestormhun
#31051
üzenetére
Nincsenek, mert a deferred rendering pont a mozaikos optimalizálást használó hardverekhez készült. Vega, Pascal, Maxwell. Direkt azért rakták bele, mert a forwardhoz képest lényeges előnyt tud felmutatni. Kár volt kikapcsolni. A régi hardverek úgyis halottak, lásd GTX 770. Vagy akkor a Pascal, Maxwell, Vega trióra kapcsolják be, a többire pedig ki. De úgy sem lesz olyan játékos, aki nem fogja bekapcsolni egy modernebb architektúrán, hiszen sebességet ad minőségvesztés nélkül.
Az meg kicseszés az NV-vel, hogy a GPU-culling náluk nincs bekapcsolva, hiszen így a CPU végzi el ezt a feladatot. Azért az nem kevés extra meló, amit egy négymagos 4 GHz-es Core lehet, hogy megold, de egy gyengébb procit azért meggyötörne. Most vagy vágja ki a nem látható háromszögeket a GPU, vagy mindkettőn csinálja ezt a CPU. Szóval finoman szólva is furcsa a teszt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31056
Abu85
HÁZIGAZDA
huskydog17
#31055
Abu85
HÁZIGAZDA
válasz
huskydog17
#31055
üzenetére
Én a review guide alapján írom ezt. A deferred renderinget azért rakták bele, mert az utóbbi időben jöttek olyan "binning" architektúrák, amelyeknek ez jobban fekszik. Ilyen a Maxwell, a Pascal és a Vega. Ezek ezen a beállításon nyernek. Elképzelhető, hogy a többi architektúra veszít rajta, de most őszintén ez kit érdekel? Úgyis a legmodernebbeket nézi mindenki. Csak azért hülyeség kikapcsolni valamit, mert a Kepler/GCN1/2/3/4 ettől egy picikét lassabb lehet, a modern hardverek viszont komolyabbat ugranak tőle.
Csak a Kepler és Maxwell esetében érdemes ezzel élni, mert a GPU-culling aszinkron compute-tal valósul meg, és ezt a Pascal már támogatja Vulkan alatt. Azt pedig sajnos nem jegyzik meg, hogy ha ezt kikapcsolod, akkor erősen ajánlottá válik a hat-nyolcmagos proci is, mert a CPU futtatja le AVX-en azt a sok vektormatematikai számítást, amit a GPU csinál aktivált móddal. Mivel a legtöbb embernek négymagosa sincs, így még az is lehet, hogy Kepler/Maxwell esetében is gyorsabb marad a bekapcsolt állapot. A végleges verzióra én ezt jobban kifejteném a menüben, mert túl általános, hogy az NV-n ki, az AMD-n be. Valójában nagyon konfigurációfüggő, hogy mi az előnyösebb. Az persze világos, hogy a PCGH nem futott teljesítményproblémába 16-szálas core i7-6900K-val, amit még fel is rántottak 4 GHz-re, csak kételkedek benne, hogy a felhasználóknak is ilyen gépük van otthon.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31059
Abu85
HÁZIGAZDA
huskydog17
#31058
Abu85
HÁZIGAZDA
válasz
huskydog17
#31058
üzenetére
Akkor nem végleges kódjuk van, mert ~5%-ot gyorsít a deferred a binning architektúrákon. A többin ~1-2%-ot lassít. Azért van kikapcsolva, mert a régebbi hardvereken lassít egy picit, amelyek amúgy sem elég gyorsak, míg azokon gyorsít, amelyek újak, és alapból elég gyorsan számolnak. Viszont az új architektúrákhoz ajánlott bekapcsolni.
A GPU-culling hatása leginkább az átlagos CPU-kon látszik meg. Ha van már hat magod, akkor gyakorlatilag mindegy, hogy ki vagy be van kapcsolva. De ha nincs minimum hat magod, akkor nyilván többet ér a GPU-val számoltatni, hiszen elég sok vektormatematikai műveletről van szó, amit nem feltétlenül jó ráereszteni a procira, hiszen annak van más dolga is, míg a GPU-n sokszor pihennek a multiprocesszorok, és oda be lehet szúrni a számítást. Tehát arról beszélünk, hogy messze nem arról van szó, hogy az NV-n kikapcs, az AMD-n pedig be.
Csak nálunk nincs olyan, hogy az egyik hardveren aktiválunk valamit, míg a másikon nem. Vagy be van kapcsolva, vagy nincs. Ez a lényege az azonos tesztkörülménynek.[ 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
Raymond
#31060
üzenetére
Miért? Nekem is van már hozzáférésem az aktuális journalist preview verzióhoz, de hozzá van írva, hogy a végleges csak 27-én lesz elérhető. Ahhoz később jön meg a PH-s kód, mert az Influence programon belül kapott hozzáférés nem szűnik meg novembertől, az olyan, mintha megvettük volna (ehhez van review guide a mérések megkönnyítésére), míg a journalist preview verzió csak októberben használható, utána lejár a licenc.
Ebben egyébként van Denuvo is, remélhetőleg a véglegesben nem lesz.Legalábbis abból kiindulva, hogy a The Evil Within 2-nél a journalist preview Denuvós volt, míg a végleges nem. Tök jó, hogy ezeket a dolgokat jobban tudod azoknál, akiknek konkrétan van hozzáférésük a programhoz.
Szerk.: Bocs. Megnéztem még egyszer és Denuvo nincs a journalist previewben sem. Erre tévesen emlékeztem. Úgy néz ki, hogy a The Evil Within 2 volt az utolsó mohikán.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31064
Abu85
HÁZIGAZDA
huskydog17
#31063
Abu85
HÁZIGAZDA
válasz
huskydog17
#31063
üzenetére
Tehát építettek egy időgépet, és visszautaztak a holnapi patch-csel. Nice.
Gondolom ezért cserélik a preview kódokat holnap az Influence programban. A preview nem frissíthető, míg az Influence-en belül küldött kód az retail minősítésű, ami így frissíthető is a patch-ekkel. Persze újra le kell tölteni a játékot, de belefér a mai netes sebességek mellett. Azt amúgy kötve hiszem, hogy ők mindenki más előtt kaptak hozzáférést az Influence kódokhoz. Ez példátlan lenne, mivel ezek egységesen kerülnek kiküldésre, méghozzá holnap. Ez mindig így volt, a Prey-nél, a The Evil Within 2-nél és erősen kétlem, hogy most megváltozott. Szóval bocsánat, ha jobban hiszek az programot szolgáltatónak, mint a ComputerBase-nek, elvégre én is a részese vagyok ennek a programnak, tudnák róla, ha módosultak volna a feltételek, vagy ha itt lenne a végleges kód a mailboxomban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31119
Abu85
HÁZIGAZDA
->Raizen<-
#31101
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#31101
üzenetére
Arról van szó, hogy mindegy, hogy mi az átlagos sebesség a játékra eléggé jellemző, hogy bezuhan az fps, majd visszamegy. Ez eléggé jellemző dolog a Steam fórum alapján, bár hardverenként eltérő a mértéke. A másik jellemző tényező, hogy a városokba érve az fps összeomlik. Ott ez a sebességfluktuáció extrémmé válik még 1080 Ti-vel is [link], illetve a cutscene-ek konkrétan akadoznak mindenkinél [link].
Az egésznek az az oka az, hogy az új AnvilNext már nem az a régi iRender stílusú motor, hanem átrakták bindlessre.
De mivel a D3D12 támogatást még csak az Xbox One kapta meg, így PC-n a bindless miatt még van egy extra binding wrapper is a leképező és a D3D11 API között. Mert a D3D11 az alapértelmezetten írt bindless leképezőt nem tudja kezelni, ha egy wrapper nem fordítja át neki bekötést. Ez a wrapper egyébként az Intel és az Ubi közös fejlesztése.
[ 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
Crytek
#31118
üzenetére
Az Intel csomagolja az egyes CPU-i mellé. Az AMD és az NV nem valószínű, hogy addig ezzel foglalkozni fog, amíg a binding wrappert használ a játék. Ezzel csak egy rakás CPU-erőforrást elköltenek a semmiért, aminek a GPU issza meg a levét. Ezt így nem lehet kitenni az ablakba. Főleg úgy, hogy az AMD és az NV is régóta olyan előadásokat tart, ahol erről az irányról lebeszélik a fejlesztőket, mert oké, hogy egyszerűen beépíthetővé teszi a bindlesst, de borzalmasan lassúvá válik általa egy potenciális D3D11/OpenGL mód, amire mondjuk esetleg még szükség lehet, ha a D3D12 mód mégsem működne jól a startra.
[ 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
Raymond
#31122
üzenetére
Nem kellene annyit dolgoznia rajta. Számos módja van annak, hogy a D3D11-et támogassák újszerű motorstruktúrával. Például kaphat a motor kétféle low-level back-endet. Egyet bindlessel, és egyet a D3D11 binding API-jára írva, amelyeken keresztül támogatható akármelyik API.
Ezzel lenne egy ilyen rendszer:
'
Játék
||
High-level leképező
|| ||
Low-level leképező Low-level leképező
|| ||
OpenGL/D3D11 Vulkan/D3D12Ennek az előnye, hogy mindegyik API-ra wrapper nélküli, gyakorlatilag natív a path, viszont hátránya, hogy eléggé melós, mert kétféle low-level leképezőt írnak a kétféle bindinghez, és a közös high-level leképező miatt a gyártóknak egy külön drivert is kell írni a játékra a jó D3D11/OpenGL sebességhez. Így működik egyébként a Nitrous, és csak azért fut jól D3D11-ben, mert az AMD és az NV írt rá egy külön, alternatív D3D11 implementációt.
A másik megoldás ez:
'
Játék
||
Mid-level leképező
|| ||
Binding wrapper Low-level leképező
|| ||
OpenGL/D3D11 Vulkan/D3D12Ennek az előnye, hogy sokkal kevesebb meló a programfejlesztő oldalán, főleg úgy, hogy elég sok kód van meg régebbről, mivel nem nulláról készült a motor, illetve nem kell két különálló low-level leképező. A modernizált mid-level rész támogat mindent, amivel működhet a D3D11/OpenGL, és csak egy wrapper kell alá a bindinghez, míg a bindless kód működhet a Vulkan/D3D12-vel egy low-level leképezőt berakva, ami tartalmazza a memóriamenedzsmentet és kezeli a hazardokat, ugye a bekötés eleve mid-level szinten van itt kezelve. Emellett járulékos előny, hogy nem kell külön legacy implementációt írni a gyártóknak hozzá. Ilyen az AC Origins motorja. Az egész hátránya persze, hogy rohadt lassú a legacy path, és egy rakás felesleges munkát ró a CPU nyaká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
Raymond
#31125
üzenetére
Nem lenne szükség rá. A probléma ugyanis nem az objektumok/fényforrások száma vagy a LOD. Ezeknél az ugyanúgy bindless rendszerrel dolgozó Nitrous motorral Ashes of the Singularity mérföldekkel többet jelenít meg. Az AC Origins terhelésének akár a 20-sorosát, és még jobb is a sebesség, ráadásul egy stratégiánál agresszív LOD-ra nincs is igazán lehetőség, tehát még a szituáció is sem a Nitrousnak kedvez. A probléma tehát nem a hardverekkel vagy a beállításokkal van. Ha ez lenne a gond, akkor az Ashes of the Singularity maximum 3-5 fps-sel futna a csúcsgépeken, de nem ezt látjuk.
[ 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
Raymond
#31127
üzenetére
Annyiban nem mindegy, hogy a Nitrous alapján egyáltalán nem a mai hardverekkel és a beállításokkal van a gond, hanem azzal, ahogy az új AnvilNext alatt nagyon rossz hatásfokkal működik a D3D11 path. Fentebb le is írtam, hogy miért.
Amúgy nem baj, hogy ilyen lett, mert legalább az AMD és az NV tud példát is hozni a jövő évi GDC-re, hogy miért ajánlják a bindless átálláshoz a motorstruktúra jelentős átírását, és a high-level->low-level rendering modellt, a jóval egyszerűbb mid-level forma helyett.[ 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
Raymond
#31129
üzenetére
Azért ne tekintsünk már úgy a motorstruktúra szempontjából a leképezőkre, mintha teljesen más lenne az elfogadott modell két játéknál. Abszolút nem más, függetlenül attól, hogy a játék stratégia vagy kaland. Emiatt van egységes ajánlás arra, hogy milyen a következő ideális motorstruktúra. Senki más nem mond mást a gyártók közül, ugyanis az az ideális, ha a régi leképező->iRenderSytem-szerű rendszereket úgy alakítják át, hogy két jól elkülönülő részre bontják az egészet. Ajánlott egy magas szintre helyezett leképezőrész, mi tulajdonképpen tartalmazza mindazt, amiben a célozható API-k megegyeznek. És ez alá kell behúzni legalább két alacsony szintre helyezett leképezőt, ami tartalmazza azokat, amikben a célozható API-k eltérnek (például bekötés, hazardok kezelése, memóriamenedzsment, erőforrás-korlátozások, stb.). A cél ezzel az, hogy az explicit és a legacy API-kra is tudjál egy motorban natív pathot kínálni, így nem kell wrappert bevetni, mert esetleg egy olyan dolgot a közös, magasabb szintű leképezőrészbe raktál, amit az egyik célzott API pont nem támogat. Működik wrapperrel is persze, csak rohadtul rossz lesz a hatásfoka. Ez még addig oké, amíg egy program lehetőséget ad a natív path használatára, mert akkor kit érdekel, hogy ott a wrapper. De amikor úgy jön ki valami, hogy nincs natív path-ra sem lehetőség, akkor nyilván felkiáltanak ott a gyártóknál, hogy "erről pofáztunk 2-3 GDC-n át, hogy ezt ne".
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Igen, csak a PC nem konzol. Ott elhiszem, hogy ez működik, de az AC Originsre az a legfőbb panasz, hogy rendkívül kicsi a teljesítménykülönbség a full low és a full high grafika között. Nyilván ennek az oka a rossz hatásfokban keresendő. PC-n emiatt egy rakás grafikai beállításnak nincs is értelme. Hiába veszed le, semmit sem gyorsulsz.
(#31134) Raymond: Konkrétan az nyomja agyon, hogy a CPU egy rakás olyan munkára van kényszerítve, amelyek szükségtelenek lennének, ha nem kellene a bekötéseket ennyire körülményesen kezelni. Kb. olyan, mintha elindítanál egy OCCT-t szálra és úgy játszanál mellette egy játékon. Haszna nincs, mert csak azért működik így, mert a fejlesztés egy szakaszában hoztak egy hibás döntést, és már túl drága lenne kijavítani.
[ 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
Fred23
#31133
üzenetére
Már ami megmaradt belőle. Azért az Ubisoft Montrealt jól lerabolták az elmúlt években. A két nagy 3D ninja Bart Wronski és Michal Drobot már nem dolgozik nekik. Steve McAuley maradt ott mint utolsó nagy mohikán, de őt meg rárakták teljesen az új Dunia motorra. Persze Steve McAuley még önmagában is marha nagy név, de azért látszik, hogy az igazán neves szakemberek száma csökkent. Ez már csak azon is észrevehető, hogy a Massive Entertainment lehagyta őket a Snowdroppal. Egyre nehezebbé válik egy stúdión belül két motort fenntartani, megcsappant szakembergárdával.
[ 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
Raggie
#31167
üzenetére
A HBM tuningjával addig lehet nyerni, amíg a meghajtóba nem kerül be a pseudo-channel mód. Illetve az NGG mód is kifejezetten a memória-sávszélességről veszi le a terhet, bár ennek a hatása közvetett.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31236
Abu85
HÁZIGAZDA
cskamacska
#31222
Abu85
HÁZIGAZDA
válasz
cskamacska
#31222
üzenetére
Ez nem igazán a fejlesztőkön múlik. A gond az, hogy amikor a Khronos átemelte a Mantle kódját a Vulkan API-ba, akkor igazából egy dolog komoly módosítása mellett döntöttek, méghozzá a bekötési modellén. Ugyanakkor a memória kezelését szimplán átemelték a Mantle-ből, ami utólag elég nagy hiba volt, mert a GCN-re volt írva az egész. Az a lényeg, hogy csak a GCN képes úgy kezelni dedikált VRAM-os memóriahalmazt a Vulkan API-ban, hogy ne rendeljen hozzá flaget, és ez számottevő hátrány a többi hardvernek, mert így az NV és az Intel olyan implementációra kényszerül, amelyben a flag nélküli memóriahalmaz a rendszermemória, vagy annak egy része. Ez az Intelnél opcionálisan kihagyható, lévén IGP-ről van szó, eleve látja a grafikus rész a rendszermemóriát, de egy GeForce-nál nem, itt meg kell határozni, hogy maximum mekkora halmazt olvashat és írhat a hardver a processzorral együtt.
Erre a problémára reagál a dedikált allokáció, ami tulajdonképpen még a lokális flages memóriahalmazból ki tud jelölni olyan allokációkat, amelyeket a program elszakíthat a meghajtótól. Ezek ugyan a lokális memóriahalmazba tartoznak, de a kijelölt részre nem vonatkozik a flag. Ennek az előnye, hogy utólagosan kezelhető a Vulkan API rendkívül GCN-orientált memóriadizájnja, viszont hátránya, hogy az így írt alkalmazások máshogy kezelik a memóriát az érintett hardvereken, ami limitációkkal jár.
Jelen formában az id úgy döntött, hogy inkább memóriát áldoznak be a sebességért, ami persze a 3 GB-os GeForce-okat rosszul érinti, de a 4+ GB-osakat már jól. Nyilván a 3 GB-os 1060-nak jól ki lett baszarintva, de a többi erősebb hardver inkább nyer ezen.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Én elég sokáig tanultam statisztikát ahhoz, hogy tudjam miképp lehet valami reprezentatív, és miképpen nem.
Ú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.
- EA Sports WRC '23
- Luck Dragon: Asszociációs játék. :)
- Autós topik látogatók beszélgetős, offolós topikja
- LEGO klub
- Konzolokról KULTURÁLT módon
- JavaScript topic
- PlayStation 5
- Samsung Galaxy Fit 3 - keveset, de jól
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen