Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A Fermi volt az utolsó generáció, ahol a túlterhelés valós problémát jelenthet. Nem feltétlenül kell hardveres védelem és hardveres rendszer. Lehet szoftveresen asszisztált hardveres konstrukció. Ez is stabil marad, csak picit nagyobbat esik az órajel a kelleténél.
A Fermi is stabil marad már, mert a driverbe van egy szoftveres rendszer építve. Ha túlterhelést érzékel, akkor levágja az órajelet elég alacsonyra. Fagyni egyik sem fog. Arra már be vannak építve a rendszerek. A kérdés, hogy mennyire lesz jó a folyamatos órajelállítás.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Kész. Rárepültek a Titan-GTX 960 harcára a W3-ban.
Egyébként azt mondják, hogy a 352-es driver sorozatban egyszerűsítették a shader fordítót. Ez például lehet az oka annak, hogy nem meg annyira jól a Kepler. Érdemes lenne egy régebbi driverrel kipróbálni, ahol még a régi fordító volt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az a baj a GameGPU-val, hogy egy olyan driverrel teszteltek, amelyben nincs Witcher 3 profil. A 15.4.1-ben van, ami elérhető volt már május első felében. A 15.4-es áprilisi, és ezt használták. Ezért nem hozza ez a teszt azt, amit más tesztekben látsz a 15.4.1-es driverrel, amibe már raktak profilt pont a játékra készülve.
[ 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
#5667
üzenetére
Sajnos semmivel sem jobb egyik AFR technológia sem. Ahol az egyik működőképes ott a másik is, de ahol az egyik nem az ott a másik sem. Erre jön a változás a low-level API-ban, hogy a fejlesztő írja meg, hogy miképp működjön, és ne lehessen a driverekből kényszeríteni egy alig működő megoldást. Ez majd nagy változást fog hozni, mivel újra megéri multi-GPU-ra gyúrni, hiszen a gyártók kontrollja teljesen megszűnik a rendszer felett és átkerül a program irányítása alá a teljes vezérlés.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
PCLabs teszteket sosem néztem. Korábban is mondtam, hogy az a tesztmetodikájuk, hogy a gyorsaság érdekében több konfiguráción nyomják párhuzamosan nem feltétlenül jó. Még ha tök ugyanaz is két konfigban a VGA-n kívül minden, akkor is lehetnek eltérések a szoftverben. De ettől te hihetsz nekik, de a PCGamesHardware jellemzően jobb konstrukcióban tesztel, és jóval közelebb állnak más oldalakhoz az általuk közölt eredmények, mint a PCLabs-osoké.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az XDMA-nak nincs köze az AFR profilhoz. Az XDMA kizárólag azt teszi lehetővé, hogy 4K-ban is egyenletes legyen az AFR frame pacing, és ne legyen tele mikroakadással, mint a hidas megoldásokkal:
Semmi más jelentősége nincs szoftveres és profilozási szempontból. Low-level API-val lehet más előnye is az XDMA-nak, de AFR-ben csak ennyi.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A low-level API-nál azt is figyelembe kell venni, hogy mit csinál a program. WDDM 2.0 alatt nem szükséges tudnia, hogy mennyi VRAM van a kártyán, mert ott a virtuális memóriára vonatkozó GPUMMU mód. Ha a program mindenképpen fizikai címzésre akarja kényszeríteni magát, akkor kell tudnia a hardver VRAM kapacitását. Ez lehetséges, főleg akkor, ha nem akarják, hogy az alkalmazás csak Windows 10-en fusson. De többen mondták már, hogy 2016 végére inkább bevállalják a Windows 10 only dolgot, mert a WDDM 2.0 túl sok előnyt kínál a GPUMMU-val és az IOMMU-val.
(#5814) Szaby59: A low-level API igazából mindegy. A WDDM 2.0 kínál olyan előnyöket, amelyekkel a VRAM használata a mainál lényegesen hatékonyabb lehet, és igazából lesz is. Mindegy, hogy DX12, Vulkan vagy Mantle, mindegyik rendszerből kihasználható a WDDM 2.0 extrája. A GPUMMU rendkívül hasznos, mert igazából a VRAM működése sokkal jobban fog hasonlítani a rendszermemória működéséhez. Az IOMMU pedig még egy lépés előre, mert igazából az adatnak nem is kell a VRAM-ban lennie, egyszerűen olvashatja és írhatja azt a hardver a rendszermemóriában is. A különböző linkelési lehetőségek is nagyon jók. Például egy GPU-val minden különösebb probléma nélkül olvashatod egy másik GPU memóriáját, sőt írhatsz is abba. Ezek a mai limitált modellhez képest nagyságrendi előrelépések. Elsődlegesen ott fog ez érződni, hogy jóval több szabad VRAM-od marad, amit persze elhasználhatsz másra. Tehát önmagában a mai pazarló rendszer ki lesz ütve.
(#5826) gbors: Hagyományos fizikai címzéssel a fejlesztő is képes beleírni az alkalmazásába, hogy a GTX 970 esetében 3,5 GB gyors memória van és 0,5 GB lassú. Tehát ez egyedi szinten lekezelhető. GPUMMU mellett nem lehet kezelni, mert ott az OS jelzi a rendszernek a VRAM méretét. A user-mode driver csak arról dönt, hogy az allokációhoz 4 kB-os vagy 64 kB-os lapméret legyen használva.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A WDDM 2.0 alatt megmarad a régi WDDM szegmentált fizikai címzése. Ez egy legacy funkció lesz, de maga a low-level API meg fogja engedni, hogy a fejlesztő megírja az implementációt a programban a szegmentált fizikai címzés működéséhez. A kezdetekben valszeg ilyen motorok fognak születni, mert túl kevés lesz a Windows 10 felhasználó WDDM 2.0 only játékokhoz. Ilyen esetben a fejlesztőknek lényegében ugyanolyan lehetőségei vannak a VRAM vezérlésére, mint ma a kernek drivernek, persze a közvetlenebb elérés miatt a WDDM ellenőrzésre vonatkozó funkcióit el lehet felejteni, tehát a sebesség jobb lesz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Igen, ezért írtam hagyományosat. Bár lehet, hogy ez így tényleg félreérthető volt.
(#5832) mlinus: Várható volt. Folyamatos regiszterhiánnyal küzd a Kepler, amire azért illik hozni egy fordított.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#5834
üzenetére
Én a GTX 760-en a 25-30%-os kihasználást nem mondanám magasnak. Ezt szerintem fel lehet tornázni a GCN-es hardverek 35-40%-os szintjére, vagy a közelébe. Az, hogy egy program mit ír semmit sem jelent. A belső kihasználás számít, amit mondjuk GPUView-vel tudsz ellenőrizni, vagy GPUPerfStudióval. Ettől a 99%-ot oda fogja írni rá az olyan kamuprogram, mint az afterburner és bármi hasonló.
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
#5843
üzenetére
Az MSAA részletességét a HairWorksre vonatkozóan csökkenteni kérdéses. Így sem elég a 8xMSAA opció. 16x lenne az ideális.
A HairWorks esetében semmilyen minőségvesztést nem eredményezne a tesszellálás 64x-ről 16x-re csökkentése és két-háromszorosára gyorsítaná az effekt sebességét. Ez sem lenne optimalizálás, de gyakorlatilag minőségvesztés nélkül kapnál extra sebességet, ami kezdetnek jó. A következő lépcső egy analitikai élsimítás lenne, ami kiváltaná a HairWorksre futtatott MSAA-t, mert ez valószínűleg olcsóbban jobb minőséget eredményezne pusztán a célirányos jellege miatt.
Ezután esetleg el lehetne gondolkodni az önárnyék és az átlátszóság problémáján, amivel a HairWorks újra -20-30%-os teljesítménybe kerülne, de a minősége a mostani szinthez képest nagyban megugrana.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
#5846
üzenetére
Az a baj, hogy a haj annyira vékony geometria, hogy az nem így működik. Elképzelhető, hogy még 16 mintavételi pontnál is úgy átmegy egy haj a pixelen, hogy egyetlen mintavételi pont sem "döfi át". És onnantól kezdve rögtön rossz az adott pixel színe. Ezért nem adnak rá külön opciót, mert tudják, hogy a 8x is kevés.
Az anizo esetében vannak problémák. Nem minden felülettel kompatibilis, így előbb ezeket kell megoldani, hogy használható legyen.
[ 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
#5852
üzenetére
Pedig a fejlesztő most a legkevésbé okolható azért, hogy az NV milyen paraméterezéssel kéri szállítani a GameWorks csomagokat. Ezt ők határozzák meg.
Szerinted az AMD miért tehette meg, hogy letiltatja a TressFX-et a Lichdom januári frissítésében? Egyszerűen szerződésben megvan hozzá a joguk. Ott sem a fejlesztő a hibás, de ha nem teszi meg, akkor olyan kötbérrel tud kiszállni a szerződésből, hogy azonnal tönkremennek.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem értitek a gondot. A gyártók olyan szerződéseket kötnek, amellyel az adott partnernek gyakorlatilag nincs reális kiszállója. Még ha a szerződésnél át is beszélik: jó persze erre nem fog sor kerülni, mert aranyosak vagyunk, akkor is szerződés világosan fogalmaz. Gondoljatok bele. Az AMD fogja magát és ismét hirtelen felindulásból letiltatja a TressFX-et, vagy akármelyik effektet a Star Citizenben. Nem fog a CIG ellenkezni, mert túl drága lenne. Inkább megteszik, amit kérnek.
Ez az egész ipar problémája. Még ha az iparért is akarnak dolgozni a szerződésekben kibiztosítják magukat és ha elpattan a húr, akkor itt tök szabványos effektek lesznek Radeon és GeForce only megoldások szinte minden játékban. Melyikőtök akar ilyen jövőt?
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
stratova
#5866
üzenetére
A saját felhasználóid megszopatása a következő szint ebben a nem túl fényes jövőben. Ez alapvetően sikeresnek mondható, hiszen nem egy ember védi azt az álláspontot, hogy a saját PC-jén legyen egy effektnek -20-30%-os deficitje az amúgy reális -5-10%-os helyett, csak azért, mert biztosan jót akart ezzel az adott gyártó.
[ 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
#5869
üzenetére
És lám kiderült, hogy ezért tudják megcsinálni, mert ugyan felfogod, hogy konkrétan veled csesznek ki, de egyszerűen elfogadod, hogy ez így jó, és hogy ez egy szép jövő lesz. A teljesítményigényes és gyenge minőségű effektek jövője. Eközben keresel minden lehetőséget, hogy kontráz, aminek konkrétan semmi köze ahhoz, hogy a HairWorks jóval több teljesítményvesztést okoz annál, mint amennyit igazából kellene, hogy okozzon.
Nem értem mi az, amitől egy felhasználó annyira jól jár, hogy védeni kell a mesterségesen magasra pakolt gépigényt? Többet költhetsz gépre? Ezt megteheted úgy is, hogy az adott program és effekt úgy fut ahogy kell.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#5874
Abu85
HÁZIGAZDA
Malibutomi
#5872
Abu85
HÁZIGAZDA
válasz
Malibutomi
#5872
üzenetére
A D3D driver egy komplex probléma. Amit sokan nem vesznek figyelembe, hogy itt nem csak a megjelent játékokat nézik a cégek, hanem a megjelenés előtt állókat is. Alapvetően az Intel D3D drivere a legjobb. Messze az látszik a legrosszabbnak a tesztekben, de reálisan felhasználható processzoridő jut a programnak. Az NV drivere a másik véglet. Iszonyatosan zabálja az erőforrást, míg az AMD drivere a kettő közötti átmenet.
Hogy ez miért fontos? Bizonyos konzolra írt játékokban az AI és a fizika komplexitása a PC-s játékokon túlmutat. Viszont a D3D driverek miatt ezeket nem lehet PC-re portolni, mert túl sok erőforrást elvesznek a driverek. Ezért kér a Microsoft thin drivert, mert a grafikát képes skálázni a fejlesztő, de az AI-t és a játékmenetre ható fizikát nem.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Halo 3 azért nem jött PC-re, mert nem volt elég processzoridő a driver szálak mellett. Ekkor volt az, hogy az MS összehívta a cégeket, hogy ez így nem lesz jó, mert hiába jönnek a jobb processzorok a reálisan felhasználható processzoridő az egyre agresszívabb driverek mellett inkább csökken. Ezért nem látsz AI innovációt évek óta. Egyre kevesebb rá a büdzsé.
Szinte mindegyik exkluzív ls komolyabb konzolos játék AI-ja és fizikája túlmutat a PC-s szinten. Az AI szempontjából különösen durva a The Last of Us és a Dragon's Dogma. A fizika szempontjából az Uncharted 3.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#5880
Abu85
HÁZIGAZDA
Malibutomi
#5875
Abu85
HÁZIGAZDA
válasz
Malibutomi
#5875
üzenetére
Ez egy ballansz probléma. Mennyi processzoridőt igényel a játék és mennyit vesz el a driver. A mai multiplatform címek szándékosan rendkívül butítottak a játékmenet szempontjából, hogy maga a szimuláció kevés processzoridőt igényeljen, és az NV driverének is legyen elég szabad erőforrás. Az AMD és az Intel drivere ezzel biztosan jó lesz, mert kevesebb szálat futtatnak.
(#5877) Szaby59: Ez a lényeg. Azért kapcsolod ki, mert nagyon zabálja a géped, pedig valójában ugyanehhez a minőséghez nem kellene ennyi veszteség. És akkor már átgondolnád, hogy mást kapcsolj ki például.
A Frostbite 3 egy deferred MSAA technikát használ. Minden render targetet leszűr, vagyis más játékokhoz mérten az MSAA munkája 4-5x-ös.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Microsoft már magára vállalta a felelősséget. Amikor bemutatták a DirectX 12-t, akkor elmondták, hogy DX11-ben használt modell egy totális tévút, és mindenkit lebeszélnek azóta róla. A probléma egyébként jelentős. Minden évben azt tapasztalták a fejlesztők, hogy jönnek az új processzorok, és eközben csökken az elérhető processzoridő. Ez nem jó irány sehogy sem.
Ha olvastad, amit írok, akkor az Intel drivere ebből a szempontból a legjobb. Az AMD a két végpont között lavírozik.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
stratova
#5886
üzenetére
A full deferredet semmiképpen, mert a PBS-re az a legjobb. Igaz, szétzabálja a sávszélt, de megvan a maga előnye.
Low-level API-nak annyi az előnye, hogy eltűnik a driver. Tehát a program a teljes processzoridőt megkapja és szabadon felhasználhatja.
A problémát maga a driver okozza. Ezért nincs kernel driver DX12 alatt. Minden új API így oldja meg ezt a gondot. Ez az MS megoldása. A DX11 meg így marad. Nem tudnak vele mit kezdeni.A példákkal az a baj, hogy az MS is itt hasalt el. Lefuttatták a teszteket és szuper volt. De egy játék nem csak rajzolás, hanem szimulációs munka is, és ott már negatívba megy a sebesség. Ezért kért meg mindenkit az MS egy éve, hogy ne használják. Inkább skálázzák le a grafikát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Minden multiplatform játékot multiplatformnak terveznek. Veszik minden esetben a legszűkebb keresztmetszetet és arra terveznek. Ha a PC ebben benne van, akkor tudják, hogy a szimuláció korlátozott, mert kevesebb valóban felhasználható processzoridő áll rendelkezésre. Tehát ez már be van tervezve.
A Halo 3 a Microsoft címe, ahogy a Halo és a Halo 2 sem jött Sony gépekre, úgy a Halo 3 sem volt tervben. De Windows-ra ki akarták adni, mert az első két rész is jött PC-re, de nem volt meg az erőforrás hozzá PC-n. Az AI-t kellett volna butítani, de nem tették meg. Aztán mivel a processzoridő évről-évre csak csökkent, így lelőtték a projektet.
A Capcomtól tudom, hogy hasonlóan járt a Dragon's Dogma is. Talán egy remasterre van esély.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem szerintem, hanem a Microsoft szerint.
Szerintem az egész rendszer úgy ahogy van rossz, ha a gyártók nem képesek betartani a szabályait. Gondolom ezért veszi el a kernel drivert a Microsoft a DirectX 12-ben, hogy a gyökerénél tűnjön el az alapprobléma. Ezzel az a gond is eltűnik, hogy a kevés valós processzoridő miatt nem lehet komoly AI-val konzolra tervezett játékokat PC-re portolni.Az is fontos, hogy az első dolog, ami fejlődni fog a DX12-vel az az AI. Megvannak az algoritmusok. Nem állt le a fejlesztés, csak nincs meg a számítási kapacitást hozzá PC-n, de nem a hardver, hanem a grafikus driverek miatt.
Kevin Floyer-Lea low-level leírásában is ott van ez: "Ability to increase the CPU budget for other systems like AI".[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A multiplatform játékokat eleve úgy tervezik, hogy minden célplatformot figyelembe vesznek, és az egyes szempontok szerint a leggyengébb platformelemekre lőnek. A DX11-ben a PC-n van a legkevesebb befogható processzoridő, így a szimulációt ehhez igazítják.
Nem az NV a probléma, hanem a DirectX 11 és az agresszív kernel driver. Ezért kezeli a Microsoft ezt a problémát úgy a DirectX 12-ben, hogy eltünteti a rendszerből a kernel drivert.
Az NV-nek nyilván az a lényeg, hogy a grafika legyen jó, az nem számít, hogy a játékmenetben az előző generációs konzolcímek is lealázzák a PC-t. Abban viszont igaza van a Microsoftnak, hogy a grafika skálázható, míg az AI nem, tehát ha egy játékot nem tervezel úgy, hogy a PC-t is számításba veszed, akkor az probléma lesz a portolásnál.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Miben? Mert a hozzáférhető processzoridőben sajnos az. Hiába vannak erős hardvereid, ha nem nyúlhatsz büntetlenül hozzájuk.
Az nem úgy működik. Valójában az a processzoridő hozzáférhetetlen, mert a meghajtó soros munkára kényszeríti a programot. Hiába van ott elméletben, ha nem férhetsz hozzá.
A user mode driver egy shader fordító, illetve egy alapvető vezérlőcsomag. Nem látja el a kernel driver feladatát. A fejlesztőnek kell megírnia azt a programon belül. Nyilván ez is hozzájárul ahhoz, hogy nő a processzor kihasználásának hatékonysága, mert eltűnik minden olyan rendszer, amit nem profilozhatsz. Ma ha valami nem működik, nem tudnak a fejlesztők beleírni a driverbe. Ez okoz sok gondot. A jövőben ez nem lesz gond, mert lényegében nem lesz driver, a saját kódod pedig tudod javítani.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
[link] - ez segít megérteni, hogy miért nem hozzáférhető az a temérdek processzoridő.
Sajnos ezt nagyon rosszul érted. A user mode driver valójában csak allokációval foglalkozik. Eldönti, hogy a programnak 4 vagy 64 kB-os lapokat foglaljon le például, illetve végzi a valós idejű shader fordítást. Az ami régen a kernel driver feladata volt, mint a hazárdok kezelése vagy például a memóriamenedzsment teljesen átkerül a programba. A fejlesztő fogja ezt vezérelni. Ezért hívjuk ezeket explicit vagy low-level API-knak, mert a munkát a programozó határozza meg és nem egy driver. A fentebb linkelt videó erre is kitér.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Miért lenne irreleváns? Az iparág két legjobb fejlesztője magyarázza, hogy mi a gond a DX11-gyel. Ők a GAB tagjai, pontosan tudják, hogy mi a helyzet. Azért ne őket hibáztasd, hogy azt mondják amit én, valószínűleg azért teszik, mert 15-25 éves tapasztalatuk birtokában képesek megállapítani, hogy mi a probléma a DX11-es modellekkel.
Mert a driver soros feldolgozásra kényszeríti a rendszert. Ez a nagy problémája a rendszernek. Hiába van ott még 7-9-11 szabad mag a soros feldolgozás miatt nem érhetők el.
Tökéletesen ábrázolták, te értelmezed rosszul. A kernel driver eltűnik, ahogy az MS is lerajzolta. Nem veszi át a feladatát a user mode driver. A program lesz, ami átveszi a munkát. A videóban erről is beszélnek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Szándékosan belinkeltem azt a részt, ahol erről beszél.
Ez egyszerű. Attól, hogy nincs kernel driver még a feladatokat el kell végezni. Az alkalmazásnak explicit elérése van a GPU felé, de ez csak azt jelenti, hogy meghatározhatják, hogy mit csináljon a hardver, de a parancskiadáshoz már szükséges egy driver, ami például lefordítja a szoftver queue-t a hardver nyelvére, stb. Ez a user driverben fog látszódni, még akkor is, ha az alkalmazásban van rá a kód.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ezért lenne jó, ha végignéznéd a videót és megértenéd, hogy miért érinti. Miért baj, ha soros feldolgozásra kényszeríti a meghajtó a teljes rendszert.
Nem az alkalmazás fogja ezeket elvégezni. A user mode driver csak a hardver felé irányuló fordításokat csinálja.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem is kell, hogy összekapcsolva legyenek, bár szinkronizáció azért van. De elég, ha egy rosszul kialakított API és a kernel driver nem engedi a programszálakat hozzáférni az amúgy szabad erőforrásokhoz.
Ez tudom, hogy nagyon mellbevágó dolog, hogy a PC ennyire pazarló platform lett, de ez van. Viszont nem véletlenül alakult úgy, hogy két év alatt egy komplett reformot végigvittek az érintettek a teljes rendszeren.Amikor arról beszélünk, hogy a DX12 micsoda előrelépés a DX11-hez képest, akkor az jön elő, hogy milyen jó ez a DX12. Valójában ezt úgy kellene felfogni, hogy milyen rossz a DX11. A DX12 csak rendbe hozza, amit már rég rendbe kellett volna hozni.
[ 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
#5926
üzenetére
Azóta csúnyán eltelt 7 év. 7 éve jó volt, ma semennyire nem az. Valószínűleg 7 év múlva a DX12-re is azt mondjuk, hogy limitál, és jön a következő lépcső. Biztosan megmondom most, hogy a DX12 sem tart örökké. De az elkövetkező fél évtizedre jó lesz. Addig pedig van idő újat fejleszteni.
[ 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
#5964
üzenetére
És most hasonlítsd össze az EA és a CDPR készpénzállományát és fejlesztői lehetőségeit.
De amúgy ja egyetértek, a Dragon Age: Inquisition-t grafikailag nem sikerült lenyomni, csak ez pénzkérdés inkább, mintsem technikai.Egyébként nem vagyok benne biztos, hogy az elkövetkező két évben bárkinek is esélye lehet a PC-n az EA által követett újszerű fejlesztési modell mellett. Egyszerűen a váltásokra marha sok pénzt mozgósítottak, és marha jó a szakemberi gárda a Frostbite mögött. Leghamarabb a Square Enix tudja őket befogni, de ők is lassabban kapcsoltak, és alapvetően több erőforrást kell majd mozgósítaniuk.
[ 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
#5979
üzenetére
A gépigényre gyúrni az EA-nek megint egyszerűbb. A Dragon Age: Inquisition a Frostbite aktuális verziójának utolsó nagyobb címe. Ez azt jelenti, hogy a 3-as főverzió már eléggé optimalizált, hiszen az első játék óta másfél évet lehetett polírozni. A Red Engine új, szinte polírozás nélküli rendszer.
Majd az EA is át fog állni a következő nagyobb Frostbite frissítésre. Talán nem 4 lesz a neve, de az NFS és a SW: Battlefront már ezzel jön.[ 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
#5982
üzenetére
Én Witchert az első rész után csak így veszek. Az Enhanced patch mellett kiszedik a bugokat, és jó lesz. Az első részt egy nagy bug miatt be se tudtam fejezni az Enhanced patchig, akkor is újra kellett kezdenem. Szóval a W2-nél már tanultam ebből és csak később vettem meg. Most is ugyanígy teszek. Mire lesz Enhanced verzió, addigra az ára is a fele lesz.
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
#5990
üzenetére
A Vulkanról még felesleges beszélni, mert a base specifikációk sincsenek véglegesítve. Ettől függetlenül egy hasonló bekötési modellt használ, mint a DX12, csak más paraméterezéssel, és több emulációs lehetőséggel. De a véglegesítésig ezek változhatnak. Láthatod, hogy a DX12 modelljét négyszer módosítottak, mire végleges lett.
A DX12 végleges bekötési modelljével (amire még mindig rá kell mondani az áment, de szinte ki van zárva, hogy változik) a TIER1 egy emuláció lett. Azt támogatja az Intel Gen7.5, Gen8 és az NV Fermi. A TIER2-t a Kepler és Maxwell, míg a TIER3-at a GCN.
Az opcionális funkciók nincsenek véglegesítve, mert kevés volt rá az idő. A fejlesztők használhatják, de a Microsoft kiadta nekik, hogy vigyázzanak vele, mert ha év végén jön egy végleges verzió és változik, akkor a kiadott program nem fog működni.
Egyébként igazából a ROVs egy mutex zárolás a rendszerben. Olyan mint az Intel PixelSync, a GCN ezt tudja támogatni, mert a GDS-re írható egy olyan implementáció, amely zárolja a folyamatokat a megfelelő megérkezéséig. Ezt OpenGL-ben már támogatják. A Conservative Rasterization igazából eltérő interpolációt igényel a hardverben. De mivel a GCN szoftveres interpolációt használ már évek óta, így az egész támogatás csupán a fordítón múlik és nem a hardveren. Eleve az interpoláció a GCN-en annyi, hogy a CU-nkénti 64 kB-os LDS-ből 32 kB-ban ott vannak az interpolált háromszögadatok. Annyi interpolációs rendszert írsz rá a shadereken keresztül, amennyit akarsz. Most csak egy van, de például a Mantle új verziójában maga a fejlesztő is megírhatja a saját interpolációs rendszerét.A Wikipédiás táblázat teljesen téves. Nincs olyan, hogy hUMA a DX12-ben, az egy HSA specifikáció
. IOMMU-van a WDDM 2.0-ban. És azt sem tudja támogatni egyetlen dedikált GPU. Emellett azt hiszik, hogy a TIER szinten az egyes eljárásokon a bekötésre vonatkoznak. Hát nem.A DX12-ben és a WDDM 2.0-ban nincs minden opcionális rendszer véglegesítve.
Ami véglegesítve van arra a támogatás ilyen:
Bekötési modell fentebb, nem írom le újból.
WDDM MMU modell: emulált: Intel Gen7.5, NV Fermi, dedikált: Intel Gen8, NV Kepler és Maxwell, AMD GCN
WDDM GPUMMU: minden dedikált GPU
WDDM IOMMU: csak APU: AMD Kaveri, Carrizo vagy Intel Broadwell, Skylake
Aszinkron Compute: AMD GCN, NV Maxwell (kivéve a GM107). Az Intel Gen8 támogatja, de az Intel mondta, hogy náluk ez lassulást okoz, így nem fogják engedélyezni.
SAD4: mindenen emulált, kivéve a GCN, ott ez dedikált utasítás
Aszinkron DMA: AMD GCN, NV Maxwell (kivéve a GM107). Emellett számos korábbi Quadro VGA-n ez működni fog, mert a Kepler óta van két DMA az NV GPU-ban, de abból a GeForce-okban egy mindig le lett tiltva.
Atomi számláló: mindenen emulált, kivéve a GCN, ott ez dedikált utasításVéglegesítésre vár még a maradék opcionális funkciók és a WDDM hard preempció. Ezeket az elkövetkező egy évben tervezik befrissíteni a Windows 10-be. Lehet, hogy apránként, lehet, hogy egyszerre.
A bekötési modell gyakorlati haszna csupán az, hogy mennyire limitálja az adott modell az erőforrás-használatot. Kvázi ennek a jelentősége az lesz, hogy mennyi effekt kerülhet egy játékba egyszerre. Itt főleg compute effektre kell gondolni, mert leginkább az UAV-k száma lesz a limit. Ma nagyjából 4-7 compute effekt van egy játékban, de a jövőben ez a szám növekedni fog, tehát végeredményben az a cél, hogy a limitáció tulajdonképpen csak a memória legyen, és ne más.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5992
üzenetére
Nem. A DirectX 12 az DirectX 12. A feature level innentől kezdve nem komoly dolog, mert nagyrészt csak opcionális funkciókat tartalmaz, zömében nem véglegesítetteket.
A DX12-ben a legfontosabb újítás szoftveres, vagyis az overhead csökkentése. Ez a kulcstényező és nem más. A másik fontos újítása az asszinkron compute, ami a GPU-limit ellen küzd. Ezzel lehetőség van ezeket a masszívan párhuzamos lapkákat tényleg párhuzamosan dolgoztatni, mert nem csak sorban kerülhetnek rá feladatok.A bekötési modell az azért nagyon fontos és azért van folyamatosan kiemelve a fejlesztők és a Microsoft által, mert ez határozza meg az API-nak azokat a képességeit, ahogy a hardvert elérheti. A GPU-k nem olyanok, mint a CPU-k, hogy írsz rá programokat és azok futnak. Itt amellett, hogy van memóriájuk, még masszív limitációkkal írhatók programok rá. Ezért került bevezetésre a DX12-ben ez az új bekötési modell, hogy a fejlesztők ahogy egyre komplexebb programokat írnak, ne fussanak ki az erőforrásokból. A hosszabb távú cél igazából az, hogy a fejlesztőnek csak arra kelljen figyelni, hogy a GPU-nak van x GB memóriája és azon belül annyi erőforrást hoznak létre amennyit abba belefér. Ma ez óriási limit, mert az API nem enged meg akármit, még akkor sem, ha a hardverek jók lennének. Ez pedig akadályozza azt, hogy végeredményben hány effektet írhatsz bele az adott játékba. Hosszabb távon ezt az állandó kompromisszumkényszert akarja leküzdeni a Microsoft ezzel az átdolgozott DX12-es bekötési modellel. Egyszerűen, ha a fejlesztő megálmodik valamit, akkor csinálja meg, ne azért legyenek kidobva dolgok a programból, mert kifutott az API által megengedett erőforrásokból.
A véglegesített specifikációk tekintetében a GCN egyes verziói egységesek. A nem véglegesített opcionális specifikációk esetében meg kell várni a véglegesítést.
Az overhead biztosan csökken, az független a feature level szinttől. Ezt két dolog határozza meg. Az egyik a parancsok párhuzamos beírása a parancspufferekbe, ami egy szoftveres funkció, vagyis igazából nem igényel semmilyen komolyabb dolgot a GPU-n. Jó persze kér egy modernebb hardvert, de az elmúlt hét évben megjelent GPU-k elméletben tuti jók. Amelyik cucc kap DX12 drivert ott ez a funkció megy. A másik a bekötési modell, ami szintén meghatározza az overheadet. Ebból a szempontból a TIER1 jár a legnagyobbal, mert az emuláció. Nem rossz így sem, de érezhető lesz. A TIER2 már bindless, tehát eléggé alacsony a többletterhelése. A TIER3 pedig explicit bindless, vagyis nincs többletterhelé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
#85552128
#6027
üzenetére
Ahogy írtam korábban, alapvetően a bekötési modell messze a legfontosabb. Mivel ez határozza meg, hogy mennyi erőforrás áll rendelkezésre a fejlesztőknek, vagy másképp fogalmazva mennyi effektet képesek engedélyezni egy játékon belül. Például az idén érkező DX játékban a TressFX mindenkinek a haján rajta lesz, de ezt a módot csak akkor aktiválja, ha TIER3 a bekötési szint. Alacsonyabb szinten csak a főszereplő hajára lesz korlátozva.
Azért tervezte ennyi ideig a bekötési modellt a Microsoft, hogy az mindenkinek jó legyen. Szépen lehessen használni az Xbox One képességeit, miközben ez a PC-s portolást ne nehezítse. Egyszerűen az effekteket alacsonyabb szinten le lehet tiltani, és mindenki boldog.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
#6030
üzenetére
A TIER3-as bekötési szint alapvetően egy skalár processzort igényel a multiprocesszorba, hogy a bekötés ne a mintavételezőbe, hanem magába a multiprocesszorba történjen. Egy ilyen rendszer már eleve garantálja azt, hogy a bekötés korlát nélküli, mert nem egy fixfunkciós egység gondoskodik a meglévő erőforrásokról, hanem egy teljesen programozható. Alapvetően a GCN minden bekötést egységesként kezel. A hardver belül nem különbözteti meg ezeket, így mindegyik létrehozott erőforrás írható, olvasható, akár egyszerre is, és gyorsítótárazható. Az API-kkal kapcsolatos különbségeket majd a meghajtó lekezeli.
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
#6030
üzenetére
Mások a célok itt. Az új API-knak a korlát nélküli bekötési módjai azt teszik lehetővé, hogy a programozók a hardver használatánál és az algoritmusok kialakításánál szabad kezet kapjanak. Nyilván korlátozza a lehetőségeket, ha hardveres vagy szoftveres szempontok miatt nem tudják létrehozni a szükséges erőforrást a hardveren belül. Ez megakadályozza az innovációt.
A GameWorks egy más céllal született. Azzal, hogy az NVIDIA kontrollálhassa az adott játék igényeit, és teljesen elfojtsák az innováció lehetőségének a csíráját is.
Nagyon érdekes az AndroidWorks. Az NV-nek Androidon érdeke az innováció, és nyílt forráskódú, szabadon módosítható GameWorks effekteket adnak a GitHubra feltöltve, ellentétben a PC-s rendszerrel.[ 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
#6033
üzenetére
Ez a következménye annak, hogy az API-k felnőttek a hardverek tudásához. Az ipar ezzel a lehetőséggel szabadon fejlődhet.
A bekötési modell fejlesztése alapvető lehetőséget ad, hogy egy effekt minősége jó legyen. A TressFX előnye ma, hogy messze ez kínálja a legjobb leképzési minőséget a hajra és a szőrre, mert tartalmaz OIT-t, ami ennek a koncepciónak az alapja, hiszen mindenképp abból a hajtincsből kell a színminta, amely legfelül van. Viszont a TressFX 2 UAV-t igényel a működéshez, vagyis ahhoz, hogy ez minden karakteren működjön korlát nélküli bekötés kell.
A HairWorks a másik véglet, mivel nem igényel UAV-t. Meg is látszik a minőségén, hogy ki van hagyva a legfontosabb eljárás a leképzéséből, amivel nincs garantálva, hogy jó hajtincsből lesz meg a pixel színmintája.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Sok más oka nincs annak, amiért megéri szívatni a fejlesztőket. Az innováció a PC-n nem szolgálja az NV érdekeit. Ezért minden olyan effekt, amit átadnak a fejlesztőknek zárt, hogy bármennyire okos és tehetős egy partner ne tudja úgy módosítani, hogy szebb és gyorsabb legyen az adott effekt, mint ahogy azt az NV elgondolta.
Cégen belül tök jó példa az AndroidWorks. Nemrég mutatták be. Abban a GameWorks for OpenGL nyílt forráskódú és szabadon módosítható, annak érdekében, hogy a fejlesztő lehetősége meglegyen az innovációra, ami Androidon már érdeke az NV-nek.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Tehetős fejlesztő még nem is használta, szóval természetesen senkinek a fejéhez nincs pisztoly nyomva. Maximum nem kapnak pénzt, ha nem használják.
Szerintem 2015-ben, amikor sorra nyitják meg a middleware-eket a zártság melletti indokok okafogyottak. Főleg egy hardvergyártónak, ahol nem is ebből élnek. Mert egy Havokot még megértenék, de ők is nyitnak, miután az EA és az Ubisoft belengette, hogy váltanak nyílt forráskódú motorra, ha nem kapnak teljes kontrollt a Havoktól. Nyilván innen nem volt kérdés, hogy nyitni kell.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Módját vagy hiányát? Mert ez az, amit a fejlesztők a legjobban kritizálnak, hogy nem tudják optimalizálni a zárt middleware-eket. Mi sem láthatjuk azt, hogy ezek jól optimalizált, jó minőséget kínáló rendszerek lennének. Ha azt látnánk semmi gond nem lenne, de helyette azt látjuk, hogy szimpla felhasználói hack minőségvesztés nélkül a kétszeresére gyorsítja a HairWorksöt. Milyen optimalizáció ez, amikor ilyet meg lehet tenni? Miért kellene ezt titkolni? Az iskolában kellene oktatni, hogy ezt ne csináld.
A másik dolog, hogy ezt mennyire célszerű megcsinálni, hogy közben tudod, hogy az iparág nagyágyúit elveszted ezzel a stratégiával? Ők nem akarnak feketedobozokat. Évek óta ezek ellen küzdenek, mert csak megakadályozzák őket abban, hogy jó minőségű programot szállítsanak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Abszolút nem vagyok arról meggyőződve, hogy a PC-piacnak jót tesz, ha mesterségesen magas egy játék gépigénye a beépített zárt effektekkel. Nem tudom, hogy ezt az NVIDIA miért látja úgy, hogy ez a PC érdeke. Szerintem, ha megkérdeznénk őket, valószínűleg ők sem tudnák elmondani.
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
#6060
üzenetére
Én ezt sem látom annyira reálisnak. Úgy néznek ki a Kepler VGA-sok, mint akik Maxwellre akarnak váltani? Inkább GCN-t nézik, mert nem tetszik nekik, hogy az anno ezer dolláros Titánt már a középkategóriás Maxwellek és GCN-ek ütik.
(#6064) Szaby59: De milyen igény? Fizetünk ennyit és ennyit, ha használod? Ez nem igény, csak vannak olyan fejlesztők, akik pechesek, hogy az Intel és az AMD partnerprogramjába már nem férnek be. Az NV-nek meg erre bőven van kapacitása, mert a tehetős kiadók már elmentek tőlük.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem lesz kupakja.
(#6153) gbors: Ezt mondom egy ideje. Ezzel csak a saját felhasználóikat szívatják, mert az AMD-seknek csak annyit kell tenni, hogy x16-ra állítják a maximum faktort és jobban megy a HairWorks, mint GeForce-on valaha is fog. Ezért nettó hülyeség, amit csinálnak, hiszen a GeForce tulajdonosoknak az egyetlen lehetőség inaktiválni az effektet. Nekem a HairWorks aktiválása 45-ről 30 fps-re csökkenti a sebességet, de ha beállítom a 16x korlátot, akkor csak -2-4 fps-be kerül, és ugyanazt kapom. Nem velem szúrtak ki, hanem a saját felhasználóikkal. Én boldogan bekapcsolom és élvezem, mindenféle komoly teljesítményveszteség nélkül.
Bár én az Intel terveit nem tudom, de emlékszel az Ionra? Az Intel tudja, hogy nem számít ha valami jobb, ha nem tudod megvenni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mondjuk ez érdekes cikk így. Elmondja, hogy mit támogat a rendszer és berakja a Caps Viewer képet, amiben "No" van odapörkölve két funkció mellé is.
Szerintem le kellett volna írnia, hogy a WHQL driverekben a Microsoft megtiltja a nem véglegesített funkciók támogatását, mert így a user csak azt látja, hogy nem támogatja.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem. A bekötési modellnél a TIER_3 ki lett emelve a feature level szintekből, ahogy a PS-specifikus stencil referencia is, illetve a CR TIER_2 szint.
A Tiled Resources is ki lett ezekből emelve.Valójában ez elég bonyolult lett, de lesz egy cikk, ami táblázatokba foglalja a végleges, és még ámenre váró specifikációt.
Az a lényeg, hogy a TIER az nem egy általános dolog. Vannak funkciók és azoknak belsőleg vannak TIER szintjeik. És ezekből a funkciókból a kötelezőek vannak hozzákötve a feature level szintekhez, ezen belül is egy kötelező minimum TIER szinttel. De ezt majd egyszerűbb lesz a táblázatokból látni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
. IOMMU-van a WDDM 2.0-ban. És azt sem tudja támogatni egyetlen dedikált GPU. Emellett azt hiszik, hogy a TIER szinten az egyes eljárásokon a bekötésre vonatkoznak. Hát 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.
- Parfüm topik
- Milyen okostelefont vegyek?
- HiFi műszaki szemmel - sztereó hangrendszerek
- Kerékpárosok, bringások ide!
- Olcsó és visszafogottan elegáns kompakt AIO jön az ID-Cooling berkeiből
- Autós topik
- Mobil flották
- Huawei Mate 40 Pro - a csúcson kell abbahagyni?
- Autóhifi
- Futás, futópályák
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs