Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Ez nem feltétlenül ilyen egyszerű. Már nem mindenki látja annyira jónak ezt a GameWorksöt az NV-n belül sem. És nem arra gondolok, hogy a korábbi TWIMTBP zsenik (John McDonald, Timmothy Lottes, Cass Everitt, stb.) otthagyták a céget. Számold bele azt, hogy az egyetlen dolog, amivel ezt el lehet adni az a pénz. Viszont olyan fejlesztők szorulnak erre rá, akik nem nagyon törődnek a PC-s portokkal, mert így is szűkös az egész keret. Ezért szaporodtak el nagyon a rossz PC-s portok az NV oldalán, és nincs igazán lehetőség behúzni egy innovatív és jól optimalizált PC-s címet. Az már csak tetézi a bajt, hogy az AMD erre rájátszik ezekkel az üzenetekkel. Elég csak a bogár elültetése és az NV elvégzi a munkát a csomó fos TWIMTBP PC-s porttal.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
rocket
nagyúr
Szerintem meg o utana is ilyen lesz, az NV zsenialisan muveli a szoftvertamogatast, es nagyon magas eladasokat realizalnak ezzel.
Neha beut egy Batman Arkham Knight tortenet , ami aztan nehany het alatt lecseng, semmilyen szignifikans negativ hatassal nincs az eladasaikra.Az meg, hogy az AMD, Abu, meg nehany jatekfejleszto mit gondol a middlewareekrol, nem tantoritja el az NV-t, mindig lesznek akik hasznalni fogjak, es nem csak zs kategorias fejlesztok, legujabb pelda a COD3 ahol GW-t nem mondtak (meg) szo szerint, de az NV sajat kodot ir ami annyiban ter csak el attol, ha GW lenne, hogy az AMD megjelenes napjan majd kezdheti a hetekig tarto optimalizaciot, mig a GW eseteben erre nincs lehtoseguk, de ettol ugyanugy kar fogja oket erni, mert nem fogjak hozni a csoda Radeonok az elvarhato teljesitmenyt. (persze ez egyelore feltetelezes, de a history record alapjan nagy az esely, hogy ez fog tortenni)
Kivancsi leszek mikor jonnek ra az AMD-nel, hogy marketing eszkoznek nagyon jo a middleware, es csinalnak egy sajatot, persze mar nem lenne konnyu ~20%-os piaci reszesedessel megfelelo partnert talalni ehez.
[ Szerkesztve ]
"A lower resolution generally means that there can be more quality per pixel."
-
-
-Solt-
veterán
Az ilyen vakteszteken kijött eredményeknek én képtelen vagyok hinni. Csinált ilyet az AMD is, kétlem, hogy itt a topikban a többség elhinné, vagy egyetértene a végeredményével. [link]
Ettől függetlenül a megállapításaid java részével egyetértek, de azért pár dologgal kiegészíteném. Kiválasztottak két olyan FreeSync monitort, ami tudottan problémás, így eleve nem igazán van értelme még összehasonlítani őket. BenQ Asus
Az Asus esetében jött egy új firmware ami állítólag sokat javított rajta, de a tesztben nem szerepel, hogy a vakteszten résztvevő monitoron melyik firmware van. Az általam linkelt teszteken jól látszik, hogy 60Hz-n mindkét FreeSync-s monitor csak 2-s Lag Classification besorolást kapott, míg a két G-Sync monitor bőven 1-s besorolású, Asus, Acer. Innen nézve még hízelgő is a kapott végeredmény!
Jelenleg nincs még olyan FreeSync monitor a piacon, amivel rendesen lehetne prezentálni a technológiát. Nemrég volt itt hír a PH-n, hogy jönnek a Samsung megoldásai, illetve pár napos hír, hogy az Eizo is jönni fog FreeSync technológiával. Bízom benne, hogy a Dell is beáll a sorba, és akkor már lehet majd következtetéseket levonni.
Egyébként aki monitor kérdésben hiteles információt akar, az a TFT Central, vagy a Prad tesztjeit nézze meg.
www.smart-bus.hu
-
-Solt-
veterán
2014 januárjában volt az első FreeSync bejelentés, tehát a másfél évhez közelebb vagyunk mint a kettőhöz.
Új technológia, kevés vele a tapasztalat, szerintem egyáltalán nem tiszta még, hogy a monitor gyártók bénáznak, vagy maga a technológia defektes. Az összevetés vásárlási szempontból természetesen jogos, de ez csak az adott monitorra kivetíthető, magáról a technológiára nem lehet vonatkoztatni még. A cikk pedig úgy lett linkelve, hogy bukott a FreeSync a G-Sync ellen. Ez a következtetés igencsak korai még.
www.smart-bus.hu
-
Abu85
HÁZIGAZDA
De lehet. A notis G-Sync nem használ modult.
Egyébként meg mindegy a dolog. Az Acer és az Asus a G-Sync utolsó bástyája. De gyorsabban fejlődnek a FreeSync megoldásaik. Szóval a dolog ott eldőlt, hogy a G-Sync támogatók többsége kihátrált. A következő körben támogatnia kell az NV-nek a szabványt, mert két partnerrel nem lesz több kompatibilis termék évi 2-3 monitornál, míg a FreeSyncből dömping lesz. Már most is az van, hiszen 12 bejelentett G-Sync monitor van/készül és 0 tévé. A FreeSync 20 monitornál és 4 tévénél tart. Akkora túltermelés lesz a FreeSyncből, hogy bőven 90:10 lesz a FreeSync:G-Sync raktárkészlet arány, ami nem sok jót jelent a G-Syncnek. Az NV-nek sürgősen meg kell győznie a Samsungot és az LG-t, akár úgy, hogy fizetnek azért, hogy adjanak ki G-Sync kijelzőket. Itt az a kérdés, hogy az NV-nek a G-Sync csak üzlet vagy inkább presztízs.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mert tavaly még nem voltak számok, de ezek alapján mar tisztán látszik, hogy a G-Sync sorsa attól függ, hogy az NV fizet-e a Samsungnak és az LG-nek azért, hogy építsenek legalább évi 5-5 új kijelzőt rá. Erre egyébként meg van is esély, mert az NV-nek hátrányos lenne, ha a 3D Vision után befuccsolna egy új technikájuk azért, mert a monitorgyártók a saját érdeküket nézik. De ha pusztán az anyagi szempontok döntenek, akkor egyszerűbb csendben kivégezni, ahogy a 3D Visiont.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Ren Hoek
veterán
-
Ren Hoek
veterán
-
nagyúr
fixed for ya
Elindult az előrendelése annak a játéknak, amelyben lesz egy
Elérhető az abenchmark, aminek meg kellene mutatni, hogy a dx12GCNmennyire über, és a publikum számára nem elérhető ingyen, valamint egy darab tesztet nem látok vele. WTF?[ Szerkesztve ]
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
Abu85
HÁZIGAZDA
Pedig igaza van. Ez egy olyan teszt lesz, amit az új API-khoz terveztek, tehát alapvetően nem a hardverekre van kihegyezve, hanem arra, amit az új API-k kínálnak. Ettől még hardverteszt is, de a Microsoft elsődlegesen azért rajong érte, mert a DX11 benne nagyon gatya, és a DX12 brutálisan lealázza. Ez minden hardver esetében így lesz, és ez segít eladni a Windows 10-et.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Yllgrim
őstag
Lehet megmutatja miert is jobb a low level API mint amik elterjedtek, lasd DX11
Nem minden e-p@n!s meresere jo csak
Peace is a lie, there is only passion. Through passion, I gain strength. Through strength, I gain power. Through power, I gain victory. Through victory, my chains are broken. The Force shall free me.
-
Abu85
HÁZIGAZDA
Ezt ti magyaráztátok bele. Ez a motor arra készült, hogy megmutassa az új API-k fontos képességeit. Igen ezekben jó a GCN (pl.: multiengine), de ez nem jelenti azt, hogy ezt a tesztprogramot a GCN-re írták. Valójában egy tök szabványos program, aminek a fejlesztésében mindenki részt vett.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Semmit sem állítottam a teljesítményről, de igen az AotS nem egy sávszélbarát program, mert annak, hogy nem maximum 8, hanem sok száz shadow casting fényforrás van benne, az nyilván fájni fog a mai hardvereknek. De a Nitrous fejlesztésének a célja az volt, hogy olyan területre merészkedjenek, ahol előttük még nem járt senki. És ezt nem igazán a hadverek teszik lehetővé, hanem az új API-k. Ezért fontos ez a program.
Ha nem lennének új API-k, akkor ez a program nem született volna meg, függetlenül attól, hogy a hardverek megjelentek volna.(#8986) TTomax: Eddig is tudta a piac, hogy az aktuális technikákról való továbblépést a filmes CGI technikák jelentik. Csak az volt a kérdés, hogy melyik stúdió lesz az, amelyik mer arra költeni, hogy felhúzzon egy teljesen új motort erre. Az Oxide volt az, és erre kellene koncentrálni, mert elhihetitek, hogy nem egyszerű feladat olyan utat járni, amit még senki sem taposott ki. Ehhez képest csak egy GCN techdemóként gondolunk erre a programra, amire nem szolgált rá. Ennek a fejlesztésként sokkal nagyobb szerepe van.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Ren Hoek
veterán
Bezony ott a pont... én arra számítottam, mint extrém draw call meg anyámtyúkja, hogy 970 elvérzik.
Ehelyett heavy draw call-ban 30 FPS-t megy a szívószál 390 meg 32-őt
Rendes procival meg 290X szintjén van... HSM urat kérném a mikrofonhozAkkor hol is a negyedére lassulás ennyi compute pipeline alatt?
Egyébként annyi eredmény ahány teszt... kb kuka eredmények ezek szerintem. Örülök, hogy AMD kicsit felhozta magát, de sehol nem látok NV alázást.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Ráduplázni DX12-ben nem fog, hiszen a D3D bájtkód nem változott meg. A DX12 elsődlegesen azon változtatott, hogy közelebb vitte a működést a GCN típusú hardverekhez, hogy ne kelljen emulálniuk a bekötést, stb. Most persze a többi hardver emulál, kivéve a Skylake.
Az Oxide-nak nem számít, hogy dokumentálják-e az architektúrát. Dan Baker mögött komoly szaktudás van, hiszen elmondhatja magáról, hogy nem csak elsőként, hanem konkrétan egyedüliként rakott össze működő deferred context motort, illetve egyedüliként implementált Reyes-féle leképzőt valós időben, ami még több száz shadow casting fényforrást is kezel. Neki egy hardver visszafejtése nem téma, csak időbe kerül. A dokumentáció hiánya leginkább a kisebb tudással rendelkező programozókat fogja negatívan érinteni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A DX12 kódban a Nitrous még nem teljes. Nem véletlenül van mögé rakva az alpha, mert két szálra van limitálva a több szálú parancskreálás. Nyilván van egy csomó dolog a motorban, ami még nincs rákapcsolva, de tuti működni fog, mert az AMD saját API-jával működik. Eleve a DX12 implementációk csak öt! hetesek, és nem is stabilak. De ezek fejlődni fognak az elkövetkező fél évben, már csak azért is, mert vagy egy tucat DX12 update jön még a Windows 10-hez.
(#9212) schawo: Van benne AI, csak a mostani szinkronizálás ma még soros feldolgozásra kényszeríti a rendszert. Nyilván nem véletlen, hogy a legkisebb pálya lett megmutatva kevés egységgel. Ide elég ez a készültségi szint, és már látszik rajta a DX12 előnye. Az MS pedig örül, hogy végre kirakhat valamit az ablakba.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egy mítosz miatt az iparág nem dobja el a megszokott API-kat és kezd eszeveszett költekezésbe, mert nem egy, hanem rögtön két új API érkezik.
Az, hogy a Stardock képes annyi pénzt biztosítani Dan Bakernek, amennyit csak akar, egy rendkívül kivételes helyzet az egész iparágon belül. Nincs még egy olyan programozó, akinek megengednék, hogy két évet optimalizáljon DX11-re, amikor jobb eredményt hetek alatt kihozhat DX12-vel.Egyébként úgy is fogalmazhatunk a DX12-ről, hogy ha lenne hozzávetőleg 4 évnyi optimalizálási idő minden PC-s portra, akkor nem lenne szükség rá. De sokszor 4 hónapjuk, vagy rosszabb esetben 4 hetük sincs a fejlesztőknek optimalizálni, mert jövőre jön az új rész, és azt el kell kezdeni nagyban fejleszteni. Így már egészen durva igény mutatkozik a reformra.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
sayinpety
tag
Volt szerencsem AotS jatekmenetet latni. Zsenialis. Velemenyem szerint nagy hatasa lesz. Vizsgaljuk egy hasonlo ur RTS fejleszteset.
Anonimkent elmondok egy titkot. Nem szeretnem, ha felreertenetek. A PC jatekfejlesztes draga. Minden IHV ad bizonyos anyagi tamogatast. Enelkul nem fognank bele AAA PC portolasba. Tul kockazatos. Penzert cserebe kiallunk E3on, elmondjuk Radeon/Geforce/Iris kiraly es kapunk penzt. Exkluziv magasztalas tobb penz. Am egyetlen IHV sem tamogat olyan jatekot, ahol grafika nem jobb a konzolnal. Szerzodesben rogzitik. Ezert butitjuk a simulationt.
A jatekfejlesztes uzlet. Legtobb penzt harom platform port hoz es IHV tamogatas. Senki sem tudja mit hagytunk ki a jatekbol megjelenesig. Grafika butitast eszre veszik, am ha tudnatok mi marad meg ki, nem erdekelne grafika. -
HSM
félisten
Szerintem elég szélsőséges. Az egyik olyan játék, ahol DX-ben látványosan gyorsabb az Nv drivere maxgrafikán olyankor, amikor mindenféle szirszar repked a levegőben.
A felvetésem lényegi részére hogy nem válaszoltál, egyetértést jelent?
(#9273) rocket: A profit termelés kinek jó? Nekik! Nekem édesmindegy, nem vagyok egyik cégnél sem részvényes. Pontosabban nem mindegy. Ugyanis én még 3 év múlva is szeretnék PC-s játékokat játszani, és nem olyanokat, amik a csilli-villi grafika kedvéért a béka segge alá vannak minden más téren butítva, hogy az Nv drivernek is maradjon elég CPU-ideje a játékot vinni a hátán.
Bár lehet, végülis ez sem érdekel. Már egy ideje tizedannyira sem érdekel a PC játék, mint régen.(#9289) cyberkind: Engem hagyj ki ebből, nem piacrobbanást vártam a DX12-től, hanem egész más dolgokat. Amik nagyjából megvalósulni is látszanak.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Pont ez a baj ezekkel, hogy program oldaláról nem lehet szabályozni. Pontosan ez az oka annak, amiért mind a négy új API teljesen kidobta ezt a működési modellt. A Microsoft is megtanulta a leckét, hiába mondja meg, hogy mit tart ideálisnak, ha egy gyártó nem követi, akkor teljesen felborul minden. És a gyártók nézőpontja is érthető, szétszednék a PC-t a rajongók, ha látnák, hogy a konzolok megverik grafikában, de egy átlag user nem annyira képzett, hogy megértse miről kell így lemondania. És ez egyáltalán nem jó a usereknek.
Aztán persze az sem ideális szerintem, hogy add oda az egészet a fejlesztőknek, hogy boldoguljanak vele. De tulajdonképpen ez a két lehetőség van, és az egyik lehetőség elbukott, tehát marad az alternatíva.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
nagyúr
afaik ez a benchmark nem használ 4 magnál többet. legalábbis a 8magos haswell-e lassabb a 4magos skylane-nél. az fx nyerhet még némi teljesítményt, ha több szálat is használhat majd az engine.
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
Abu85
HÁZIGAZDA
Pedig a modell hibája. Ha ez nem ad lehetőséget a szabályozhatóságra, ilyenkor az implementációnak sincs lehetősége erre.
Nyilván az egészen egyértelmű, hogy a mostani modell nem működik, tehát egy másik irányt kell választani. Persze el lehetett volna azon gondolkodni, hogy egy olyan köztes modellt dolgozzanak ki, amivel szabályozni lehet a driver munkáját, de soha senki sem csinált ilyet, tehát nem tudjuk, hogy működne-e. A konzolon viszont a teljes szabályozást már csinálják a fejlesztők, és az működik. Szerintem a kérdéses és egy már bizonyított modell közül mindenki az utóbbit választaná.Korábban írtam, hogy ez a motor az L1 gyorsítótárból sok adatot másol a VRAM-ba, és ez érzékenyen érinthet olyan processzorokat, amelyeknek nincs integrált PCI Express vezérlőjük.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
nagyúr
lyukak vannak benne, de az i3 és az fxek látványosan capelnek 40 fps környékén. az fxek előbb, amit magyarázhat a gyengébb clock-to-clock teljesítményük. a 8magos (x2 ht miatt) haswell-e és a 4 (x2) magos skylake is hasonló fps-t produkálnak. ha van jobb elméleted, szívesen meghallgatom.
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
HSM
félisten
De ez nem megoldás! Éppen ez a lényeg! Ez egyfajta kompromisszum, az AMD egy másik, az Intel pedig egy harmadik. Mindegyiknek megvan a maga előnye és hátránya.
A BSOD-t okozó hibák szvsz igen hamar ki fognak bukni. Ha pedig kibuknak, ki lesznek javítva, amivel már játszani fogunk, nem nagyon fog BSOD-zni.
"Ha limitálom a szálak számát, akkor nem teszek nekik félre erőforrást, hanem maximálom, hogy mennyit vihetnek el. Ha ez nem elég a grafikára, akkor kevés lesz az FPS, és vissza kell venni a beállításokból."
Az AMD pontosan ezt csinálta, nem indított annyi szálat, mint az Nv drivere, és pontosan az is történik, pl. BF4-ben kicsit lejjebb kell venni a grafikát DX11 alatt (Ultra-->High), mert nem bír el a driver a sok repkedő szirszarral, amiket szétszór a játék Ultra-n.
Kicsit fura, hogy azt a megoldást írod rosszabbnak, amit magad is javasoltál megoldásnak egy másik hsz-ban. Most akkor hogy is van ez? Vagy én értettem félre valamit?[ Szerkesztve ]
-
HSM
félisten
Itt a jelentéssel volt gondom. A nem tökéletes megoldás azt sejteti, hogy egy problémának a megoldásáról van szó, miközben itt nem megoldják a problémát, csak odébbtolják, oldja meg a fejlesztő vagy vegyél alá húzott kórájszevönt.
Na, na... Az Intel nagyon is csinált. Egyszerű drivert, mint a faék. Nekik ugyanis a lehető legkisebb CPU munka árán kell teljesítmény, és az IGP-t se feltétlen kell nagyon megetetni optimálisan. Mindkettő oka, hogy a TDP keretben maradjon, és agresszíven turbózhasson a csip. Tehát ők szándékosan mentek erre a végletre.
Az AMD eredetileg egy köztes utat próbált tartani, de a friss drivernél ott is elmentek kissé az Nv driverének irányába, megjegyzem érthető okokból.
Ami a mostani játékok kiadáskori állapotát illeti, ebből kiindulni hiba lenne. Jelenleg azért lehet ilyen vacak kódot kiadni, mert nem komoly gond, ha lehal a játék. Ezt nem engedheted meg magadnak, ha BSOD a következmény, tehát nem ennyire tré játékok fognak jönni, mert a kiadó sem fog akarni bajt magának.
Én Mantle-vel toltam sok órát BF4-ben, és egyáltalán nem fagyogatott. Szóval amit eddig láttam, tetszett.Értem már az érvelésed. Van benne ráció, de rengeteg gyakorlati apróságon elvérezne szerintem a koncepció.
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Malibutomi
nagyúr
Ezt talaltam most, nekem ez mar tul mely, de talan te le tudod forditani.
Ez is csak egy forum comment, szoval csak erdekessegkepp, hogy diskuraljunk rola.A GTX 980 Ti can handle both compute and graphic commands in parallel. What they cannot handle is Asynchronous compute. That's to say the ability for independent units (ACEs in GCN and AWSs in Maxwell/2) to function out of order while handling error correction.
It's quite simple if you look at the block diagrams between both architectures. The ACEs reside outside of the Shader Engines. They have access to the Global data share cache, L2 R/W cache pools on front of each quad CUs as well as the HBM/GDDR5 memory un order to fetch commands, send commands, perform error checking or synchronize for dependencies.
The AWSs, in Maxwell/2, reside within their respective SMMs. They may have the ability to issue commands to the CUDA cores residing within their respective SMMs but communicating or issueing commands outside of their respective SMMs would demand sharing a single L2 cache pool. This caching pool neither has the space (sizing) nor the bandwidth to function in this manner.
Therefore enabling Async Shading results in a noticeable drop in performance, so noticeable that Oxide disabled the feature and worked with NVIDIA to get the most out of Maxwell/2 through shader optimizations.
Its architectural. Maxwell/2 will NEVER have this capability.
[ Szerkesztve ]
-
nagyúr
írta korábban abu, hogy a win10es driverek még nem kezelik az async shadereket, egyik oldalon sem, hanem sorba fűzik az utasításokat. hogy ez a compute részre is vonatkozik-e, azt nem tudom.
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
nagyúr
Szerintem azért mert túl sok párhuzamos feladatot kapott amit már nem tudott lekezelni elég gyosan (fel akarta pl mindet sorba fűzni, de ugye az több időt vett el a végrehajtástól), vagy olyan sok compute kerül a grafikus "időszeletek közé" a soros átrendezéssel, hogy a grafika túlságosan lassan végzett.
De túl keveset tudunk arról az nVidia driver meg hw tulajdonképpen mit is csinál párhuzamosan kapott feladatoknál.Legalábbis async problémakörben csak ezt tudom elképzelni.
Ideális esetben csak annyi a gond, hogy tényleg a jelenlegi driver csak soros feladatokat vár, és azt utána max belül ők szétdobálják párhuzamos csomagokra végrehajtás előtt (ez ugye jó DX11 és DX12 alatt is). És csak ezt kell úgy átírni hogy mostmár maga a program megtehesse ezt.
Rosszabb esetben az van hogy tényleg hw korlát van, amit spéci módon sorban kell etetni, elég korlátos módon/limitek között és azon belül tud csak párhuzamosítani valamennyire az egész rendszer. Pl egyszere ilyen 31+1-es csomagokat tud csak megenni, és a feladatot ilyen 32-es csomagokban kell sorban adni neki... nem pedig ráengedni mittomén 300-at egyszerre.Majd kiderül.
[ Szerkesztve ]
Steam/Origin/Uplay/PSN/Xbox: FollowTheORI / BF Discord server: https://discord.gg/9ezkK3m
-
nagyúr
31+1 -et én most itt queue limitnek néztem, nem compute motornak... szóval a moderált is ki tudja mennyi... persze lehet jóval kevesebb meg több is.
De tekintve hogy mennyi mindent szélsőségesen paralellizáltak ebben a motorban (amivel amugy semmi gond, hisz ez a cél), könnyen lehet túlvannak a 32 queue-n (összegészében)...És igazából a problémát is abban gondoltam hogy mi van ha ennél többet akarnak rátenni egyszerre és a driver ezt úgy kezeli le hogy felbontja 31/2-es "csomagokra".
És ha nagyon beesik a teljesítmény az azért van, mert pl van egy 32-es csomag (1 graf + 31 compute queue) a második, meg a harmadik meg csak compute (nincs graf), neadjisten egy egy ilyen 32 csomag után még pre-emp is kell ami szintén időkiesés. Aztán kezdődik elölről.Mondjuk AMD-n meg jól megy, elég lehet akár azis ha csak 32-nél több, de 64nél kevesebb, és pl emiatt nem kell (meg amugyse náluk pre-emp), plusz az egészet egyszerre le is tudják kezelni, nem kell pl ketté bontani. Ami ugyan lehet tovább tart mint nVidián egy 32-es "csomag", de a többi "overhead" miatt mégis az AMD jobb összidőben. Ki tudja lehet akár 100%-al is, ami már nevezhető durva beesésnek.
Na mindegy tényleg keveset tudunk, arról is a bench mit akar csinálni és a hw/driver is, hogy működik.
Meg mást nem tudok elképzelni, mert ha a nVidia már rég közölte és dokumentálta hogy a Maxwell 2 tud egyszerre compute és grafikát is, a Maxwell 1 és előtt meg csak egyik vagy másik, akkor önmagában ez nem lehet baj. Tehát mennie kell egyszerre. Inkább csak valami limitáció van máshol rá hogy mennyi az annyi, vagy hogyan kell etetni.
Szerk +, mondjuk ez a BY3D-s otthoni barkács tesztprogi is lehet ezt jelenti, mert minden egyes 32-es csomagnál nőtt az idő... AMD meg egyforma ugye.
Ez kicsit olyan mintha 32-es csomagokra kéne bontania a drivernek a queue-kat.
Aztán persze ugyis tévedhetek, hisz nem értek hozzá ennyire (sem).[ Szerkesztve ]
Steam/Origin/Uplay/PSN/Xbox: FollowTheORI / BF Discord server: https://discord.gg/9ezkK3m
Ú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.
- Gigabyte GA-H81M-DS2 rev:2.1 LGA 1150 alaplap
- IPhone SE2 2020 64GB megkímélt akku 86%
- Asus P8H67 LGA 1155 alaplap
- Bomba ár! Fujitsu LifeBook E754 - i7-4712MQ I 8GB I 128SSD I 15,6" I HDMI I Cam I W10 I Garancia!
- Bomba ár! Fujitsu LifeBook E754 - i5-4GEN I 8GB I 128SSD I 15,6" FHD I HDMI I Cam I W10 I Garancia!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs