Új hozzászólás Aktív témák
-
huskydog17
addikt
-
-
#85552128
törölt tag
AMD Wants You to Choose Radeon RX 470 Over the GTX 1050 Ti, For Now
Megjött a
slideware"válasz" a 1050Ti-re.Civilization 6 benchmarkot azért nem raktak be
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
->Raizen<-
veterán
Üdv!
Szeretném megkérdezni tőled,hogy az NVIDIA GTX 1070eknél melyeket micron rammal szereltek ott minden micron rammal szerelt kártyán hibásan működik a memória??
Értem ez alatt azt,hogy aki nem tapasztalt még képi hibákat a micron rammal szerelt kártyáján attól függetlenül azokon a kártyákon is hibásan működik a memória??
Van arról információ,hogy a gyártók mennyire gyorsan fognak BIOS javítással elő állni a probléma orvoslására???
Ha nekem gtx 1070 micron ram tulajdonosképp nem tapasztalok hibát attól függetlenül ajánlott lesz feltennem a BIOS frissítést???
A boltnak vissza küldhetem javításra a kártyát ha itthon nem akarok bajlódni a BIOS frissítéssel??
Megcsinálhatod otthon, vannak bolondbiztos leírások. Eladáskor szempont lehet hogy milyen bios van rajta. De ha nem akarod elpasszolni nekem mondjuk 60k-ért akkor tedd fel a biost, ártani nem ártasz vele.
(#23593) letepem:
Rohanok is venni, bárki aki elémugrik közben, fellököm. -
Dancs Ákos
csendes tag
Nincs. Csak DX11-ben, nagy térképnél és a vége felé percekkel tovább tart, amíg lép. DX12-ben sokszor ötször gyorsabb egy AI kör.
Üdv!
Szeretném megkérdezni tőled,hogy az NVIDIA GTX 1070eknél melyeket micron rammal szereltek ott minden micron rammal szerelt kártyán hibásan működik a memória??
Értem ez alatt azt,hogy aki nem tapasztalt még képi hibákat a micron rammal szerelt kártyáján attól függetlenül azokon a kártyákon is hibásan működik a memória??
Van arról információ,hogy a gyártók mennyire gyorsan fognak BIOS javítással elő állni a probléma orvoslására???
Ha nekem gtx 1070 micron ram tulajdonosképp nem tapasztalok hibát attól függetlenül ajánlott lesz feltennem a BIOS frissítést???
A boltnak vissza küldhetem javításra a kártyát ha itthon nem akarok bajlódni a BIOS frissítéssel??
-
->Raizen<-
veterán
-
->Raizen<-
veterán
-
Alakul, bár a Zen újboli (kicsi?) késése szomorú, főleg, hogy mire megjelenik a 4/8-as zen, nem sokkal utána az intel már a 6/12-es i7-eket hozza. Amire megint semmi nem lesz AMD-től (vagy lesz sokmagos zen is?)
Állítólag lesz 8/16 is, desktopon is. A találgatós topik szerint inkább az a kérdéses, hogy mi lesz a végleges órajel, elég magas lesz e. Az egy szálas teljesítmény ugye.
-
összefoglaló cikk magyarul: [link]
Lisa Su, a vállalat vezérigazgatója elmondta, hogy az AMD egyre közelebb kerül a Zen processzorok piaci rajtjához. Az asztali, Summit Ridge kódnevű modellek végül csak a jövő év első negyedévében jelennek meg, idén legfeljebb csak mintapéldányok látnak napvilágot. Ez kisebb csúszás a cég korábbi tervéhez képest, amely az idei negyedik negyedévet célozta a megjelenéssel. A Summit Ridge processzorokkal a nagyjából felsőkategóriás PC-k 4 milliárd dolláros piacára lő az AMD. Su megerősítette, hogy az Intel i5-ös és i7-es termékeknek állíthat konkurenciát cége, ezekre jó ideje nem kínál komoly alternatívát az AMD.
Az is kiderült, hogy az új felsőkategóriás Radeonok is már csak 2017-ben kerülnek piacra, a Vega kódnevű megoldások az első félévben bukkanhatnak fel. Ugyanebben az intervallumban jelenhetnek meg a Zen-alapú (Naples) szerverprocesszorok. A vállalat vezérigazgatója továbbra is optimista, szerinte a 2017-es palettához hasonlóan erős termékportfóliója legutóbb több mint 10 éve volt az AMD-nek.
mod: off
-
A jelenleg elérhető játékverzióban nincs DX12-es mód, hogy amúgy milyen verziók léteznek a játékból az más dolog, majd valamikor biztos belekerül...
Akkor valószínűleg a régi 1390xxx-es build lett kiadva. Abba nem volt beépítve a DX12. Akkor itt iszonyatos patch-özön lesz az elkövetkező hetekben, mert rendkívül sokban különböznek még DX11 alatt is az új buildek.
-
Benne van, legalábbis a 1398924-es buildben: "../Base/Binaries/Win64Steam/CivilizationVI_DX12.exe"
Kérdés, hogy melyik build lett a publikus. Gondolom a teszteléstől is függ, mert nagyon sokban különbözik a DX11-es mód a DX12-estől. A multiadapter mód is teljesen más, mint a DX11-es CF/SLI.
-
kijött az amd 16q3 jelentése is.
tl;dr:a cég rendes működését továbbra is sikerül a pozitív tartományban tartani, az összképet viszont lerontja a wsa (wafer supply agreement) miatti 340 millió dolláros kifizetés.
q3 bevétel $1,307m usd;
üzemi veszteség 293m usd;
adózás utáni eredmény 406m usd,
részvényenként realizált veszteség 0,50 usd.
a bevétel q2q 27%kal y2y 23%kal magasabb az előző negyedévnél, illetve az előző év azonos negyedévénél;
a bruttó marzs 5%ra esett, ami 31%kal alacsonyabb q2q, az említett 340 milliós wsa megállapodás miatt. az egyszeri hatások nélkül nélküli ugyanúgy 31% a bruttó marzs, mint az előző negyedévben;
az üzemi kiadás 376m usd, az előző évi 356m usdhez képest, egyszeri hatások nélkül pedig 353m usd, q2 342m usdjéhez képest, ezt a megnövekedett k+f költségekkel indokolják;
az üzemi eredmény -293m usd (ez negatív, azaz veszteséget jelent), 16q2 8m usd-s eredményéhez képest, ezt döntően befolyásolta a wsa megállapodás miatt kifizetett 340m usd-s tétel. egyszeri hatások nélkül az üzemi eredmény 70m usd, q2 3m usdjéhez képest, ez a növekedés főleg a 16q2höz képest elért magasabb bevételek miatt van.
az adózott eredmény -406m usd, részvényenként -0,50 usd veszteség, q2 69m usd-s eredményéhez, és részvényenkénti 0,08 usd eredményhez képest. ez a már említett wsa megállapodáson kívül egy további, 61m usd-s tartozás előtörlesztés miatt van így, amelyet a megnövekedett bevétel miatt fizettek be. 16q2 üzemi eredményét tovább növelte egy 150 milliós, adózás előtti nyereség, amely atmp létesítmények értékesítéséből származott.
az egyszeri hatásoktól megtisztított adózott eredménye a cégnek 16q3ban 27m usd, amelyik szintén non-gaap 0,03 usd nyereséget jelent részvényenként. ezek a mutatók q2ben 40m usd adózás utáni veszteséget, és részvényenkénti 0,05 usd veszteséget mutattak. az eltérés fő oka szintén a q2höz képest elért nagyobb bevétel.
ami a cég adósságát illeti, az a negyedév végén 1632m usd volt, 606m usdvel kevesebb, mint az előző negyedévben.
az amd 16q4re q2q 18 +/-3 százalékkal kevesebb árbevételt vár. ha ennek középértéke teljesül, az egyben 16q4 12%os árbevételnövekedését jelentené y2y alapon, és 2016 árbevételben pedig 6%kal teljesítene jobban 2015höz képest. -
Benne van, legalábbis a 1398924-es buildben: "../Base/Binaries/Win64Steam/CivilizationVI_DX12.exe"
Kérdés, hogy melyik build lett a publikus. Gondolom a teszteléstől is függ, mert nagyon sokban különbözik a DX11-es mód a DX12-estől. A multiadapter mód is teljesen más, mint a DX11-es CF/SLI.
-
kijött az amd 16q3 jelentése is.
tl;dr:a cég rendes működését továbbra is sikerül a pozitív tartományban tartani, az összképet viszont lerontja a wsa (wafer supply agreement) miatti 340 millió dolláros kifizetés.
q3 bevétel $1,307m usd;
üzemi veszteség 293m usd;
adózás utáni eredmény 406m usd,
részvényenként realizált veszteség 0,50 usd.
a bevétel q2q 27%kal y2y 23%kal magasabb az előző negyedévnél, illetve az előző év azonos negyedévénél;
a bruttó marzs 5%ra esett, ami 31%kal alacsonyabb q2q, az említett 340 milliós wsa megállapodás miatt. az egyszeri hatások nélkül nélküli ugyanúgy 31% a bruttó marzs, mint az előző negyedévben;
az üzemi kiadás 376m usd, az előző évi 356m usdhez képest, egyszeri hatások nélkül pedig 353m usd, q2 342m usdjéhez képest, ezt a megnövekedett k+f költségekkel indokolják;
az üzemi eredmény -293m usd (ez negatív, azaz veszteséget jelent), 16q2 8m usd-s eredményéhez képest, ezt döntően befolyásolta a wsa megállapodás miatt kifizetett 340m usd-s tétel. egyszeri hatások nélkül az üzemi eredmény 70m usd, q2 3m usdjéhez képest, ez a növekedés főleg a 16q2höz képest elért magasabb bevételek miatt van.
az adózott eredmény -406m usd, részvényenként -0,50 usd veszteség, q2 69m usd-s eredményéhez, és részvényenkénti 0,08 usd eredményhez képest. ez a már említett wsa megállapodáson kívül egy további, 61m usd-s tartozás előtörlesztés miatt van így, amelyet a megnövekedett bevétel miatt fizettek be. 16q2 üzemi eredményét tovább növelte egy 150 milliós, adózás előtti nyereség, amely atmp létesítmények értékesítéséből származott.
az egyszeri hatásoktól megtisztított adózott eredménye a cégnek 16q3ban 27m usd, amelyik szintén non-gaap 0,03 usd nyereséget jelent részvényenként. ezek a mutatók q2ben 40m usd adózás utáni veszteséget, és részvényenkénti 0,05 usd veszteséget mutattak. az eltérés fő oka szintén a q2höz képest elért nagyobb bevétel.
ami a cég adósságát illeti, az a negyedév végén 1632m usd volt, 606m usdvel kevesebb, mint az előző negyedévben.
az amd 16q4re q2q 18 +/-3 százalékkal kevesebb árbevételt vár. ha ennek középértéke teljesül, az egyben 16q4 12%os árbevételnövekedését jelentené y2y alapon, és 2016 árbevételben pedig 6%kal teljesítene jobban 2015höz képest.Köszi az összefoglalót!
-
-
-
-
+Yoshi, Kirby, Donkey, Smash Bros, talán Metroid. Plusz 1-2 új cím a gépre, ha bukik akkor is. Így belegondolva kőkemény a Nintendo first party felhozatala. Ha mellé még beesik néhány jobb 3rd party fejlesztés is. Simán meg fogja érni a masina. Meg is győztem magam
Bocs az offért.
-
imi123
őstag
Nintendo-to-release-switch-a-handheld-console-power-by-nvidia.
Jónak tűnik.
Szurkolok a Nintendonak,főleg hogy Nv szív dobog a masinában. -
Nyilván a DX12 kód erősen többszálú, így egy 8 magos procin nagyobb előnyt tud biztosítani a DX11 kódhoz, mint egy erősebb négymagoson. Pusztán a skálázás lehetősége miatt. Emiatt az egy szálú teljesítmény kevésbé domináns, mint DX11-ben, amiből minden rendszer képes profitálni. Hasonlóan viselkedhetnek a kevésbé erős négymagosok is.
Az Intel gyors négymagosával a skálázásból nyert teljesítmény kevésbé domináns, így inkább a hátrányok jönnek elő. A Frostbite alatt ez a GeForce-okat különösen érinti, mert a motor nem tud UAV-t menteni a root signature-be, illetve az NV egy extra másolásra kényszerül, amikor a compute shader adatot ír ki. Az AMD-t bekötési modellje jobban illeszkedik a DX12-höz, így nem zavarja, ha a root signature-ben nincs UAV, illetve a konstans puffer elérése pont ugyanolyan gyors, mint más pufferé, vagyis nem kell másolgatni a compute shader adatkiírását. Emiatt az AMD DX12 alatt gyorsulni tud a DX11-hez képest minden körülmény esetén.
-
Akármeddig gondolkodom, egyre inkább úgy tűnik, hogy ez nagy mértékben növeli a stutter névvel jellemzett problémát. Ha van egy kis rés a számítási kapacitásban, akkor nyomunk egy presentet, és elkezdjük számolni a következő képkockát (tehát már most rögzíjtük az állapotokat). Számoljuk a képkockát bőszen, de mivel nem áll rendelkezésre a teljes számítási kapacitás (hiszen még az előzőn is molyolunk egy ideig) az újonnan érkező képkocka számítási ideje is teljen véletlenszerű lesz. Aztán megint lesz egy kis rés, ahogy a képkocka vége felé közelítünk, amire átlapol egy újabb képkocka. Mivel a presentek nem képkockahatáron vannak, hanem szinte dobókockázunk egyet, hogy mikor érkezzenek, nekem ez mindenképpen megnövekedett stuttert (rángatást) jelez, de talán késleltetést is megnöveli (habár a késleltetést kompenzálhatja a több kirakott képkocka).
Eddig azt képzeltem, hogy csak képkockahatárok között multiengine-eznek. Ennek így nem sok értelmét látom. Az fps növekszik, az élvezeti faktor csökken.
-
Akármeddig gondolkodom, egyre inkább úgy tűnik, hogy ez nagy mértékben növeli a stutter névvel jellemzett problémát. Ha van egy kis rés a számítási kapacitásban, akkor nyomunk egy presentet, és elkezdjük számolni a következő képkockát (tehát már most rögzíjtük az állapotokat). Számoljuk a képkockát bőszen, de mivel nem áll rendelkezésre a teljes számítási kapacitás (hiszen még az előzőn is molyolunk egy ideig) az újonnan érkező képkocka számítási ideje is teljen véletlenszerű lesz. Aztán megint lesz egy kis rés, ahogy a képkocka vége felé közelítünk, amire átlapol egy újabb képkocka. Mivel a presentek nem képkockahatáron vannak, hanem szinte dobókockázunk egyet, hogy mikor érkezzenek, nekem ez mindenképpen megnövekedett stuttert (rángatást) jelez, de talán késleltetést is megnöveli (habár a késleltetést kompenzálhatja a több kirakott képkocka).
Eddig azt képzeltem, hogy csak képkockahatárok között multiengine-eznek. Ennek így nem sok értelmét látom. Az fps növekszik, az élvezeti faktor csökken.
-
Hamarabb elkezdhető a következő képkocka számítása. Ezzel hamarabb lesz eredmény is. Ergo összességében csökken a késleltetés.
Az efféle trükközés miatt a CPU fps más lesz, mint a GPU fps. Régen ez majdnem megegyezett, mert két present között eltelt ms kb. hasonló a frame számításának ms-ban mért idejével. Ma lehet olyat csinálni, hogy a presentek közötti ms eltérjen a frame számításához szükséges időtől, hiszen tulajdonképpen konkrétan az a trükk, hogy a presentek meghívásával játszol, hogy hamarabb végezzen a tényleges képszámítás. Ez azért éri meg, mert a GPU egy heterogén processzor. Bőven dolgozhat már az új képen az egyik része, amíg a másik része befejezi az aktuális képet. Ezek a részek az átlapolás nélkül nem dolgoznának párhuzamosan.(#23542) proci985: Az jó megoldás.
-
Mint írtam ilyen trükköt a Doom, az új Deus Ex és a Battlefield 1 használ. Amelyik játék nem használ ilyen trükközést, ott nyilván nem sok eltérés lesz a CPU és a GPU fps között.
(#23546) Szaby59: Egyik sem. Pont azért, mert a CPU fps a trükközés miatt nem amúgy is pontatlan lenne, úgy meg minek jelezni azt?
Szerk.: Nem értem mit akarsz bizonyítani? Vagy arra gondolsz, hogy a motorokból azért hagyták ki ezeket a méréseket, mert valamit el akarnak titkolni. Nem hiszem, hogy így lenne. A Microsoft se hívná fel erre a figyelmet.
CPU frame-t persze közöl a Frostbite, de nem present-to-present, hanem t_game-to-t_present mérést. -
Hitmanben pár FPS-nyi (jelentéktelen) eltérés van CPU és GPU FPS-nél.
Amúgy computerbase meg más site is már lemérte az érkező 16.10.2-vel és a multi-GPU azzal is csak DX11-ben működik, dx11/12 között is minimális különbségek vannak, sőt leginkább pont a DX11-es mód gyorsult kicsit az FX-en.
-
Hamarabb elkezdhető a következő képkocka számítása. Ezzel hamarabb lesz eredmény is. Ergo összességében csökken a késleltetés.
Az efféle trükközés miatt a CPU fps más lesz, mint a GPU fps. Régen ez majdnem megegyezett, mert két present között eltelt ms kb. hasonló a frame számításának ms-ban mért idejével. Ma lehet olyat csinálni, hogy a presentek közötti ms eltérjen a frame számításához szükséges időtől, hiszen tulajdonképpen konkrétan az a trükk, hogy a presentek meghívásával játszol, hogy hamarabb végezzen a tényleges képszámítás. Ez azért éri meg, mert a GPU egy heterogén processzor. Bőven dolgozhat már az új képen az egyik része, amíg a másik része befejezi az aktuális képet. Ezek a részek az átlapolás nélkül nem dolgoznának párhuzamosan.(#23542) proci985: Az jó megoldás.
-
De érted magát a problémát? A 3rd party program explicit API-val nem megbízható. Teljesen más eredményeket közölhet, mint a valóság. Azzal nem megyünk sokra, hogy később a Guru3D leírja, hogy elbaszták. Ettől a 3rd party programok megbízhatósága nem nő.
Igen, ez elég nehéz, de ha pontos eredményt akarsz, akkor jelen pillanatban nincs választás. Talán fél vagy egy év múlva fejlesztenek egy sokkal jobb 3rd party mérőprogramot, ami minden lehetséges problémát figyelembe vesz, mert amúgy ez nem lehetetlen, de addig meg vagyunk lőve.
-
Sokan nem értik, hogy mi az a multi-engine. A present akármelyik parancslistán meghívható, ha az előnyös. A Radeonon számos programban engedélyezett opcionálisan a compute parancslista, ha az az adott képkocka számítása esetében előnyösebb, késleltetést csökkentő aszinkron compute implementáció például. Persze lehet, hogy nem előnyös, és akkor nem ott hívja meg. Ilyen a Doom, az új Deus Ex, illetve a Battlefield 1 is. Na most a 3rd party monitorozó nem képes ezt lekezelni, mert nem ismeri, hogy az adott játék konstrukcióját. A sebességet ~10%-os hibaaránnyal meg tudja mérni, de képtelen lesz valós frametime-ot felállítani, ha nem látja az összes present hívást. Mivel ezek átlapoltak az egész egy összekuszált frametime lesz. Ennyi.
-
Dehogynem. Bár másik 3rd party mérőprogramról volt szó, de az ExtremeTech is írt arról, hogy ez nem olyan egyszerű, mint a régi rendszer. [link] - itt konkrétan a Guru3D mikroakadást mért, de valójában nem volt mikroakadás, csak az FCAT nem működött úgy, ahogy kellett volna. Viszont a valós output jó volt! Ezért kell programon belüli mérőt használni DX12-ben!
Sajnos nagyon kevesen néznek utána, hogy hogyan működik az explicit API. Még a Microsoft ajánlásait sem olvassák el. Egyszerűen csak nyakalják be azt a számot, amit a 3rd party program kiköp, és fel sem merül senkiben, hogy az esetleg nem jó. A boldog tudatlanság ugye. Nekünk is sokkal egyszerűbb lenne. Lemérnénk 3rd party programmal, és szarnánk bele, hogy az igaz-e vagy sem.
Az fcat-os mérést később maga a guru3d is elismerte, itt nem fcattal mernék és ott látszott is, hogy valami nincs rendben.
Elég nehéz úgy a programon belülivel mérni ha nincs rá lehetőség...
-
Ezek szerint akkor senki nem érti rajtad kívül ? Jó, írd meg az adott siteoknak a véleményed, attól, hogy más fórumon cáfolod az eredményeiket semmire nem mész és nem bizonyítasz. Ha nem megbízható akkor tényleg ne mérjenek, addig amig nincs tisztázva elmegy...
Dehogynem. Bár másik 3rd party mérőprogramról volt szó, de az ExtremeTech is írt arról, hogy ez nem olyan egyszerű, mint a régi rendszer. [link] - itt konkrétan a Guru3D mikroakadást mért, de valójában nem volt mikroakadás, csak az FCAT nem működött úgy, ahogy kellett volna. Viszont a valós output jó volt! Ezért kell programon belüli mérőt használni DX12-ben!
Sajnos nagyon kevesen néznek utána, hogy hogyan működik az explicit API. Még a Microsoft ajánlásait sem olvassák el. Egyszerűen csak nyakalják be azt a számot, amit a 3rd party program kiköp, és fel sem merül senkiben, hogy az esetleg nem jó. A boldog tudatlanság ugye. Nekünk is sokkal egyszerűbb lenne. Lemérnénk 3rd party programmal, és szarnánk bele, hogy az igaz-e vagy sem.
-
-
Sokan nem értik, hogy mi az a multi-engine. A present akármelyik parancslistán meghívható, ha az előnyös. A Radeonon számos programban engedélyezett opcionálisan a compute parancslista, ha az az adott képkocka számítása esetében előnyösebb, késleltetést csökkentő aszinkron compute implementáció például. Persze lehet, hogy nem előnyös, és akkor nem ott hívja meg. Ilyen a Doom, az új Deus Ex, illetve a Battlefield 1 is. Na most a 3rd party monitorozó nem képes ezt lekezelni, mert nem ismeri, hogy az adott játék konstrukcióját. A sebességet ~10%-os hibaaránnyal meg tudja mérni, de képtelen lesz valós frametime-ot felállítani, ha nem látja az összes present hívást. Mivel ezek átlapoltak az egész egy összekuszált frametime lesz. Ennyi.
-
A frametime alapján pont az nVidia a jobb, a mérési metódust meg csak itt kérdőjelezték meg (lehet, hogy igaz, de amikor x sitera egy olyan panaszkodik akik soha nem mérnek frametime-ot addig nem nekik hiszek míg be nem bizonyították
). Ha nem jól mérne az AMD/nV lenne az első aki hőbörögne, hogy hülyeséget mérnek 
-
Persze értem, én nem szigorúan a témára reagáltam, inkább csak az Nvidia tulajok általános DX12 hőbörgésére.
A frametime alapján pont az nVidia a jobb, a mérési metódust meg csak itt kérdőjelezték meg (lehet, hogy igaz, de amikor x sitera egy olyan panaszkodik akik soha nem mérnek frametime-ot addig nem nekik hiszek míg be nem bizonyították
). Ha nem jól mérne az AMD/nV lenne az első aki hőbörögne, hogy hülyeséget mérnek -
Erre már adott megoldást a Microsoft. A mérőmodul úgy is be van építve minden motorba, így azt ajánlja a cég, hogy legyen felvehető a játékmenet. Ennyit kell beépíteni csak.
De egyébként az explicit API-k fejlesztésénél még csak tárgyalni sem tárgyalták azt a szempontot, hogy a benchmarkolás legyen-e egyszerű. Millió egy nagyobb, megoldásra váró probléma volt a rendszerrel.(#23529) Raggie: Az NV-n is félremérhet egy 3rd party program. Ez egy szoftverben keletkező probléma, persze hardverfüggő a hatása, de alapvetően nem válogat a gyártók között. A legjobb módszer, amit a Microsoft mond. Beépített mérőmodul és felvehető játékmenet.
Persze értem, én nem szigorúan a témára reagáltam, inkább csak az Nvidia tulajok általános DX12 hőbörgésére.
-
-
-
Tehát akadályozza a DX12 rendszer a független tesztelhetőséget. Milyen kényelmes...
Bár az elmúlt évek során amennyire darabokra szedték őket a tesztekkel, el is hiszem, hogy valamit ki kellett találniuk ellene.Igen-igen, plusz jönnek a gyíkemberek T-rex háton....
Hanyagoljuk már ezt a szintet, ennél még a konstans "szar a driver" duma is "szakmaibb"....
-
Ha arra gondolsz, hogy általános 3rd party programmal nem biztos, hogy pontos lesz az eredmény, akkor igen. De ez alapvetően az explicit hozzáférés és a multi-engine modell átka, semmint egy szándékos limitáció a DX12 és a Vulkan alatt. Másfelől viszont vannak előnyei is. Amíg DX11 alatt csak CPU oldali fps-t mérhettél (t_present-to-t_present), addig az explicit API-kkal ténylegesen mérhető a t_game-to-t_render idő is, vagyis pontosabb lesz az eredmény, amit az alkalmazás közöl. A hátrányok mellett tehát vannak előnyök is. Nem csak CPU fps-t lehet közölni, hanem GPU fps-t is. Mi a tesztjeinkben DX12-vel már ezt közöljük.
-
Egy GPU-val nincs frame pacing.
Párszor leírtam már, hogy DX12 és Vulkan alatt 3rd party programmal mérni a legnagyobb hiba, amit el lehet követni egy tesztelés során. Erre kis túlzással mindenki felhívta már figyelmet, mert ezek az API-k nem single-engine rendszerek.
Volt már ilyen grafikon a Guru3D által, aztán kiderült, hogy az egész egy programhiba. [link] - a valóságban a megjelenítés jó volt.Nagyon jól mondja a Microsoft, hogy a DX12-ben (és persze a Vulkanban, csak erre nem térnek ki) csak a direkten az alkalmazásba épített mérőkkel szabad bármit is mérni. Az a mérőmodul ugyanis ismeri az alkalmazást, míg egy 3rd party opció sajnos nem.
-
A Frostbite-ra ez nem igaz. Ez a motor új fejlesztés, a DX12-re írva. Gyorsít is a Radeonon, még aszinkron csodák nélkül is. Arról a DICE nem tehet, hogy az NV architektúrája nem általánosra van tervezve. A GeForce-ok DX11 alatt azért gyorsak sokszor, mert egy csomó sűrűn használt írási folyamatra, vagy pufferelérésre van speciális gyors hozzáférés, amivel lerövidíthető az az idő, ami a feldolgozáshoz kell. Ellenben az általános adatutak jóval lassabbak, vagyis amit megnyernek a speciális adatutakon, azt elveszthetik az általánosokon. DX12-ben ez látható, mert ez az API rengeteg ilyen speciális adatelérést tesz lehetetlenné, vagyis ellehetetleníti, hogy a GeForce úgy működjön, ahogy a hardvert tervezték. 5-6 év múlva sem tudnak majd ezzel mit kezdeni, mert ez nem programozásbeli, hanem hardveres gond.
Hát, ehhez képest még AMD-n is jóval rosszabb a frame pacing DX12-vel, hiába magasabb kicsit az fps. Most se nagyon jött össze ez a DX12.
-
Ez most nem olyan egyszerű. Az Intel bácsi is látja, hogy az új API-kkal nem az IPC vagy a magszám fog nyerni, hanem az egyensúly. Ez nagyon megnehezíti a fejlesztést. Emellett pont az Intel bácsi mondta nemrég, hogy nem tudják, hogy miket raknak át a játékfejlesztők a tipikus munkafolyamatokból a GPU-ra. Például megemlítették, hogy a Nitrous új verziója más minimum magszámot igényel, ha van aszinkron compute a GPU-n és több mag kell, ha nincs. És ezzel a lehetőséggel többen élhetnek, ami megint nehezíti a processzortervezőket. Többek között ezért hoz az Intel mainstream platformba hatmagost, mert aszinkron compute nélkül a Nitrous minimum igénye hat mag lesz.
-
Láthatod, hogy nem azon múlik, hogy melyik VGA-ban nem lesz, hanem sokkal inkább azon, hogy aktív-e. A Maxwell és a Pascal is támogatja ezt a funkciót, de a meghajtó rendre letiltja a DX12-es játékokra.
Az a baj az aszinkron compute-tal, hogy nem olyan egyszerű a hatékony hardveres implementációja, hogy csak beraksz a lapkába pár független compute parancsmotort, esetleg csinálsz még egy előre definiált statikus particionálást alkalmazó üzemmódot rá. Igen alacsony szinten kell a rendszert beépíteni, ami majdhogynem teljes újratervezést igényel. Amíg ez nem történik meg, addig a funkció támogatható, de előny ebből nagyon korlátozott formában lehet. -
Ez most nem olyan egyszerű. Az Intel bácsi is látja, hogy az új API-kkal nem az IPC vagy a magszám fog nyerni, hanem az egyensúly. Ez nagyon megnehezíti a fejlesztést. Emellett pont az Intel bácsi mondta nemrég, hogy nem tudják, hogy miket raknak át a játékfejlesztők a tipikus munkafolyamatokból a GPU-ra. Például megemlítették, hogy a Nitrous új verziója más minimum magszámot igényel, ha van aszinkron compute a GPU-n és több mag kell, ha nincs. És ezzel a lehetőséggel többen élhetnek, ami megint nehezíti a processzortervezőket. Többek között ezért hoz az Intel mainstream platformba hatmagost, mert aszinkron compute nélkül a Nitrous minimum igénye hat mag lesz.
-
A GPU egyáltalán nem úgy működik, mint egy CPU. Lehet beszélni itt is IPC-ről, csak nem érdemes.
Ezek a lapkák igen komplex heterogén feldolgozók, míg egy CPU jóval egyszerűbb homogén feldolgozó.(#23493) Yutani: Itt azt kell látni, hogy a következő évben a programok zöme igényli a négy magot, tehát mindenképpen négy szálat kell adni a prociknak. Enélkül egyszerűen nem fognak elindulni. Az mindegy, hogy egy kétmagosban meglenne az erő a programfuttatáshoz, akkor sem fog rajta elindulni, amíg nincs négy szál.
-
A GPU egyáltalán nem úgy működik, mint egy CPU. Lehet beszélni itt is IPC-ről, csak nem érdemes.
Ezek a lapkák igen komplex heterogén feldolgozók, míg egy CPU jóval egyszerűbb homogén feldolgozó.(#23493) Yutani: Itt azt kell látni, hogy a következő évben a programok zöme igényli a négy magot, tehát mindenképpen négy szálat kell adni a prociknak. Enélkül egyszerűen nem fognak elindulni. Az mindegy, hogy egy kétmagosban meglenne az erő a programfuttatáshoz, akkor sem fog rajta elindulni, amíg nincs négy szál.
-
már szétszaggatja az ipc az intel procikat. Legalább 50%-kal gyorsabb lett 8-10 év alatt. Közben nézd meg hogy mennyit gyorsult a vga ipc...
A GPU egyáltalán nem úgy működik, mint egy CPU. Lehet beszélni itt is IPC-ről, csak nem érdemes.
Ezek a lapkák igen komplex heterogén feldolgozók, míg egy CPU jóval egyszerűbb homogén feldolgozó.(#23493) Yutani: Itt azt kell látni, hogy a következő évben a programok zöme igényli a négy magot, tehát mindenképpen négy szálat kell adni a prociknak. Enélkül egyszerűen nem fognak elindulni. Az mindegy, hogy egy kétmagosban meglenne az erő a programfuttatáshoz, akkor sem fog rajta elindulni, amíg nincs négy szál.
-
schawo
titán
Az ipc teljesítmény nőtt, de az igp is ugye belekerült első i7 óta és jelenleg 720p low grafikán viszi a mai játékokat is. A paszta nem olyan szar csont nélkül megy 4,5 ghz-en a 6600k-m.
-
Az a vicces, hogy a 2 éve vett haswell processzor jelenleg drágább mint akkor, sőt, egy árban van a legújabb cpu-kal is. Régen vettem egy procit és 2 hónap múlva szívtam a fogamat, mert már akkor véget nem érő csökkenésbe kezdett az ára. Biztos közre játszik, hogy lelassult manapság a fejlődés cpu fronton.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Rohanok is venni, bárki aki elémugrik közben, fellököm. 
Még 5x gyorsabban is k...va lassú lesz.
). Ha nem jól mérne az AMD/nV lenne az első aki hőbörögne, hogy hülyeséget mérnek 
Ú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.
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest