- Milyen széket vegyek?
- OLED TV topic
- Léghűtés topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- ZIDOO médialejátszók
- Intel Core Ultra 3, Core Ultra 5, Ultra 7, Ultra 9 "Arrow Lake" LGA 1851
- OLED monitor topik
- A Windows 11 lett az úr az asztali PC-k piacán
- Home server / házi szerver építése
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
schwartz
#13812
üzenetére
Tehát egy zárt middleware-kkel teletömött játék nem ment day-1. Hát ez sokkoló.
![;]](//cdn.rios.hu/dl/s/v1.gif)
A viccet félretéve nyilván az NV-nek nem kevésbbé kellemetlen, hogy egy támogatott játék rosszul fut, de mit tudnának csinálni? Ha egyszer megengedik, hogy a fejlesztő módosítsa a kódokat, akkor onnantól mindenki azt fogja kérni.
Azért az nem volt véletlen, hogy az NV 8 éve még a dokumentálás és a nyílt fejlesztés élharcosa volt. Így lehet eredményeket elérni. Csak a mai világban többet ér a hype, mint a minőség, és egy cégnek ez egy mérlegelendő tényező. Lehet érte haragudni rájuk, de pont leszarják. -
Abu85
HÁZIGAZDA
Ezt a TressF X3.0-PureHair dolgot fontos lenne megérteni, mielőtt megint farkast kiáltunk. A lényeg a TressFX 3.0 esetében, hogy az külsőleg egy middleware, tehát teljesen nyílt, így bele lehet túrni, de akkor is egy middleware. Ez annyival jobb, mint a zárt middleware, hogy egyénileg optimalizálható, így nem kell a működőséhez esetleg letiltani a leképező optimalizációit. Viszont az AMD TressFX 3.0-s kutatásaiban az Eidos Montreal, a Crystal Dynamics és a LABS részt vállalat és ők tisztában voltak végig, hogy mi változik. Ezért megcsinálták azt, hogy a TressFX 3.0-t a következő generációs játékoknál már nem nyílt middleware-ként, hanem mélyen a motorba integrálva fogják használni. Ez a PureHair.
Az ilyen felfogásnak nagyon sok előnye van. Ezeket az előnyöket ma még csak a Frostbite-nál láthatjuk a PC-piacon, de az vitathatatlan, hogy mindent mélyen integrálva sokkal jobb minőség és sebesség hozható ki, mert az egész rendszer egymáshoz van tervezve. Nem fogsz csak egy effekt miatt külön RT-ket létrehozni, mert az brutális pazarlás. Nyilván ez viszonylagos kérdés. Például egy Fallout 4-es Creation alap annyira le van maradva technológiailag, hogy nem különösebben számít, hogy hat RT-t használ, amelyből hármat csak egy middleware effekt visz el, és ha az ki van kapcsolva, akkor is ki lesz számolva az a hat RT, de akkor csak megtörténik a számolás és ennyi, eredménye nem lesz. Természetesen forrnának a fórumok, ha kiderülne, hogy a Fallout 4 grafika jól integrált effektekkel 70-80%-kal gyorsabban megoldható mindenen, de a user nem tudja, és amúgy sem nagy a játék gépigénye.
A GPUOpen egyik célja pont az, hogy az effekteket nem tudják készre, mély integrálásra előkészítve odaadni mindenkinek, mert annyiféle motor van, hogy ez lehetetlen, de a fejlesztők a nyílt forráskód miatt el tudják végezni a munkát maguk, és a PureHair egy példa erre a lehetőségre, amely a TressFX 3.0-ból készült. Ez borzasztóan fontos egy olyan világban, ahol az EA-nek van egy Frostbite-ja, és majdnem annyi R&D-ből tartja fent azt az egy motort, amennyiből 5 top AAA stúdió megélne, ráadásul stratégiai megfontolásból nem licencelik. Egyszerűen megtehetik, hogy iszonyatos mennyiségű pénzt beletolnak, és mindent megoldanak maguk. Az olló pedig a nemhogy szűkül a többi motorhoz képest, hanem egyenesen jobban kinyílik. Ilyen felfogással még az Oxide, a Rebellion, a Firaxis és Crytek rendelkezik, mert ők megértik a problémát, de például a Crytek ebbe nemrég majdnem belerokkantak, tehát amellett, hogy piszkosul dicsérendő az, ahogy a CryEngine-t fejlesztik, egyszerűen nincs a hátuk mögött egy EA kaliberű cég, akik beletolnál a dollármilliókat. És tulajdonképpen a Frostbite a CryEngine-höz képest csak itt van előnyben, de ez egy elég nagy előny. És itt jön az a pont, hogy a piac nagy része már meg sem próbálja követni az EA-t ebben. Egyszerűen olyan mértékű strukturális átalakítást igényelne egy EA-hez hasonló fejlesztési politika, hogy borzalmasan nehéz meggyőzni a kiadók vezérkarát arról, hogy technikailag ez megéri. Még ha el is jut a pénzemberek agyáig, hogy ezzel a modellel mennyivel többre lennének képesek, akkor is ott van az az R&D, amit az effektfejlesztésre kell költeni. Ezt a terhet próbálja levenni a GPUOpen. A PureHair ilyen módszerrel anélkül volt megvalósítható, hogy abba a Square Enix beletolt volna egy rakás pénzt. Emiatt lett kivíve a GPUOpen a GitHUB-ra, hogy fejlesztők a többi fejlesztővel is megoszthassák a tudást. A legtöbben nem látnak a színfalak mögé, de amellett, hogy külsőre mindent faszának acceptálnak a stúdiók, azért látják, hogy a Frostbite ilyet tud ([link] , [link]) kurva jó sebességgel. Ez ellen önerőből már képtelenség versenyezni, tehát vagy megosztja a piac a tudást, vagy leszarja a sebességet és a minőséget, így jöhetnek a middleware-ek. A piacra egyébként hosszú távon káros az, hogy az EA az anyagi fölényét, és a jól elvégzett strukturális átalakítás előnyét kihasználva évről-évre távolabb kerül a többiektől. Ennek a lekövetésére maximum egy-két kiadó lenne képes, de ott is ordítják a nemet a pénzemberek, amint látják, hogy ez milyen költségekkel járna. Valamiféle összefogásra mindenképpen szükség van. Az is probléma egyébként, hogy az iparág legjobb szakemberei az EA-nél és a Sony-nál dolgoznak. Őket el kellene kezdeni visszacsábítani a többieknek. Lehet, hogy a fizetési igényeik magasak egy kiadó vezérkara nézőpontjából, de az EA elsődlegesen azért van ott ahol, mert megadta például Johan Anderssonnak azt, amit kér, így őt nem tudta elcsábítani a Sony vagy például az AMD. És utóbbi is probléma, mert az AMD is olyan embereket visz ki erről a piacról, mint Gareth Thomas vagy Timothy Lottes. De például a Sony is Michal Drobottal, illetve Bart Wronskival erősített. Őket nem szabadna a PC-s kiadóknak elengedni. -
-
#13642
Abu85
HÁZIGAZDA
Malibutomi
#13635
Abu85
HÁZIGAZDA
válasz
Malibutomi
#13635
üzenetére
Nem valamiért, egészen pontosan azért, mert egyszerre 10 wavefront futhat. Minél nagyobb lesz egy hardver, annál fontosabb, hogy a skálázás érdekében egyszerre több wavefront fusson, hogy ha ezeknek nincs elérhető adat, akkor legyen elég tartalék wavefront, ami beugorhat a helyére. A GCN-t az AMD legalább öt generációra tervezte, annak érdekében, hogy a konzolpiacra vonatkozó győzelmet ki tudják használni a PC-n, tehát már az elején úgy kellett tervezniük a hardvert, hogy az elskálázódjon 40 TFLOPS-ig anélkül, hogy a CU főbb jellemzőit megváltoztatnák.
Az NV például már a Maxwellt sem viszi tovább, mert elérte a limitet, amit beleterveztek, így a következő körben meg kell változtatni az ütemezést és a kihasználtságra vonatkozó jellemzőket. Ez több párhuzamosan futó WARP-ot jelent. -
#13633
Abu85
HÁZIGAZDA
Malibutomi
#13632
Abu85
HÁZIGAZDA
válasz
Malibutomi
#13632
üzenetére
A Fiji. Az eléggé sávszéllimites bizonyos motorokban.
Ha nem kellene nekik ekkora sávszél, akkor nem raknának rájuk HBM-et. -
Abu85
HÁZIGAZDA
válasz
Milka 78
#13628
üzenetére
De a csúcskártyához már kötelező a HBM. Túl sokat fogyasztana a GDDR5X, hogy azzal reálisan hozható legyen egy 12-14 TFLOPS-hoz szükséges 700-900 GB/s-os sávszélesség. Nincs meg rá a fogyasztási keret. Emiatt nem lesz kiadva egyetlen csúcskártya sem hagyományos konfigurációval.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13611
üzenetére
Attól rárakják, csak a VGA ára lesz magas, de megéri a teljesítmény miatt.
Nyilván az AMD ezért tervezi már azt, hogy nem csak egyetlen egy új generációs lapkára használnak majd HBM-et.
A következő körben még a sima GDDR5 lesz a leginkább használva. Egyelőre egyik cégnél sincs GDDR5X-et használó termék teszten.Az Xbox One-on a D3D12-n fut. A volumetrikus fényt, illetve a TressFX szimulációt aszinkron compute-ban számolja és ehhez kellett az Xbox One frissítés, ami tartalmazza a D3D12-t, mert az eredeti Xbox One API-ban ez nem lehetséges. Emellett az OIT-re ordered atomics-et használ. Ez mondjuk PC-n eleve nem lehetséges szabványosan.
A miértekre tudni kellene, hogy mennyire fut az Xbox One kód az összes D3D12 implementáción. Lehet, hogy nem igazán. -
Abu85
HÁZIGAZDA
válasz
#85552128
#13605
üzenetére
Számolj utána. Ha mondjuk szükséged van 512 GB/s-os tempóra, akkor az GDDR5X-szel ~80 wattból hozható, míg HBM-mel ~15 wattból. Azért ez nem mindegy.
A HBM-mel szerencsére nincs probléma, hiszen a JESD235a nem kapott működésre vonatkozó módosítást. A Hynix az elmúlt fél évben végig a Fiji-t vizsgálta és leadta a tapasztalatokat, amelyek alapján a JEDEC konstatálta, hogy a HBM hibátlanul működik a gyakorlatban is, tehát az alap specifikációt érintetlenül lehet hagyni, sőt, még kiegészítésre sem szorultak.Az NV-nek is ugyanaz lesz a HBM bevezetésének a modellje. Az teljesen normális, hogy első körben egy gyártó egy terméknél többre nem vállalja be, mert ha az nem sikerült, akkor csak egy terméket kell törölni, vagy jobb esetben részpiacokra korlátozni.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13602
üzenetére
A HBM még drága, így bizonyos termékeknél a GDDR5 jobb. A GDDR5X már kérdéses. Ezt nem biztos, hogy sok VGA-n beveti az AMD. Az előny, hogy olcsó maga a memória, de ha nem GDDR5 módban működik, akkor ez a NYÁK költségeinél hátrányos lesz.
Idén a HBM csak a felsőházban kap szerepet. Jövőre fog lejutni a középkategóriába. De itt a középkategóriát majd át kell értelmezni, mert az AMD-nél a termékskála az egyre gyorsabb dGPU-ról, a "leglassabb dGPU->IGP->egy gyorsabb dGPU->egy brutál IGP->és egy még gyorsabb dGPU" termékskálára vált át. Már az IGP is HBM-et kap. -
Abu85
HÁZIGAZDA
Most nem azért, de mi másban lehet hinni most? Azért Joe Marci már 8 éve felvázolta, hogy a hagyományos elvek szerint épített memóriarendszerek nem skálázhatók addig, ameddig erre szükség lenne. Ergo a fogyasztásuk egy idő után olyan szintre emelkedik, amivel az erre épített termékkategóriában az új generáció nem gyorsulni, hanem lassulni fog. Elég megnézni a GDDR fejlődését, ahol a dupla teljesítmény azonos buszon mindig kétszeresnél nagyobb fogyasztástöbblettel járt. Az persze világos, hogy a JEDEC feje 8 éve még nem tudta, hogy mi lesz a megmentő, de ettől függetlenül az előrejelzése pontról-pontra bejött. Persze őt ezért fizetik.
Ma HBM-en kívül semmilyen más működő alternatíva nem létezik a Marci által 8 éve felvázolt problémára, így baromira nehéz kétségbe vonni a HBM jövőjét. -
Abu85
HÁZIGAZDA
Akkor kezdjük az elején, ******** Egyrészt több tűt használ, tehát bonyolultabb lesz a routing, amivel bonyolultabb lesz a NYÁK. A magasabb effektív órajel miatt az EMI nagyobb gond, tehát a NYÁK-ot ez még tovább bonyolítja. Meg kell oldani, hogy ez ne zavarja a többi komponens működését, ezen belül is a NYÁK-ot érdemes nagyon sok rétegőre tervezni. Ezek nem kisebb módosítások, hanem komplett áttervezés és leárnyékolás. Egyedül akkor nem szükséges ez, ha eldöntöd, hogy GDDR5 módban működteted a GDDR5X-et.
Az interposer nem könnyű, de egyszerűbb vele bánni, mint az EMI-vel.A híreknél mindenkinek joga van benyalni a Micron marketingjét. Az viszont fontos tényező, hogy az AMD és az NVIDIA is a HBM felé tart, mert tisztában vannak a GDDR5X problémáival. A Hynix és a Samsung is erre épít.
[ Módosította: Racecam ]
-
Abu85
HÁZIGAZDA
Valójában HBM2 nincs. A HBM az egyetlen specifikált szabvány, csak a magasabb órajel miatt HBM2-nek hívják, de szabvány szinten csak egy HBM update. A két rendszer, amit mi külsőleg számmal megkülönböztetünk, valójában ugyanabba a JESD235 specifikációba van besorolva. Tehát pontosan ugyanaz a technológia.
Akkor beszélünk külön technológiáról, ha más besorolást kap. Például GDDR5 (JESD212), illetve GDDR5X (JESD232). -
Abu85
HÁZIGAZDA
Nem szar csak van sokkal jobb.
Előrelépést a HBM hoz. A GDDR5X egy kényszermegoldás, mert az implementálása nagyon nehéz. Az EMI régóta probléma ezeknél a magas effektív órajelű rendszereknél. 6 GHz az, ameddig úgy relatíve egyszerű leárnyékolni a VGA-t. Efölött már egyre nagyobb probléma az EMI. 7-8 GHz még talán megoldható, de például a 14 GHz-es GDDR5X+FPGA tesztszett 256 bites busszal 37 cm-es. Egyszerűen nagyon hosszú NYÁK-ot kell tervezni, hogy az EMI ne jelentsen gondot.
A másik gond a fogyasztás, bár az csak hűtés kérdése. Ugyanakkor a 14 GHz-es effektív órajelen 3,5-5 watt egy ilyen lapka kapacitástól függően. Szimpla GDDR5 módban fogyaszt kevesebbet, de akkor 8 GHz a max órajel. -
Abu85
HÁZIGAZDA
A mi cikkünk nem a specifikációból származik, hanem a gyártói leírásokból, amelyek részben tartalmazták a specifikációt, de részletezve van, hogy az EMI, a tokozás, illetve az árnyékolás miatt, valamint a dupla órajel fogyasztásnövelő hatása miatt miket kell módosítani. Ez sajnos nem egyszerű. Csak akkor kell kevés módosítás, ha a GDDR5X GDDR5 módban működik, de ekkor nincs magas órajel. Viszont nem gond az EMI.
-
Abu85
HÁZIGAZDA
Maga a timewarp eléggé általános megoldás, tehát többféle felhasználási módja van. Most, ha csak arról beszélünk, hogy mi az ideális, akkor nyilván egyértelműen az, ha minden kész nyers képkockát timewarpolunk. De ezt elsődlegesen azért tesszük, mert az aktuális szabványos grafikus API-k csak a jelenet kamerapozícióját fogadják el. Alternatíva a LiquidVR LDL funkciója, amely képes a jelenet kamerapozícióját megváltoztatni a képszámítás előtt. Ilyen módon úgy is kaphatsz felezett késleltetést, hogy nem timewarpolsz.
-
Abu85
HÁZIGAZDA
válasz
#45185024
#13563
üzenetére
90 Hz-es a Rift, de mindegy. Viszont a timewarp miatt nem kell 90 sztereó 3D képkocka. Elég 45 és a másik 45 pedig lehet timewarp. Persze ez csak az elmélet. A valóságban kelleni fog a magas frissítés, mert ideális szinkron a gyakorlatban nincs, így a timewarp is a késleltetés csökkentésére megy rá. Legalábbis ez az eredeti célja, de annyira általános a megoldás, hogy többféleképpen lehet használni. Bár az a módszer, amiről írtam most nem ajánlott.
-
Abu85
HÁZIGAZDA
Nyilván, ha nem számít a pénz, akkor megveszed a Falcon Northwest Tiki-t és le van tudva. Vagy DIY alapon veszel egy Dual Fiji kártyát. Ezzel biztosan nem lesz gond, mert erre lett tervezve. Csak ennyiért autót is vehetsz majd.
Nem akkora gond a timewarp. Bőven megéri használni, mert biztonságos, hogy ha megkétszerezed a valós frame-számítás szinkronablakát.
Az AMD ma még nem alkalmaz semmilyen képminőséget csökkentő módszert a saját SDK-jában. Az NV alkalmaz egy multi-res shading eljárást, ami a kép szélét csökkentett minőségben számolja. Ezt a fejlesztő aktiválhatja, vagy letilthatja attól függően, hogy mennyire van a programja a "hányáshatáron".
A multi-res shading célja egyébként pont a timewarp szabadabb alkalmazása. Kevesebb számítással csökken a késés esélye. -
Abu85
HÁZIGAZDA
A ritka drop nem számít. Nem kellemes, de viszonylag könnyen túléli az agy. A problémát az jelenti, ha folyamatosan lecsúszik a timewarp a szinkronablakról. Itt van egy olyan jelenség, hogy az aktuális grafikus API-kon belül nincs frame megszakítás. A megkezdett munkát be kell fejezni, még akkor is, ha már tudjuk, hogy a szinkronablakról lecsúszott. Ez akár még 3-5 ms-nyi extra számítást is jelenthet, de ugye már mindegy. Viszont a hardver innentől folyamatos hátrányba kerül, mert a még futó, de már felesleges számítás miatt késik az új, de fontos számítás.
Erre lesz egy megoldás idén, de csak a Mantle-be. Ez az instant killnek gúnyolt képesség, ami tulajdonképpen a szinkronablak lekésése után azonnal megöl minden késői timewarp-hez tartozó számítást. -
#13557
Abu85
HÁZIGAZDA
gainwardgs
#13556
Abu85
HÁZIGAZDA
válasz
gainwardgs
#13556
üzenetére
Csak azt tudom, hogy Xbox One-on hogyan csinálják. Ott az OIT-t ordered atomicsre építve használják és mutexszel zárolják a wavefrontokat. Ennek az előnye, hogy memóriakímélő és gyors. Ezzel a módszerrel az OIT az Xbox One-on 1 ms-os feladat. A gond az, hogy a PC-be ezt csak GCN-re lehet átmenteni jó eredménnyel, mert nem minden hardver tudja a feldolgozási sorrendet. Láthatod a Lichdom Battlemage című játékban (patch előtt), hogy a mutex zárolás más hardveren is lefut, de az eredmény hibás lehet. A másik megoldás a PPLL adatstruktúra használata, amely megoldja a problémát minden hardveren jó eredménnyel, de 3-4 ms-ba kerül, tehát sokkal lassabb, mint a mutexes megoldás. A harmadik opció az OIT kikapcsolása, de akkor olyan ronda lesz mint a HairWorks.
-
Abu85
HÁZIGAZDA
Finomszemcsés preempcióval gyakorlatilag garantált az aszinkron timewarp elkészülte. Az NV-féle rajzolási szintű preempció is jó, addig amíg 2 ms alatt van az üzemmódváltás. Ha valami beragad 2-nél több ms-ra, akkor a timewarp garantáltan lekési a szinkronablakot. Ezek eléggé nyíltan beszélt problémák a fejlesztők és az Oculus/Valve, illetve a gyártók által.
-
#13549
Abu85
HÁZIGAZDA
gainwardgs
#13546
Abu85
HÁZIGAZDA
válasz
gainwardgs
#13546
üzenetére
PureHair=TressFX 3.0 egyedi art pipeline-nal. A Square Enix EIDOS csoportja használja. Sajnos a GPUOpen GitHUB oldalra nem lesz visszatöltve, de a TressFX 3.0-val bárki csinálhat hasonlót.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#13521
üzenetére
Az NV-t biztosan nem érte váratlanul, hogy romlott a teljesítmény a Gameworks beépítésétől. Ők nem először látnak ilyet. Ez csak nektek új, mert még nem láttátok, hogy mit okoz a middleware beépítése. De persze módosítani bármikor lehet rajta, viszont sokkal egyszerűbb így hagyni és majd egy új meghajtóban lecserélni a HBAO+ shadert. Szinte egyik Gameworks játék sem a szállított kódot futtatja, mert az AMD biztosan lecseréli, és emiatt az NV-nek is le kell cserélnie egy optimalizáltabbra.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#13518
üzenetére
Az optimalizált kódút nem jelenti azt, hogy minden architektúrán javít. Inkább az manapság a cél, hogy kihozz egy olyan sorrendet, amit a játékos megszokott. Ezeket a megjelenés előtt nem látod, mert nem mérnek alpha programokkal. Egyszerűen megkapod a végeredményt, és azt hiszed, hogy az jobb mindenben, mint amilyen volt. A valóságban nem az.
Amikor a változás patch-ekben áll be, akkor láthatod, hogy mennyit változik. Az eredeti optimalizálás valószínűleg nem feküdt annyira az AMD-nek, bár azóta a driverek is javultak, tehát valószínűleg ennek a kényszerű kikapcsolásával csak maximum 5%-ot nyertek. De ez lényegtelen már, mert az új effektek miatt ez az optimalizálás nem használható. Írni kell újat, vagy így kell hagyni a kódot. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#13504
üzenetére
Igen, csak az előző verzióban nem volt még HBAO+, illetve Flex. Mivel ezek a kódok nem módosíthatók, így ahhoz, hogy ezeket beépítsd ki kell kapcsolni bizonyos leképező optimalizálásokat, amik akkor is inaktívak, ha a HBAO+-t vagy a Flexet nem aktiválod. Emiatt változott meg a teljesítmény. Most ezek helyére zsír új optimalizálásokat kell írni, amelyek kompatibilisek az újonnan beépített zárt middleware kódokkal. Nyilván egyébként az kérdés, hogy ilyeneket írnak-e, mert ez akár időigényes is lehet. Önmagában ez nem hiba, hanem annak a mellékterméke, hogy nem módosíthatók az újonnan beépített effektek kódjai, így a leképezőt kell hozzájuk szabni.
-
Abu85
HÁZIGAZDA
Azért csökkentik, mert jóval többet tudnak belőle gyártani az új interposer miatt, így jóval több kerül a piacra is, így ugyanazt a mennyiséget gyorsabban kell eladni. Korábban mondtam, hogy a Fiji esetében problémát jelentett az, hogy külön-külön működött az összes komponens, míg összerakva a csomag már nem működött. Ennek az okát lényegében megkeresték és korrigálták, így most már nem kell eldobni egy csomó Fiji-t.
Lesz még a hónap vége felé egy másik, Fury-ra vonatkozó bejelentés is emellett.(#13481) Locutus: Mondj gyorsabb és olcsóbb VGA-t.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#13416
üzenetére
Nem nehezebb vagy költségesebb, csak ha nem jó a motor struktúrája, akkor úgy járnak, mint a Unity vagy az Unreal Engine 4. Mindkét motornak van DX12 módja és megfelezi a sebességet.
A legfőbb gond az, hogy kvázi hasonló időben elérhető volt két explicit API. Most ne számítsuk a nagyon korai elérést. Az AMD Mantle a tömegek számára nagyjából 2014 februárjától, míg az Apple Metal márciustól vált elérhetővé. Majdnem azonos időben, az az egy hónap nem számít. Számos cég a Mantle-t igényelte, míg a másik tömeg az Metált. Ekkor már mindenki tudta, hogy lesz DX12, tehát akartak valami tapasztalatot róla.
A Frostbite Team, a Rebellion, a Firaxis, az Oxide, a Nixxes, az EIDOS Montreal, a CIG, az Arkane Studios, a Capcom, a Crytek, a Crystal Dynamics, a Codemasters, a Bohemia Interactive, stb a Mantle-t kezdték tesztelni és erre írták át a motorokat. Nekik a DX12 (és a Vulkan is persze - csak az akkor még nem létezett) implementálása egyszerű volt, mert tulajdonképpen a Mantle a két új PC-s API apja, tehát hasonlók az igények. Emiatt tudott az Oxide előállni egy DX12-es tesztprogrammal viszonylag hamar, és ezek közül a cégek közül más sem panaszkodott gondra. Ezzel szemben voltak akik az Apple Metalt implementálták elsődlegesen, ami persze ment. Ilyen cég az Epic, a Unity, pár Zenimax és WB stúdió, és akik ezeket a motorokat használják erősen panaszkodnak, mert amíg a Metal nem igényel új motorstruktúrát, addig a DX12 igen. Tehát az az elmélet, hogy először tesztelem a Mantle vagy a Metal API-t és aztán majd onnan megyek szabványra csak a Mantle-lel működik. Nem azért mert a Metal rossz, hanem azért, mert túl sok az eltérés a DX12-höz képest. A Unity motorprogramozója ennek teljes előadásokat szentelt az előző évben, hogy portolta a motort Metalra, aktiválta és alázott a teljesítmény, aztán innen portolta DX12-re és még a DX11-hez képest felére esett a tempó. Nem helyrehozhatatlan csak az elmélet nem találkozott a gyakorlattal. Tipikusan egyébként azoknál a cégeknél van a baj, ahol a motor nagyon öreg, így a konzolokon sem használják az alacsonyabb szintű elérést, tehát rá sem voltak kényszerítve arra, hogy modern struktúrát tervezzenek.
Aztán még ott vannak a gyártói profilozó és debug eszközök, amelyek nagyon bugosak a DX12-re vonatkozóan. Ezek javítása nem kevés időt vesz igénybe, tehát a kódok ellenőrzése igen lassan halad. Jellemzően azok a cégek állnak jól, akik írtak maguknak DX12 profilozót, mint az Oxide, mert még az MS cuccával sem lehet igazán haladni. Valószínűleg sokat segít, hogy az AMD a saját fejlesztőcsomagjának a forráskódják nyilvánosságra hozza, hogy lehessen javítani a bugokat a fejlesztőcsomag biztosítója nélkül is. -
Abu85
HÁZIGAZDA
Igen, csak nem tudod, hogy milyen beállításokat rejt az a high ... Simán lehet, hogy minimumon van a post-processt, vagy inaktív a lágy árnyék, meg egy rakás dolog ezen kívül, miközben pár olyan dolog meg maxra van rakva, amelynek látható hatása nem igen van a játékban, de a procit zabálja, hogy még a hat pixelnek látszó útra is autókat rak.
-
#13381
Abu85
HÁZIGAZDA
Firestormhun
#13378
Abu85
HÁZIGAZDA
válasz
Firestormhun
#13378
üzenetére
Nem csak nekik. A CR-re vonatkozó részek TIER_3-as effektek, mert az Intel csak olyan algoritmust írt, ami belső bemeneti lefedettséget használ, és ezt csak a Skylake IGP támogatja. Azt nem tudom, hogy a Codemasters ír-e rá alternatív kódot. A Just Cause 3-nál van, mert ott az Avalance eleve használ light assignmentet compute shaderrel, csak azt gyorsabban meg lehet csinálni CR TIER_3-mal.
A Polaris nem biztos, hogy támogatni fogja a ROVs-ot, mert a GCN-ben ordered atomics van. [link] - a két konzol ezt támogatja és lesz is hozzá kiterjesztés a PC-s API-khoz. Ez a következő szintje az order funkcióknak. Még ha támogatják is a ROVs-ot, akkor sem igazán lényeges az AMD-nek, mert a konzolból áthozható az ordered atomics képességet használó eljárás, aztán az már marhára hidegen hagyja az AMD-t, hogy a fejlesztők csinálnak-e ROVs alternatívát. Az már észrevehető egy ideje, hogy az AMD nem a többiekhez igazodik, hanem a két konzolhoz.
-
-
Abu85
HÁZIGAZDA
válasz
#45185024
#13361
üzenetére
Chrome Engine 6. Sok fejlesztést kap, de az alapja a 6-os főverzió. Azt nem tudom, hogy ezen belül mennyit fejlődött. Nyilván nem ugyanaz lesz, amivel megjelent eredetileg.
(#13362) Crytek: A Capcom Microsoft supportos cég. Ők szerintem simán megkapják a Microsoft UE4 verzióját.
-
#13357
Abu85
HÁZIGAZDA
Firestormhun
#13356
Abu85
HÁZIGAZDA
válasz
Firestormhun
#13356
üzenetére
AMD ordered atomics algoritmust kap, ami az Xbox One-on van. Az ugyanarra jó, mint a ROVs, na jó picit többre, de kell hozzá az AMD DX12 kiterjesztése.
A CR-ből mindenki kimarad, mert TIER_3-as szintet kér, vagyis az az effekt csak Skylake IGP-vel működik. Persze maga az effekt szabványos szóval, amelyik hardver tudni fogja a belső bemeneti lefedettséget az jó lesz hozzá. A light assignment egyébként nem akkora gond, mert az Xbox One-ból átmenthető egy alternatív compute algorimtus ugyanarra a problémára. Az Intel ezt csak azért kéri, mert ez így nekik gyorsabb. A DX11-ben is aktív ez a compute shader, csak meg lehet csinálni aszinkron módban is. Ergo ez mindenkinek megjelenik csak máshogy is számolható. -
-
Abu85
HÁZIGAZDA
válasz
Crytek
#13333
üzenetére
Arra, hogy ingyé van hozzáférés a GitHUB-on a forráshoz, illetve van egy saját boltja, amin belül tartalmakat vehetnek, illetve hogy csak akkor kell fizetniük, ha már van 50000 dollár bevételük, és akkor is csak 5%-ot...
A motor választásánál természetesen van több alternatíva, de mondjuk egy CryEngine full licenc már elég drága, míg egy szintén licencelhető Nitrous kezdő cégnek megfizethetetlen. Az ARK-ra összesen a töredékét költik, mint amennyi ma a Nitrous licenc.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#13330
üzenetére
Nem mindegy, hogy az embered neve Albert Einstein vagy Budai Józsi*.
Nincs igazán sok szakember az iparágon belül, így aki tényleg tud valamit, és nem csak átlagos programozó, azokat már rég elvitte az EA, a Sony, a Microsoft, és egy csomó nagy cég. A garázsstúdiók nem tudnák megfizetni őket.
*disclaimer: semmi bajom a Budai Józsikkal...
-
Abu85
HÁZIGAZDA
válasz
Crytek
#13326
üzenetére
Nem érteni kell hozzá, hanem pénz kell hozzá. És az MS-nek van pénze ahhoz, hogy az Epic pénzhiány miatt érdektelenné vált, jellemzően komolyabb fejlesztéseit kiegészítse, normálisan megcsinálja. Ennyi a titok. Csak sajnos ami hiányzik az Epicnél, az hiányzik azoknál a stúdióknál is, akik azért választják az UE4-et, mert a kezdés ingyenes.
Fel kell fogni, hogy abba az egyébként tényleg baráti üzleti modellbe, amit az Epic kínál már nem igazán lehet minden egyes platformra minőséget építeni. -
Abu85
HÁZIGAZDA
válasz
TTomax
#13323
üzenetére
Azt tudom, hogy a Daylight mobil leképezőt használt és azon ment is az AFR. A többi játékot annyira nem követtem. A Daylightot is csak azért, mert az első UE4-es cím volt, persze akkor még nem volt igazán jól optimalizálva a motor a mobil leképezővel sem.
A DX12 csak a PC-es leképezőre készült el. A mobil leképező Vulkan alatt lesz használható. Egyedül Metal API-val választható meg a leképező. Persze a DX12-es mód az UE4-ben elég gyenge. Nagyon sokszor abnormálisan működik, valószínűleg az Epic is azt várja, hogy a Microsoft odaadja nekik a saját DX12 portját, és ezt biztos megteszik, így az Epic számára nincs különösebb szükség ebbe pénzt rakni. -
Abu85
HÁZIGAZDA
válasz
Areturus
#13320
üzenetére
Radeonra talán át tudják hozni, de nem hiszem, hogy általánosan elég stabil a kiadásra. Az a baj, hogy az UE4-nek is van DX12 módja, de az elég rossz. Az ARK-nál írták egy módosítást X1-re és szerintem eddig jutottak. Az lenne a legjobb, ha a Microsoft DX12 leképezőjét beleraknák az UE4 main branch-be, mert az működik a Fable-ben.
DX12 drivert használó IGP kell és elég a GPUMMU mód. -
-
#13318
Abu85
HÁZIGAZDA
huskydog17
#13311
Abu85
HÁZIGAZDA
válasz
huskydog17
#13311
üzenetére
Többször írtam már, hogy az UE4-nek két leképezője van, és a PC-s leképező optimalizálása nagyon rossz. A Microsoft sem ezt használja, hanem írtak egy sajátot. Ez van. Az Epic számára a mobil leképező a fontos, és az nagyon is jó.
-
#13305
Abu85
HÁZIGAZDA
huskydog17
#13293
Abu85
HÁZIGAZDA
válasz
huskydog17
#13293
üzenetére
A Tencent több pénzt akar rakni a kutatásba, így nekik a GPUOpen nagyon fontos. Ők egy olyan modellt akarnak kialakítani, mint az EA, hogy mindent házon belül csinálnak. Ez amiatt is fontos, mert saját konzolt csinálnak, illetve ezt kiterjesztik egy saját operációs rendszerre, így bárki tervezhet a Tencent OS-hez konzolt. Szóval elég durván le fogják támadni a kínai piacot a közeljövőben. Van még VR projektjük is csak még nem jelentették be hivatalosan, de azt már elmondták, hogy a teljes kínai VR-piacot uralni szeretnék.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13267
üzenetére
A Feature levelt furcsamód a D3D12 legacy funkcióként specifikálja. Ergo egyetlen program sem írható meg aszerint, hogy a Feature level szintet lekérdezi a fejlesztő. Helyette egyenként kell lekérdezni az egyes funkciók meglétét. Ilyen formában ez egy szükségtelen paraméter, mert semmit sem definiál a program számára.
-
Abu85
HÁZIGAZDA
válasz
Areturus
#13264
üzenetére
Köszi. Igen az "and" egy hiba. Ki fogom javítani.
A sztereó 3D kötelező. A shader modell esetében is mindenki a legjobbat kell, hogy támogassa. SAD4 is kötelező lett, akinek nincs rá hardvere írnia kell a driverbe egy emulációt, de ezt a funkciót átrakták a DXGI-ba, hogy ne csak a DirectX érhesse el. A dedikált atomi számláló is kötelező lett, ha nem tudja a hardver, akkor emulálni kell annyit, amennyit az API megkövetel. Emiatt van kétféle ajánlás a DX12-nél. Az AMD azt ajánlja, hogy használj Atomicot, mert gyors, míg az NV és az Intel ennek az ellentétét ajánlja, mert az API már nem különbözteti meg a hardvert az emulációtól.
Az is. De a Full Heap mérete architektúránként más.
A Tiled Texture3D nem emulálható. Alternatív algoritmus írható csak.
-
Abu85
HÁZIGAZDA
Egész korrekt lett a Vulkan specifikáció. Just saying...
Nem olyan vagy mindent vagy semmit elvű a multi-engine koncepció, mint a DX12-nél. Vulkan alatt a Maxwell és a Kepler is aránylag normálisan tudja majd támogatni az aszinkron compute-ot. Legalábbis egyszerűen megoldható, hogy szabványos kódtól nem pusztuljon meg, így nem kell külön kódbázis rá, és még érni is fog valamit a párhuzamosítás. A Khronos most nagyon odatette magát, így szerintem a Vulkan jobb API lett. -
Abu85
HÁZIGAZDA
válasz
Areturus
#13240
üzenetére
Ezt egyébként tényleg nem értem, hogy miért gyártanak összeesküvéseket sokan. Én sem láttam még stabil UE4-es DX12 kódot. A Microsofté kb. stabil, de ennyi. Ha nekik nem stabil, akkor nem éri meg kiadni. Elvégre egy csomó dolog a driver eddigi munkájából átkerült a programkódba.
Azt is elmondta a végén, hogy az NV messze van az AMD-től ha a párhuzamosításról van szó, de ez is csak egy javítandó probléma. Mondjuk ezt nem írtam volna le a helyében, mert a következő összeesküvés az lesz, hogy megerősítette, hogy az NV-n nem megy jól. Biztos azért nem jön a DX12 mód.
-
Abu85
HÁZIGAZDA
válasz
nonsen5e
#13233
üzenetére
Az Epicet nem érdekli, hogy ki milyen Flappy Bird klónt készít vele, csak használják. Akármilyen semmi a játék a motor alatta lehet UE4, mert erre mentek el a licenckonstrukcióban. A bevételük zöme már innen származik, ezért fektetnek sokkal többet a mobil leképezőbe. Az egész jól működik. Az asztali leképező sajnos eléggé optimalizálatlan, ami arra vezethető vissza, hogy kevés pénzt raknak bele. Az, hogy nem lesz normális dGPU+dGPU szintű multi-GPU meg múltkor durván kiverte a biztosítékot, de az Epic helyzete érthető. Egyszerűen versenyképtelenek a Frostbite és a többi belsős projekttel, így inkább a tömegek igényeire mennek rá.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13231
üzenetére
Az ARK nehéz ügy, mert Unreal Engine 4-es. Az Epic nagyon kevés erőforrást fektet a komolyabb leképezőbe, mert a motort zömében mobilhoz használják. Az Android a célpiac, és az ahhoz készült leképező nagyon jól optimalizált, de nem ezt használja az ARM. Xbox One-on egyébként már DX12-ben fut a program, de csak azért, mert oda elérhető a Microsoft optimalizálása az Unreal Engine 4-re. Ezt elég sokára fogják visszaírni a főverzióba. Ergo vagy megoldják maguk az Xbox One kód alapján, vagy várnak az Epicre, amíg hajlandó ránézni a PC-re. Az a baj, hogy az Epic számára ez nem fontos. A multi-GPU-t is csak IGP+dGPU-ra írják meg, míg hagyományos formára nem. Azt is elmondta Sweeney, hogy nem éri meg pénzt költeni rá.
-
Abu85
HÁZIGAZDA
válasz
#45185024
#13223
üzenetére
De, hiszen a DX12 API-n fut.
A volumetrikus megvilágítás a Rise of the Tomb Raiderben multi-engine módban, vagyis aszinkron compute-ban van számolva a shadow mapokkal párhuzamosan.
Minden DX12 kód kötelezően multi-engine. Single-engine módot az API nem is definiál.(#13224) Szaby59: Nem fontos annyira, de nézd az MS nézőpontjából. Nekik pont az a lényeg, hogy megmutathassák a piacnak, hogy elég a kódot az Xbox One-ra megírni és az jöhet PC-re. Nekik ehhez példákat kell hozni.
A Frostbite-nak a Vulkan kedvezőbb, mint a DX12. Ők csak ott akarnak a Windows 10-hez kötődni, ahol muszáj, amúgy inkább platformfüggetlenül gondolkodnak. -
Abu85
HÁZIGAZDA
A RotTR-hez nem kell DX12 leképezőt írni, egyszerűen csak pár sor kell az Xbox One leképező elejére. Vagy az sem, mert előre beleírták. A Microsoft a játékaival ezt akarja demostrálni. Persze lehet tovább is optimalizálni PC-re.
Az új TR Xbox One-on ugyanazon a DX12 API-n fut, ami a Win10-hez van. -
Abu85
HÁZIGAZDA
-
#13204
Abu85
HÁZIGAZDA
Firestormhun
#13203
Abu85
HÁZIGAZDA
válasz
Firestormhun
#13203
üzenetére
A broad temporal ambient obscurance nem AO, hanem obscurance fields alapú technika. A AO mellette egy HDAO. Az sample distribution shadows map egy Z partícionáló kiterjesztés. Ez kiegészíti a CHS-t. Ettől hatékonyabb lesz.
Kizárólag az AMD-é a TressFX. A felhasználása szabad csak.
A VXGI AO only opció eleve egy DX11-es effekt volt még 2014-ben, amikor szó volt róla. Azt is elmondták, hogy Full HD-ben egy GTX 770 3,8 ms alatt számolja. Persze ez az akkori kód volt.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13197
üzenetére
De nem olyan dolog ez, hogy odamész és azt mondod, hogy légyszi cseréld ki. Azon a minőségi szinten, amit a Microsoft elvár ez legalább úgy egy éves procedúrával járna, amíg az odavitt middleware-khez úgy módosítják a leképezőt, hogy jó legyen. Egy hónappal a megjelenés előtt ilyet nem fog bevállalni senki.
(#13198) Gertrius: Az a Voxel-based Ambient Occlusion. Még az eredeti VXGI effektnek egy mellékága lett, mert a VXGI nem támogatja az animációt, de VXAO-val nem kötelező a dinamikus objektumokat számításba venni, így lehet csak a statikus geometriára dolgozni. Több cégnél is elindult ez a kutatás csak aztán leállt, mert az obscurance fields jobb eredményt ad, de csak töredéke a hardverre kifejtett terhelése és mozgást is támogat.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13195
üzenetére
Mire cserélnék a TressFX-et? Nem lehet csak úgy kicserélni ezeket az effekteket egy hónap alatt. Vagy marad minden, ami a konzolverzióban volt, vagy szimplán letiltásra kerülnek a PC-s verzióban. Az biztos, hogy az Xbox One-on van számos korábbról használt AMD-s effekt, mint a TressFX, a HDAO és a CHS, illetve van még egy mozaikos gyorsítással dolgozó részecskeszimuláció is, ami szintén az AMD-é, és a Dirt Rally már használta.
-
Abu85
HÁZIGAZDA
Na szóval a sikerült pár dolgot megkérdeznem. A Nixxes mondta, hogy valóban részt vesznek a portolásban, de ez csak mellékprojekt. Egészen pontosan a DX11-es leképezőn dolgoznak, illetve megpróbálják a 32 bites módot összehegeszteni, de inkább 64 bitre kell készülni, mert memóriából relatíve sok kell a játéknak. A többi hardverelem szempontjából nagyon alap igények vannak.
-
Abu85
HÁZIGAZDA
A Nixxes elég gyorsan frissül listájában csak az van, hogy Xbox 360-hoz készítették a portot. Mondjuk ettől a CD mellett ők is fejlesztők, csak kérdés, hogy a PC verzióra is azok-e, mert hivatalosan ők csak Xbox 360-ra vannak odaírva. Azért nem szabad elfelejteni, hogy ők már két projektet csinálnak, és ez nem egy nagy csapat. Csupán 20-30 fő közötti a létszám. Szóval összességében sok embert nem adhattak egy harmadik projekthez, de egy ember is elég ahhoz, hogy listázva legyenek. Az más kérdés, hogy ezt mennyire tekintik saját portnak.
Az meg logikus, hogy kell a Windows 10, amikor a játéknak tudtommal csak DX12-es (Xbox One) leképezője van. Ez nem meglepetés.
A Steam pedig elfogad 3rd party DRM-et, így jó a Winstore is, ahogy a Uplay is például. -
Abu85
HÁZIGAZDA
válasz
füles_
#13142
üzenetére
Kellene egy újabb driver, mert a DiRT Rally végleges kódja sokat változott az Early Accesshez képest. És az új drivert úgy értem, hogy az NV-nél még nem jelent meg olyan driver, amely megjeleníti az összes objektumot. Szóval ott még várni kell egy januári frissítésre. Ilyen formában ez a játék még nem jó tesztre, mert a végleges kód az eddigi optimalizálást elkaszálta.
(#13141) daveoff: Leírtam már régebben, hogy az AMD partnere a Nixxes, illetve a Square Enixnek az EIDOS csoportja. Ők is csak azért, mert nem hajlandók az NV-vel dolgozni. A Rise of the Tomb Raider nem kapcsolódik az EIDOS csoporthoz, vagy a Nixxeshez. A Microsoft technikai csoportja segített összerakni. Gyártói szerződést ők nem kötöttek, mert több régióban is a Microsofté a kiadás joga, de ha a gyártók megveszik megfelelően magas áron, akkor nyilván adnak kulcsokat. Az AMD-nek ez egy Star Wars Battlefront után nem ideális, mert az EA is olyan, hogy dömpingárat nem szokásuk biztosítani.
-
#13134
Abu85
HÁZIGAZDA
huskydog17
#13124
Abu85
HÁZIGAZDA
válasz
huskydog17
#13124
üzenetére
Éppenséggel esélyük lenne javítani rajta csak az egész projekt eleve pengeélen táncolt. A Raven's Cry eredeti fejlesztőit a fejlesztés közben kicsapták. Az AMD ekkor elvett minden segítséget a projekttől, mert a törlés szélére került. Ekkor jött a Reality Pump, akiket kijelölt a kiadó, hogy hozzák rendbe a játékot. Ebből lett végül a Raven's Cry. Viszont tiszta bug volt így is, ami érhető, mert marhára időre dolgoztak. A Reality Pump nagyon sok szempontból abból a tudásból él, amit az AMD otthagyott nekik a Two Worlds II kiegészítőjénél. 2012 végéig élt a szerződésük, és addig a GRACE 2-t optimalizálták. Többek között visszafejtették nekik a Keplert is. De 2013-ban már nem újították meg a szerződést, így a Reality Pump kvázi magára maradt. Ez meglátszik a technikán is, ami megragadt azon a szinten. A Maxwellt már senki sem segített nekik visszafejteni, pénzük pedig gondolom nem volt rá.
-
Abu85
HÁZIGAZDA
Többször leírtam az okot. A Kepler esetében a magok 33%-a elvész, ha nem optimalizálod jól. Érdekes, hogy sokan jól csinálják, és még a Maxwell is jó.
Nekem mindegy, hogy mit csinálnak, mert ez is csak üzlet. De nem értek egyet vele, mert honnan vagyok kibiztosítva, hogy nem csinálják majd ugyanezt a Maxwellel? Az persze, hogy a Kepler esetében nem tapsikolnak a userek a helyzetre reménykeltő.
A GameWorks esetében a probléma mindig is az volt, hogy rossz minőségű és optimalizálatlan, illetve átgondolatlan. Ez érint minden hardvert. Néha a Keplert jobban. Az igazi probléma a Keplernél a TWIMTBP.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13097
üzenetére
Pont az a lényege a multi-draw indirectnek, hogy ezt lecsökkentse. Az nagyon fontos még a Frostbite motorokban, hogy a pre-render egy natív motorbeállítás és nagyon eltérő a gyártók között. Az AMD csak egyet számol előre, míg az NV ötöt. Az Intel háromra van kalibrálva. Emiatt az AMD-t másképp kell kezelni a DX11-ben, mint a többi gyártót, mert jóval alacsonyabb az input lag. A DX12 és a Vulkan ezt is megváltoztatja. Ott mindenkinek egy lesz a pre-render. Ez nagyrészt egyébként meghajtókonfiguráció eredménye. Az AMD az elmúlt években sokat költött arra, hogy az input lag rohadt alacsony legyen, és a Crimson drivertől kezdve minden esetben alapértelmezetten 1 a pre-render. A többi gyártó az egyet nem kockáztatja meg, mert nem fektettek be ide szinte semmi pénzt. Inkább 3-5 közötti a pre-render.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13093
üzenetére
Olvasd el a többi részét is a hsz-nek. Ezek a funkciók már működnek benne, de csak az AMD szervizkönyvtárán keresztül. A többi hardverre a DX12 és a Vulkan a megoldás, mert a DX11 nem támogatja szabványos formában a multi-draw indirectet. Az egészet azért fejlesztette ki a Frostbite Team, mert az AMD csinált hozzá egy kiterjesztést, és erre a kiterjesztésre építették a mainline kódot, mondván a DX12 és a Vulkan úgyis támogatni fogja a GPU-driven pipeline-t. Ennek a fő célja egyébként az overhead kezelése úgy, hogy ne essen le tartósan a sebesség az egyes helyeken, de ezt csak az AMD-re tudják "ma" megcsinálni. "Holnap" már másra is.
-
Abu85
HÁZIGAZDA
A Battlefronthoz annyit tennék hozzá, hogy az új Frostbite verziónak vannak olyan kiterjesztései, amelyek a DX11 API-ban nincsenek benne. Többek között az új Frostbite már GPU-driven pipeline-t használ, amit a DX11 nem specifikál. Emellett az NV és az Intel sem rendelkezik rá DX11 kiterjesztéssel, de az AMD-nek van egy AGSL 3.0-ja DX11-es multi-draw indirect kiterjesztéssel. Erre épül az új Frostbite kódja, míg a többi hardveren egy alternatív kódbázis van, amely multi-draw indirect nélkül is megoldja a rajzolást. Utóbbi viszont előnyösebb, mert töredék rajzolásból megcsinál mindent, tehát az AMD-nek az AGSL 3.0-val jóval kevesebb többletterheléssel kell számolnia, mint a Intelnek és az NV-nek.
A DX12 és a Vulkan ezt a multi-draw indirectet támogatni fogja szabványosan is. -
Abu85
HÁZIGAZDA
Nem. Te azt mondtad, hogy a hiba nem tuninghoz kötődik. Valójában ahhoz kötődik.
Ha szerinted normális, hogy a 780 a 960 szintjén van pár TWIMTBP játékban, miközben számos játékban a 970-nel küzd, akkor az a te dolgod. Szerintem viszont nem normális, és számos Kepler tulaj szerint sem az, aminek hangot is adnak még az NV fórumán is. Szerintem jól teszik. Próbálják elérni, hogy nagyobb teljesítményt kapjanak, hogy egy 384 bites egykori csúcsmodellt ne verjen el egy 128 bites új talicska, mert amikor megvették a 780-at, akkor bizonyosan nem erre számítottak.
-
Abu85
HÁZIGAZDA
De a tuninghoz kapcsolódott, mert az Overdrive modul onnantól működött rosszul, hogy megváltoztattad a venti szabályozást. Ha azt nem bántottad, akkor nem jött elő a hiba. Ezt onnan tudom, hogy az overdrive modult én használtam még a kiadás előtt, és három játékhoz beállítottam külön órajelet, hogy működik-e a játékokra lebontott tuning, persze a ventihez nem nyúltam, mert az elvégzi a feladatát tuninggal is, hiszen a BIOS-ban leírt profilnál úgy sem tudok neki jobban csinálni. Ilyen formában a venti nem ragadt be.
Természetesen addig eljutnak, hogy aktiválják a modul egyes elemeit, de pont az volt a baj, hogy a tuningra vonatkozott a hiba. Tuningot pedig már nem tesztel senki. Ameddig bekapcsoltad a funkcióit, addig nem jelzett problémát, márpedig az alap teszprotokoll kimerül abban, hogy aktiválják és működik-e. Ilyen formában átment a meghajtó, mert működött. Azoknál nem működött, akik megváltoztatták a tuningbeállításokat.
Arra kérsz bizonyítékot, hogy tuningot senki sem tesztel? Ez a legegyértelműbb dolog. Mit teszteljenek rajta? Nem fogják 1 MHz-enként és 1%-onként az összes nagyjából 1-2 millió kombinációt kártyánként ellenőrizni. Erre nincs kapacitás sehol. Azt csinálják meg, hogy aktiválják a funkciókat és az aktiválás működik-e. Ez működött. Ez az, amit reálisan lehet tesztelni kártyánként. Ez így is elvihet két napot.
Mondtam példát, csak nem tartottad elég jónak. Még linkeltem is az NV felhasználók fórumát, akik elégedetlenek azzal, amit az NV csinál a Keplerrel.
(#13037) ffodi: Nem arról van szó, hogy nem probléma, csak nem olyan probléma, amivel kapcsolatban bárki felelősségre vonható, mert egy olyan modulon belül volt a hiba, amelynek az aktiválásához el kell fogadnod, hogy a gyártó mentesül minden felelősség alól. Ez pont azért van így csinálva, mert képtelenség VGA-nként egymillió konfigurációt végigtesztelni. Tegyük fel, hogy egymillió lehetséges kombinációt kell tesztelni 100 VGA-ra. Az 100 millió teszt, és egy stabilitásteszt 8 órás. Tehát egy meghajtó tesztje 800 millió óra lenne. Ez képtelenség. Ezért jobb a tuningra nem vállalni garanciát.
A tönkretétel egy kamu volt. Egyetlen ember sem jelentkezett a twitteren azok közül, akik beírták, hogy tönkrement a Radeonjuk. Pedig felajánlották mindnek a cserét.
Az overdrive modul eleve a drivertől független settings modul része. Ha utóbbit nem telepíted attól a meghajtó működni fog.(#13038) FLATRONW: Én is arra gondoltam. Volt olyanom. Ma már nincs, mert a GPU PhysX leállt. A Witcher 3-ban is csak lassulást okoz.
(#13041) schawo: Nem hiszem, hogy akármelyik bíróság érvénytelenítene egy olyan EULA-t, amely azt fogadtatja el a felhasználóval, hogy a termék nem rendeltetésszerű használata okozta hiba a user felelőssége.
(#13042) Macka: Azokban a tuningprogramokban is van hiba, amelyeket a gyártók az GeForce-okhoz adnak. Csak az NVIDIA nem teszi lehetővé a tuningot egy gyári modulból, de registry módosítással lehet.
(#13048) Egon: Ez tévedés. A tuningra akkor sincs garancia, ha 1 MHz-et emelsz rajta, és hibátlanul működik. Megteheted, hogy tuningolod, de garanciát senki sem vállal rá. Akármilyen hiba jön elő a te felelősséged, mert egy olyan szerződés elfogadása után egyetlen programban sem lehet tuningolni, ahol te nem fogadtad el azt a feltételt, hogy az esetleges hibák téged és kizárólag téged terhelnek.
Ha aktiváltad az overdrive-ot attól még működött. Onnantól nem működött, hogy kézi ventivezérlésre kapcsoltad, vagyis bekapcsoltál egy tuningfunkciót.(#13050) daveoff: Azért nem csinálják azt, mert az AMD-nek PowerTune technológiája van a hardver vezérlésére és ez nem szoftveres, hanem teljesen hardveres rendszer. Ezt a technológiát annyira védik, hogy még a gyártóknak sem árulják el a működését, így a gyártói tuningprogramok is abból élnek meg, hogy az egyes PowerTune verziókat visszafejtik. Ezért késik mindig az új Radeon VGA-k tuningjának támogatása a 3rd party programokból. Az NV által használt rendszer félig szoftveres csomag, vagyis tulajdonképpen egy szoftvert kérdez meg a hardver, hogy az egyes állapotokra mit lépjen. Ezt jóval egyszerűbb lekövetni, mint az AMD PowerTune rendszerének szoftveres hátterét feltörni. Emiatt csak az AMD képes arra, hogy a PowerTune profilhoz szabott tuningfunkciót biztosítson.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#13029
üzenetére
Hibátlan meghajtó természetesen sosem lesz, de a gond amiről beszélünk nem jött elő mindaddig, amíg nem volt aktív a tuning. És ez nagybetűs TÉNY.
Akár tetszik akár nem a tuning az tuning. A garancia a tuningszolgáltatások aktiválásával elveszik, vagyis minden, ami erre vonatkozik nem rendeltetésszerű használat. Természetesen megteheted, hogy úgy használod a hardvert ahogy neked tetszik, de semmi jogod nincs reklamálni, mert elfogadtad azt az EULA-t, amelyben erről a jogodról lemondasz. És ez független az AMD-től. Minden gyártó ezt fogadtatja el veled a tuningra vonatkozó EULA-kban!(#13031) ffodi: Mert a tuning az tuning. Értsétek meg, hogy a gyártók megkülönböztetnek rendeltetésszerű és nem rendeltetésszerű használatot. Előbbi esetben teljes a teszt, de utóbbi esetben nem lehetséges olyan tesztprotokollt készíteni, amely minden eshetőséget lefed. Éppen ezért kerül ez a nem rendeltetésszerű használat csoportjába egy saját felelősségvállalásra vonatkozó EULA mögé.
Attól, hogy valaki nem olvassa el az EULA-t nem jelenti azt, hogy mentesül a feltételei alól.
A termék beüzemelhető a manual nélkül. Bár nagyon ajánlott azt is elolvasni.(#13032) TTomax: Ez nem jó példa, mert ilyen nincs. De olyan egyébként van, hogy a kocsi motorja szoftveresen le van fojtva. Ezt sokszor fel lehet oldani egy szoftveres tuninggal, amit számos műhelyben megcsinálnak, de arra a kocsi gyártója nem vállal majd garanciát. Ez teljesen normális. És igen a szoftveres fojtással is addig van tesztelve a kocsi, ameddig a tartományig a szoftver engedi a motort működni.
Nem értem, hogy miért beszélünk ennyire specifikusan. Az AMD feltételei a tuningra semmiben sem különböznek más cég feltételeitől. Amint aktív bármilyen tuningszoftver a garancia a normális működésre elvész. Ha ezt egy felhasználó nem képes megérteni, akkor minden cég úgy van vele, hogy jobb, ha többet nem vesz tőlük hardvert, mert csak a baj lesz a userrel.
-
Abu85
HÁZIGAZDA
Nem lehet, mert a meghajtó hibátlan volt a tuningmodul nélkül.
A tuningra egyetlen cég sem vállal garanciát. Ez nem az AMD egyedi dolga. Nem tudsz mondani olyan céget, amelyik bármilyen tuningfunkcióra garanciát vállalna.(#13027) TTomax: Nem kell annyin használnod. Számos olyan VGA van, amely másik hűtőt használ. Meg eleve a gyári hűtővel az én VGA-m nem megy 60°C fölé.
Akkor sem fognak a tuningra garanciát vállalni, ha most itt vért izzadva követeled ezt. Nincs olyan cég, amely a tuningfunkciók feloldása előtt ne fogadtatná el veled azt az EULA-t, amely kimondja, hogy tied a felelősség. Ez benne van az Afterburner, a GPU Tweak, a Trixxx, akármilyen más tuningprogram telepítőjében. Természetesen megteheted azt is, hogy nem fogadod el, és a program nem települ.Egészen félelmetes, hogy 2015-ben eljutottunk oda, hogy tuningszoftverre/funkcióra garanciát követel a felhasználó.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
Májkii
#13021
üzenetére
Volt. Természetesen. Ugyanazt a szerződést kellett elfogadni.
(#13022) TTomax: Dehogynem. Bármikor kiveheted a telepítőből a vezérlő telepítését. A meghajtó enélkül is működik. Custom telepítést kell kérni.
Az UELA arra vonatkozik, hogy ha aktiválod a felületet, akkor az AMD felelőssége minden hibára megszűnik. Olvasd el.
Az egyedi ventiprofil is tuning! Pont ugyanúgy a te felelősséged, ahogy az extra órajel. -
Abu85
HÁZIGAZDA
válasz
TTomax
#13017
üzenetére
Az overdrive modul nem a meghajtó része. Le van lakatolva!. Addig nem is érheted el, amíg nem fogadod el, hogy a lakat kioldása után nem vállal felelősséget az AMD semmilyen hibáért. Ha elfogadod, akkor pedig minden a te hibád. Te döntesz. A meghajtó az overdrive modul nélkül hibátlanul is működik.
(#13018) Macka: A tuning üzemképtelensége nem meghajtóhiba! Az sem meghajtóhiba, hogy az erre szolgáló modul hibás. Ez vezérlőhiba, de eleve egy olyan felületen, amelynek a kilakatolásával elfogadtad, hogy a felelősség a tied.
(#13019) gbors: Az, hogy nem teszteli a tuningmodulokat senki? Bocs, hogy felébresztettelek, de a tuning nem része sehol sem a tesztprotokollnak. Ha tetszik, ha nem, ez így van.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
imi123
#13010
üzenetére
A Mantle esetében azért jó 3000 sort kellett beírni. Plusz nem kevés shadert átírni. Illetve, ha a motorok nem voltak felkészítve strukturálisan erre, akkor azokat is át kellett írni. Utóbbi volt igazán időigényes. A jó hír igazából, hogy rengeteg stúdió írt Mantle leképezőt, csak azért, hogy a motorokat felkészítsék a DX12-re is. A Mantle ugyanis ugyanazokat az igényeket támassza egy motor felé, mint a DX12 és a Vulkan. Ha ezt megcsinálták, akkor másik back-endet lehet írni két hét alatt is. Szerencsére mindhárom PC-s low-level API annyira hasonló (kvázi ugyanaz az AMD-s forrás az alap), hogy nem szükséges választani közöttük. Elég könnyen megoldható mindhárom támogatása nagyrészt közös kódból. A legtöbb multiplatform fejlesztés erre megy rá.
A Microsoft ennél annyival ment tovább, hogy az Xbox One-ra szállítják ugyanazt az OS-t és ugyanazt az API-t, amit PC-re. Persze szállítanak egy még alacsonyabb szintű mono elérést, de ez most mindegy. Tehát ha a DX12-es elérést használja egy program Xbox One-on, akkor úgy is meg lehet oldani a portot, hogy az erőforrás-kreáláshoz szükséges ellenőrzéseket beírják az elejére és kész. Vagy, ha nagyon előre gondolkodtak, akkor ez már az Xbox One kódban is benne van. Ilyenkor tényleg copy-paste az egész.
Egyébként apró műhelytitok, hogy a Sony ugyanezt fogja csinálni a Vulkan API-val. Azt is támogatni fogják a libGNM és a libGNMX mellett. A Nintendo meg eleve a Vulkan API-t használja az NX-hez. -
Abu85
HÁZIGAZDA
válasz
imi123
#13007
üzenetére
Pedig ez az alapvető cél a Microsoft nézőpontjából. Ha megvan az Xbox One kód DX12-re, akkor az elejére kell írni pár sort és mehet PC-re. Persze nem biztos, hogy ez minden esetben jó ötlet, de garantáltan futni fog a program. Ahhoz, hogy ezt nyomatékosítsák demonstrálni kell pár programmal. A Fable Legends, az új Tomb Raider és a Gears of War felújítás lett kiválasztva első körben. A Fable Legends pre-alpha alapján ebből nem lesz gond. Persze ez azért nagyrészt annak is köszönhető, hogy a Microsoftnál értenek is hozzá, így eleve jó minőségű a kód. Az inkább kérdés, hogy más képes-e ilyen jó minőségű multiplatform kódot csinálni. Az Unreal Engine 4 D3D12 experimental build alapján az Epic nem volt képes erre és ez már aggodalomra ad okot.
(#13008) gbors: A drivernek csak az overdrive moduljában volt a hiba, amit eleve nem kell engedélyezni a működéshez, vagy ha engedélyezed, akkor el kell fogadni, hogy innentől minden a te felelősséged. A driver hibátlanul üzemelt, ha a tuningmodul nem volt aktív! Az overdrive modult elrontották ez tény, de ezt csak azokat érintette akik tuningolnak. Tehát rendeltetésszerű környezetben a meghajtó működött. Arra is mérget vehet bárki, hogy a tuningot a jövőben sem fogja senki ellenőrizni.
-
Abu85
HÁZIGAZDA
válasz
imi123
#13005
üzenetére
Tekintve, hogy az Xbox One-on nem létezik DX11-es API, csak DX12-es, így ha tényleg copy-paste lesz, akkor DX12 kell majd hozzá. A DX11-hez írni kell egy másik leképezőt, amire nem biztos, hogy erőforrást pazarol a Microsoft. Ezt szerintem nem véletlenül csinálja a Microsoft. Szimplán demonstrálni akarják a DX12 előnyét, hogy az Xbox One kód pillanatok alatt átültethető PC-re. Az új TR lesz a kísérleti nyúl.
-
Abu85
HÁZIGAZDA
Mi a baj vele? Már azelőtt felraktam, hogy megjelent és azóta működik, persze egy hete lefrissítettem az új verzióra.
A ventivezérlés is működik. Tuningnál nem működött, de azt senki sem ellenőrzi soha és sosem fogja, mert benne van az EULA-ban, hogy elfogadod a hiba lehetőségét.(#12998) Szaby59: Az új Tomb Raider PC-s kiadója a Microsoft lesz több régióban is és ők eleve nem érdekeltek a bundle-ökben. Nem is nagyon van lehetőség ilyenre a Windows Store-on belül.
Az AMD-nek egyébként biztos nincs sok köze a Rise of the Tomb Raiderhez a technikai segítség szintjén, mert nem a Nixxes portolja, hanem egyszerűen az Xbox One kódot adják ki PC-re tulajdonképpen copy-paste szinten.
A Nixxes az új Hitman és új Deus Ex játékokon dolgozik az AMD-vel. Azok nem csak szimpla Xbox One másolatok lesznek. -
Abu85
HÁZIGAZDA
Olyan a valóságban nem létezik. Minden API-nak van egy conformance tesztje, ahol az API tulajdonosa hitelesíti az összes meghajtót. Ha ott átmegy, akkor a meghajtó megfelel a specifikációknak. Viszont ma az a probléma, hogy ezek az API-k, ideértve a DX11-et és kiemelve az OpenGL-t. Az egyes problémákra számos megoldást kínálnak. Például az adatfeltöltésre az OpenGL-ben legalább másfél tucat alternatív megoldás van, és kis túlzással mindegyik hardvernek csak egy-kettő fekszik, vagyis ideálisan az lenne a jó, ha a program mindegyik lehetőségre tartalmazna egy implementációt. A DX11-ben is igaz ez csak ott azért a Microsoftnak volt annyi esze, hogy ne fogadja el ész nélkül minden újítást. A DX12 és a Vulkan egyik kritikus fícsőrje, hogy minden problémára csak egy gyors megoldás van, vagyis a fejlesztőknek elég arra építeni egy programot és az garantáltan gyors lesz minden hardveren. Nem biztos, hogy a leggyorsabb út lesz xy gyártónál, de elég gyors, ahhoz, hogy ez ne legyen gond. Ez egy nagyon kritikus pont. Nyilván ennek a hátránya, hogy akkora változást jelent a korábbi API-khoz képest, hogy a visszafelé kompatibilitás megszűnt, de ez más szempontból is így van. Nagyjából elérkezett az az idő, amikor megéri egy tiszta lapot indítani. A másik fontos dolog, hogy a gyártók ezeket az API-kat persze kiegészíthetik a saját eljárásaikkal, ami megint ugyanoda vezetne, ahol most tart a DX11 és az OpenGL. Erre viszont megoldás a validátor. Ez meg fogja akadályozni azt, hogy a gyártók ezt a csomagot is szétbarmolják a különböző kiterjesztésekkel, mert a kiterjesztéseket nem lehet majd validálni. Ettől persze a program szállítható lesz, csak a gyártók kétszer is meggondolják majd, hogy lecserélik-e a szabványos eljárásokat egy kiterjesztésben, mert validáció nélkül a következő generációs hardveren az a kód jó eséllyel nem fog elindulni. Kvázi bele lett kényszerítve mindenki a szabványos, specifikált, validálható eljárások használatába, ha azt akarják, hogy a játékok ne csak egy évig fussanak. Olyan kiterjesztés tehát nem fog érkezni a DX12 és a Vulkan API-hoz, amely például alternatív adatfeltöltésre vonatkozó specifikációt kínál.
-
Abu85
HÁZIGAZDA
Az egyébként a probléma jóval mélyebb. Az NV a GameWorksöt azért kezdte el, mert az AMD puccsolja a szabványalkotást. Ez is nagyon csúnya dolog. Az NV éveket és dollár százmillókat ölt abba, hogy elérjék az aktuális API-k eljárásainak folyamatos kiegészítését. Viszont sosem gondolták azt, hogy bárki, a kompatibilitást felrúgva hozzon egy új irányt. Az AMD azonban hozott, és erre épül a DX12/Vulkan. Az AMD megmondhatja a tutit a GAB/ARB-s vétójoggal. Hiába fog ordítani az Intel/NVIDIA/akárki, hogy a hardvereiknek az API tervezete rossz, vagy megszavazzák, vagy az AMD leszavazza az alternatív javaslatokat.
Látszik is a hatás. Az NV elment a Maxwellel egy irányba, amiből a Pascal visszatér a fermis alapokhoz. Nem azért, mert ez a jó, hanem, mert az AMD vétójoga kikényszerítette. -
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12947
üzenetére
Az NV-nek nem kell ebbe beszállnia. A fejlesztők az NV segítsége nélkül is elmondhatják a tapasztalataikat. Továbbra sem fogják tudni, hogy NV-n mennyi az egyes RT formátumok exportjának ciklusigénye, vagy mennyi a mintavételi sebesség az egyes textúraformátumoknál az egyes szűrésekhez, stb. Ugyanakkor azt leírhatják, hogy kinek melyik formátum vált be, és ilyen formában ez már egy kiindulási alap más számára. Ezek újra optimalizálást hozhatnak a PC-nek. Erre viszonylag nagy igény van, mert az NV nem mondja meg, hogyan lehet optimalizált kódot írni a GeForce-okra, ami nem fog megváltozni, de a fejlesztők rengeteg tapasztalatot megoszthatnak, így nem is szükséges az NV-vel kapcsolatot teremteni a fejlesztéshez.
-
Abu85
HÁZIGAZDA
válasz
jacint78
#12948
üzenetére
Nem azért teszik, hogy a konkurencia kezére adják. Az a cél, hogy optimalizált játékok szülessenek. Az elmúlt évben a hibás optimalizálásokért az felelt, hogy a GameWorks miatt egy rakás leképezőre vonatkozó optimalizálást PC-be nem lehetett szállítani. A játékosok pedig szívtak a veszettül növekedő gépigénnyel. A nyílt forráskód az egyetlen megoldás erre a problémára, mert ha az effekt ne adj isten nem kompatibilis a leképezővel, akkor az effekten könnyen lehet módosítani. A zárt forráskód azonban ezt lehetetlenné teszi, így a leképezőt kell hackelni, amitől a PC-s portok sokszor rosszak lesznek. A cél tehát a PC-s optimalizálás.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#12946
üzenetére
A Radeon SDK régebbi, mint a GameWorks. A GPUOpen sem más, csak megváltozott a licenc, így mostantól, ha az AMD-től visz valaki egy effektet, akkor arról nem kell az AMD-nek szólnia, illetve a módosításokat közzéteheti a GPUOpen portálon.
A fejlesztők régóta segítik egymást azzal, hogy bizonyos dolgokat a különböző rendezvényeken megosztanak. A GPUOpen célja, hogy ezt magasabb szintre vigyék.
A régi Radeon SDK-val az is gond volt, hogy a létező kutatások mikor kerültek visszaírásra. Például az Intel az optimalizációkat mindig gyorsan elkészítette, de volt olyan, hogy az csak egy év múlva került bele a Radeon SDK-ba. A GPUOpennel az Intel az optimalizálásait rögtön publikálhatja. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12919
üzenetére
Kétféle képi hibáról írnak az AMD fórumán. Az egyik az Eyefinity esetében fellépő probléma, de ott már leírták többször is, hogy két külön interfészt nehéz szinkronizálni belsőleg. Ahhoz, hogy a szinkron Eyefinity mellett is teljes legyen HUB-ot kell vásárolni. Ez szinkronizálja a három kimeneti képet.
A másik képi hiba amiről szokott szó lenni az a Fury-vel kapcsolatos, de ezt még nem sikerült reprodukálnia senkinek. Egyelőre úgy néz ki, hogy ez nem driverhiba, hanem kompatibilitási és csak bizonyos alaplapokban jön elő. Ahhoz, hogy ezt javítsák kell egy olyan teljes konfig, amin előjön. Aztán az alaplapgyártónak majd ki kell adnia rá egy új BIOS-t, vagy ha ez nem megoldható, akkor kell valami hack rá.
-
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12908
üzenetére
A WHQL-re eleve hibátlan olyan meghajtókat küldenek, ami biztosan átmegy. Csupán azért, mert ha kifizeted az tesztet, de nem kapod meg az aláírást, akkor az kidobott pénz.
Amit ti vártok, az az hogy tuningra is teszteljenek. Na most ezt se a WHQL, sem a gyártói tesztcsomag nem fogja megtenni. Erre hiába is vártok. -
Abu85
HÁZIGAZDA
Teszteletlen verziót senki sem ad WHQL-re. Az túl nagy kockázat lenne, mert az MS nem ad vissza pénzt. De a gyártók tesztcsomagjának csak egy részét képzik csak a WHQL tesztek. Maga a WHQL nem egy zárt dolog. Teljesen specifikálva van az egész, így a gyártók a laborjakon belül is ellenőrizhetik, hogy a meghajtó átmenne-e vagy sem. Ha átmenne elküldik és az MS aláírja.
Sosem megy el olyan driver, amely legalább a WHQL tesztcsokron ne lett volna tesztelve, viszont a teljes tesztsor nem biztos, hogy lemegy a WHQL drivereken. Túl sokáig tartana. Persze vannak meghajtók, amelyeket lehúzzák a teljes tesztsort, mint például az új Crimson.
-
Abu85
HÁZIGAZDA
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- 0% THM 3 havi részlet! Beszámítás, 27% áfa, Sapphire Nitro+ RX 9070XT 16GB készletről
- ÁRGARANCIA!Épített KomPhone Ryzen 5 5600X 16/32/64GB RAM RTX 4060 8GB GAMER PC termékbeszámítással
- Bomba Ár! Lenovo ThinkPad L14 - Ryzen 5 I 16GB I 256SSD I 14" FHD Touch I HDMI I Cam I W11 I Gari!
- Bomba ár HP X360 11 G5 - Intel 4020 I 4GB I 128GB SSD I 11,6" HD Touch I Cam I W11 I Garancia!
- DELL PowerEdge R630 rack szerver - 2xE5-2650v3 (20 mag / 40 szál, 2.3/3.0GHz), 32GB RAM, 55992Ft+ÁFA
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest