- Milyen billentyűzetet vegyek?
- Léghűtés topik
- Philips LCD és LED TV-k
- 3D nyomtatás
- Megcélozta az NVIDIA-t a 2 nm-es node-jával a Samsung
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Vélemény: nem úgy tűnik, de Lip-Bu Tan most menti meg az Intelt
- Amlogic S905, S912 processzoros készülékek
- Melyik tápegységet vegyem?
- Milyen processzort vegyek?
Új hozzászólás Aktív témák
-
rocket
nagyúr
-
Abu85
HÁZIGAZDA
Abban volt szó dollármilliókról?
Mi a szép? Az biztos, hogy a Thief fény-árnyék hatásokban verhetetlen jelenleg. De más stílus. A hangulaton nem tudom mit értesz, de ha az élményt, akkor technikai dolgokba szerintem ezt ne keverjük bele.
A Witcher 3 lehetett volna szebb is, ha berakták volna a tervezett effekteket. Ez szintén egy middleware probléma sajnos. Dying Light nem kimondottan szép. Elég rossz a LOD-kezelése, így távolra elnézve kifejezetten ronda lesz.Figyelj, erre azt tudom írni, hogy hozzanak bizonyítékot arra, hogy a GameWorks jól működik. Mind sebességben, mind minőségben. Amíg ez nincs, addig természetes, hogy kapni fogja a sarat. És természetes, hogy a PC-s játékosok itt a leghangosabbak, mert ők kerültek a fallosz rosszabbik végéhez.
-
Abu85
HÁZIGAZDA
Ki mondta, hogy annyit perkálnak le érte? A millió dollárok csak akkor jönnek elő, ha kódokat vásárolnak. Ha megüti a játék azt a mércét, amiért megéri venni pár százezer kódot.
Én nem láttam még idén a Thiefnél jobban optimalizált játékot (60-70%-ra terheli a GPU-kat, egy mai év végi játék a 20-30%-ot sem éri el), vagy olyat, ami olyan skálázást csinál, mint a Dirt Rally. [link] - nem beszélve arról, hogy sosem láttam még olyan játékot, ami ennyire nem küzd a részecskeszimuláció szintjén a többletrajzolás problémájával. Egyszerűen nagyon konstans a sebesség, akármilyen közeli a kamera, és akármennyi a részecske.
Mondj egy olyan GameWorksös címet, amelyben a GameWorksnek nincs valami problémája a sebesség vagy minőség tekintetében. Nem véletlenül alakult ki a világon a Shitworksözés, vagy a Game(Don't)Worksözés. Szerinted van olyan fejlesztő a világon, aki bármit is tud tenni azzal, hogy az által kapott lényegében dll-ben szállított zárt kód nem működik jól? Nem ez a probléma gyökere, hanem az, hogy akármilyen minőséget elfogad az NV és fizet érte, de a GameWorks a probléma része, mivel hogyan várhatnák el azt, hogy a program optimalizált legyen, ha nem biztosítják a forráskódot a fejlesztőnek, hogy optimalizálja.
Nézd meg mi történik a világban. Kétféle általános fejlesztői nézőpont van most. Menjünk a middleware-ek felé (és nem csak a GameWorks, hanem mindenféle middleware felé), mert az olcsó és ennyi. Ilyet alkalmaz az Ubisoft, az Epic, a Rocksteady/Warner, stb. Az eredmény AC Unity, AC Syndicate, UE4 PC-s leképző, Batman AK. A másik opció az oké, hogy a middleware olcsó, de lassú és bugos, illetve esetenként zárt is tehát javítani sem lehet. Az efféle távolodjunk a middleware-ektől irányba megy az EA, a Square Enix EIDOS csoportja, a Crytek, stb. Az eredmény Star Wars Battlefront, Thief, Ryse. Az egészen egyértelmű, hogy melyik működik, mint ahogy az is egészen egyértelmű, hogy melyik irány oldható meg olcsóbban, sokkal olcsóbban. Létjogosultsága mindkettőnek van, ez vitathatatlan, mert bizonyos kiadók nem engednek a minőségből, míg bizonyos kiadók egyszerűen nem rendelkeznek akkora tőkével, hogy a PC-vel szimplán csak minimálisan is törődjenek. Ugyanakkor a PC-s játékosok szemszögéből a middleware-ek csak rossz portokat fognak jelenteni. Pusztán azért, mert meg kell küzdeni a bugjaival, a nehézkes integrálásával, és rosszabb esetben azzal, hogy szimplán a zárt kód miatt implementálni sem lehet megfelelően, mert nem tudod módosítani, hogy a leképezőhöz igazítsd. Egy működő leképezőt pedig szimplán egy middleware effekt beépítéséért nem fognak átírni. Ilyenkor jön a "Nézd a downgrade-et az E3-hoz képest!", lásd Witcher 3. Szemét fejlesztők nem ezt ígérték. Hát persze, de mit csináljanak? XY effektért készítsenek alternatív leképezőt, csak azért, mert az effekt nem igazítható hozzá a stabil és kész leképezőhöz? Inkább búcsút intenek az effektnek.
-
#12474
huskydog17
addikt
gbors
#12473
huskydog17
addikt
A Thief-fel egyet értek, az valóban kiváló PC port lett, a játék nem csak nagyon szép lett, de egy alsó középkategóriás VGA (Radeon 7800 series) elegendő magas részletesség mellett a 60 FPS-hez.
Én a 7870-esemmel majdnem maxon (csak az árnyékokat hagytam Normal-on) tolom élsimítással együtt DX11-ben és stabil 60 FPS-el megy. Ez a mai AAA címekről már abszolút nem mondható el.Bár az fura, hogy a Mantle render szimplán nem működik (ezért játszok vele DX11-ben), hiába a 15.7.1 WHQL driver.
Van még néhány független fejlesztő, akik szintén kiváló PC verziót készítenek.
-
Abu85
HÁZIGAZDA
Éppenséggel de. Sokaknak már a PC egy hatalmas nyűg. Inkább elfogadják az óriási gépigényeket, ha ezért is kapnak támogatást a porthoz. Az NV csak arra kéri őket, hogy ne módosítsák az effektjeiket a jobb sebességért. Vannak persze még kiadók, akik nem akarják, hogy a PC egy szemétdomb legyen, de ők egyre kevesebben vannak. Inkább azok a kiadók vannak többen, akik elfogadták, hogy a konzolpiac az egyetlen értékelhető terület, és a PC pedig mindegy. Csinálnak egy portot, ami épphogy működik, oda pedig tökéletesek a middleware-ek, akár zárt, akár nyílt.
Nyilván ebben a kiadók többségének igaza van. Sokkal nehezebb olyan szuperoptimalizált PC-s portokat csinálni, mint a Star Wars Battlefront, a Sniper Elite 3, a Tomb Raider, Dirt Rally, Thief, stb-stb. Sokkal könnyebb azt mondani, hogy a PC egy másodlagos platform a konzol mögött, és eszerint kell hozzáállni. Az, hogy az NV ilyen felfogásra is fizeti a marketingtámogatást, csak erősíti ezeket a kiadókat abban, hogy jól választottak, amikor úgy döntöttek, hogy elvágják a PC-s portoktól a pénzcsapot. Ezért kaptunk idén Batman AK-féle szörnyűségeket. Egyszerűen már ezért a minőségért is fizet az NV. Régen nem fizettek volna, mert volt egy léc, amit azért át kellett volna lépni. Ma akkor is fizetnek egy rakás kulcsért, ha a PC-s port egy rakás szar. Egyszerűen a minőséget mennyiségre váltották.
Az AMD-nek azért sikerül mindig szuperoptimalizált játékokat kihozni, mert nagyon magasan tartják a lécet. Ha azt a játék nem ugorja meg, akkor még a fejlesztőnek kell fizetni, hogy az AMD egyáltalán foglalkozott velük. Mivel ilyen formában sokkal rosszabbul járna a kiadó, így törekednek arra, hogy a meghatározott minőségi szintet elérjék. Akár extra befektetéssel is, mert ha ez megtörténik, akkor az AMD kinyitja a pénzcsapot, és egy csomó kulcsot vásárolnak, ami végső soron már megéri.
Azt egyébként nem mondanám, hogy az NV felfogása hibás. Tény, hogy a PC-s játékosoknak sokat árt, mert semmi sem kényszeríti a partnereket, hogy legyen jó a port, viszont az NV-t ez már nem érdekli. Akármilyen lesz megveszik a kulcsokat.A kettő között az van, hogy a fejlesztőnek mi a jó. Az AMD-féle dolgoznotok kell azért, hogy fizessünk a kulcsokért, mert nem fogadunk el akármit. Vagy az NV-féle mindegy a minőséget mindenképpen megvesszük. A legtöbb vezetőségben utóbbit választják, mert a gyártói pénz biztos. És azért már megéri portolni. A piacon pedig elég, ha a konzolport jól teljesít, a PC mindegy.
-
nonsen5e
veterán
Igazából akkor miért is kerül mindenbe GameWorks effekt?
Régen simán meg tudták csinálni az adott fejlesztők a jobb minőségű / kisebb erőforrásigényű effekteket.
A GameWorks a fejlesztők által történő teljesen önkéntes választásában nem feltétlen kellene korrelációban lennie azzal, hogy hogyan teljesít az AMD. -
daveoff
veterán
Crimsonnal kapcsolatban tapasztalatok Szaby59-től...
[link] és [link]A másik dologgal kapcsolatban, egy bizonyos személy(szerintem tudod kire gondolok) elég sokat hozzátesz a csodaváráshoz, meg a piros álomvilág építéséhez. Már-már marketinges szintjén áradnak az infók tőle, mindemellett a konkurencia dolgai felől pedig jönnek a trollkodó, és az urban legend szintű hozzászólások, szintén tőle.
-
Nekem elsőre annyit, hogy meg tudtam etetni a monitorommal végre a 2560x1080/72Hz-et, az eddigi 2560x1080/60Hz max helyett. Nv-nél ez már régebb óta megoldott, végre itt is megy.
Tudom-tudom, nem nagy valami, de nálam ez az újdonság.
AC syndicate-et nyüstölöm jelenleg, abban semmi pluszt nem hozott, igaz mínuszt sem. -
Abu85
HÁZIGAZDA
Ez még hagyján, de nézd meg az elmúlt 3 évet. Nagyjából látom, hogy ki mit fejleszt, és igazából egy kezemen meg tudom számolni, hogy komoly problémákra hány fejlesztés reagált. És most itt nem a hajszimulálásra gondolok, mert az új terület, hanem évek óta létező kritikus problémákra, mint például a részecskerendszereknél az többletrajzolás jelensége. Faszért terheljük agyon a hardverek fill-rate-jét, amikor az effekthez közelítve a számítások 80%-a irrelevánssá válik. Az ehhez hasonló problémákon kellene gondolkodni nem pedig azon, hogy mi lenne, ha egy sík felület nem kettő, hanem 16-256-4096 poligonból állna.
Mondjuk igaz, hogy a részecskerendszereknél már van két potenciális megoldás, de a lényeg érthető belőle. -
#12026
huskydog17
addikt
gbors
#12023
huskydog17
addikt
Csak tudod az a gáz ebben, hogy a God Rays-t kb. 2007 óta (vagy még előbb) használják PC játékokban. A 2008-as Far Cry 2-ben medium beállításon a játékra alkalmatlan Radeon HD 5470-em olyan God Rays-t csinált 60 FPS-en, hogy még a mostani Fallout 4-es marketing bullshit szintjét is megüti. Most meg a 700-1000 dolláros VGA-knál reklámozzák az effektet. Végtelenül szánalmas.
Még az SCS Software is sokkal gyorsabb God Rays-t rakott a DX9-es ETS2-be.
-
Abu85
HÁZIGAZDA
Mihez képest? Az nem volt eltitkolva, hogy a front-end mit tud, annak ellenére, hogy a vásárlókat nem érdekli. Olyan pedig minden processzorban előfordul, hogy a végrehajtó adat hiányában éhezik. Ez a velejárója a processzoroknak. Az oka ennek az, hogy nincsen kvázi végtelen mennyiségű tranzisztor arra, hogy a legrosszabbakra felkészüljenek a mérnökök. Tehát arra építenek, hogy ha nem optimalizálod megfelelően az adott processzorra kódot, akkor lassan futhat? És erre most jöttek rá?
Nem látom még az USA-ban sem, hogy ez bármilyen formában megállná a helyét. Egyszerűen nincs meg az alapja. Amit látok, hogy fogalmuk sincsen a processzorokról úgy általában, ezért leegyszerűsítik annyira a működést, hogy megértsék, és így lett egy saját víziójuk arról, hogy mi történhet. -
Abu85
HÁZIGAZDA
Oké tényleg. Nem vettem észre. Viszont ha erre alapoznak, akkor eleve vert helyzetből indulnak neki, mert nem ismerik, hogy miképpen működik a lapka. Előtte talán ki kellene kérni egy szakember véleményét, hogy ne hülyeséggel menjenek bíróságra, ugyanis a Bulldozer sosem működik olyan módban, amikor a modulon belüli két mag nem működhet egymástól függetlenül. Egyáltalán ki mondta azt nekik, hogy így működik a lapka?
-
Abu85
HÁZIGAZDA
Először is tisztázni kellene, hogy mit hit az áldozat. A leírás szerint azt, hogy egy nyolcmagos processzort vett. Az pedig egyértelmű, hogy annak a procinak, amit vett nyolc magja van. Nincs olyan, hogy nem úgy nyolcmagos. Ha a Phenom II a kiindulási pont, akkor valószínűleg arra mehet rá a vád, hogy azokban a magokban egy szálhoz van dedikálva integer és FP erőforrás, de valójában ez pontosan ugyanebben a formában igaz a Bulldozerre is. Hiszen nem normál FP erőforrása van. Ez valójában a marketinggel ellentétben nem kapcsolódik sosem össze. Mindig az adott maghoz tartozik az erőforrás, de ha úgy az ideális, akkor az egyik mag FP-je futtathat olyan folyamatot, ami a másik magot segíti. Egyszerűen nincs olyan tényező, ami a Phenom II és a Bulldozer esetében ne lenne egységesen igaz.
-
Abu85
HÁZIGAZDA
Ez szimplán józan ész. A vád semmilyen formában nem áll meg. Olyan ez, amikor a Al Bundy behúzott az őt beperelő betörőnek és beperelte, mert a szakálla felsértette a kezén a bőrt. Mondjuk igaz, hogy a sorozatban azt megnyerte.
De nyugodtam mond meg azt a formát, amiben a vádjuk megáll. Bármivel, amivel alá lehet támasztani azt. -
Abu85
HÁZIGAZDA
Teljesen mindegy. A definíció jogilag teljesen helytálló. Egyszerűen csak be kell vinni a terembe azt a whitepapert és kész. Azzal nem lehet mit kezdeni, mert abszolút meg van magyarázva technikailag is, ráadásul még így kívülállóként is helytálló az egész dokumentum leírása. A cégek emiatt leszarják ezeket a pereket, ezért mondtam, hogy az embereknek kell változni, mert megnyerni ezt a pert nem lehet.
-
-
Anubris
őstag
[link] Legalul lelehet tölteni két képet, egyik ultra másik nagyon magas. Én ultra-n játszom, akkor esik be nagyon az fps ha totál ráközelítek a tárgyakra, de az eléggé felesleges ennél a játéknál.
"Damit verliert man mit der lediglich zweithöchsten Einstellung der Shader-Qualität nicht viel, gewinnt aber eine Menge Geschwindigkeit. Der höchste Preset „Ultrahoch“ setzt die Shader-Qualität auf „Ultrahoch“. Das Preset „Sehr Hoch“ nutzt „Sehr Hoch“. Auch bei dem Punkt lässt sich also sinnvoll eine Menge Performance heraus holen."
-
#11729
FollowTheORI
nagyúr
gbors
#11722
Meglátjuk, a Skylines-ban lehet olyan szitut összehozni, ahol egyik CPU összeomlik és emiatt a GPU sem fut már teljesen jól, pedig az még bírná tovább szufflával... aláteszel egy erősebb procit és akkor megint jó... és így tovább. Ilyenkor jönnek, hogy egy i7 sem "hajtsa ki" a 980Ti-t pl.
Miközben egy benchmarkban ezt lehet nem mutatja ki... (ahogy pl egy BF4 sem a 64fős nonpluszultrát).Nem mondom az Anno ilyen, de akár lehet ilyen is.
-
#11719
FollowTheORI
nagyúr
gbors
#11718
-
#11713
FollowTheORI
nagyúr
gbors
#11712
-
#11555
FollowTheORI
nagyúr
gbors
#11541
Ez nekem sem derült ki most így visszaolvasva... most akkor a GW a szar csak, vagy a játék is szar... vagy a játék a GW miatt szar... vagy nem is szar a játék csak a GW...
Ha a játékot mint játék nézzük, azért olyan sok rossz GW játék nincs... ha csak a GW-t nézzük, az meg opciális, vagyis ha csak az a szar kikapcsolod.
Amugy szerintem nem a GW miatt rossz egyik játék sem ami rossz (akármilyen szempontból nézem).
Itt a fejlesztők meg a kiadók a sarasak főleg, látva ahol gond volt azt is meg tudták oldani idővel és munkával, úgy hogy a GW is maradt. Tehát nem a GW szar, hanem az elvégzett munka max... -
Yllgrim
őstag
Hu, tenlyeg az NV a Satan? Ezentul ha bekapcsoljatok a gepeteket, tessek szentelt vizet locsolni ra, az segit (az eladasokban)
Amugy igen, ha kikapcsolod akkor jobb a teljesitmenye a jateknak es nem lesz sokkal csunyabb, bar en bent hagyom minimumon, szebb az alatok szore, de nem eszi le a padloig az FPS-t. Az megvan amikor Geralt meg Vesemir megmentik a kereskedot a Griff-tol? Szep a sorenye a Griffnek, mi?
Szep, csak 25%-ot nem er Amugy nekem teljesitmeny szempontjabol nem volt gondom a zoldek termekeivel, a marketing az igazan zsenialis kapitalista szemszogbol, ellenben a mentalitas, korites es a szurkolotabor-tamogatoi kor kiepitese mar nem annyira.
Peace
-
Yllgrim
őstag
Szeretnelek idezni es osszefuggesekre ramutatni
![;]](//cdn.rios.hu/dl/s/v1.gif)
Gameworks már előre feltételez egy elrontott játékot =Nem kéne ilyen zöldségeket terjeszteniHA kikapcsolod, akkor jo, koszonom, vegre te is elismered. (tudom kiforditom amit irtal, de adta magat
)Szaby: nem csak azzal van a gond hogy hibas termekeket vasarolunk es ezzel biztatjuk oket ennek a mentalitasnak a folytatasara, de ennek meg orulunk es tapsolunk is, illetve masokat is erre biztatunk
Nekem nem bonusz jatek kell, hanem olyan termekek es mentalitas, hozzaallas ahol en mint fogyaszto vagyok az elso, nekem csinaljak meg azt a jatekot a leheto legjobbra. A GW az olyan mint olcso vasari "varazslo" addig lenyugozo amig nem jossz ra hogy atvernek
Az hogy kozben meg ki is zsebelnek (igen, onkent adjuk oda a penzunket, de ez nem valtoztat a lenyegen ) az mar csak hab a tortan -
Abu85
HÁZIGAZDA
Az a baj, hogy ez az általános megítélés. Ami jogos egy átlagfelhasználó szemével, mert ők egyszerűen csak nem tudnak felhozni pozitív példákat a GameWorks-re. Egyszerűen van bennük egy rakás negatív tapasztalat, amire jut egy rakás olyan pozitív tapasztalat olyan játékok formájában, amelyek nem NV logóval indulnak. Ez volt, amire az NV-től eljött rendszerprogramozók figyelmeztettek, hogy ezt lehetetlen jól eladni a játékosoknak, mert a fejlesztők keze az optimalizálás szempontjából meg lesz kötve. Az, hogy ez a nézet Magyarországra is becsúszott alapvetően várható volt. Picit késett, mert írtunk pár cikket, amiben próbáltuk a GameWorks problémakörét átfogóbban elemezni, de a végső szempont a felhasználónak úgyis az, amit tapasztal, és ez jelenleg negatív jellegű.
-
#11445
Dark KillerX
addikt
gbors
#11443
Dark KillerX
addikt
A FX proci témával kapcsolatban, még annyit, amióta lecseréltem a 7950-et ami ment 1150/1600Mhz-et is, mindezek ellenére, egy GTX960-ra, jóval kiegyensúlyozottabbak lettek a játékok, és bizony ez FPS ugrás számokban is megmutatkozik, mert pl a GTA, vagy akár az F1 2015, kb 15-20%-al lett gyorsabb, de pl a Dyning Light , simán 30%-al, ott nagyon látszott a CPU limit, ami köszönhető amúgy is gyenge 1 szálas teljesítménynek,amit a driveres optimalizálatlanság tovább rombolt.
Lehet majd csinálok pár mérést, hogy lássuk számokba, kb mekkora CPU- limit van driveresen a Catalystba építve
-
Yllgrim
őstag
Akkor ha visszaterunk a kezdetekhez akkor a komoly jatekos nem vesz I3-at, hanem vesz I5-t minimum de inkabb I7-et (mert a penz ugye nem szamit) vesz melle 1-2 top VGA-t meg 16-32 GB RAM-ot es meg van oldva a dolog. Na most jatekelmeny szempontjabol az altalam linkelt konfig mennyivel ad kevesebbet? (vagy forditsd at a magad I3-as konfigjara ha ugy jobban tetszik)
J a t e k e l m e n y.
Az allaspontunk alapulhat mindketton egyszerre, nem csak kulon kulon, adott penzbol a legjobb (OFF)muszaki(/OFF) megoldas, szemelyes preferenciak sokat szamitanak (mennyi a keret, milyen hosszu tavra tervezed az adott konfigot... na meg jatekon kivul tervezed-e masra is, nalam peldaul a 8350 sokkal jobban fekszik a VM-eknek mint az I3, meg ha Skylake is...Jelenlegi OS-em jobban preferalja a tobszalusitott alkalmazasokat, jobban hasznalja fel az eroforrasokat, oda I7 (ami most is van ) vagy 8350)
-
-Solt-
veterán
Emlékeim szerint a fejlesztési költsége minimális volt, ha ebből indulunk ki, akkor már jelenleg is eléggé jól állnak vele szerintem,
- Pár játékban igencsak jól jött a júzereknek.
- Szorosabb kapcsolat nagyobb stúdiókkal.
- A DX12 érkezését jelentősen befolyásolta, így elérte, hogy abba az irányba menjenek a dolgok, ahol az AMD önmagához képest jobban szerepel.És akkor ott van még a Vulkan és a LiquidVR... utóbbiban az eddigiek alapján van potenciál.
A jelentős extra teljesítményt szerintem konkrétan nem fogjuk látni, mert azt majd "elköltik" a fejlesztők másra. (látvány, ai, akármi) Max pár játék lesz ami jelenleg szarul megy, és DX12 után javul a teljesítménye. Pl PCars, vagy mi a neve!
-
Egon
nagyúr
Különítsük el a technikai sikertörténetet, a gazdasági sikertörténettől; illetve nézzük meg, hogy a felhasználók szempontjából hogyan néz ki konkrétan a Mantle (és nem egyéb API-k, amelyek megjelenését esetleg valamilyen mértékben eszkalálta a Mantle), mondjuk a kiadása óta eltelt nemtomhányév alatt megjelent/támogatott programok számát tekintve, és úgy nézzük meg, mi marad a "sikertörténetből"...
-
Biztos, hogy nem attól jó vagy szép egy játék, hogy kilóban mérik azt egységeket. Úgyse lehet őket egyesével irányítani, akkor pedig még rosszabb is, ha egy csoport 100 pontszerű, de nullára zoomolva rogyásig kidolgozott egységet tartalmaz, mintha 15 látható méretű, normálisan kidolgozottat. Pont ezt mondom én is, hogy sikerült túltolni a DX12-t.
-
#85552128
törölt tag
Nem arról volt szó, hogy a DX12-vel szép grafikát eltrédeljük a sok
drawcallértegységért... Mert ezzel csak egyik problémát lecseréltük a másikra, sőt visszafejlődtünk...
Bár így végül is elég egy sivár map a játékba, vagy majd max variálják egyik barna másik zöld lesz.
Amúgy az effektek is bűn rondák nagy szikrázás, lövöldözés, de azt se látod honnan/hová.Még 1080p - high mellett is 99%-ban GPU limites: [link]
-
-
#52815360
törölt tag
Egy bizonyos pontig igen, aztán már inkább idegesitő. Red Alert 2 multiban is milyen izgalmas volt mindig, mikor a felek legyártottak 500+ kirov léghajót, aztán 5fps -el döcögött a játék, amig mindenki meg nem halt. De most itt lesz a csodálatos DX12, igy már mehet 10000 kirov léghajó is és a pusztulás 10 perc helyett 2 alatt végbemegy. Zseniális. A civilization sorozatot is inkább abba az irányba vitték el, hogy kevesebb egység legyen, de jobban kezelhető.
-
Abu85
HÁZIGAZDA
Akkor erre építve a következő kérdés. Képes lenne megkönnyíteni a fejlesztők dolgát úgy is, ha nyílt forráskódú lenne? Szerinted rontana, vagy javítana a helyzeten?
Nyilván tudom előre a választ, így bónuszkérdés, hogy ha javítana, akkor miért nem nyílt forráskódú? Netán nem lenne előnyös, ha a fejlesztő kiműtené belőle a lassításokat és optimalizálná Keplerre? -
Abu85
HÁZIGAZDA
A middleware-ek célja általánosan az, hogy megkönnyítsék a fejlesztők munkáját. 2015-ben kvázi mindenki biztosít forráskódot, ami megkönnyíti a munkát. Az AndroidWorks vagy Radeon SDK pontosan ilyen. Nyílt és jól használható.
A GameWorks pontosan lehetne ugyanez, ha nyílt lenne, de zárt. Pedig utóbbinak semmi értelme, mert még az algoritmus védelme sem merül fel. Mit lehet védeni egy HairWorksön, aminél például a TressFX konstrukciója sebességben és minőségben is jobb. Az egyetlen cél, hogy a fejlesztő képtelen legyen kikapcsolni a gépigényt nagymértékben megnövelő, de a minőségre semmilyen előnyös hatást nem kifejtő algoritmust.
De ha úgy gondolod, hogy tudsz olyan előnyt mondani, amit a GameWorks nem tudna biztosítani nyílt forráskód mellett, akkor itt a lehetőség. -
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. -
Gainka
őstag
Tök normálisan ment a beszélgetés addig, míg nem kell újból elolvasnom a csilliárdszor le irt szövegeket.
(#11151) do3om, (#11152) mcwolf79
Csak azt nem értem miért kell mindegy egyes hírnél, ahol a 10-böl 1 játékban jol megy a negyed akkor cég 3 éves kártyája le írni ezeket és besértődni. Meg majd jön a pászkál addigra az durva lesz stb....
Ezeknek semmi értelme, aki meg jövöbe alázásokról beszél ki kell nevetni nem 100 oldalon sablon szövegekkel be oltani és elk.rnu a jó beszélgetést.
És igen szelektíven olvasok, nem veszem figyelembe az ilyen hozzászólásokat : (#11145) mcwolf79, (#11150) letepem 
Menjen jól az a játék amd-n és nvidian is, úgy is vásárlás előtt állok és hát nem valami szuper a felhozatal azon az árszinten ahol nézelődök...
Béke
-
-
TTomax
félisten
4K-ban a stabil 60fpshez bizony nem elég hogy "very high"-ról leveszed "highra" a legtöbb egy gpus megoldás még úgy is elvérzik.Egyébként ez pedig játékra váltogatja,hogy mit érdemes,és mit kell kikapcsolni,illetve mit egyáltalán nem érdemes bekapcsolni mert csak rondább lesz.
Ha te 48"-50"-ra látod értelmét a 4K-nak azzal nincs semmi baj,csak hogy akkor megkapod ugyanazt a PPI-t és képminőséget mint 24"-on FHD-ban.... ugye akkor kelleni fog MSAA ami 28"-on szinte teljesen nélkülözhető,2XMSAA felett szerintem 10böl 9en nem tudnák megmondani mi van beállítva egy 28"-os 4K monitoron, mert egész egyszerűen nem látszik ilyen PPI mellett.2003-as DX8-as játék egész másként mutat,élvezet vele játszani ismét,hiába nincs HD textura...
Nem véletlen,hogy már anno mikor dsr nem volt ,elég sokan nyomták custom res-al csak hát akkoriban gépigénnyel nem lehetett bírni...de ha már itt tartunk ez egy olyan régi igény (magasabb PPI) mint amilyen régi az MSAA...
(#10660) hpeter10
Várj még vele nyugodtan,legalább addig amig 4K-n nem megy a 120Hz támogatása.Akkora már lesz normális scaler,meg elektronika is.Mert a mostani 4K-s monitork kivétel nélkül lassúak,legyen az TN VA vagy IPS.Nem panel függő.Szép a képük,már a TN-ek is vállalhatóak,de lassúak.Persze el lehet vele lenni,az ár dönti el mindig az ember mennyi megalkuvásra képes. DP1.3-ra már lesznek gyorsabb monitorok,amúgy mindenképpen ez a jövő,csupán idő kérdése. (#10659) proci985
Most 4K van az asztalon,a csoda ROG pihen és gyanítom így is marad egy ideig.
-
TTomax
félisten
A nativ 4k gyönyörü 28"-on a PPI meg a felbontás és a kijelzöméret függvénye,jellemzöen minnél magasabb annál jobb a dsr meg vsr nyomába sem lép egy magas PPIs monitornak.Az hogy az UI skálázodik-e vagy sem semmit sem von le abból a gyönyörü kép értékéböl ami mozgás alatt is részletes és éles marad.Ha viszont le kell adni a grafikából akkor az elöny elvész,meg akkor is ha 30-40fpsel kell játszanod egy fps játékot egérrel és billel.Ehhez kevés egy gpu,no meg persze ott jobban össze lehet mosni az eredményeket,mondván pár fps ugy se számit....nálam csak annyira jött be a 4k 28"-on,hogy a 144Hzes g-synces 1440p monitor félre lett tolva az asztalról...
-
rocket
nagyúr
Akkor minek hypeolta Huddy az AOTS kapcsan az aszinkon computeot, ha a benchmarkban nem mukodik naluk se?
Egyebkent ez a lenyege az aszinkron compute koruli cirkusznak:
"Aquanox Dev: We'd Do Async Compute Only With An Implementation That Doesn't Limit NVIDIA Users" -
sayinpety
tag
Volt szivas, am megoldottuk. Sajnos developer driverek sokat valtoznak, nem stabilak meg. Jelenleg multi-engine & sync code eredmenye +4% Geforce es +22% Radeon. Am mi software tessellationt futtatunk async compute modeban. Specialis eset.
Szerintem Nv tul ideges. Latszik rajtuk, am nem ertem miert. Tobb alternate pathot irtunk be enginebe fel ev alatt. Sokat segitett a Geforceoknak. Mar hasonlo teljesitmenyu a 980 es 290x. VR-tol felnek. Mi VR tamogatasunk nem lesz kesz jovore. Elmondtam nekik. Latszott rajtuk a megkonnyebbules. Vicces volt. :-)
Szerintem Nv tul optimista volt. Tobb programozojuk belatta nem jo a Gameworks. Hiaba hoztak 4 effektet, egyiket se tudom beepiteni. Legalabb egy evvel csuszna engine. A kiado nem orulne. Par uj Gameworks effekt hasznal conservative rasterizationt es ROVsot, am olyan enginerol nem tudok, ami tamogatna. En jovore kezdem tervezni az updatet. Akkor veszem szamitasba uj lehetosegeket. Ha minden jol alakul conservative rasterization es ROVs algoritmusokat harom ev mulva tudunk beepiteni. Nem varazsutessel fejlesztunk! D3D12 tul nagy update. Nem lehet mindent gyorsan tamogatni. A tamogatast eloszor alapfunkciokra korlatozom, plus multiadapter. Ha mukodik lepunk tovabb. Meg be kell epiteni a Vulcan APIt. Mantle miatt nem varok nehezseget, am par hetet elvisz.
-
Anubris
őstag
Sebesség különbség nem volt olyan jelentős, de azért a +1gb vram főleg 1440p monitor tulajoknak már jól jött. Én például sokkal inkább azért váltottam, mert az a gtx 980 sokkal hűvösebb kártya és semmi hangja nincsen. Ezt a 780 Ti-nél legfeljebb vizezve tudtam volna elérni.
-
TTomax
félisten
Ja,hát ezért kell teljes termékpalettát hozni és nem csak a csúcsot letolni a középbe mint ahogy az AMD teszi...eza difi a két cég között,míg az AMD hoz 3 új vga-t a csúcsba mindig,és az aktuális csúcsot letolja egy szinttel addig az nV egy egész termékpalettát...
(#10089) Pepeeeee
Azt nem is csodálom,mert ahhoz képest hogy cinematic jó ronda.Kell is a zacskó... -
TTomax
félisten
A 780Ti a 980Tivel van egy ársávban,az hogy túlárazva kínálták a 980akat konkurencia hiányában nem meglepő,de ettől bizony még nem lesz 780Ti utódja...ez már nem tudom hanyadik generáció ahol az nV ugyanazt játsza el,igy volt a 680al is,az se az 580 utódja volt még ha egy ideig egy árban is adták...
A 980 sosem volt a high end,még ha az árazásával ezt próbálják meg sugalni... az bizony egy felsö közép kat. vga.Ezért is hatalmas fejlődés volt a maxwell mert bizony nem nagyon van lemaradva teljesítményben a csúcs radeonoktól.Ilyenkor látszik szépen miért is lovagolunk a fogyasztáson,mert az a kulcsa az egésznek.
-
HSM
félisten
Most nem azért, de ha egy 290X 19ms alatt végez ugyanazzal, amihez a GTX980-nak 28ms kell, az eléggé mocsáricsiga kategória, pláne ahhoz képest, mennyivel drágább kártya volt a 980.
Ez másfélszeres FPS, ha átszámolod.... 35 vs. 52.A kérdéseid amúgy jogosak. Ugyanakkor ha azt nézem, a fő platform a konzol, akkor azért nem biztos, hogy prioritás lesz, hogy az Nv hardveres gyengeségeit valahogy szoftverből gyorsítgatni próbálják, amikor a GCN "magától" is gyors lesz.
-
nyilván nem retail drivert használtak. írta korábban, hogy az ő motorjuk karakterisztikája nagyon eltér attól, ami az aotsben van. ergo mindkét állítás igaz lehet, mert nem feltétlenül lehet az egyik engineről tapasztalatakat kivetíteni a másikra. túl kevés az infó.
-
Ren Hoek
veterán
Amúgy AOTS bench akkor most milyen állapotban van? Nekem ez sem tiszta.
- Multicore támogatás egyelőre nem aktív? (FX ezért maradt le)
- Van benne jelenleg Async? Milyen mértékben/formában? (Abu említette, lesz majd olyan pálya ami DX12-ben indul csak el, olyan "durva") Vagy NV egyelőre kikapcsoltatta a saját kártyáira?Csak mert sokan olyan következtetéseket vonnak le architektúrákra nézve, egyetlen programból, hogy az totál értelmetlen.
-
HSM
félisten
Azért azt tartsuk szem előtt, hogy a város alatti óceán mindkét hardvert megizzasztotta annak idején, csak belerakatták, mert míg NV-n csak 17-21% sebességbe került, addig az AMD-s kártyákon 31-38%-ot vett el a teljesítményből. [link]
Háttérstory, hogy az Nv halál feleslegesen rakta bele a hardverébe az atomdurva tesszelátort, a HD5850-em "elsőgenerációs" tesszelátorával is még évekig remekül el lehetett lenni a legkisebb gond nélkül.
Async shader esetében viszont arról van szó, hogy az egyik termék tud egy igen hasznos funkciót, ami ráadásul a DX12 egyik lényegi újdonsága, amivel jócskán gyorsulhat a feldolgozás, míg a másik hardver úgy néz ki, csak papíron tudja ugyanezt és még lassulhat is.
Tehát az első esetben egy nem központi funkció irreális (mesterséges) túlhasználatáról volt szó, amitől mindkét hardver szenvedett, csak az AMD kicsit jobban praktikusan a semmiért. A második esetben viszont az új API egyik lényegi újdonsága fest úgy, hogy nem hoz pozitív eredményt az Nv hardveren, míg az AMD-n igencsak.
Továbbra is amondó vagyok, hogy korai lenne túl messzemenő következtetést még levonni (mindamellett azért már kezdenek kirajzolódni dolgok), az érvelésem csupán arra irányult, hogy én egészen másmilyennek látom ezt a szituációt, mint anno a Crysis 2 tesszelálós történetét.
(#9982) Ren Hoek: A GCN-nek nem okoz fejtörést, mert ott vannak a hardveres ütemezők (ACE-k) valamint "stateless" architektúra, azaz nem kell állapotot váltania bizonyos funkciók elvégzésére.
-
Ren Hoek
veterán
Ha jól értem, ez azt jelenti (amit 970 topicba is írtam), hogy limitált módon, de működhet az Async nem?
Tehát 1 graf, 1 compute szál még oké lehet slow context switch-el is, mert az még etethető szoftveresen, beleférne a frame-be."Ezt meg lehet csinálni egészen addig, amíg a graf és a compute feladatok nem használják össze-vissza egymás eredményeit."
Erre alapból figyelni kéne a paralell programozás miatt, nem? Vagy nem világos GCN-en ez miért ne okozna fejtörést.
-
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.
-
Habugi
addikt
Ugyan.., értékelendő a szándékod de aki himpitől felvesz bármit az meg is érdemli, Laja333-nak odaböfögött egy ilyet:
"Tényleg nem akarok megbántani senkit, de, akinek AMD cpu van a gépében játékra az nem tud hiteleset írni előttem ebben a témában."
Miközben még a Mantle achievement is lockolva van még nála szemlátomást..
Most komolyan, látod magad előtt azokat akik AMD CPU-val hosszú tömött sorokba rendeződve sorban állnak előtte azért hogy a tőle kapható "hitelességet" megszerezhessék?
Szakmaiság? Kabaré, szerintem..
Nyilván himpi sem veszi fel hisz tudja ez nem a barátkozós topicok egyike, csillámpóni lelkületűnek sem vallja magát.
Ezért olvasom a mai napig ezt a topicot, még ha az aktív szerkesztésből ki is ugrottam hónapokkal ezelőtt.
-
#9701
FollowTheORI
nagyúr
gbors
#9693
-
#9688
FollowTheORI
nagyúr
gbors
#9674
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). -
#9659
FollowTheORI
nagyúr
gbors
#9647
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.
-
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. -
#9524
Malibutomi
nagyúr
gbors
#9509
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.
-
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.
-
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ó.
-
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? -
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.
-
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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Az hogy kozben meg ki is zsebelnek (igen, onkent adjuk oda a penzunket, de ez nem valtoztat a lenyegen ) az mar csak hab a tortan 
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 9070 XT GAMER PC termékbeszámítással
- AKCIÓ! "ÚJ" Microsoft Surface 5 13,5 notebook - i5 1235U 8GB RAM 256GB SSD Intel Iris Xe IGP 27% áfa
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
- ismét elérhető 3db - Sennheiser MOMENTUM 4 fejhallgatók
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest