kernel_panikuoja wrote: ↑

2018-09-09 10:19

Man rodos tu pats nesupranti scale'inimo prasmes. Scale'as reiskia ne kiek % branduoliai isnaudojami, ar load'as pasiskirstes (nes tai yra load balance'ingas siaip), o kiek procentu ar kartu pasparteja programos vykdymas pagal kazkoki spartos parametra, didinant branduoliu skaiciu.

Sveikinu iradus nauja isgalvota savoka, prasom nuoroda i saltini.
Scale'inimui reikalingos dvi salygos:
1 threadu isnaudojimas,
2 didziausio threado isskaidymas, ta prasme, kad ne bottleneckint'u. Pvz ankstesni zaidimai naudodavo ir 4 ir 8 threadus, bet vienas threadas vistiek 95-+loado valgydavo.

Kitaip tariant scale'inimas vyksta iki ribos, kiek labiausiai gali isskaidyti/sumazinti maksimalu threada ir is to sekantis jau antras punktas, kiek threadu naudoja. Tiesa, pats threadu skaidymas irgi kainuojanti operacija, atsiranda tam tikros delsos, laukimai, tad praktine riba kazkiek auksciau ivyksta lyginant su teorine.

kernel_panikuoja wrote: ↑

2018-09-09 10:19

Siuo atveju akivaizdziai nei minimalus, nei vidutiniai FPS'ai efektyviai nedideja kai CPU yra daugiau nei 4C8T Intel atveju.

Reiskias i7 susitvarko, joks didesnis branduoliu skaicius net ir teoriskai negali didinti fps skaiciaus. "Branduoliu skaicius" realiai tik apdoroja didesni skaiciavimu load'a. Kita vertus, zaidimas The Witcher. Pries 3 gal metus nagrinejausi 4/4 vs 4/8. Ant "popieriaus" parametrai buvo beveik identiski, tiek vidutiniai, tiek minimalus, skirtumas vos apciuopiamas. Kai pasinagrinejau "gyvai" fps, pamaciau, kad miesto teritorioje, 4/8 turedavo geresnius minimalius. Tas pats ir didesniuose musiuose. O kai jodavo po pievas ar pievoje/tvarte koki padara dorodavo, jokio skirtumo. Tiesiog mieste 4/4 jau retkarciais siek tiek bottlenickindavo. Tas neatsispindejo zaidimo vidurkiuose, nes miestas sudare testo nedidele dali.

kernel_panikuoja wrote: ↑

2018-09-09 10:19

Galima pasirinkti ir kitoki parametra, kuriuo lyginti - tarkim AI "protingumas" singleplayer'yje, kazkokiu budu apibreztu microlag'o stutter kiekis, zaideju tankio ir FPS santykis, fizikos simuliacijos lygis ar dar kazkas, kam itakos turi CPU. Reikia aiskiai parodyti, kas konkreciai praktiskai pagereja, padidinus branduolius, nes ju apkrovimas absoliuciai nieko nesako sia prasme. Gal ten puse to load'o yra kazkoks overhead'as pvz. Ar koks nors chat'a cenzuruojancio AI kodas

Nope. Nepagauni pagrindines esmes, i7 susitvarko, reiskias joks scale'inimas net teoriskai nelabai ka pades, nebent ten per plauka pageres grynai optimizacijos prasme, bet ne bendraja scale'inimo. Kitaip tariant, jei 1 branduolys neturi bottleneck'o, tai ir 100 branduoliu spartos nepadidins. Nekalbu apie tai, kad kai kurios programos paduoda skaiciavimu srauta pagal branduoliu skaiciu.

kernel_panikuoja wrote: ↑

2018-09-09 10:19

Apie Ryzen kolkas is vis nera prasmes B5 prasme sneket, nes jis pasak vedejo vietomis truputi stuterina kaip 7600K, kas aiskiai rodo, jog scale'as gaidiskas, nes beveik viskas remiasi i latency ir dazni, bent kas susije su core expierence'u (svarbiausiu dalyku).

Pats buvai nebloga nuoroda imetes i straipsni apie micro stuttering'a. Kazkaip main nesikoreliuoja stuttering'as su scale'inimu. Gi pats pripazinai, kad problema vienoda su 7600k. Tad padarius dar didesni scale'inima (Razynkos atvejis), joks stuttering'as nepadidejo. Niekur neradau parasyta, kad jis turi ji sumazinti. Beje, stuttering'ui nemazai itakos turi ir operacine sistema.

kernel_panikuoja wrote: ↑

2018-09-09 10:19

Tarkim taip atrodo labai geras scale'as softe: https://openbenchmarking.org/embed.php? ... 593a32&p=2
O cia geras zaidimo scale'as iki 6C https://openbenchmarking.org/embed.php? ... 5e7066&p=2

Scale'as, tai ne rezultatas, scale'as, tai programos savybe paskirstyti load'a pagal pries tai mano 2 parasytus pozymius. Akivaizdu, kad tos skaidres, ir rodo toki koda. O battlefield'o atveju, ji irgi turi tokias savybes, bet nera ka skirstyti. Ko tereikia, kad grafikas tai atvaizduotu (geresni fps), tiesiog developeriams imesti daugiau proco load'o, bet tada i7 neves...
Kita vertus, scale'intas programos veikimas turi dar viena savybe, kad pvz Razynkos atveju numetus dazni nuo branduoliu, fps kristu, bet ne tiek daug, kiek proporcingai numetus nuo i7, nes tiesiog branduoliu load'as uzkiltu. O pas i7 prasidetu bottleneck'as ir zaidimas tiesiog imtu strigineti. Cia jei vis dar manai, kad battlefield'as ne scalin'tas .

Jei fiksuota pc load'a sutalpinsi ant vieno branduolio, ves ir 1 branduolys. O tie tavo grafikai igauna prasme arba toki pavidala tik del to, kad visi branduoliai uzkraunami, kitaip tariant visi branduoliai turi sociai darbo. Siuo Razynkos atveju, net daugiausiai apkrautas threadas naudoja apie 60-65% loado.


P.s.
Beje, as ir pats galiu per 1 minutes parasyti toki koda, kad isnaudotu n threadu, cia tereikia 2 ciklu su async/thread call'u

Reikia atskirti du dalykus, apie ka diskutuojam: ar apie konkreciai B5 betos CPU scale, ar apie CPU scale'inga in general.

Del B5 gincytis nera daug prasmes, nes nei zaidimas yra final versijos, nei vienas jotuberio testavimas tiksliai reprezentuoja situacija. Nera kuom pagristi teiginiu, galima daryti tik kruva prielaidu. Gali buti, kad 7700K yra tiesiog visiskai pakankamas patenkinti kureju dizaino reikalavimus, ir didesnio branduoliu skaiciaus paprasciausiai nereikia. Tai nera trukumas, tai by design (jei taip yra). O Ryzen'ui gal dar nespejo optimizuoti, nes man rodos, jie net nespes visu mechaniku sudeti i final, veliau isleis. As tik konstatavau fakta, jog pagal ta konkretu video ir naudota metodika, bei pagal jotuberio ispudzius, nera jokio praktinio benefit'o is kazko daugiau, nei 7700K. Ar tai tikslu - pamatysim su busimais final versijos testavimais. Nesakau, kad tai butinai trukumas. Ir nesakau, kad tu butinai klisti - kai kazkas padarys tuos tavo minetus eksperimentus su daznio numetimais ir perf pokyciais tarp skirtingo kiekio branduoliu, tada as 100% sutiksiu del B5 scale'o. Kol tas nera pademonstruota, tai tik prielaida, kaip galbut/tiketina veiks B5.

O multicore/multithread scale'as in general tai yra priklausomybe tarp kodo lygiagretumo laipsnio ir bendros jo spartos. Savo bendraja forma ji yra isreiskiama amdahl desningumu https://en.wikipedia.org/wiki/Amdahl%27s_law . Scale'a galima interpretuoti ir kaip teorine softo (ir/arba hw) dizaino savybe, ir kaip konkrecios implementacijos pamatuojama galutini rezultata, nes at the end of the day kodas turi efektyviai spresti kazkokia konkrecia praktine problema, o ne egzistuoti savo sultyse kaip kazkoks teorinis reference'as ar abstraktas be applicable naudos.

O kalbant apie zaidimus, tai jie is esmes yra real-time application'as su aukstu dependenciu laipsniu. Juos lygiagretinti yra sudetingas darbas, ir jiems naturaliai labiau tinka mazo latency ir auksto daznio HW, nei auksto latency ir mazesnio daznio daugiau branduoliu. Ir man absoliuciai giliai pochui, kokiom konkreciai savokom, "zodynais" ir apibrezimais operuoja dev'ai (nes tai skiriasi pagal sriti), jeigu imetus daugiau HW resurso konkreti implementacija man nedemonstruoja scale'o pagal rezultata (darant prielaida, kad yra reikiamas kiekis load'o ir testavimas neiseina is pirminiu perf reikalavimu ribu), vadinasi implementacija sudinai scale'ina ir praktiskai neveikia. Kas kaip nupaisyta ant dev'u whiteboard'u ir kaip viskas veikia ant popieriaus manes, kaip user'io, visiskai nedomina.

Pasikartosiu dar karta, kad neprisikabintum be reikalo - jeigu geras CPU scale'as yra implementintas softe, bet del kazkokiu priezasciu tiesiog "idle'ina" ir negali buti efektyviai praktiskai panaudotas (nei vienam scenarijuje) tam tikram kontekste - tai efektyviai tas pats, kas jo tam kontekste nera. O del B5 as nesigincysiu, nes gal paaiskes, kad apkrautam map'e, action driven scenoje 7700K pagal min. 0.1/1% gaus ant 30% nuo 8700K, tiesiog to dar niekas nepatestavo - matysim. Imanoma. Kaip ir imanoma, kad tarp ju nebus jokio skirtumo.

Sutinku, kad mano sakinys: "Scale'as reiskia ne kiek % branduoliai isnaudojami, ar load'as pasiskirstes (nes tai yra load balance'ingas siaip)" techniskai buvo ne iki galo teisingas, nes geras CPU scale'as koreliuoja su tolygiu load'o pasiskirstymu tarp branduoliu. Omenyje turejau tai, kad priklausomai nuo HW/OS (UMA/NUMA, affinity, scheduler etc.), ka matai task manager'yje nebutinai reiskia vien tik zaidima. Todel geriausia ziuret praktiskai. Zinoma, tai taip pat reiskia, jog ne vien zaidimas atsakingas uz gera scale'a.

Ir visada lieka filosofija: jeigu scale'as geras iki X branduoliu, bet blogas prie X+n, ar tai reiskia, kad scale'as in general blogas? Is vienos puses taip, jei lyginsim su teoriniu modeliu, kur branduoliu skaicius begalinis. Is kitos puses, jeigu X kiekio visiskai pakanka spresti problema ir patenkinti perf reikalavimus, tai scale'as kaip ir geras. Tai cia nera vieno teisingo atsakymo, nes vienam "geras" bus artimesnis teorijai, o kitam "geras" bus efektyviai susitvarkantis konkreciom salygom. Is principo tai skirtumas tarp mokslinio ir inzinerinio poziurio i klausima.

kernel_panikuoja wrote: ↑

2018-09-10 12:21

Reikia atskirti du dalykus, apie ka diskutuojam: ar apie konkreciai B5 betos CPU scale, ar apie CPU scale'inga in general.

Del B5 gincytis nera daug prasmes, nes nei zaidimas yra final versijos, nei vienas jotuberio testavimas tiksliai reprezentuoja situacija. Nera kuom pagristi teiginiu, galima daryti tik kruva prielaidu. Gali buti, kad 7700K yra tiesiog visiskai pakankamas patenkinti kureju dizaino reikalavimus, ir didesnio branduoliu skaiciaus paprasciausiai nereikia. Tai nera trukumas, tai by design (jei taip yra). O Ryzen'ui gal dar nespejo optimizuoti, nes man rodos, jie net nespes visu mechaniku sudeti i final, veliau isleis. As tik konstatavau objektyvu fakta, jog pagal ta konkretu video ir naudota metodika, bei pagal jotuberio ispudzius, nera jokio praktinio benefit'o is kazko daugiau, nei 7700K. Ar tai tikslu - pamatysim su busimais final versijos testavimais. Nesakau, kad tai butinai trukumas. Ir nesakau, kad tu klisti - kai kazkas padarys tuos tavo minetus eksperimentus su daznio numetimais ir perf pokyciais tarp skirtingo kiekio branduoliu, tada as 100% sutiksiu. Kol tas nera pademonstruota, tai tik prielaida, kaip galbut/tiketina veiks B5.

O multicore/multithread scale'as in general tai yra priklausomybe tarp kodo lygiagretumo laipsnio ir bendros jo spartos. Savo bendraja forma ji yra isreiskiama amdahl desningumu https://en.wikipedia.org/wiki/Amdahl%27s_law . Scale'a galima interpretuoti ir kaip teorine softo dizaino savybe, ir kaip konkrecios implementacijos pamatuojama galutini rezultata, nes at the end of the day kodas turi efektyviai spresti kazkokia konkrecia praktine problema, o ne egzistuoti savo sultyse kaip kazkoks teorinis reference'as ar abstraktas be applicable naudos.

O kalbant apie zaidimus, tai jie is esmes yra real-time application'as su aukstu dependenciu laipsniu. Juos lygiagretinti yra sudetingas darbas, ir jiems naturaliai labiau tinka mazo latecy ir auksto daznio HW, nei auksto latency ir mazesnio daznio daugiau branduoliu. Ir man absoliuciai giliai pochui, kokiom konkreciai savokom, "zodynais" ir apibrezimais operuoja dev'ai (nes tai skiriasi pagal sriti), jeigu imetus daugiau HW resurso konkreti implementacija man nedemonstruoja scale'o pagal rezultata (darant prielaida, kad yra reikiamas kiekis load'o ir testavimas neiseina is pirminiu perf reikalavimu ribu), vadinasi implementacija sudinai scale'ina ir praktiskai neveikia. Kas kaip nupaisyta ant dev'u whiteboard'u ir kaip viskas veikia ant popieriaus manes, kaip user'io, visiskai nedomina.

Pasikartosiu dar karta, kad neprisikabintum be reikalo - jeigu geras CPU scale'as yra implementintas softe, bet del kazkokiu priezasciu tiesiog "idle'ina" ir negali buti efektyviai praktiskai panaudotas (nei vienam scenarijuje) - tas pats, kas jo nera. O del B5 as nesigincysiu, nes gal paaiskes, kad apkrautam map'e, action driven scenoje 7700K pagal min. 0.1/1% gaus ant 30% nuo 8700K, tiesiog to dar niekas nepatestavo - matysim. Imanoma. Kaip ir imanoma, kad tarp ju nebus jokio skirtumo.

Sutinku, kad mano sakinys: "Scale'as reiskia ne kiek % branduoliai isnaudojami, ar load'as pasiskirstes (nes tai yra load balance'ingas siaip)" techniskai buvo ne iki galo teisingas, nes geras CPU scale'as koreliuoja su tolygiu load'o pasiskirstymu tarp branduoliu. Omenyje turejau tai, kad priklausomai nuo HW/OS (UMA/NUMA, affinity, scheduler etc.), ka matai task manager'yje nebutinai reiskia vien tik zaidima. Todel geriausia ziuret praktiskai. Zinoma, tai taip pat reiskia, jog ne vien zaidimas atsakingas uz gera scale'a.

Nezinau, kazka tu cia maisai. As jau pateikiau viena is scale'inimo savybiu ir galimos naudos: numusk 30% daznius Razynkai ir i7, ir pmatysi viena is scale'inimo pliusu konkreciai Battlefield zaidime.
Anksciau zaidimai prastai scale'inosi: arba daug threadu nepalaike, arba ziauriai netolygiai buvo pasiskirste, vienas branduolys 95% loaudus valge, kiti
15%. Su Battlefieldu vienas geriausiu scale'u sia prasme. Kaip ir sakiau, viena is pagrindiniu scale'inimo savybiu yra load'o paskirstymas. Is tavo pateiktu pavyzdziu, mutlithreadines aplikacijos turi neribojama loada iki 64 ar kiek tai branduoliu.

Ir dar, drtx 11 zaidimai turi ribota scaleinima pagal teorija, nes tik viena gija bendrauja su drtx. Ka as matau sitoje situacijoje, kad priesingai, battlefield sauniai padirbejo, ir yra vietos kur deti papildomus skaiciavimus: geresniai fizikai, efektams, zaidimo mechanikai. Ir tikrai jie taip padarytu. Bet kol zaidimai optimizuoti konsolems ir silpnesniems procesoriams... tol praktines naudos is daugiau ir letesniu branduoliu nelabai ir matysime.

Kas idomu siuolaikiniuose zaidimuose, kad fps irgi pilnai pasitiketi neuztenka. Pvz teksturu uzloadinimo greiciai, tam tikri blurai, efektai, toks jausmas, kad dedami tiesiog i eile, ir jei truksta resursu, tiesiog veliau ar mazesniu kiekiu atvaizduojami. Is esmes, tai gerai, numusa lagus, fps didesnis. Tik kita vertus, jei skaiciavimai ar pralaidumas kitoje sistemoje geri, ukzraus greiciau teksturas, uzmes efektus ar kitus dalykus, ir fps kazkiek gali ta puses sekundes nukristi, nes vienu atveju skaiciuos fps su uzloadintom teksturom, kitu atveju ne. Tad va idomus klausimas, ar asmuo turintis procesoriu su 4/4 matys vienodai griunanti pastata, kur pvz 8/16.

Ir as kaip game'ris jau simta karta kartoju, vien fps yra ne viskas. Zaidimas tai daug daugiau negu vien fps. Tai gyvi adaptyvus miestai ar pasauliai su savo gyvnetojais. Ir jei tu matai scale'inimo tik fps prasme, as dar matau, gyvensi zaidima. Anksciau buvo dvi bedos: nebuvo gelezies, nebuvo softo.
Dabar matau is Battlefieldo, kad softas yra, gelezis irgi, tereikia sulaukti zaidimu.

O grynai is zaidejo puses, tai Battlefield 1 mano megstamiausiu zaidimu. Ir man tikslas ne siaip laimeti, ar buti geriausiu komandoje, bet buti MVP. Ir cia jau zmones net patys su pc hackeriais priotetus ant atskiru threadu deda, kad tik mazesnis input lagas butu. O nustatymai buna minimalus, isskyrus atstumo matyma ir teksturas. Ir dar konfiguraciju keitimai jau failineje sitemoje, nes tiek optionu per GI nepateikta. Tad battlefield fps diskusija aktuali tik tiems, kas nezaidzia rimtai saudykliu arba retkariciais, siek tiek pele pajudina. Bet cia kaip ir mienjau, is zaidejo pozicijos.

Nu tai as ir sakau, kad reikia nuodugniu, detaliu final versijos testavimu, kad tokius dalykus ivertinti Nes dabar tiesiog postringaujam apie teorija, ir apie prielaidas tik is 1 BETA saltinio. Taip pat nesakau, kad B5 nescale'ina. As tik sakau, kad kaip gerai scale'ina, ir koks branduoliu skaicius kaip itakoja expierence'a (kaip actually pasiskirstys load'as apkrautam map'e), kolkas tiksliai neaisku.

O del pacio scale'o, tai as gal neaiskiai savo mintis isdesciau ir mes nususisnekejom. Sutinku, kad thread'u isnaudojimas ir load paskirstymas yra salygos scale'ui. Bet salia to, overall nasumas taip pat yra salyga. Jeigu isskaidai load'a i daug thread'u, bet overhead'as gaunasi toks didelis, kad bendras nasumas nepadideja (ar padideja minimaliai), vadinasi, scale'ingas sudas, nors ir visi thread'ai graziai vienodai apkrauti. As tai turejau omenyje.

kernel_panikuoja wrote: ↑

2018-09-10 14:18

Nu tai as ir sakau, kad reikia nuodugniu, detaliu final versijos testavimu, kad tokius dalykus ivertinti Nes dabar tiesiog postringaujam apie teorija, ir apie prielaidas tik is 1 BETA saltinio. Taip pat nesakau, kad B5 nescale'ina. As tik sakau, kad kaip gerai scale'ina, ir koks branduoliu skaicius kaip itakoja expierence'a (kaip actually pasiskirstys load'as apkrautam map'e), kolkas tiksliai neaisku.

del BF5 kazkaip jis keistai cpu isnaudoja nes pats bandziau su saviskiu senuku pc i5 3570k@4.4GHz ir plius senute
ASUS HD 7970 DirectCU II TOP+matrix platinum bios tai ant default setings tas yra medium gaunu 70~60fps ir jie gan stabilus bet cpu apkrova visada 100% na o pakelus iki max setings cpu apkrova nukrenta iki max 67% bet fps max 52 na o min fps 35 cia kai daug veiksmo hmm taigi wtf atsiprasant kas cia per nesamone nes to dar neteko matyti nei ant vieno zaidimo beja rez pas mane 2560x1080 jai ka.

kernel_panikuoja wrote: ↑

2018-09-10 14:18

O del pacio scale'o, tai as gal neaiskiai savo mintis isdesciau ir mes nususisnekejom. Sutinku, kad thread'u isnaudojimas ir load paskirstymas yra salygos scale'ui. Bet salia to, overall nasumas taip pat yra salyga. Jeigu isskaidai load'a i daug thread'u, bet overhead'as gaunasi toks didelis, kad bendras nasumas nepadideja (ar padideja minimaliai), vadinasi, scale'ingas sudas, nors ir visi thread'ai graziai vienodai apkrauti. As tai turejau omenyje.

Gal ne scale'inimas sudas, o kazkas kode yra sudino. Nes fps skiriasi nuo kitu suminiu skaiciavimu, kad cia su time'ingu daug kas labai susisje, kad ir pats zaidimo taktas, ta prasme, idomus daiktas, kuris priklauso nuo pvz net'o duomenu apdorojimo. Kitaip tariant pats fps smarkiai priristas prie ko kors vieno thread'o, o tas threadas prilklauso nuo vieno branduolio charakteristiku. Aisku, galutini varianta galima vadinti ir apskritai sudinu scale'inimu fps ivertinimo prasme.
Realiai, Battlefieldas 1 turi ziauriai daug nesamoniu, ir tikejausi, kad jie jas istaisys, kad normaliai zaisti butu galima, bet nuejo marketingo keliu - kaledines eglutes, arba blizgesio keliu.

Scaling'u aš vadinu paprasčiausią spartos koreliaciją priklausomai nuo kintamojo, kaip dažnis ar branduolių skaičius. Jei kas du papildomus branduolius (pradedant 4C ir baigiant 8C) gaunama, sakykim, +20 proc spartos - scaling'as šių dienų mastais puikus. Jei vis +2C duoda spartos, kuri lygi paklaidos ribose - scaling'as blogas/jo nėra. Mažesni vėlinimai ir resursų paskirstymas tarp gijų yra vienas iš galimų raktų į didesnį scaling'ą, tačiau tolygesnis paskirstymas dar nėra garantas didesniems fps, greičiau gali pagerinti bendrą experience. Jei labai daug lemtų resursų paskirstymas tarp gijų, kuris didesnėje žaidimų dabar visai neblogai atrodo, skundų nebūtų, kad jokio scaling'o vėl ir vėl nėra. Mano nuomone, didžiausia dalis viso šito priklauso nuo programinės įrangos, pavadinkime, kaip ten viskas surašyta/optimizuota. Puikus pavyzdys DRAM dažnio įtaka Ryzen'ams. Architektūra labai jautri tam, bet turime apsčiai tokių žaidimų, kuriuose nė velnio DRAM dažnis nesuveikia ir turim tokių, kur spartos prieuagis labai gražus.

man idomu kokia situacija butu Razynkos atveju atjungi HT (ale kitaip pas AMD vadinasi) nes kai branduoliu kiekis didelis, tai gali greiciau kenkti, negu padeti, nes operacinei sistemai lengviau priotizuoti threadus, permetineti tarp branduoliu.

Čia tikrai tik sutapimas, nu tikrai tikrai Nvidia specialiai to bug'o nedarė kad pakišt koją AMD
https://www.pcper.com/reviews/Graphics- ... 0WX-Tested

Stipena wrote: ↑

2018-09-15 01:59

Čia tikrai tik sutapimas, nu tikrai tikrai Nvidia specialiai to bug'o nedarė kad pakišt koją AMD
https://www.pcper.com/reviews/Graphics- ... 0WX-Tested

Aš labai abejoju, kad taip specialiai darytų. Žaidimų greitis žmonės su šituo CPU turėtų praktiškai nerūpėti.

SoTOP wrote: ↑

2018-09-15 06:32

Stipena wrote: ↑

2018-09-15 01:59

Čia tikrai tik sutapimas, nu tikrai tikrai Nvidia specialiai to bug'o nedarė kad pakišt koją AMD
https://www.pcper.com/reviews/Graphics- ... 0WX-Tested

Aš labai abejoju, kad taip specialiai darytų. Žaidimų greitis žmonės su šituo CPU turėtų praktiškai nerūpėti.

Jo, aš taip pat netikiu kad Nvidia'i rūpi atsigaunanti AMD finansinė padėtis.

[quote=Stipena post_id=58192 time=1536983821 user_id=1619]
[quote=SoTOP post_id=58191 time=1536982379 user_id=230]
[quote=Stipena post_id=58189 time=1536965953 user_id=1619]
Čia tikrai tik sutapimas, nu tikrai tikrai Nvidia specialiai to bug'o nedarė kad pakišt koją AMD
https://www.pcper.com/reviews/Graphics- ... 0WX-Tested
[/quote]Aš labai abejoju, kad taip specialiai darytų. Žaidimų greitis žmonės su šituo CPU turėtų praktiškai nerūpėti.
[/quote]

Jo, aš taip pat netikiu kad Nvidia'i rūpi atsigaunanti AMD finansinė padėtis.
[/quote]

aš tai kaip tik manau, kad nvidijai labai paranku turėti tokį "konkurentą" :idea:

Jei ne fake test, turim siokiu tokiu naujienu.
https://videocardz.com/77983/nvidia-gef ... e-unveiled

https://wccftech.com/amd-epyc-rome-7nm- ... -leak/amp/

Įdomi ateitis nusimato..

daimonass wrote: ↑

2018-09-16 20:57

https://wccftech.com/amd-epyc-rome-7nm- ... -leak/amp/

Įdomi ateitis nusimato..

Panašu jog tikras rezultatas, pagal skaičiavimus +- atitinka.

O pvz idomu kaip atskirti kuris PCB geresnis ir paruostas technologiskai tvarkingiau? pvz sitame video gigabyte ir msi pcb, pas msi matosi tie senoviniai kondikai.. ar cia mazai jie itakos turi? nebuna del ju didesnis coilwine?

5:22 ir 11:17

Povilas wrote: ↑

2018-09-19 14:23

O pvz idomu kaip atskirti kuris PCB geresnis ir paruostas technologiskai tvarkingiau? pvz sitame video gigabyte ir msi pcb, pas msi matosi tie senoviniai kondikai.. ar cia mazai jie itakos turi? nebuna del ju didesnis coilwine?

5:22 ir 11:17

Zirzia ne kondikai, o ritės, todėl abejoju ar kondikai kažką galėtų lemti. Šiaip high end vaizdo plokščių PCB (komponentai) tarp gamintojų daug panašesni nei motininių plokščių, niekas nedrįsta montuoti fuflo. Motinų rinkoje skirtumai už tą pačią kainą pasitaiko daug didesni, kalbu apie VRM fazes. Paskutinį kartą, kiek pamenu, Powercolor buvo pagauta dedanti prastesnius nei yra stock'iniam AMD modelyje galios blokus lyg į RX 480 Red Dragon...

http://www.skytech.lt/dualrtx2080tio11g ... 04137.html
Nu ar yra savanoriu?

0 sandely, paimciau pora