- Kiemelkedően csendes ASUS VGA jött a Noctua közreműködésével
- Mini kijelzős SSD-hűtő a Thermalright névjegyével
- Windows: mi történik valójában Leállításkor, Alvó módban és Újraindításkor?
- Gyenge Wi-Fi otthon? – a leggyakoribb hibák és megoldások
- Korábbi vezetője szerint 40 milliárd dollár kell az Intel versenyképességéhez
- Melyik tápegységet vegyem?
- Azonnali notebookos kérdések órája
- Házimozi belépő szinten
- Lopakodva befutott a Radeon RX 9060
- Kiegészítette az öregedő professzionális Radeonokat az AMD
- Fejhallgató erősítő és DAC topik
- Apple asztali gépek
- Milyen egeret válasszak?
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Milyen cserélhető objektíves gépet?
Hirdetés
Új hozzászólás Aktív témák
-
#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)
-
#23594
->Raizen<-
veterán
Dancs Ákos
#23592
->Raizen<-
veterán
válasz
Dancs Ákos
#23592
üzenetére
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. -
#23593
letepem
aktív tag
->Raizen<-
#23587
letepem
aktív tag
válasz
->Raizen<-
#23587
üzenetére
Ez ilyen formában nem igaz, a Nano gyorsult
-
#23592
Dancs Ákos
csendes tag
Abu85
#23583
Dancs Ákos
csendes tag
Ü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??
-
#23590
->Raizen<-
veterán
lezso6
#23589
->Raizen<-
veterán
válasz
lezso6
#23589
üzenetére
We use a frametime run with the ULTRA quality preset. We will test DX11 and a good number of cards in DX12 mode performance wise. Both modes look very similar, DX11 seems to be a slight notch faster albeit we are taliing a few FPS here. We flick the quality settings at Ultra before each resolution run and disable VSYNC. Games typically should be able to run in the 40 FPS range combined with your monitor resolution. From there on-wards you can enable/disable things if you need-more performance or demand even better game rendering quality.
-
#23589
lezso6
HÁZIGAZDA
->Raizen<-
#23587
válasz
->Raizen<-
#23587
üzenetére
BF1-ben van beépített bench, s ha igen, azt használták?
-
#23588
cyberkind
félisten
->Raizen<-
#23587
cyberkind
félisten
válasz
->Raizen<-
#23587
üzenetére
És még nem is szebb a játék.
-
#23587
->Raizen<-
veterán
->Raizen<-
veterán
NA FASZA az összes kártya lassul dx12-ben FHD-ben bf1 teszt. [link]
-
Abu85
HÁZIGAZDA
válasz
velizare
#23575
üzenetére
Az explicit parancskezelésen túl a DX12 mód bindless, így a CPU-terhelés még az erőforrás-bekötés szempontjából is alacsony. Ez főleg a játék végén fog érződni, ugyanis DX11 módban egyetlen hardver sem tud 10-15 fps-nél többet kinyomni zoom outban. A DX12-vel simán megvan a 30-50 fps hardverfüggően. A DX12-ben az AI lépése több szálon lesz számolva, míg DX11-ben ez még mindig egy szálon fut. Tehát DX12-ben nem kell elmenni a játék végén lefőzni egy kávét lépésenként. A motor szoftveres raszterizálással dolgozik, ami DX11-ben eszi a hardvert, de DX12-ben az aszinkron compute miatt ingyenes. Multiadapterre pedig egy alacsony késleltetésű mód lesz beépítve, aminek az SFR az alapja, de ki van egészítve némi temporális átlapolással.
-
-
válasz
velizare
#23568
üzenetére
ö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
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23567
üzenetére
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. -
imi123
őstag
-
-
Puma K
nagyúr
válasz
mcwolf79
#23558
üzenetére
Az megvan, hogy attol meg hogy a jatek nevenek az elso szava megegyezik a sok evvel ezelott megjelent verziokkal a jatek amugy fejlodott grafikailag es jatekmehanikailag?
Amugy jatszottal is valamelyik ujabb verzioval? Vagy legalabb neztel videot milyen is egy ujabb pl: Mario?
-
-
mcwolf79
veterán
-
DudeHUN
senior tag
válasz
mcwolf79
#23558
üzenetére
+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. -
Abu85
HÁZIGAZDA
válasz
Crytek
#23549
üzenetére
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.
-
Abu85
HÁZIGAZDA
válasz
schawo
#23547
üzenetére
Arra ez nincs hatással. Itt nem rések vannak, hanem tökéletsen kihasználatlan részegységek. Ezek malmoznak, amíg a képkocka számítása befejeződik. Ezeket ezzel a módszerrel befogják, hogy ne csak várjanak ölbe tett kézzel, hanem dolgozzanak. Ez a GPU-k tipikus problémája, hogy nagyjából ~20 elemből álló heterogén processzorok, és ezek az elemek egymástól teljesen függetlenül képesek lennének működni, ha különállóan etetné őket az API. Erre találta ki a Microsoft a multi-engine-t, illetve a Khronos a queue family-t.
Még egyszer kihangsúlyozom ez nem újdonság. Konzolon több tucat cím alkalmazza évek óta. PC-n még csak három, de az látható, hogy nagyon terjed.
(#23548) Szaby59: Nem. Amiatt akadt be, mert a DX12 memóriamenedzsment szemetelt a programban. Megjelenésre kap egy fixet, illetve ehhez kell új driver is.
-
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.
-
#85552128
törölt tag
És ezek közül melyik jelenti vissza külön a CPU és GPU FPS-t ? Kétlem, hogy akkora különbség lenne, főleg, hogy akkor az erősebb procin is ugyanúgy hülyeséget kéne mutatnia.
(#23545) Abu85 Tehát akkor 0, ismétlem nulla gyakorlati bizonyítéka van ennek, márpedig ebben az esetben nemcsak az FX-en, de a másikon is jelen kéne lennie azoknak az "anomáliáknak". CPU frametimeot egyébként a BF1 biztosan közöl, mert a frostbite már jó ideje tudja ezt.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23544
üzenetére
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. -
#85552128
törölt tag
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.
-
Abu85
HÁZIGAZDA
válasz
schawo
#23541
üzenetére
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.
-
proci985
MODERÁTOR
ugy emlekszem valamelyik tesztoldalnak van kamera alapu frametime merese, annak elvileg mukodnie kell. viszont nem emlekszem, hogy tomsnak, anandnak techpowerupnak vagy hocpnek volt ilyenje. (utobbi egy-masfel evben miota megvannak a 290Xek nem nagyon nezek GPU teszteket).
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23539
üzenetére
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.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23534
üzenetére
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.
-
Raggie
őstag
válasz
Locutus
#23535
üzenetére
Én biztos vagyok benne, hogy ki lesz erre találva valami, amivel ismét egyszerűen lehet benchmarkolni. A nagyobb váltások körül mindig vannak olyan időszakok amikor ki kell újra alakulnia a bevett szokásoknak/módszereknek az új környezetben is. Jelenleg ez az időszak tart.
Szerintem felesleges ezt a DX12-nek és a Microsoft-nak felróni. mert pl egyik eddigi API és DX feljesztésénél sem volt ez, mint szempont figyelembe véve.
-
#85552128
törölt tag
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23532
üzenetére
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.
-
#85552128
törölt tag
válasz
Raggie
#23531
üzeneté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 
-
Abu85
HÁZIGAZDA
válasz
Locutus
#23528
üzenetére
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.
-
Raggie
őstag
válasz
Locutus
#23528
üzenetére
A fejlődés és az új irányok valakiknek mindig rossz, míg másoknak kedvező. Ez így volt amióta világ a világ.
Jelen esetben én (nem fanságból) örülök, hogy az AMD-nek kedvező és az Nvidiá-nak hátrányos, mert jobb volna mindenki számára ha a két cég kiegyenlítettebben uralná a piacot. -
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23525
üzenetére
DX11-ben csak present időket mérhettél. Azért a bármitől az nagyon messze van. Sokszor nem is pontos ez az eredmény. Egyébként programra levetítve itt is van esély rá, hogy a present időket normálisan lehessen mérni, mert természetesen írható egy olyan 3rd party alkalmazás, ami figyelembe veszi az adott játék működését, és az játékon belül a hardverek kategorizálását. A probléma az, hogy senki sem fejleszt ilyen programot játékonként lebontva, mert azt karban kell tartani, és minden patch után ellenőrizni kell, hogy mi változott, azaz a program továbbra is hiteles eredményeket közöl-e. Ezért mondja a Microsoft, hogy csak a programon belüli mérőmodul a hiteles.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#23522
üzenetére
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.
-
Abu85
HÁZIGAZDA
válasz
schawo
#23518
üzenetére
Nem a proci a probléma, hanem a mérőprogram. Ezeket sajnos el kell felejteni, mert a DX12 és a Vulkan nem single-engine API. Ha az adott mérőprogram nincs konkrétan a mért programhoz szabva, akkor teljesen fals eredményeket adhat. Annyira alacsony szintű a működés, hogy egy általánosan, csak a grafikai presentek érzékelésére kialakított program azt képtelen jól mérni. Arra számít, hogy csak ott lehet presentet meghívni, közben ez hardverenként eltérő lehet.
A játékokba épített mérők tudják, hogy melyik hardver hogyan működik, így annak a működésnek megfelelően el tudják dönteni, hogy a több present hívás között ténylegesen mettől meddig tart egy frame számítása. Erre egy 3rd party program sajnos képtelen. -
Abu85
HÁZIGAZDA
válasz
mlinus
#23517
üzenetére
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.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#23512
üzenetére
A GoW4-ben az aszinkron compute opció változtatható a Pascal és a GCN architektúrára. A többinél ki van szürkítve, de az is lehet, hogy magát az opciót sem ajánlja fel. Az biztos, hogy csak az említett két architektúrára aktiválható, ezt a Microsoft megerősítette, amikor kérdeztem őket erről.
A PC-re kialakított implementáció a jellege miatt nem segít sokat a sebességen. A legtöbb játék az aszinkron compute-ot compute shader offloadra használja, míg a GoW 4 ilyen formában ezt a funkciót csak Xbox One-on használja. PC-n a többletterhelést próbálja csökkenteni, amivel nem igazán lehet 2-3%-nál többet nyerni. Ez még a Rise of the Tomb Raiderben helyet kapó implementációnál is alacsonyabb határfokú. De szó se róla gyengusabb procikkal tényleg segít egy picit. -
Abu85
HÁZIGAZDA
válasz
schawo
#23510
üzenetére
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. -
Abu85
HÁZIGAZDA
válasz
schawo
#23508
üzenetére
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.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#23506
üzenetére
Már most is van ilyen játék, ami három-négy magot igényel minimum.
Általánosságban egyébként azért lesz minimum a négy mag, mert az új API-kkal a skálázás megoldása mellett szereztünk egy új problémát. Ahhoz, hogy ez az explicit parancspufferes modell skálázódjon az kell, hogy a motor job rendszerű legyen, vagyis nincsenek előre leosztott szálak, hanem munkák vannak, és van egy mag, ami ezeket a munkákat kezeli a maradék magokon. Ez egyrészt addig jó, amíg van minimum három magod, mert abból egy csinálja a menedzsmentet, kettő pedig csinálja a valós feldolgozást. Ha két magod van, akkor az azért hátrányos, mert nincs mit menedzselni. Egy mag marad a valós munkára, és egyet pedig elvisz az a menedzsment, hogy minden munka legyen berakva arra az egy szem magra. Emiatt tiltják a fejlesztők ezeknél a job motoroknál, hogy két szállal elinduljanak. A szoftverstruktúra olyan, hogy biztosan rosszul futna.
-
Abu85
HÁZIGAZDA
válasz
schawo
#23503
üzenetére
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.
-
#23503
schawo
titán
->Raizen<-
#23499
válasz
->Raizen<-
#23499
üzenetére
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...
-
Csupingo
veterán
válasz
#85552128
#23501
üzenetére
Persze világos, hogy a nálunk lévő árakhoz nem sok köze van az intelnek, vagy az nvidia-nak.
Most nem is néztem meg a kezdő és a jelenlegi árakat dollárban, csak mint végfelhasználó hőbörgök kicsit: hogyha most akarnék venni egy 3 éves 4570-es processzort, akkor még mindig annyit kéne fizetnem érte, mint 3 évvel ezelőtt. Régebben, ha türelmes volt az ember, akkor az 1-2 éves komolyabb dolgokhoz jóval olcsóbban hozzájutott.
![;]](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
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.
- Sapphire PULSE RX 6600 XT 8GB Garanciával!
- Zotac RTX 3080 10GB GDDR6 GAMING AMP HOLO Eladó!
- Készpénzes / Utalásos Videokártya és Hardver felvásárlás! Személyesen vagy Postával!
- Manli GeForce RTX 3070 Ti 8GB GDDR6X 256bit LHR videokártya (használt)
- EVGA GeForce RTX 2080 XC GAMING 8GB GDDR6 Videokártya
Állásajánlatok
Cég: FOTC
Város: Budapest