AMD Ryzen -prosessori (Summit Ridge)

[Dygaza]

Onko jossain selitetty, mitä tuo downcore tarkoittaa? Kahden eri CCX:n ytimiä vai SMT:tä?

edit:
ilmeisesti ytimiä, 1+1 tarkoittaa että molemmista CCX:stä yksi ydin?
ja 2+0 tarkoittaa että toinen CCX pois päältä ja toisesta 2 ydintä päällä?

Sitähän sillä haetaan, mutta noissa tuloksissa ei oo mitää järkeä. Miksi opengl:llä 2+2 /4/0 eroaa vulkanin vastaavista. Jos ongelmana pidetään että säikeet hyppivät CCX:ltä toiselle vaikka optimi olisi pitää ne yhdellä ccx:llä oman L2 ja L3 kakkunsa lämpimässä syleilyssä, niin mistä moiset erot johtuvat.

Jotenkin vaan tuntuu että olettamus että Affinityt 0-7 (CCX1) ja 8-15 (CCX2) ovat väärin. CCX 1 corethan voivat olla vaikka 0,1,6,7 ja CCX2 3,4,5,6. Tai vastaavasti vielä 0,1,4,5 ja 2,3,6,7.

 

[Stephen Elop]

Tuossa olisi parempi vertailukohta AMD Ryzen 7 1800X vs. Intel Core i7 7700K Linux Gaming Performance Review - Phoronix
Huomioitavaa on tuo muutos OpenGl versiosta Vulcaniin ja kun tuota muutosta vertailee noiden prossujen kesken. Tietysti pitää myös muistaa mahdollinen testaajan kädetys.

Mää mutuilen jotain pcie väylän kommunikointi ongelmaa/hidastelua.

 

[FireFly Renaissance]

Sitähän sillä haetaan, mutta noissa tuloksissa ei oo mitää järkeä. Miksi opengl:llä 2+2 /4/0 eroaa vulkanin vastaavista. Jos ongelmana pidetään että säikeet hyppivät CCX:ltä toiselle vaikka optimi olisi pitää ne yhdellä ccx:llä oman L2 ja L3 kakkunsa lämpimässä syleilyssä, niin mistä moiset erot johtuvat.

Jotenkin vaan tuntuu että olettamus että Affinityt 0-7 (CCX1) ja 8-15 (CCX2) ovat väärin. CCX 1 corethan voivat olla vaikka 0,1,6,7 ja CCX2 3,4,5,6. Tai vastaavasti vielä 0,1,4,5 ja 2,3,6,7.

tuossa on biosissa kytketty ytimiä päälle kummastakin ccx:stä. Eli eiköhän noi ole ihan oikein, tuskin se bios ihan mitä sattuu ytimiä disabloi.

Näissä tuloksissahan isoja ongelmia on selvästi vain tuossa vulcanissa. Harmi ettei ole laajempia tuloksia/testejä useilla peleillä.

 

[Dygaza]

tuossa on biosissa kytketty ytimiä päälle kummastakin ccx:stä. Eli eiköhän noi ole ihan oikein, tuskin se bios ihan mitä sattuu ytimiä disabloi.

Näissä tuloksissahan isoja ongelmia on selvästi vain tuossa vulcanissa. Harmi ettei ole laajempia tuloksia/testejä useilla peleillä.

Miten siinä biosissa disabloidaan ytimiä? Jos siinä on vaan että coret 1-8 erillisillä rivillä, niin ei se kerro vielä välttämättä niiden fyysistä sijaintia.

 

[hkultala]

Sitähän sillä haetaan, mutta noissa tuloksissa ei oo mitää järkeä. Miksi opengl:llä 2+2 /4/0 eroaa vulkanin vastaavista. Jos ongelmana pidetään että säikeet hyppivät CCX:ltä toiselle vaikka optimi olisi pitää ne yhdellä ccx:llä oman L2 ja L3 kakkunsa lämpimässä syleilyssä, niin mistä moiset erot johtuvat.

Vaikuttaisi vähän siltä, että siellä on todella paljon jotain ylimääräistä synkronointia, tai cachen false sharingia, ja kaikki aika menee ping-pong-liikenteeseen kakkujen välillä, kun kunkin ytimen välimuisti yrittää aina ottaa kilpaa samaan osoitteeseen osoittavaa välimuistilinjaa omakseen kirjoittaakseen siihen.

Kun käytössä on vain yhden CCX:n ytimiä, tämä liikenne on saman CCX:n L2- ja L1-kakkujen välillä, ja tämä on nopeampaa, ja hidastaa vähemmän.

Kun käytössä on kahden CCX:n ytimiä, tulee tätä ping pong-liikennettä myös kahden eri CCX:n kakkujn välillä, ja tämä liikenne hitaampaa.

Perimmäinen syy: Dota2n vulkan-implementaation koodi Linuxilla siis vaikuttaisi sukkaavan pahasti.

 

[hkultala]

Miten siinä biosissa disabloidaan ytimiä? Jos siinä on vaan että coret 1-8 erillisillä rivillä, niin ei se kerro vielä välttämättä niiden fyysistä sijaintia.

Tuon artikkelin edellisellä sivulla näytetään miltä se BIOSin valintaoptio ytimien disabloinniksi näyttää.

 

[Stephen Elop]

Vaikuttaisi vähän siltä, että siellä on todella paljon jotain ylimääräistä synkronointia, tai cachen false sharingia, ja kaikki aika menee ping-pong-liikenteeseen kakkujen välillä, kun kunkin ytimen välimuisti yrittää aina ottaa kilpaa samaan osoitteeseen osoittavaa välimuistilinjaa omakseen kirjoittaakseen siihen.

Kun käytössä on vain yhden CCX:n ytimiä, tämä liikenne on saman CCX:n L2- ja L1-kakkujen välillä, ja tämä on nopeampaa, ja hidastaa vähemmän.

Kun käytössä on kahden CCX:n ytimiä, tulee tätä ping pong-liikennettä myös kahden eri CCX:n kakkujn välillä, ja tämä liikenne hitaampaa.

Perimmäinen syy: Dota2n vulkan-implementaation koodi Linuxilla siis vaikuttaisi sukkaavan pahasti.

Vaikka coreja ja CCX:iä onkin disabloitu, niin SMT on vielä päällä. Osaako toi Dota2 erottaa nopeat ytimet noista virtuaaliytimistä oikein? Ja voiko pelin koodi valita missä ytimessä sitä ajetaan vai määrääkö käyttis sen? Tuossa olisi tarvinnut olla jokin ydinkohtainen kuormitus lisäksi näytettävänä.

 

[Dygaza]

Tuon artikkelin edellisellä sivulla näytetään miltä se BIOSin valintaoptio ytimien disabloinniksi näyttää.

No niinpä näyttää. Luulisi olevan kunnossa.

 

[Dygaza]

Vaikka coreja ja CCX:iä onkin disabloitu, niin SMT on vielä päällä. Osaako toi Dota2 erottaa nopeat ytimet noista virtuaaliytimistä oikein? Ja voiko pelin koodi valita missä ytimessä sitä ajetaan vai määrääkö käyttis sen? Tuossa olisi tarvinnut olla jokin ydinkohtainen kuormitus lisäksi näytettävänä.

Jotenkin nää tulokset on niin randomia kun on keskisuurimäärä säikeitä käytössä että ei oikeasti tiedä mitä tapahtuu. Loadit jossa oikeasti 16 säiettä käytössä että säikeet eivät pompi toimivat hyvin. Muut eivät. Harmittaa kun ei löydy mitään custom affinity testejä jossa eri threadeja pakotetaan eri ytimille. Tekisi mieli hakea kaupasta lankku ja prossu ja testata.

 

[hkultala]

Vaikka coreja ja CCX:iä onkin disabloitu, niin SMT on vielä päällä. Osaako toi Dota2 erottaa nopeat ytimet noista virtuaaliytimistä oikein? Ja voiko pelin koodi valita missä ytimessä sitä ajetaan vai määrääkö käyttis sen? Tuossa olisi tarvinnut olla jokin ydinkohtainen kuormitus lisäksi näytettävänä.

Saman ytimen kahden virtuaaliytimen välillä false sharing ei ole ongelma, koska niille kaikki välimuistit on yhteisiä.

Käyttis määrää missä säikeitä ajetaan.

Tosin useimmilla käyttiksillä säie voi myös yrittää esittää toivomuksen siitä, millä ytimellä sitä ajetaan. Tämä on kuitenkin vain toivomus, ja luulisin, että pelit eivät näitä toivomuksia esitä, koska sen laskeminen, mikä "toivomus" on se oikea ja hyödyllinen on hyvin vaikeaa ja riippuu hyvin paljon siitä millä raudalla softaa ajetaan, ja mitä muuta koneella on samaan aikaan pyörimässä, ja näiden laskeminen siten että siitä olisi useammin hyötyä kuin haittaa olisi ihan hirveää nysväämistä ja silti osutaan liian helpolla pahasti pieleen.

 

[Dygaza]

Saman ytimen kahden virtuaaliytimen välillä false sharing ei ole ongelma, koska niille kaikki välimuistit on yhteisiä.

Käyttis määrää missä säikeitä ajetaan.

No eikös tämä juuri ole se ongelma jos käyttis ei erota virtuaaliytimiä oikeista. Esim pelissä vaikka pelin maithread ja näyttiksen ajurithreadi samalle ytimelle, vaikka molemmat käytännössä vaativat oman dedikoidun ytimen.

 

[jsa]

Ihan nyt vois tietty testata Windowsillakin samat testit niin jäisi pois tuo "pieni" olettamus että noi AMD:n Linux driverit on Vulkan(inkin) osalta vaiheessa.

 

[hkultala]

No eikös tämä juuri ole se ongelma jos käyttis ei erota virtuaaliytimiä oikeista. Esim pelissä vaikka pelin maithread ja näyttiksen ajurithreadi samalle ytimelle, vaikka molemmat käytännössä vaativat oman dedikoidun ytimen.

Yleensä käyttis erottaa, lähinnä bulldozerin tapauksessa heti julkaisun jälkeen käyttikset eivät erottaneet.

Ja ainakin käyttis tietää sen paljon paremmin kuin peli itse, minkä takia peli helposti antaisi käyttikselle vääränlaisia vihjeitä, jos se yrittäisi alkaa samomaan millä ytimellä se haluaa pyöriä.

Zenin kanssa ongelma on se, että käyttikset eivät osaa mallintaa/laskea tuota hitaampaa/kalliimpaa kommunikaatiohintaa kahden eri CCXn ydinten välillä. Mutta tämähän on oikeastaan päinvastainen ongelma, Zenillä haluttaisin sijoitella (keskenään kommunikoivat) säikeet samalle CCX:lle eikä hajauttaa niitä useammalle, kun taas SMT-ongelmissa on kyse siitä että haluttaisiin hajauttaa useammalle fyysiselle ytimelle eikä ajaa saman fyysisen ytimen virutaaliytimissä

Käytännössä järkevä skeduli Zenille 4-säikeiselle pelille olisi yleensä sijoittaa pelin 4 säiettä yhden CCX:n kaikille ytimille, ja lukita ne sinne, eikä sallia mitään muuta ajoon niillä, vaikka pelin säikeet nukkuisivat(jottei välimuisteista heitetä pois mitään pelin dataa), ja jättää toinen CCX kaikille taustaprosesseille. Mutta sitten kuin pelillä on enemmän kuin 4 säiettä, tämä ratkaisu ei enää toimi.

 

[Stephen Elop]

Ihan nyt vois tietty testata Windowsillakin samat testit niin jäisi pois tuo "pieni" olettamus että noi AMD:n Linux driverit on Vulkan(inkin) osalta vaiheessa.

Avoimen lähdekoodin ajuri AMD grafiikka kortilla. Samalla ajurilla myös i7-7700K:n framerate putoaa kun siirrytään vulkan rajapintaan. Pudotus on vain paljon pienempi.

 

[copter]

Voisi kuvitella että jos ongelma olisi Windows drivereissä niin vastaava ongelma esiintyisi myös hyötyohjelmissa ja CPU benchmarkeissa?

Varmasti niissä on parannettavaa sitä en sano, mutta näin mutuna näkisin että ongelma on enemmän pelien tavassa käyttää ytimiä. Kuten aiemmin sanoin, niin ongelma ei pelien suhteen välttämättä ole se että niitä pitäisi optimoida tajuttomasti, mutta ennemminkin se että ne käyttää Ryzeniä samalla tapaa kuin Inteliä ja niille tehdyillä optimoinneilla.

 

[FireFly Renaissance]

Yleensä käyttis erottaa, lähinnä bulldozerin tapauksessa heti julkaisun jälkeen käyttikset eivät erottaneet.

Ja ainakin käyttis tietää sen paljon paremmin kuin peli itse, minkä takia peli helposti antaisi käyttikselle vääränlaisia vihjeitä, jos se yrittäisi alkaa samomaan millä ytimellä se haluaa pyöriä.

Zenin kanssa ongelma on se, että käyttikset eivät osaa mallintaa/laskea tuota hitaampaa/kalliimpaa kommunikaatiohintaa kahden eri CCXn ydinten välillä. Mutta tämähän on oikeastaan päinvastainen ongelma, Zenillä haluttaiisin sijoitella (keskenään kommunikoivat) säikeet samalle CCX:lle eikä hajauttaa niitä useammalle.

Käytännössä järkevä skeduli Zenille 4-säikeiselle pelille olisi sijoittaa pelin 4 säiettä yhden säikeen kaikille ytimille, ja lukita ne sinne, ja jättää toinen CCX kaikille taustaprosesseille. Mutta sitten kuin pelillä on enemmän kuin 4 säiettä, tämä ratkaisu ei enää toimi.

Niin toisaalta, jos taas sitä kommunikaatiota ei ole paljoa on parempi kun ne säikeet on eri CCX:llä ja kaikilla on nopea oma cache. Eli jotenkin se pitäisi sitten saada tuohon skedulointiin mukaan, jos halutaan että se toimii aina optimaalisesti.

 

[hkultala]

Avoimen lähdekoodin ajuri AMD grafiikka kortilla. Samalla ajurilla myös i7-7700K:n framerate putoaa kun siirrytään vulkan rajapintaan. Pudotus on vain paljon pienempi.

Vulkan on hyvin matalan tason rajapinta joten veikkaisin, että tuo ongelma on ihan pelin koodin eikä ajurin koodin puolella; Vulkanilla pelin koodi joutuu tekemään asioita jotka aiemmilla rajapinnoilla oli ajurin vastuulla.

 

[rlame]

AMD Ryzen Performance Negatively Affected by Windows 10 Scheduler Bug


AMD Ryzen Performance Negatively Affected by Windows 10 Scheduler Bug

Peleihin 5-10% lisää kun bugi on korjattu?

 

[Mechanical Man]

Tuostahan ei tosiaan voi tietää yhtään kuinka iso vaikutus sillä on. Saattaa olla suurikin tai sitten täysin olematon. Vaihtelu eri ohjelmien ja pelien välilläkin todennäköisesti suurta.

 

[Taneli-]

Tuostahan ei tosiaan voi tietää yhtään kuinka iso vaikutus sillä on. Saattaa olla suurikin tai sitten täysin olematon. Vaihtelu eri ohjelmien ja pelien välilläkin todennäköisesti suurta.

Testaamalla sen näkee, käytännössähän säikeistys antaa hieman bonusta peleihin (huomaa esim. kun testaa i7 ilman säikeistystä = i5) joten JOS pelissä Ryzenillä saat paremman pelikokemuksen ilman säikeitä kuin säikeiden kanssa => tulet saamaan vielä enempi bonusta kun tuo saadaan korjattua. Tosin osassa peleistä ei tullut mitään eroa joten pelikohtaista (mitä arvosteluista katsellut).

 

[Dygaza]

Säikeistyksenhän voi windowsissa itsekin korjata kun vaa määrittää theadien affinityn itse. Se on vaan vähä turhan vaivalloista.

 

[rlame]

Säikeistyksenhän voi windowsissa itsekin korjata kun vaa määrittää theadien affinityn itse. Se on vaan vähä turhan vaivalloista.

Process hackerin nightly versiossa voi tallentaa affinityn ohjelmakohtaisesti.

Nightly Builds - Process Hacker
(windowsin tehtävienhallinnan kaltainen ohjelma)

 

[Dygaza]

Process hackerin nightly versiossa voi tallentaa affinityn ohjelmakohtaisesti.

Nightly Builds - Process Hacker
(windowsin tehtävienhallinnan kaltainen ohjelma)

Samaa ohjelmaa olen käyttänyt, mutta uudessa versiossa ilmeisesti lisää ominaisuuksia. Tästä varmaan olisi Ryzenin omistajille apua kunnes ongelma korjataan oikeasti. Mitenhän tuo tallentaa kun thread id:t on aina eri jokaisella käynnistyskerralla.

 

[Ryydike]

Hieman offtopiccia : Kuinka monta Ryzen prosessoria AMD on tähän päivään mennessä myynyt?

 

[Jahve3]

Hieman offtopiccia : Kuinka monta Ryzen prosessoria AMD on tähän päivään mennessä myynyt?

Aika paljon, toisin mitää lukemaa ei ole kukaan julkaissut.

 

[mRkukov]

Aika paljon, toisin mitää lukemaa ei ole kukaan julkaissut.

Enemmän kuin emolevyjä on myyty.