Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
imi123
#11167
üzenetére
Én nem utálom az NV-t. Rengeteg relikviám van személyesen tőlük (egyedi NVIDIA pendrive-ok, pólók, gravírozott egyedi késkészlet), amelyekkel elismerték már a munkámat. Kifejezetten kedvelem a hardvereiket, például a Fermi nagyon tetszett, ahogy a Tegra is nagyszerű. Viszont nem értek egyet azzal, hogy a felhasználóik számára jó dolog az, ha a gépigényt mesterségesen manipulálják. Ez egy rossz döntésük, amivel kárt okoznak a PC-nek.
-
Abu85
HÁZIGAZDA
Más célja nehezen lehet egy zárt rendszernek. Már önmagában az NV-nek nagyon káros, hogy a világ pofájába kell hazudniuk, hogy 2015-ben normális egy middleware-t zártként fejleszteni, amikor ennek pont az ellenkezője igaz és idén a korábban zárt middleware-ek forráskódját folyamatosan publikálják az érintettek.
A GameWorksnek más célja nincs, mint az előző generációs GeForce-ok teljesítményének mesterséges visszafogása vagy a gépigény mesterséges növelése. Minden egyéb célhoz megengedhető a nyílt forráskód, mert a licenc így is megvásárolható. Lásd az AndroidWorks. Az tök ugyanaz, mint a GameWorks és az összes sample forráskódja fent van a GitHUB-on. Még azt is mondta az NV, hogy csak így lehet optimalizálni a programot. És az AndroidWorksöt többen licencelik mint a GameWorksöt. -
Abu85
HÁZIGAZDA
válasz
rocket
#11159
üzenetére
A Vulkan API-val egy gondja lesz a DICE-nak. Nekik a shaderek HLSL-ben, PSSL-ben vagy az AMD-féle HLSL ext.-ben vannak megírva. A Vulkan egyiket sem fogadja el, mert úgy döntöttek, hogy csak SPIR-V kód szállítható. Persze az megoldható, hogy a DICE ír egy saját fordítót, amely a HLSL, vagy az AMD HLSL ext., vagy a PSSL kódot SPIR-V-re fordítja. A gond az, hogy SPIR-V-hez az AMD-féle HLSL ext. az ideális, de az meg GCN-re szabott kód teljesen, tehát eleve sok átírást von maga után. PSSL szintén, hiszen PS4-re van. A HLSL kód pedig nem éppen SPIR-V-hez való, bár a fordítás így is megoldható, viszont így lassabb lehet a Vulkan, mint a DX12-es opció.
Semmi köze nincs a Vulkan API implementálásának ahhoz, hogy ki a Khronos elnöke. Ő amúgy is csak moderációs feladatokat lát el az ARB-ben.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#11131
üzenetére
A Keplerrel akkor nincs és nem is lesz baj, ha a fejlesztő minden shadert rá tud optimalizálni. Mindenki ismeri ennek az architektúrának a gyenge pontját, és emiatt mindenki tudja hogyan kell kezelni. Lényegében arról van szó, hogy a multiprocesszoron belül normál ütemezéssel csak a magok 66,7%-a etethető, így a maradék 33,3%-ra független feladatokat kell találni. A legtöbb shaderben ezt viszonylag egyszerű kivitelezni. Egy DICE-nak ez nem jelenthet problémát, mert az elmúlt években már kitapasztalták. Ez csak akkor gond, amikor a shadert az NV szállítja és nem lehet optimalizálni. Az NV-nek az az érdeke, hogy a Kepler már ne teljesítsen. Alapvetően emiatt vezették be a GameWorksöt, ha jön egy új architektúra, akkor szoftveresen képesek legyenek mesterségesen kivégezni az előzőt.
-
Abu85
HÁZIGAZDA
Az új CryEngine és hasonló eredményeket mutat fel, mint az új Frostbite. Valószínűleg ehhez köze van annak, hogy ezek már teljesen PBR/PBS-es motorok, és itt általánosan erősebbek a Radeonok. A PBR/PBS miatt nagyobb teher jut a memóriabuszra, mert olyan leképező kell, amely pixelenként a megszokottnál több bitnyi információt kezel hatékonyan. Ezek a leképezők az utóbbi időben háttérbe szorultak, mert szűkössé vált a sávszél, de az új technikákhoz újra elő kell szedni őket. Illetve az is látszik, hogy ma már a középkategóriában is alap a 256 bit + GDDR5. Csak egy szem GTX 960 miatt nem döntenek úgy, hogy mégse fejlődjön a motor.
-
Abu85
HÁZIGAZDA
válasz
gtamate2
#11107
üzenetére
Röviden az Apple normális OpenCL támogatást kért, de az NV nem adott. Helyette a CUDA-t erőltette. Erre az Apple lecserélte a Quadrókat a Mac Próban FirePrókra. Amire áttértek a szoftverfejlesztők OpenCL-re. Erre az NV így sem reagált jó OpenCL meghajtókkal, így nem volt más választás, mint kidobni őket. Ennyi. Az Apple célja az, hogy minden partnere a saját zárt rendszerét támogassa a jövőben. Az NV-nek ez nem tetszik, mert az Apple képes kivégezni a CUDA-t a konzumer és profi vonalon. Legalábbis azt a részét is, ami meg maradt belőle.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#11102
üzenetére
De a te géped nem presztizscucc.
Az NV egyébként a Google Pixeljébe eladta a Tegra X1-et szóval a mostani Bookkal kb. jól állnak. De majd vissza kell szerezni az Apple bizalmát. Mondjuk ez nehéz lesz, mert ehhez az AMD-nek úgy kell majd szopatnia az Apple-t, ahogy az NV tette az elmúlt években. -
Abu85
HÁZIGAZDA
válasz
Yllgrim
#11098
üzenetére
A Linuxban az AMD játékos szemmel nem bízik. Annyira töredezett az egész, hogy esélye sincs a Windows 10 ellen. A Vulkan is Windows 10-en lesz a legjobb, mert a Linuxból hiányzik a WDDM2.0 alternatíva. Még a WDDM 1.1 képességeit sem tudják hozni.
Az egyetlen remény a játékosoknak a SteamOS, de ahhoz is meg legalább két év fejlesztés kell, hogy Windows 10 szintre jusson. De az biztató, hogy a Valve látja azt a problémát, hogy a Linux legfőbb baja a kismillió ablakkezelő és kompozitor, amelyek fejlesztése teljesen átgondolatlan, és erre vonatozóan lemásolják azt, akit az MS csinál. Lesz egy kivalasztott alapcsomag és az lesz szarráoptimalizálva. -
Abu85
HÁZIGAZDA
Egy ilyen üzletnek semmi köze a hardverek képességeihez. Az Apple, a Google és az MS úgy választ, hogy melyik cég tudja nagyon olcsón biztosítani a megfelelő termeket. Az NV-nek nulla presztízscuccban van idén VGA-ja, mert az AMD elvitte az Apple megrendeléseket, így a Booksba muszáj volt bekerülni egy VGA-val. Jó eséllyel az AMD-t ez már nem is érdekelte, mert elég az Apple megrendelés. Nem jó túl sok olcsó üzletbe belemenni. Ezért nincs olyan, hogy valaki végignyeri az Apple, Google, Amazon, MS cuccokat.
-
#11087
Abu85
HÁZIGAZDA
gainwardgs
#11086
Abu85
HÁZIGAZDA
válasz
gainwardgs
#11086
üzenetére
Egy low-level API biztos támogatva lesz a három közül. Nem tudom melyik, azt nem mondták.
-
Abu85
HÁZIGAZDA
válasz
janos666
#11073
üzenetére
Biztos nem lesz visszaportolva egyik régebbi Frostbite verzióba sem a DX12 és a Vulkan. Valójában a Mantle is csak akkor lehet használatban mostantól, ha a fejlesztő olyan dolgot szeretne, ami szabványosan nem érhető el. Elég sok dolog hiányzik még a DX12-ből ami konzolokon van, és a Mantle API-ban benne van.
A Mantle bekötési modellje is sokkal jobban hasonlít a PS4-es libGNM-re, illetve az Xbox One DX12 mono API-jához. A normál DX12 és a Vulkan API más bekötési modellt használ, bár a Vulkan modellje csak annyiban különbözik, hogy emuláció céljából fenntart bizonyos specifikus puffereket, hogy az AMD-n kívül más is tudja futtatni a Vulkan alkalmazásokat. -
Abu85
HÁZIGAZDA
válasz
Sir Ny
#11063
üzenetére
GP100 vagy GP200. Összekavartam. Köszi.
(#11064) Szaby59: A GM200 az nem számít, mert az semmi újat nem mutatott. Ergo a tape-outtól a megjelenésig megcsinálták 9 hónap alatt. A következő kör sokkal nehezebb, mert tapasztalat nélkül lesz egy új node-ra való átállás, új memóriavezérlő tervezésével, új memória bevezetésével és interposerrel. Egyenként megvan rá az esély, hogy kivégeznek egy terméket és egyszerre kell átállni mind a négy nagy váltásra. Tehát itt azért több idő fog eltelni, amíg a tape-outtól eljut a termék a boltig. Másfél év alsó hangon, de látva, hogy a Fiji mikor ért el a boltokig 2013Q2-es tape-outtal inkább két évet mondanék.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#10968
üzenetére
Azért nincs újra kiadva, mert még nincs kész. Ugyanis tele van hibával az újraírt erőforrás-kezelés. A patch azért került ki, mert már segít a teljesítményen, de még bele telik pár hétbe, amíg a hibákat kijavítják. Amint ezzel végeznek felrakják újra a Steamre, és akkor lesz kész, akkor lehet újra megvenni.
Az early access esetében is alapvető követelmény, hogy legyen stabil, de ezt még az Arkham Knight nem teljesíti. De ez nem gond, nyilván ezért nincs még visszarakva a Steamre. Még tart a tesztelés.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#10965
üzenetére
A hiba jellegét tekintve teljesen mindegy lenne, hogy a driver WHQL vagy béta. A WHQL teszt ugyanis nem tartalmaz ellenőrzést egy ilyen problémára.
Tegyük hozzá, hogy az Arkham Knight még ki sincs újra adva. Nem véletlenül vonta vissza a Steam a játék értékesítését. Egyszerűen ma még béta állapotú. Emiatt teljesen természetesen a hibák vele. Akkor lehet reklamálni, ha újra kiadják.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#10880
üzenetére
Az OpenGL és a driverek állapota csak tünet. A probléma az, hogy egy rakás kompozitor és ablakkezelő létezik, és ezek fejlesztésében a gyártók nem vesznek részt. Plusz a zárt driverek ezekbe nagyon beletúrnak, tehát gyakorlatilag minden céghez külön implementáció kell. A Valve nem véletlen választotta azt, hogy áttérnek a Waylandre, de az erre való váltás sem problémamentes, mert a Wayland nem támogatja natívan az OpenGL-t. A SteamOS azért jön, mert a Valve rájött arra a problémára, hogy a sok alternatíva egy problémára nem nyerő, így csinálnak egy olyan disztribúciót, amelyben kiválasztanak egy alternatívát minden területre, és azt optimalizálják majd halálra, illetve a fejlesztőknek is aszerint kell dolgozniuk. Nem véletlen, hogy ők már átrakták a Source 2-t Vulkan API-ra, mert amikor bevezetik a Waylandet, akkor jó eséllyel sok probléma lesz az OpenGL-ben írt játékokkal, hiszen a legtöbb OpenGL implementáció telepít GLX-et, ami összeakad a Waylanddel.
-
Abu85
HÁZIGAZDA
válasz
letepem
#10874
üzenetére
Linus azért mutatott be az NV-nek, mert leálltak az open source projektek támogatásával és nem dokumentálják a hardvereiket. Ez jelentősen megnehezíti a Linux fejlesztését az NVIDIA hardvereken. Illetve nehezebb lesz olyan cégekre Linuxot tukmálni, akik NVIDIA-t használnak. A játékokat Linus le se szarja, aki használ Linuxot az elsődlegesen nem játékra használja.
-
Abu85
HÁZIGAZDA
válasz
sayinpety
#10857
üzenetére
Az parancslista túlterhelése vezethet olyan problémához, amiről az Oxide beszélt a Nitrous és az async compute NV-s problémáival kapcsolatban? Szimplán annyira megnövelte a processzorterhelést a driver munkája a hardver hiányosságainak kezelésére, hogy az egész eredménye lassulás lett úgy is, hogy elméletben gyorsulnia kellett volna?
-
Abu85
HÁZIGAZDA
válasz
Laja333
#10822
üzenetére
Valószínűleg ehhez köze van annak, hogy az AMD csak pár órával a megjelenés előtt adta oda az új meghajtót, így nem volt idő mindent azzal letesztelni. Erre egyébként az Anand is felhívta a figyelmet. Szóval vagy a régi, vagy az új meghajtóval futottak a hardverek, vagy keverten.
Ebből szerintem úgyis lesz még egy kör teszt, amikor az MS kiadja a végleges tesztprogramot.Az UE4 MS-es verziója eléggé sávszélzabáló. Ezért rendeződnek ennek megfelelően a hardverek.
-
Abu85
HÁZIGAZDA
válasz
rocket
#10819
üzenetére
Tök mindegy, hogy mi kerül beállításra a driverben DX12-ben a kényszerített szűrők nem számítanak, mert a driver nem tud már kényszeríteni kernel meghajtó hiányában. Másrészt az UE4 új verziója nem támogatja az AF-et. Egy speciális szoftveres szűrést használ a POM miatt.
Egyébként most tök mindegy, hogy ki mér, mert a program csak három előre konfigurált profilt használ. Ezeket egyénileg nem lehet paraméterezni.(#10820) gV: A Kepler csak akkor szerepel rosszul, ha a program nem veszi számításba, hogy független utasítással ki lehet tömni a feldolgozók 33%-át. Mivel a Microsoft nem használ GameWorksöt, így képesek úgy írni a programot, hogy optimálisan fusson Kepleren. Ezek nem nehéz optimalizálások, csak szánni kell pár órát a beépítésükre.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#10757
üzenetére
Ha arra gondolsz, hogy ellopják az adatokat, akkor azt megtehetik, ha azt akarják, hogy a termékük sose jelenjen meg. Ugyanis az AMD a saját csomagjára kapott értékeket tartja számon. Az NVIDIA lapkáival nem is tesztelnek. Amiket pedig a HBM-ről tudni lehet, azt a Hynix és a Samsung úgyis elmondja. Persze leginkább a Hynix, mert a Samsung itt szűz ilyen szempontból.
(#10759) rocket: Amiket meg tudnak osztani, azt megosztják, de az NV nem megy semmire azzal, hogy az AMD-n milyen konfiguráció a működőképes. Megnézhetik, de számukra ez értéktelen információ.
(#10763) Loha: Erről beszélek. Az AMD és az NV is közel két évvel az első termék után jutott túl az 5 GHz-en. Sajnos 5,5 GHz felett drasztikusan romlik a GDDR5 fogyasztása, így csak akkor mentek fölé, ha nagyon szükséges volt.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#10754
üzenetére
Itt nem a mérnökök tudásán múlik. Lehet szuperokos akármennyi mérnök, de alapvetően előnyben van az a csapat, amelyik nem 2015 közepén látott először HBM termékmintát, hanem 2014 első felében. Az a mérnök csapat, amelynek másfél éve van hardvere már túl van minden olyan fontosabb teszten, aminek a többi csapat még csak most kezd neki. És az ezeken a teszteken gyűjtött tapasztalatot semmilyen elméleti tudás nem képes helyettesíteni.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#10751
üzenetére
Ahogy ez most alakul messze nekik lesz a legjobb, mert gyorsabban válthatnak HBM2-re, mint tervezték. Nekik az átállás eleve sokkal könnyebb lesz, mint bárki másnak, mert tömeggyártanak egy komplett HBM-es rendszert. Olyan dolgokat ismernek a teljes rendszer működéséről, amelyet más 2016-ban fedez majd fel, mint probléma.
Minden memóriaváltás nehéz, és a GDDR5-nél látható, hogy miért. Az AMD az elején képes volt építeni 4 GHz-es VGA-kat, majd később 5 GHz-eseket és így tovább. Ezeket a lépcsőket a tapasztalat hozta össze. A Radeonokon már 5,5 GHz-es memóriák voltak, amikor más épphogy elérte a 4 GHz-et.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#10733
üzenetére
A Micron HMC borzalmasan drága és nem is működik. Az Intel is egy speciális változatot használ, ami nem a Micron interfészével dolgozik. Ez elfogadható egy 2000+ dolláros Xeon Phi-n, de még így sem biztos a nyereség. Egy 1000 dollár alatti VGA-ra darabonként 1000 dollár veszteség nem vállalható be.
A HBM1+GDDR5X lehetséges, csak borzalmasan hátrányos és drága, mert fizeted az interposert és fizeted a NYÁK extra költségét is. Akkor már inkább csak GDDR5X-et érdemes használni.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#10741
üzenetére
Az a baj, hogy a konzol egy fix hardver. Tehát a programozó tökéletesen képes olyan kódot írni, amelynek minimalizálja a memóriaelérését. Kvázi a munkát a lapkán belül tartja. Egy PC-n a rakás eltérő hardver miatt ilyet nem lehet csinálni, mert nem érdemes egy hardvert kiválasztani a sok száz közül, és arra rágyúrni a programot. Fix hardvert a változó hardvert kínáló platformokkal nem szabad összehasonlítani, mert fix hardverrel olyan dolgokat tehetsz meg, amelyek drasztikusan gyorsíthatják a feldolgozást.
-
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#10568
üzenetére
Akkor egy kicsit érthetőbben. A VR-nél a lényeg, hogy legyen új képkocka a vertikális szinkron idejére. Mindegy, hogy valós vagy warp, csak ne legyen kirakva az előző. A preempció a timewarphoz kell, és ennek a hatékonysága határozza meg, hogy mekkora eséllyel lesz új warp. Finomszemcsés preempcióval a legnagyobb az esélye és rajzolási szintű preempcióval a legkisebb. A kettő között helyezkedik el a Hawaii leginkább a finomszemcsés eredményeihez közel.
(#10572) cain69: Mivel ez hardverfüggő, így nem lehet ennyire megmondani, de vannak olyan rajzolások is, amelyek 10 ms-nál is tovább tartanak egy gyors hardveren. Ez egyébként nem baj önmagában. Az a baj, ha mögé szorul a timewarp.
-
Abu85
HÁZIGAZDA
válasz
#45185024
#10565
üzenetére
Mert a GCN2-nek sem kell a timewarphoz kontextust váltania, és a preempciós képességei így is nagyon jók, csupán nem tud éppen futó wavefrontot leváltani, ami pár száz nanoszekundumos késést jelenthet. De a PS4 alapvető előnye, hogy a teljes szoftvercsomagot egy fix hardverre optimalizálták igen alacsony szinten.
Az NV problémája onnan ered, hogy nekik a timewarp nem garantált funkció. A kért kontextusváltás akár 7 ms-mal is késhet, ha előtte beragad egy hosszú rajzolás. Ilyen körülmények között gyakorlatilag biztosan nem lesz timewarp szinkronablakon belül. Ezt valószínűleg úgy fogják kezelni az NV-nél, hogy a látótér szélein keveset számolnak. Kvázi ezért került be a multi-res shading a GameWorks VR-be. Ez sokat ront a minőségen, de drasztikusan növeli a sebességet.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#10563
üzenetére
Fogalmam sincs igazából, hogy mi fog változni. Volt az AMD-nek egy régi OEM útiterve, amiben le volt írva, hogy a GCN1 verzióhoz képest miket terveznek még:
fast context switch (GCN2)
unaligned memory access (GCN2)
memory address watch (GCN2)
system & device unified addressing (GCN2)
multiply compute queue (GCN2)
mid-wave preemption (GCN3)
scan & cross-lane ops (GCN3)
mixed precision (GCN3)
quadruple precision (???)
octa precision (???)
system & device transactional memory (???)
quad-fragment merging (???)Bejelöltem zárójelben, hogy mi valósult meg és mi nem. Azt nem tudom, hogy megvalósulnak-e. Annyit tudok, hogy a GCN4 és a GCN5 kódolási sémája más, mert a GCN disassemblerben már lehet kérni ennek megfelelő kódot. Gondolom van GCN4 és GCN5 szimulátoruk.
-
Abu85
HÁZIGAZDA
válasz
imi123
#10558
üzenetére
Az az AMD-nek sem jó, hogy a konzolokra fejlesztenek. Most az egy rövid ideig, de később ez limitáló lesz nekik is, ahogy mindenki másnak. A GCN3 már okosabb annál, amit a konzolok kaptak, és akkor jön még GCN4 és GCN5.
A TrueAudiót a konzolon sem használják még, de egyre többen fogják, és onnan a kód átmenthető. De a PC-n a TrueAudio egy fontos VR komponens. Nélküle nem lehet kis teljesítményigény mellett térhangzást kínálni a VR-hez. Ez az egyik dolog, amit vizsgál például a Realtek is az ALC5677-es DSP-vel. Ez ugyan harmadannyira olyan erős, mint a TrueAudio, de a VR miatt érdemes rárakni bizonyos alaplapokra (VR-re tervezettekre), mert szükség lesz rá, és még portolhatók lesznek a konzolos hangrendszerek hozzá. -
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#10542
üzenetére
GPUPerfStudio.
A GPU-Z csak azt ellenőrzi, hogy egy másodperces időkeretben a GPU hányszor fogadott parancsot a CPU-tól, és arra ad egy százalékos értéket. Azt nem fogja megmondani neked, hogy ezek a parancsok hogyan és mikor futnak le a GPU-n belül.(#10546) imi123: Az AMD pont a gyors hardverfejlesztésekben hisz, mert jellemző, hogy két-három évvel hamarabb vetik be az újításokat, mint a konkurensek. Lásd.: SVM, FP16, ordered atomics, LDS virtualizáció, OOO parancsprocesszor, mid-wave preempció, SRIOV, gyors kontextusváltás, stb. Gyakorlatilag kimondták a Mantle-lel, hogy ha jöttök, ha nem, mi megyünk előre. Ennek az lesz a vége, hogy mindenkinek lesz egy saját API-ja, mert az nem járja, hogy az AMD-nek nem kell megvárnia az adott problémák megoldására szánt szabványt. Lásd most a VR.
-
#10554
Abu85
HÁZIGAZDA
Petykemano
#10537
Abu85
HÁZIGAZDA
válasz
Petykemano
#10537
üzenetére
Igen oda lehet tolni extra számításokat, de maga a multi-engine nem arra készült, hogy alapvetően rosszul megírt motorok működésén javítson. Persze segít, de a megoldás inkább a PC-khez való optimalizálás. A legnagyobb probléma az utóbbi hónapokban kijött játékokkal az adatfeltöltés. Annyira logikátlanul vezérelt az adatfeltöltés, hogy túl sokszor kell leállítani a GPU-t. Konzolon ez nem baj, mert ott van aszinkron mód, de DX11-ben erre nincs lehetőség, DX12-ben és Vulkánban lesz. Viszont rövidtávon ez nem jó így sem. Segít ugyan az összes GCN-en és a Maxwell2-n, de a többi hardveren továbbra is gatya lesz. Inkább jó adatfeltöltési stratégia kellene, mintsem tüneti kezelés a gondokra.
-
#10536
Abu85
HÁZIGAZDA
Petykemano
#10535
Abu85
HÁZIGAZDA
válasz
Petykemano
#10535
üzenetére
A legtöbb játékban nem volt lényeges különbség. A probléma alapja ugyanis, hogy a GPU-k a rossz optimalizálás és rossz feldolgozási stratégiák miatt tele lesznek idle buborékokkal, és ez egyaránt érinti az összes hardvert, mert a logikai felépítés hasonló. Persze az idle buborék mérete változó, de a probléma inkább program oldalon keletkezik, így végeredményben minden hardver kb. hasonló büntit kap.
Ha nagyon vissza akarjuk vezetni a problémát az alapokhoz, akkor az lehet a gond, hogy magát az adott motort nem igazán tervezték rá PC-re, vagy szimplán túl öreg. A Nitrous azért fejt ki olyan brutális terhelést, mert eleve PC-re tervezték, és a működést a modern hardverekhez igazították. -
Abu85
HÁZIGAZDA
válasz
Televan74
#10531
üzenetére
Az a baj, hogy ha kicseréli, akkor az sem feltétlenül ér valamit, mert a problémát az idézi elő, hogy az új program úgy terheli a VGA-t, amire a gyári tuning tervezésekor nem számítottak. Ergo a cserekártyánál is megvan esélye annak, hogy az sem lesz stabil.
Az utóbbi időben azért engedték meg a gyártók maguknak a már-már extrém gyári tuningokat, mert az elmúlt egy évben fokozatosan csökkent a programoknak a GPU-ra kifejtett terhelése. Amíg másfél éve tudtunk olyan programot választani a PH tesztbe, ami leterhelte a GPU-t 50%-ra is, addig ma már kénytelenek voltunk ezt a megkötésünket 30%-ra csökkenteni, mert több új játék 25%-ra sem terheli a VGA-kat. És a gyártók valószínűleg arra számítottak, hogy ez a trend belátható időn belül nem fordul meg, de úgy néz ki, hogy megfordul. -
Abu85
HÁZIGAZDA
Igen, és erre egyébként az AMD direkt figyelmeztette a gyártókat. Attól, hogy az aktuális játékokon stabil egy +200 MHz-es tuning még nem feltétlenül lesz az a jövőben. Aztán később nem is engedték, hogy sokat húzzanak a hardvereken. Az NV is most kezd rádöbbenni, hogy marhára nem jó az, ha a partnerek szénnétuningolják a lapkáikat, mert tele vannak TDR-es panaszokkal a fórumok, és a tuning után kell menni az órajelváltások optimalizálásánál, ami aztán lehet, hogy nem stabil a gyári kártyákon. Most egy kártyára minimum egy tucat rutint kell használni, és ide-oda pakolgatni az egyes termékeket, attól függően, hogy sok-e még a TDR-es panasz vagy nem. Ennek az lesz a vége, hogy a problémás játékoknál profilban levágják fix órajelre a kártyát az alap alá úgy 10-15%-kal.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#10517
üzenetére
A Nitrous ilyen. Szerintem meg fogják közelíteni a Furmark terhelést, ha így haladnak az optimalizálással. Szóval a beállított tuningok nem biztos, hogy stabilak. De nem ez a probléma vele, hanem az, hogy a gyárilag tuningolt kártyák is nagy százalékban instabilak, és egyre több gyártó panaszkodik a Stardocknak, hogy túl erős a játék terhelése, már alpha szinten. Ez a gyártóknak gáz, mert ha tovább optimalizálnak az Oxide-nál, akkor esélyes, hogy az összes eladott gyárilag tuningolt kártya felét is cserélni kell, ami a legtöbb cégnek hatalmas katasztrófa lenne, szóval most valami szoftveres megoldáson gondolkodnak, ami egy profilban fixálná alacsonyabb szinten az órajelet a tuning ellenére is.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#10433
üzenetére
Szerintem túlságosan csak a TFLOPS-okra koncentráltok. A DX12 és a Vulkan igazi célja nem éppen a teljesítmény drasztikus növelése. Az a DX10 és a DX11 célja volt, csak helyenként elhibázták a működést. Az ipar most a valóban új generációs konzolos motorokra koncentrál, amelyeket régi API-kra portolni sem lehet. Innen két választása van a PC-nek. Vagy leköveti a konzolos API dizájnokat, és hátrányokkal ugyan, de portolhatók maradnak az új játékok, vagy azt mondják, hogy a PC járja a saját útját a konzolra írt AAA játékok nélkül. Az iparág inkább a reform mellett döntött, mert az nem biztosított, hogy a top AAA játékok nélkül a PC-piacon el lehetne adni egy rakás gamer hardvert. Szerintem jó döntés született. IPhone játékok HD-sítéséből a PC nem élne meg.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#10417
üzenetére
Előfordulhat ilyen is. Nyilván az implementációtól nagyon sok függ. Azért a Frostbite-ban a Mantle implementáció a BF4 óta nagyon sokban változott, tehát lehet, hogy egy még újabb architektúrára már nem reagálna így. Önmagában a BF4 egy pilot projekt volt egy olyan ösvényen, amit a DICE előtt senki sem járt. Az optimális használatot pedig ilyenkor ki kell tapasztalni.
Egyébként ugyanezzel a gonddal a Thief is küszködött, és arra kiadtak egy javítást egy évvel később. Persze elsődlegesen nem a gondok korrigálása miatt adták ki, hanem ki akartak próbálni az async shadert élesben.
Viszont lehet vele mit kezdeni. Az AMD ezért ír GCN4 és GCN5 szimulátorokat, hogy a hardver hiányában is előre legyen optimalizálás. Ezt a lehetőséget a többi cégnek is érdemes észben tartani.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#10409
üzenetére
Ezt már többször elmondtam, hogy a low-level API-k alapvető hátránya lesz, hogy a kernel driver megszűnésével átkerülnek a menedzsmentre vonatkozó alapok a programkódba. Így ha érkezik egy új architektúra, akkor azon nem fut olyan jól a programkód, mint a kiadáskor ismert architektúrákon. A GCN3-ra nem jött ki BF4 javítást, mert túl nagy változást igényelt a motorban, de az összes későbbi Frostbite játék már GCN3 optimalizálással érkezett.
Ugyanez lesz a DX12 és a Vulkan. Sajnos előfordulhat, hogy ha veszel egy új hardvert, akkor azzal már nem tudod már olyan részletességgel játszani a kedvenc játékodat, mint az előzővel, mivel nem tudja a gyártó a driverben a megfelelő menedzsmentet ráerőszakolni a programkódra. Erre kell egy patch-et kiadni az adott játék fejlesztőjének. -
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
Locutus
#10362
üzenetére
Az AMD mindig úgy kommunikálta, hogy nagy hatása van a piacra, és tulajdonképpen az volt. Ha nem jött volna ki, akkor jelentősen csúsztak volna a DX12 fejlesztések is, mert nem tudták volna előre felkészíteni a motorokat a fejlesztők a low-level irányra. Ez azt eredményezte volna, hogy 2016 közepéig nem jött volna DX12-es játék. De mivel rengeteg motort előre átírtak az AMD API-jára, így ezeknél a motoroknál már csak a render back-endet kell lecserélni. Hozzávetőleg 120 fejlesztőről van szó, aki ezt megcsinálta az elmúlt másfél évben. Emiatt gyakorlatilag előkészült egy olyan terep, amelyre az elkövetkező egy évben több tucat DX12 és már Vulkan játék is jöhet, mert a render back-endet hetek alatt ki lehet cserélni.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#10353
üzenetére
Az E3-on is ki lehetett az NV standjánál a VR-t. De független stúdiók standjánál LiquidVR volt, még akkor is, ha NV partner volt a stúdió. Egyszerűen számottevően jobban működik az AMD megoldása. A többiek gondja ott kezdődik, hogy nincs grafikus API-juk VR-hez, az hogy hardvernek vannak hiányosságai már csak ráadás lehet. Ez a legfőbb oka, hogy az Intel és az NV nem akar VR tanácsot, mert a jelenleg előirányzott minősítési rendszerrel esélyük sem lenne arany vagy ezüst minőségre. Maximum a bronz, amit megkaphatnak, vagy az "only for multimedia" matrica.
Eleve az arany minősítés tervezett követelménye 10 ms-nál kisebb motion-to-photon latency, ami nem lehetséges Latest Data Latch nélkül. -
Abu85
HÁZIGAZDA
válasz
daveoff
#10336
üzenetére
Promózni meg beszélni lehet róla. Amiről itt szó van az a technikai megvalósítás. Ebben a LiquidVR a mezőny előtt jár, elsődlegesen azért, mert nem korlátozzák a szabványos grafikus API-k a lehetőségeket. Az E3-on nem véletlenül futott minden játékbemutató LiquidVR-en. Például hiába partnere az NV az EVE: Valkyrie című játéknak, akkor sem olyan jó a GameWorks VR csomag, hogy azon mutassák be a játékot. Persze nem írták ki, hogy amin futott az a LiquidVR, mert gondolom a partnerszerződés megtiltotta, de muszáj volt azt használni.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#10321
üzenetére
Csak nem mindegy, hogy mennyit érnek ezek a megoldások. A Latest Data Latch például nagyon sokat, és az így nagy előny az AMD-nek, de ilyen extrákat mindig az elején lehet szerezni. Ahogy kerülnek közel a határokhoz egyre nehezebb további előnyt szerezni, szóval az olló gyorsan záródik össze.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#10317
üzenetére
De azzal előrébb lennének. De az nyilván problémájuk, hogy egy ilyen megoldás nem rajtuk múlik, mert nem rendelkeznek saját grafikus API-val, mint az AMD, így a saját VR csomagjuk tervezésében sokkal korlátozottabb lehetőségeik vannak.
Az NV a fentiek miatt teljesen más opciókat fejleszt a GameWorks VR-be. Nem véletlenül adják hozzá a multi-res shadinget. Nem tudnak olyan késleltetést elérni, mint a LiquidVR, mert nem tudnak kamerapozíciót módosítani képszámítás előtt, de el tudják érni, hogy a képkockán, ami nincs középen, vagyis a szem várható fókuszpontjában az legyen rossz minőségű, tehát kevés számítást igényeljen. Ezzel szintén csökken a késleltetés, de VR-ben a szemed mozoghat, tehát rá tudsz nézni a rossz minőségű képterületekre is, ami már baj. -
Abu85
HÁZIGAZDA
válasz
#45185024
#10296
üzenetére
Jedec szabvány, akkor gyárt ilyet a többi memóriagyártó, amikor akar. Nem a memória a probléma a HBM-nél, hanem az interposer.
(#10284) pengwin: Az MS-nek egyikhez sem kell részesedést vásárolni. Egyszerűen elég terméket rendelni.
Az AMD most abból a szempontból érdekes, hogy a VR biznisz gyakorlatilag egy jó ~180 milliárd dolláros üzletnek tűnik éves szinten, és egyedül az AMD rendelkezik olyan csomaggal, amely ezeket a VR cuccokat problémamentesen meg tudja hajtani. És most a játékokat mindenki leszarja, a nagy biznisz az orvosi, az oktatási és a professzionális felhasználás lesz. Ezért megy most a matek, hogy jó lenne az AMD-ben részesedést szerezni, mert hozzávetőleg 3 évig nem lesz még szabvány, vagyis gyakorlatilag ingyen ebéddé válik minden VR terület az AMD-nek. A Facebookkal nem akar senki sem versenyezni, mert ők eleve rohadt pénzesek, más VR eszközökre szakosodott céget meg nem akarnak venni, mert az Oculus technikailag jobb, és a Facebook pénze garantálja, hogy más ne érhesse utol őket. Innentől kezdve, ha valaki VR-ből hasznot akar, akkor a komponensgyártókat célozza meg. Egyébként nem valószínű, hogy a Microsoft vagy az Intel bármit is elér. Sokkal inkább a Silver Lake az opció, mert ők mindig nagyon rástartolnak az üzletileg kritikus területekre. Nyilván ők is számolgatják, hogy mekkora lesz a VR üzleti felhasználásból származó bevétele, mert az AMD gyakorlatilag az egyetlen jelölt a VR-es alapként legyen szó orvosi vagy oktatási felhasználásról, vagy bármiről.
A Microsoftnak stratégiailag akkor lenne lényeges az AMD-be bevásárolni magát, ha túl sok alternatív területre felhasználja a cég a Mantle-t. Az a Microsoftnak nagyon káros lenne, mert arra kényszerítené az összes gyártót, hogy fejlesszenek egy saját grafikus API-t. Emiatt talán megérné részesedést szerezni, és kierőszakolni a cégen belül, hogy a Mantle halljon meg, mert potenciálisan káros a Microsoft ökoszisztémájára nézve, hogy az AMD minden problémára képes 2-3 évvel hamarabb reagálni. Ez csökkenti a Microsoft szabadságát is a kutatásban, mert bizonyosan ott ordít mindenki a fejük felett, hogy baromira kell a VR-es DirectX, hogy tudják célozni azokat a területeket, amelyeket az AMD már elér. -
Abu85
HÁZIGAZDA
válasz
rocket
#10248
üzenetére
Nem az AotS kapcsán volt róla szó. Az async DMA és compute egy olyan dolog, amit a konzolra dolgozó fejlesztők jó ideje használnak. Tehát semmi újdonság nincs benne, csak PC-re még nem használták sokan (csak a Thief). Elsődleges célja, hogy ingyenessé tegyen bizonyos számításokat, mert ezeket a hardveren belüli buborékokra rá lehet ütemezni. Például shadow mapoknál a shader feldolgozók 90%-a NOP-ot futtat, vagyis nem csinálnak semmit, csak várják, hogy végezzen a ROP a számítással. Ezekre a feldolgozókra ki lehet osztani feladatokat, amelyek addig végeznek, amíg a shadow mapok számítása zajlik. Ergo a teljes számítás, amit ezekre kiosztottak gyakorlatilag ingyenessé válik. Számolt a rendszer egy csomót, de közben kvázi semmit sem lassult a tempó, mert a shadow map számítása tovább tartott így is.
A multi-engine ezeknek a hardveren belüli idle buborékoknak a betömésére jó.
Aztán ott a gyakorlat, hogy ezt ki hogyan használja, mert egészen sok lehetőség adódik azzal a modellel, amit a DX12 lehetővé tesz. Nem muszáj buborékokat tömködni, akár elindítható több alacsony prioritású compute feladat is a grafikai feladatok mellett. Valószínűleg a Nitrous eleve egy nagyon kiegyensúlyozott motor, így nem sok buborékot lehet betömni, ami miatt inkább párhuzamos megközelítéssel dolgoznak a fejlesztők. De az valóban igaz, hogy a motorok 99%-a a Nitrous teljesítményének a töredékét sem képes hozni, és így logikus, hogy jóval több idle buborékok lesz a hardvereken belül. Így például ezeknél a motoroknál lehet más megközelítéssel is élni. Írtam az ezzel kapcsolatos cikkben, hogy az NV valószínűleg azért nem tiltja le csípőből ezt a képességet, mint az Intel, mert egyrészt szeretnék használni az async DMA-t, másrészt nagyon valószínű, hogy van olyan megközelítés, amitől a Maxwell 2 is gyorsul, mert valószínű, hogy a compute bizonyos grafikai state-ekre épül. Bár a Maxwell 2-ről nincs dokumentáció, de nagyon jellemző, hogy stateful hardvereken a compute és a pixel feladatok ugyanazokat a state-ket használják. Nyilván, ha az NV azt gondolná, hogy a fejlesztők nem képesek olyan kódot írni, ami a hardverükön gyorsul, akkor nem is gondolkodnának a multi-engine hardveres kezelésén.Az meg teljesen normális, hogy egy fejlesztő letilt dolgokat, bizonyos alternatív kódrészletekkel, ha az adott implementáció nem felel meg az adott hardvernek. Pontosan ezért van a Nitrousban egy NV-re kialakított kódrészlet a fő programkód mellett. Ez nem tudom, hogy miért újdonság, hiszen lassan egy évtizede folyamatosan alkalmazott praktika.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#10265
üzenetére
Csak más fog velük játszani. Bár a fejlesztők is gamerek bizonyos szinten, szóval ők is játszanak majd.
Hidd el egyébként nem hülyeségből kérnek olyan dolgokat, amelyekkel hatékonyabban tudnák programozni a GPU-kat. A mostani nyelveket a tíz évvel korábbi modellekre találták ki. A Vulkan az első API, amely lépéseket tesz annak érdekében, hogy C++11 vagy akár C++14 részhalmazának képességeit el lehessen érni. Ez az olyan cégeknek, mint az Ubisoft nagy segítség lenne, mert ők már most azon gondolkodnak, hogy átvisznek bizonyos számításokat a CPU-ról a GPU-ra. GPU-driven pipeline modell.
És itt megint csak a PC-ről van szó, mert konzolon megcsinálják, itt az a kérdés, hogy PC-re hogyan oldják meg. Nyilván első körben az executeindirect elég, de később szükségük lesz a Vulkan újításaira.
-
Abu85
HÁZIGAZDA
Nem feltétlenül függ az API-tól, hogy egy játék Win10 only-e. A Vulkan éppúgy lehet Win10 only, ahogy a DX12, mert a WDDM 2.0-ból profitál. Az valóban igaz, hogy a Vulkan esetében van esély rá, hogy egy játék elinduljon Win7/8.1/akárminamireleszVulkan, de ha egy motor valamilyen szempontból kötődik a WDDM 2.0-hoz, vagy egy hasonló modellhez, amit nem lehet igazán jól visszamappelni a WDDM 1.x-re, akkor Vulkan ide vagy oda a programhoz Win10 kell.
Ettől függetlenül a Vulkan valamivel jobb API. A DX12 nem tartalmaz olyan funkciókat, amelyeket a fejlesztők kifejezetten kértek, és elérhetők konzolon is. Mint például az ordered atomics, GPU dispatch, SIMD lane swizzle, template támogatás a shader nyelvben. Ezeket a Vulkan tudja.
-
#10244
Abu85
HÁZIGAZDA
Dark KillerX
#10238
Abu85
HÁZIGAZDA
válasz
Dark KillerX
#10238
üzenetére
De az MS bármikor mondhatta volna nekik, hogy köszönjük értékeljük a munkátokat, de nem kérjük. Viszont ezzel sem lenne előrébb az ipar, mert akkor is kiadták volna a saját API-jukat, és akkor ott tartanánk, hogy az Intel és az NV is tervezné a sajátját. Az átmenet rossz lesz, de összességében jól jártunk azzal a váltással, amit az MS végigvitt. Lehet, hogy jövőre lesz némi kellemetlenség belőle, de két éves távlaton túl csak pozitívumokat fog hozni.
-
Abu85
HÁZIGAZDA
válasz
Televan74
#10153
üzenetére
Arról van szó, hogy van két nagyon jövedelmező terület, amely befuthat a jövőben. Az egyik az AR, míg a másik a VR. Az AMD bemákolta a helyzetet úgy, hogy senki másnak nincs működő csomagja ezekre, és gyorsan alakítottak egy cégen belüli csoportot, hogy reagálni tudjanak az AR és a VR irányára. Ez lehetővé teszi, hogy hamar megoldjanak hardverekkel és szoftverekkel olyan problémákat, amelyek előreviszik ezeket a piacokat.
Ezt most ki kell használni, mert olyan többet nem lesz, hogy a konkurensek sehogy sem készültek fel egy már látható jövőképre. -
Abu85
HÁZIGAZDA
válasz
proci985
#10142
üzenetére
Az Oculus SDK nem támogatja a multi-GPU-t, de a LiquidVR igen, szóval azokon a játékokon fog működni, amelyek LiquidVR-t is használnak. A Hawaii nem rossz, de a VR-hez egy fokkal előnyösebb a finomszemcsés preempciót használó hardverek, mint a Tonga és a Fiji.
(#10143) NetTom: Az Oculus a Facebooké.
Szerintem az ilyen befektetési csoportokat annyira nem érdekli, hogy business vagy experience vonalról válik be egy dolog. De önmagában a VR egy business is lesz, mert a VRLA-n már elég sok ötlet merült fel az orvosi felhasználásról, oktatásról, stb. Lehet, hogy ez érdekli őket igazán.
Egy biztos, hogy nem a Zen érdekli őket, mert az csak egy szimpla processzor. -
#10141
Abu85
HÁZIGAZDA
FollowTheORI
#10139
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#10139
üzenetére
Nem teljesen. A VR a kulcs, mert az a piac felfutóban van, és az AMD egyedül kínál csomagot hozzá, egészen addig, amíg nem lesz szabvány. Ez érdekli őket, nem a Zen.
A Silver Lake amúgy is nagyon érdeklődik manapság a VR célpontok iránt.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#10082
üzenetére
Amit az Ubisoft akar az más. Oda ExecuteIndirect kell, de ezt a Unity még nem jól használta a konzolokon. Nem is igazán lehet használni magas szintű eléréssel. PC-n is csak az AMD-n érhető el ez a fícsőr DX11-ben, ráadásul ott is egy AGSL kiterjesztéssel, ami ugye a multi-draw indirect. Ilyen kiterjesztés az Intelhez és az NV-hez nincs.
A SIGGRAPH alapján az Ubi valszeg átvált teljesen DX12-re azért, hogy PC-n is működjön az ExecuteIndirect, mert annak meg nincs értelme, hogy DX11-ben csak AMD-re írnak játékot. Persze azt nem tudom, hogy más csinál-e multi-draw indirect kiterjesztést. Erre van opció, de igazából felesleges, amikor ott van szabványosan a funkció a DX12-ben. Esetleg OpenGL4-DX11 interoperabilitás lehetséges, de nem hiszem, hogy ez minden vágyuk. -
#10069
Abu85
HÁZIGAZDA
tibcsi0407
#10068
Abu85
HÁZIGAZDA
válasz
tibcsi0407
#10068
üzenetére
A valós különbségről sokat elárul a Nitrous. Ezt a motort úgy építették, hogy minden gyártóval együttműködtek, és egy évvel korábban megosztották velük a teljes forráskódot. Ez a normális fejlesztés. Sajnos lesznek olyan fejlesztések, ahol megírják a kódot az Xbox One-ra, és azt egy az egyben áthozzák PC-re. Na az gáz lesz, mert sokkal rosszabbul teljesíthet benne minden nem GCN architektúra, csupán azért, mert minden döntést csak a GCN-t szem előtt tartva hoztak meg. Ebből lesz szerintem a jövőben a probléma, nem az olyan fejlesztési modellből, amit az Oxide folytat a Nitrous esetében.
Az világosan látszik, hogy az Oxide járja most a nehezebb utat azzal, hogy mindenkire optimalizálnak, viszonylag sokat. És ez előtt le a kalappal, de félő, hogy a többség csak az XO-ra fog optimalizálni. -
#10066
Abu85
HÁZIGAZDA
tibcsi0407
#10060
Abu85
HÁZIGAZDA
válasz
tibcsi0407
#10060
üzenetére
A naiv konzolportok rosszabbak lesznek, mert olyan kódot is át lehet hozni az Xbox One-ról, amely sokkal rosszabb hatékonysággal fut a többi architektúrán, mint például a Nitrous. Ez azért nem egy átgondolt stratégia sajnos, függetlenül attól, hogy az MS arra buzdít, hogy jó az Xbox One kód PC-re. Persze GCN-re jó, de a többire egyáltalán nem az.
-
#10057
Abu85
HÁZIGAZDA
tibcsi0407
#10054
Abu85
HÁZIGAZDA
válasz
tibcsi0407
#10054
üzenetére
Azt nem kell implementálni, mert a feldolgozási modell követeli meg a TIER3 bekötést. Arra kell írni a kódot, és azt a kódot tudja az API úgy kezelni, hogy fusson az alacsonyabb szinteken. Maga a DX12-ben nincs definiálva az, hogy csak TIER2 vagy TIER1 bekötésre írsz programot. Ilyen formában egy kód nem fut az API-n, mert a Shader Modell 5.1 hiányolni fogja a shaderekben a bekötést. Nem fogja lefordítani a kódot D3D bájtkódra, mivel az API nem fogja tudni kezelni a shaderbe írt memóriaelérés nélkül. Erre a validátor fel fogja hívni a figyelmet.
-
Abu85
HÁZIGAZDA
Lényegében igen. Valójában persze a Mantle kell, de az a LiquidVR alapja.
Igazából nem ez az AMD igazi VR csodafegyvere. Fontos dolog, de a Latest Data Latch miatt olyan alacsony az AMD VR csomagjának késleltetése. Ez ugyanis lehetővé teszi, hogy a fejpozició közvetlenül a GPU-s számítás előtt legyen meg. Minden más VR rendszer a jelenetszámítás előttről szerzi ezt az adatot, és ez ad hozzá az egészhez úgy 5-10 ms-os extrát.
-
Abu85
HÁZIGAZDA
Szerintem a VR-nél ne keverjük a szoftveres problémát a hardveressel. Az AMD implementációjának azért olyan alacsony a késleltetése, mert a VR egy VR-re tervezett API-n keresztül működik. Az NV-nek csak a szabvány API-k maradnak, amelyeket nem terveztek olyan igénybevételre, amilyet a VR követel. Függetlenül attól, hogy a hardver mire képes, a szabvány API-k nem alkalmasak a megfelelő késleltetésre. Akkor lesz ez a VR alkalmas a legtöbb hardverre, ha a szabványos VR API-k elkészülnek.
-
Abu85
HÁZIGAZDA
Ki van zárva. Mondom, hogy lesz olyan gyártó, aki egyetlen egy Nano VGA-t szállít EU-ban. Az USA már három számjegyű mennyiségét kap, de a gyártók nem fogják odaadni a kereskedelmi forgalomba szánt termékeket. Akik sokat kapnak azok az OEM-ek, na ők aztán biztos nem adnak tesztre. Szóval az a pár darab lesz, amit az AMD tesztre szán, és azok kapnak, akiknek az olvasottsága magas. Akik esetleg kedveltek, de az olvasottsaguk alacsony, azok biztosan kimaradnak az NDA lejártára. Nyilvan itt az a probléma, hogy ebben a formában a kisebb oldalak vannak háttérbe szorítva a nagyobbakkal szemben. Arról például a TechReport nem tehet, hogy nem olyanok a forrásai, mint mondjuk tomnak. A TPU egészen mas kategória. Ők NDA-t szegtek régebben, és ezt manapság az AMD nem nézi el. Más Radeont sem kaptak már korábban. Ezen úgy tudnak változtatni, ha kifizetik a bírságot, ami nagyon durva pénz. Esetleg nagyon be kell puncsolni, és akkor talán újra megy a csomag.
-
Abu85
HÁZIGAZDA
válasz
wjbhbdux
#9895
üzenetére
Az aktuális tervekben egyetlen gyártó sem készít speciálisan Steam Machine PC-t. Alapvetően annyi lesz, hogy lesz pár alapgép és arra telepíthető Windows és SteamOS. A gép ugyanaz, de az előlapi logó eltérő. A legtöbb Steam Machine egyébként továbbra is Windowszal lesz szállítva, mert az MS egy rakás játékra Windows exkluzívitást kötött. Olyan játékokra, mint az új Tomb Raider. Ez azért nem kis tényező.
-
-
Abu85
HÁZIGAZDA
válasz
#85552128
#9888
üzenetére
Mert az OEM-ek vinnék már az ünnepi szezonra. Ahhoz, hogy meglegyen a kínálat novemberben, most rendelik le a készleteket. Ide megy majdnem minden Nano, mert a pici izmos lesz a menő karácsonykor, legalábbis az OEM-ek koncepciója szerint. A Nano pedig a legerősebb apró VGA.
-
Abu85
HÁZIGAZDA
Nincs pedig. Szinte mind a piacra megy. Kb. egy tucat kártya van tesztekre globális szinten. Ilyen helyzetben gyakorlatilag az olvasottság dönt, és ebben a TechReport nem olyan jó, mint mások, sőt kifejezetten rosszak. Egész Európába két számjegyű mennyiség érkezik a Nanoból a start hetére. Lesz olyan gyártó, aki csak egyetlen egy kártyát szállít le.
-
-
Abu85
HÁZIGAZDA
Az nincs megerősítve, hogy ki nyert, de az Imagination, az Intel és az AMD futott versenyt. Valszeg behúzta az AMD. Az Intelnek semmi esélye nem lehetett, mert nem vállaltak egyedi tervezést. Az Imagination valszeg jó esélyekkel indult, de többet érhetett, hogy hasonlítson a dizájn a két nagy konzolra.
-
Abu85
HÁZIGAZDA
Ez az egész bullshit. Az NV és az AMD rendelkezik keresztlicenc szerződéssel. Még ha le is jár úgyis megújítják. 3D Stacking technikával nem lehet ekkora teljesítményt kihozni. Ha az NV-nek nem lesz Pascalja 2016-ban, akkor az azért lesz, mert zéró tapasztalattal ugrottak neki a HBM2-nek. A Hynix többször is mondta, hogy előbb mindenki a HBM1-et implementálja.
-
Abu85
HÁZIGAZDA
A konzol is ugyanazt a leképzőt használja. Bár azt nem tudom, hogy melyik eléréssel, valszeg nem a low-levellel, de a JC3 már az lesz elvileg. Az meg nem akkora meglepetés, hogy Emil Persson ért hozzá. Ő eleg durva dolgokat csinált akkor is, amikor az ATI-nál dolgozott. Kb. olyan kaliber a srác, mint Johan Andersson.
-
Abu85
HÁZIGAZDA
Dehogy is. Ez már az új Avalanche motor, persze nem aktív benne minden, mert a fő projekt a JC3, de az alap ugyanaz lesz.
A Mad Maxet valószínűleg sietette a WB, de így is jól van optimalizálva. Később meg javíthatnak rajta a patchekkel, ahogy elkészülnek az új verziók a motorból.
-
Abu85
HÁZIGAZDA
Ez nem függ a CPU-magok számától. Maga a multi-engine sem függ össze a többszálú parancskreálással. Aranyszabály erre nincs, de jelenleg egy compute, egy grafikai és egy copy motor az ajánlott, vagy elterjedt. Később a compute motorok száma kettőre nőhet, de csak akkor, ha több regiszter lesz a GPU-kban, vagy a jobb IR-ek alapján (pl.: SPIR-V) ezek allokációja javul. De ma biztos nincs olyan program, ami egynél több compute motort használ.
Azt hiszem, hogy a PS4-es Dreams lesz az első, de az full compute, hiszen signed distance fields ray tracinget használ. -
Abu85
HÁZIGAZDA
Nem. A Nano is Fiji. Valójában egyik GCN3-as GPU-ban sincs nyolc ACE. Négy ACE van két HWS-sel. Az a lényeg, hogy egy HWS pontosan arra képes, mint két ACE, tehát lehet jelezni 8 ACE-nek vagy 4 ACE-nek és 2 HWS-nek is. A HWS extra képességei, mint a finomszemcsés preempció kezelése vagy a Quality of Services támogatása HSA, illetve LiquidVR alatt használhatók ki. Később ezekre majd lesz a szabványos API-kban is támogatás, hiszen a VR-hez kell a finomszemcsés preempció.
Technikailag csupán a DX12, Vulkan és OpenCL API-kre levetítve teljesen mindegy a blokkdiagramm. A 8 ACE és a 4 ACE+2 HWS is ugyanúgy 8 OOO logikás compute motort ad motoronként 16 parancslistával.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#9606
üzenetére
Az Intel a gen8-tól kezdve több compute parancslistát kezel, illetve a gen9 a Skylake-ben már képes mixált módra is, így képes egyszerre fogadni egy grafikai is több compute parancsot. Viszont az Intel ezt a képességét a driverben letiltja. Valószínűleg nem bíznak annyira a fejlesztőknek, mint az NV, hogy a hardverük miatt több path-ot írnak. Nem véletlenül olyan a DX12 amilyen. Ha a hardverben nem jó a multi-engine, akkor a driver ne jelezze vissza rá a hardveres támogatást, és akkor minden parancs a grafikai listába kerül. Ez pont azért van így felépítve, hogy a fejlesztőknek ne legyen szükséges architektúrákra butított kódot írni. Mondjuk egy Oxide megteszi, mert pénzesek, de szerintem lesz olyan, aki nem fogja extra munkában verni magát. Mondom ezt úgy, hogy szerintem az Oxide hozzáállása tényleg példás és követendő.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Szerintem te nem olvastad el a DX12 specifikációját. Ezért hiszed, hogy az aszinkron compute kikapcsolható. Ekkor ezt tegyük tisztába. A multi-engine a DX12 alap képessége. A feladatok jellege alapján ezek három motorba tölthetők: copy, compute és grafika. Így kell kötelezően írni egy DX12 alkalmazást. A fences használata, ami nem kötelező, de aki async kódot írt az biztosan használja. Innen az egész async compute csak úgy kapcsolható ki, hogy az eredeti kód mellé kerül egy olyan kód, ami a validátor javaslatai ellenére mindent a grafikai parancslistába tölt. Persze ez lényegében egyenlő a kikapcsolással, de ez nem olyan munka, hogy írnak egy sort a kódba, hogy OFF és kész.
-
Abu85
HÁZIGAZDA
Az AotS-ben csak annyit csináltak, hogy a validátor javaslatait ellenére van egy olyan path, ami minden feladatot a grafikai parancslistába tölt be. Semmi sincs igazából kikapcsolva, csak az NV kérésére írták egy validátoron hibazó szabványos kódot is. Ami azért extra munka. Nyilván puszi a hasukra érte, de a legtöbb fejlesztő a validátorra fog hallgatni. Az mondjuk megint marha jó kérdés, hogy a validátort az MS miért vette át egy az egyben az AMD-től. Tudhatták, hogy az a GCN-hez van igazítva, amikor visszajelez bizonyos problémákat. Honnan a fenéből tudja egy fejlesztő, hogy a validátor javaslata jót tesz-e a többi architektúrának. Még ha rá is jönnek a kiadás előtt, hogy nem, akkor sincs már idő lényeges módosításra. Ezért kedvezőbb a Vulkan, mert ott ugyan az AMD validátora az alap, de a nyílt specifikáció miatt lehet alternatív validátorokat fejleszteni.
-
#9583
Abu85
HÁZIGAZDA
huskydog17
#9563
Abu85
HÁZIGAZDA
válasz
huskydog17
#9563
üzenetére
Gondolom a Rise of the Tomb Raider olyan fejlesztés lesz, mint a Fable Legends. A PC-s port annyi lesz, hogy az Xbox One kód kap pár sor kiegészítést, és azt tesztelik. Az MS ezért hozza ennyire közel a konzolt és a PC-t szoftveres szempontból, hogy végtelenül egyszerű legyen portolni.
-
Abu85
HÁZIGAZDA
Nem kamuzott senki. A DX12 specifikációja azt követeli meg, hogy a multi-engine hardveres kezelése szempontjából a hardver képes legyen minimum egy copy, compute és grafikai feladatot egyszerre fogadni. Ennek a feltételnek a Maxwell 2 megfelel. Arra már nincs előírva specifikáció, hogy ezek a feladatok a hardverek belül is futhassanak egyszerre. Következésképpen az is elfogadott implementáció, ami nem hoz gyorsulást minden kódnál. Erre nincs is meg a lehetőség, mert nagy a fejlesztők szerepe. Az NV mindig is annyit mondott, hogy támogatják ezt a képességét, amikor erre irányult a kérdés, azt viszont sosem állították, hogy ennek a használata mindig pozitiv hatással van a sebességre.
-
Abu85
HÁZIGAZDA
A multi-engine kötelező funkció a DX12-ben. Ezért fogadja el rá az MS a szoftveres támogatást. Maga a validátor ki fogja adni a kódvalidálásnál, hogy mely feladatok vannak rossz engine-be töltve. Szóval itt nincs olyan, hogy nem támogatja a program. Maximum nem lesz ra szinkronizálás, de ettől egy adatfeltöltésre ki fogja adni a hibát a validátor, hogy nem a copy engine-ben van a feladat.
-
Abu85
HÁZIGAZDA
Látszólag a DX12 implementációk nincsenek normális szinten. Nagyjából megcsinálták őket stabilra, de sebesség egyelőre nincs bennük. De a stabilitás is kérdéses, abból kiindulva, hogy az ARK DX12 patch csúszik. Szóval itt a rendszer még közel sincs kész. Emellett az Oxide is írta, hogy még jönnek Win 10 update-ek a DX12-höz, és ha ez igaz (nyilván miért hazudnának), akkor maga az API sincs teljesen összerakva. Az Intel driverével pedig egyáltalán nem indul el az AotS, tehát vannak itt még gondok. Szerintem egy jó két hónap még kell ahhoz, hogy a DX12 implementációk jobban működjenek. Persze szerencsére ez régen sem volt másképp, szóval ezt valószínűleg mindenki bekalkulálta. Azt persze jó lenne tudni, hogy a meghajtók miket kezelnek teljesen és mi az, amit egyelőre csak stabilan támogatnak, de a sebességre nincsenek kigyúrva.
Igazából a Maxwellen is működik a DX12. A batch submission time jelentősen csökkent a DX11-hez képest, tehát maga az API a várakozásoknak megfelelően teljesít. A többi része a dolognak már implementációtól függ, és itt majd az NV-nek ezt ki kell vizsgálnia. De gondolom ők is tudják, hogy milyen optimalizálások nincsenek engedélyezve.
A lassulásnak egyébként lehetnek olyan okai is, hogy a DX12 változtat a működésen a DX11-hez képest. Egy csomó dolgot a driver már nem tud befolyásolni. Például a hazárdok kezelését, az erőforrások menedzsmentjét. A GDC Europe alatt volt egy előadás, ahol azt mondták, hogy az erőforrás-kezelés nehéz lesz, mert a motorra hárul a feladat, de csak egyszer kell jól összerakni és akkor oké lesz. Erre volt az a kérdés, hogy melyik architektúrára, és az MS-es csóka mondta, hogy a dokumentációk átvizsgálása után érdemes olyan irányt keresni, ami minden architektúrának úgy ahogy jó. Ez már hozhat egy olyan mértékű változást, ami csökkenthet a tempón, mert eddig a drivert ki volt gyúrva architektúraspecifikusan, míg most a programkód teljesen kiváltja, ráadásul a fejlesztőtől függ a teljesítmény is. Aztán az aszinkron compute nem csak egy DX12 only dolog. Hivatalosan az, de a DX11-nél nem a program, hanem a driver töltötte be a feladatot a parancslistába. Függetlenül attól, hogy az alkalmazás nem, a driver ismeri a hardvert, tehát ráhackelhető némi párhuzamosítás a rendszerre. Persze ez nagyon korlátozott lesz, mert szinkronizációt a driver sem tud tökéletesen biztosítani, de valamennyi sebesség nyerhető vele. Ilyen szempontból az NV DX11-es drivere elég jó volt, de ezt a kutatást teljesen kidobhatják, mert ilyenre a DX12 már nem ad lehetőséget. Ezzel az NV inkább sebességet veszít mint nyer. Szerintem több ilyen apró trükk van a DX11 meghajtójukban, aminek az előnyeit a DX12-vel teljesen elvesztik.
A jövőben egyébként nem gondolnám, hogy az NV megmarad annál a politikánál, amit most folytatnak. Láthatóan hátrányos a program oldali optimalizálásra, hogy a fejlesztők nem ismerik eléggé a GeForce-okat. Mindenképpen szükséges lesz a dokumentációk újbóli publikálása. Legalábbis más út egyelőre nem látszik, hiszen a hardvert nagyrészt az alkalmazás fogja vezérelni. -
Abu85
HÁZIGAZDA
válasz
#35434496
#9506
üzenetére
Az Ashes of the Singularity az. Egy csomó játékmód nem is lesz elindítható DX11 alatt. Nem lenne meg a sebesség a futtatáshoz.
(#9507) wjbhbdux: Lesz DX12 only játék. A Fable Legends és a Rise of the Tomb Raider. De újabban arról van szó, hogy a Gears of War felújításból is kiveszik a DX11 módot, mert csak időpazarlás lenne az optimalizálása.
(#9509) gbors: Az aszinkron compute-ot minden DX12-es drivernek vissza kell jeleznie. Ezen belül jelezni kell a program felé, hogy valóban ott van a képesség a hardverben, vagy pusztán a követelmények teljesítése érdekében jelzi a támogatást. Ez azért kell, mert tisztán aszinkron compute-ra írt kód esetében a szoftveres emuláció ronthat a teljesítményen, így a programba nem árt belerakni egy alternatív kódot is, ami csak natívan grafikai parancslistába dolgozik. A driver visszajelzése alapján az egyik opció kiválasztható. Az NV drivere azt jelzi vissza, hogy tudja a hardver ezt a képességet, és ez technikailag így van, de az API és a program már nem képes értelmezni, hogy a hardver belül hogyan tud futtatni párhuzamosan feladatokat. Szerintem itt az alapprobléma az, hogy az API-nak ezt a részét az AMD építette, és a Microsoft csak úgy átvette. A GCN stateless architektúra, tehát a compute feladatok futtatásához nem kell beállítani hardverállapotot, vagyis akármit is futtat a rendszer mellette biztosan futtatható több compute feladat. A Maxwell parancsprocesszora képes fogadni a compute és grafikai feladatokat, de a compute is hardverállapothoz kötött, ha a compute feladat már hardverállapotot igényel, mint a futtatott grafikai feladat, akkor állapotváltásra van szükség, ami előfordulhat, hogy lassabb, mintha soros lenne a végrehajtás. Valószínűleg az Ashes of the Singularity ebbe a hibába esett bele, olyan compute feladatot futtat a grafikai mellett, amire a Maxwell képtelen, annak ellenére, hogy elvben a támogatás hardveres szinten is megvan, legalábbis abban a formában, ahogy az API megköveteli. Ezt úgy orvosolták, hogy a programon belül kapott a rendszer egy tiltást, hogy Maxwellen annak ellenére se fusson aszinkron compute, hogy a driver erre a támogatást hardveres szinten jelzi. Ebbe a hibába egyébként sokan beleeshetnek, mert a DX12 és a Vulkan is logikailag úgy kezeli a hardvereket, hogy azok stateless compute képességgel rendelkeznek, tehát nincs lehetőség programkódban ellenőrizni, hogy milyen feladatokhoz milyen állapot beállítása szükséges. Ezért nem jó, ha egy hardvergyártó tervezi az API-kat, mert jó eséllyel nem gondol a konkurens architektúrák működésére. Most tulajdonképpen hiába felelnek meg az Intel és az NV új megoldásai a multi-engine képességnek, ezek a kódok esetleg lassíthatják a feldolgozást. Nem véletlen, hogy az Intel drivere szoftveres szinten jelez vissza támogatást, annak ellenére, hogy megvan a hardveres is. Valószínűleg az NVIDIA számára is jobb, ha általánosan letiltják ezt a képességet, mert nem tudják majd az összes stúdió kezét fogni, és kérni a program oldali tiltást. Ha pedig ez nincs, akkor a GeForce sebességet veszíthet.
De a driver is paraméterezhető. Ma a támogatás azért problémás, mert az aszinkron compute szinkronizációt igényel, de a kiadott meghajtók ebből a szempontból nagyon korlátozottak, és esélyes, hogy a szinkronizálás lekezelése helyett inkább befűzi a sorba az elvileg aszinkron feladatot. Persze nyilván a fejlesztőknek már vannak olyan meghajtóik is, amelyek nem így működnek. Az Oxide tapasztalatai nyilván ezekre épülnek.
Egyébként nem ők az egyedüliek, akik azt mondják, hogy a GCN ebben bitang jó. A Fable Legends fejlesztői is utaltak arra, hogy az AMD-nek ez az újítás nagyon fekszik. A kérdés, hogy ebben mennyi szerepe van annak, hogy a kódokat a konzolok miatt GCN-re írják, illetve ez mennyiben rontja a konkurens hardverek hatékonyságát. Valószínűleg a Maxwellnek abszolút nem ideális az, hogy a motorokban az egész multi-engine stratégiát a GCN-ek publikált paramétereihez konfigurálják. Jó lenne tudni, hogy ha a Maxwell dokumentálva lenne, és ezáltal tudnák a fejlesztők, hogy erre milyen konfiguráció kell, akkor ez a lassulás bekövetkezne-e, vagy gyorsulást hozna az aszinkron compute.(#9512) daveoff: A Frostbite mindenképp a Vulkan irányába megy. A WDDM 2.0 használatához nem feltétlenül szükséges a DX12, jó neki a Vulkan is. A Vulkan egyértelmű előnye az EA számára, hogy nekik a vezérplatformjuk a PS4, és arra lesz Vulkan. Nincs még bejelentve, de lesz. Emellett a Vulkan API-val képesek olyan piacokat is lefedni, amelyeket ma még nem tudnak. Például Linux (SteamOS) és Android. Emellett a Vulkan hatalmas előnye, hogy van SPIR-V támogatása, tehát nem kell magukat a HLSL-hez láncolni, ami azért egy elég öreg nyelv már. A konzolokon jobb shader nyelvek vannak, és a SPIR-V lehetővé teszi azokat a képességeket PC-n is, amelyek HLSL-ben nem használhatók ki, de a konzolon már igen.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#9494
üzenetére
Nem valószínű, hogy a kiadás pillanatában lesz DX12. Maximum egy patch-csel. Maga a játék egyébként támogat DX11-ben nem létező funkciókat, mint a multi-draw indirect, de ez nem szabványos rendszer. Azt sem tudni még, hogy tartalmaz-e a program OpenGL interoperabilityt, hogy ez NV-n és Intelen is működjön, mert enélkül csak az AGSL3 üzemképes Radeonokra. De maga a motor jól optimalizáltnak tűnik, szóval nem lesz ebből gond. Különösen jót tett a fejlesztésnek, hogy rengeteg kód D3D bájtkód manipuláció, tehát nem csak szimplán HLSL-ből lefordított, hanem még kézzel szerkesztett is.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#9487
üzenetére
Valójában ez a játékoktól is nagyon függ. A Kepler főleg azokban a játékokban szenved, amelyek GameWorksösek (nyilván aktívnak kell lennie a GameWorks effekteknek), vagy nincsenek optimalizálva független parancskiosztásra, vagy nagy regiszterigényű über-shadereket használnak. A Keplerre nagyon specifikus shader kell, mert ez az architektúra multiprocesszoronként négy dispatchet használ hat felfűzött streamre. Ha a shaderben nincs benne, hogy a program felfűzhet független utasításokat is, akkor minden Kepler GPU elveszti a rendelkezésre álló feldolgozók 33,3%-át. Ezen még ront az, ha rossz a regiszterallokáció, mert azzal további feldolgozók veszhetnek oda.
A legtöbb fejlesztő egyébként figyel erre, pontosan tudják, hogy hol szenved a Kepler, és elég tapasztalat van arról, hogy ezt kezelni tudják. Akkor lehet probléma, ha a Keplert direkt elvéreztetik, hogy a Maxwell előnye nagyobb legyen. Nyilván van az a pénz, amennyiért ezt egy fejlesztőstúdió bevállalja, és még az NV is hajlandó kifizetni. Ez ellen nem lehet mit tenni. Alapvetően a média felelőssége az, hogy az ilyen játékokat ne rakja be a tesztcsomagokba, mert ez egy korábbi architektúra teljesítményének mesterséges kolátozza valamilyen okból. Erre egyébként elég jól fel lehet figyelni. Ha vannak olyan helyzetek, ahol egy GTX 960 úgy teljesít, ahogy egy GTX 780, akkor az minimum gyanús, és ilyen például a Witcher 3 és a Project Cars bizonyos beállításokkal. Ez persze még mindig nem jelenti, hogy az NV pénzt adott a Kepler optimalizálásának hiányáért, de valamiért ez hiányzik a programból, és a TWIMTBP logók miatt az sem lehet indok, hogy valamelyik alávaló gaz konkurens keresztbe akart tenni. -
#9473
Abu85
HÁZIGAZDA
FollowTheORI
#9468
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#9468
üzenetére
Az UE4 más játékban is ilyen, szóval a teljesítményprobléma forrása a motor. Ennek a motornak nem az API-val van gondja, hanem azzal, hogy két leképzőt támogat. Egy forward opciót a mobilba és egy temporal deferred alternatívát a DX11-hez. Mivel az UE4-et AAA projektekhez a nagy kiadók már nem licencelik, így a mobil leképző kapja a fókuszt, míg az alternatív leképző optimalizálása egyelőre nagyon rossz. Természetesen az Epicnek is korlátozottak az anyagi erőforrásai, így olyan helyre invesztálnak, amely eladást hoz számukra. A DX12 annyiban jelent könnyítést, hogy az UE4 DX11 kódja meglehetősen limitált, mert a PC kapja a legkisebb fókuszt és ezen belül a legnagyobb probléma, hogy az erőforrásokat hogyan hozzák létre úgy, hogy ne legyen nagyon korlátozott a teljesítmény. Nyilván DX11-ben nem lehetséges a futtatási időben létrehozni azokat, de DX12-ben már igen, és itt pont szereznek annyi előnyt, amennyivel a DX11-es leképző rendkívül gyenge sebességét előremozdíthatják. Ennek persze az lesz a hátránya, hogy a DX11-es kódot már sosem rakják normálisan össze, mert nincs értelme hónapokat eltölteni ennek az optimalizálásával, amikor van DX12, és ott az erőforrás-kreálás sokkal kedvezőbb formában megoldható. Innen egyébként nekik nagyon egyszerű lesz a DX12-vel sebességet hozniuk, mert a DX11 kód hibáit ki tudják ütni. Ezért is lesz érdekes ez a patch, mert ez lesz az első projekt, ahol a low-level váltást nem tökéletesre csiszolt DX11 leképzőkhöz hasonlítjuk, hanem egy olyanhoz, amely meglehetősen rossz optimalizálással rendelkezik.
De az is látszik, hogy még a DX12-ben sem fókusz a PC. Az UE4 csak a kötelezően támogatandó dolgokat kezeli, mint a többszálú parancskreálás és az aszinkron DMA/compute, illetve lesz multiadapter mód, hogy az IGP teljesítménye hozzáadódjon a dGPU-hoz, de sajnos a hagyományos több GPU-s rendszerekre (2-3-4 ugyanolyan VGA) már nem lesz támogatás. Valószínűleg ezt már túl költségesnek érzik, hogy specifikus multiadapter implementációt írjanak rá. -
-
Abu85
HÁZIGAZDA
Nem az a baj, hanem, hogy egy hozzászólásra építi fel az egészet, ami ráadásul sok helyen nem is pontos.
Az async shaderre még mindig csak a Thief az egyetlen PC-s példa. Bár az AotS támogatja, mert a DirectX 12 alapból megköveteli a multi-engine működést, de a driver dolga, hogy ezeket felfűzze a különböző parancslistákba, majd időben futtassa. Egyetlen kiadott driver sem képes még erre, tehát a hardver előtt az elvben async DX12 kód mindenképp sorba lesz fűzve. Később majd lesznek persze olyan driverek, amelyekkel már ez a konstrukció működni fog.
Az async shader kapcsán két példa van előttünk. A konzolos játékok és a PC-ből a Thief. Tehát tulajdonképpen mondhatjuk, hogy működik a rendszer egy bizonyos hardverre, illetve architektúrára levetítve, és ezt nem csak én mondom (nyilván példa van rá), hanem Max McMullen is mondta a SIGGRAPH Q&A szekción, hogy egy architektúrára vonatkozóan az async shader tökéletes megoldás. De mi van több architektúrával? És itt jön elő az igazán nagy nehézség, mert két architektúra már másképp működik, illetve ahhoz, hogy tényleg nagy előnye legyen az async shadernek a mai korlátozott motorokban, nagyon kell bújni a dokumentációkat, hogy mi engedhető meg a hardveren és mi nem. Ebből a szempontból a DX12 multi-engine specifikációja legalább jól van összerakva. Minden programozó kötelezően multi-engine kódot ír, és majd a driver eldöntheti, akár egyéni profillal, hogy azt a kódot tényleg több motoron keresztül küldi rá a hardverre, vagy inkább korlátozza egy motorra. Ezért volt jó döntés az, hogy a copy motor kiterjesztése a compute motor és ennek a kiterjesztése a grafika. Ha a hardver nem tud async copy-t, akkor a driver ráküldheti a compute motorokra, ha ezt sem tudja, akkor végső esetben ott a grafikai feladatok parancsmotorja. És ez nyilván a gyártók felől úgy is elbírálható, hogy a hardver esetleg tudja ezeket a képességeket, de az async kód lassulást hozna, akkor inkább az adott játékra megszüntetik az async copy és compute lehetőséget, így minden parancs a grafikus parancslistába megy.
Ennek szerintem elég nagy jelentősége lesz, mert a legtöbben a kötelezően multi-engine kódot az Xbox One-hoz fogják szabni, tehát az időzítés, illetve a shaderek regiszterhasználata ehhez fog igazodni. Viszont ez nem mindegyik gyártónak jó. Például az Intelnek nagyon nem, és az eddigi adatok alapján az NVIDIA-nak sem, tehát nekik kell egy kerülőút, hogy legalább a programkód lassító hatását ki tudják ütni a driverekkel. Aztán később az Intel és az NV is hozni fog egy stateless compute architektúrát, out-of-order logikával dolgozó compute motorokkal. Ebből a szempontból a DirectX 12 működését érdemes lekövetni, ha már a Microsoft ennyire az Xbox One-ra szabta a rendszert.
-
Abu85
HÁZIGAZDA
A DirectX 12 és a Vulkan pontosan ugyanazt a validátort használja, amit az AMD a Mantle-re fejlesztett. Ez kiszűri ezeket a hibákat is, legalbbis a GCN-en biztosan. Itt majd az lesz a gond, hogy az AMD a validátor fejlesztését nem adta át a Microsoftnak és a Khronosnak, tehát magát a rendszert különállóan csatolják a DirectX 12 és a Vulkan API-hoz, vagyis a fejlesztést kizárólag az AMD végzi, és nem valószínű, hogy foglalkoznak majd azokkal a hibákkal, amelyek a GCN-t nem érintik. Ezért pörögnek nagyon az érintettek azon, hogy legyen egy nyílt forráskódú validátor is, aminek a fejlesztéséhez már hozzá is fogtak. Ennek majd sok előnye lesz, hiszen nem túl produktív az a piac, ahol a konkurensek validációs problémáira csak az AMD tud megoldást, ha akar persze. Az is hülye volt a Khronosnál és a Microsoftnál, aki ezt így elfogadta, mert az AMD simán mondhatja, hogy a validátor működik, mert GCN-en működik a program, még ha máson hibázik is. Ezzel senki sem tud majd mit kezdeni, mert a fejlesztőnek is nyűg lesz az egész program működését manuálisan lemodelleznie, hogy fényt derítsen a hibára. Az jó hír, hogy a Vulkan támogatni fog alternatív validátorokat, tehát az alapul szolgáló AMD-s rendszer mellé becsatolhatnak a programfejlesztők saját rendszereket.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#9349
üzenetére
Nagyrészt a programon múlik a működés, de például az allokációért, a shader fordításért, illetve a multi-engine esetében a fences kezeléséért még ma is a driver felel. A shader fordító az kb. ugyanaz, mint a DX11-es, szóval azon persze lehet javítgatni, de kvázi kész. Az allokáció viszont érdekes, mert a drivernek kell eldöntenie, hogy 64 kB-os, vagy 4 kB-os blokkokat használjon az adott pufferhez. Nem biztos, hogy ma jól döntenek a driverek, és ezen csak tapasztalattal lehet javítani. Végül a fences azért fontos, hogy az aszinkron feladatokat a driver tényleg jól időzítse, vagyis ténylegesen párhuzamosan fussanak a hardveren belül. Ma ez se feltétlenül működik jól.
A befolyás megszűnt, de ettől még pár dologról a driver dönt. De nyilván nem lehet a program hibáit driverből korrigálni.
Ú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.
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5060 Ti 8GB GAMER PC termékbeszámítással
- Lenovo T14s G2 Core i7 1185G7 16Gb 1Tb NVMe Érintőkijelző Intel Iris Boltból Számlával Garanciával
- Bomba ár! Dell Latitude 5290 - i5-8GEN I 16GB I 256SSD I 12,5" HD I Cam I W11 I Garancia!
- Vállalom Xianomi Okos kamerák, szoftveres javíttását
- Dell Precision 5530 15,6" UHD touch, i7 8850H, 16GB RAM, 4GB VGA, 512GB SSD, jó akku, számla, gar
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest